Хорошая книжка, советую.

Спасибо всем кто отозвался и помог с поиском книжки в адекватном формате!

Коллеги! может мы тоже устроим флеш-моб по обмену годной литературой? Кидайте в ЛС книги\ссылки ваших любимых изданий, а я потом все это выложу.

apt, шо ко мне приедет?

apt -s upgrade - показать список выполняемых действий, не выполняя их. Выхлоп включает версию старого пакета и нового пакета, что довольно-таки удобно чтобы посмотреть какая версия приедет не набирая apt-cache policy package. (s от слова simulate)

Пример:

Inst openssh-server [1:7.4p1-10+deb9u3] (1:7.4p1-10+deb9u4 Debian-Security:9/stable [amd64]) []
...
Conf openssh-server (1:7.4p1-10+deb9u4 Debian-Security:9/stable [amd64])

#apt

мини-заметка без заголовка
^^^ это не заголовок
(типа пошутил, да)

шобы хранить файлы libreoffice в гите, так чтобы гит не считал их как бинарники (и соответственно на изменение каждой запятой не создавал его клон), можно сменить формат на Flat XML, например fodt, fods.

#git

Gitlab helm stable chart

Gitlab наконец-то зарелизили стабильный chart:

https://about.gitlab.com/2018/08/22/gitlab-11-2-released/#cloud-native-gitlab-helm-chart-generally-available

#gitlab #helm #kubernetes

Копируем файл на N серверов

Бывает необходимость без привлечения каких-либо сторонних средств раскопировать с одного сервера файл на N других. Все что для этого нужно - ssh и разложенные везде ключи.

Однако, есть важное условие - копирование выполняется впервые. Это значит, что сервера не являются доверенными и их fingerprint не занесен в known_hosts. Можно накостылить и отключить проверку, можно воспользоваться сторонними стредствами типа ansible. Если же хочется сделать это быстро и в 2 команды, то я предлагаю такой вариант решения:

1. Логинимся на server1 с ключом -А (про исключительную полезность его я уже писал)
2. Собираем fingerprint со всех серверов, к которым будем подключаться:

for ((i=2;i<100;i++)); do ssh-keyscan server${i}.example.com >> ~/.ssh/known_hosts; done

3. Используя scp\rsync копируем данные

for ((i=2;i<100;i++)); do yes | rsync -avzr --progress /tmp/data server${i}.example.com:/tmp/data; done

Если у вас везде разложены ключи и есть права на запись - больше от вас не потребуется ни одного шевеления пальцем.

Кто подавал данные на заведение CVE через https://iwantacve.org могут с удивлением обнаружить, что заявки помещаются в открытый Google Docs. Причем можно посмотреть как на утвержденные уязвимости (прошедшие модерацию, им присвоили номер), так и на новые заявки.
Забавно получается, CVE еще нет (может и патча), а информация об уязвимости уже доступна ¯\_(ツ)_/¯

Тут пацаны в чате от нефиг делать выснили, что при коннекте по ssh. указывая или не указывая ключ, с которым выполнить авторизацию, в обоих случаях будут перебраны до успеха (или неуспеха) все ключи из .ssh. с единственной разницей, что в случае указания ключа перебор начнется с указанного.

#ssh

Календарь с Паниным в год собаки:)

Bonding и SSH сервер в initramfs
https://goo.gl/gNFFkH

Обновляем Gitlab 10.8 -> 11.x установленный через helm

нужно изменить переменную git_data_dir в templates/configmap.yaml на следующее:

git_data_dirs['default']['path'] = '/gitlab-data/git-data';

Ошибка:

Chef Client finished, 274/445 resources updated in 04 minutes 26 seconds

Deprecations:

Your git_data_dir settings are deprecated.
Please update it to the following:

git_data_dirs({
    "default" => {
        "path" => "/gitlab-data/git-data"
    }
})

Please refer to https://docs.gitlab.com/omnibus/settings/configuration.html#storing-git-data-in-an-alternative-directory for updated documentation.

#helm #kubernetes #gitlab

helm 2.10 released!

Для тех кто им пользуется постоянно наверное это не новость, но для меня, как человека почти 3 недели гонявшего в отпуска это таки новость=)

changelog: https://github.com/helm/helm/releases/tag/v2.10.0

#helm

Три способа посмотреть какой процесс слушает порт

Классический старый, покажет нам название процесса, pid и адрес:

# netstat -ltnp | grep 22

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      17105/sshd          
tcp6       0      0 :::22                   :::*                    LISTEN      17105/sshd          

ss из пакета iproute2, покажет нам название процесса, pid и адрес:

# ss -ltnp | grep 22
LISTEN     0      128          *:22                       *:*                   users:(("sshd",pid=17105,fd=3))
LISTEN     0      128         :::22                      :::*                   users:(("sshd",pid=17105,fd=4))

По сути между теми двумя практически никакой разницы, но есть еще один интересный вариант, который во-первых не требует grep, во-вторых помимо вышеперечисленного покажет еще и пользоваля, от которого запущен процесс:

# lsof -i:22
COMMAND   PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
sshd    17105 root    3u  IPv4 18800598      0t0  TCP *:ssh (LISTEN)
sshd    17105 root    4u  IPv6 18800600      0t0  TCP *:ssh (LISTEN)

Правда, с небольшим условием - первые 2 команды можно выполнять от непривилегированного пользователя, lsof же только от рута. Хотя без рута ss и netstat выдают меньше информации.

#networking

Послать сообщение по tcp\udp когда под рукой вообще нет ничего

echo "123" >/dev/tcp/127.0.0.1/7777

Можно использовать для разных целей, в том числе чтобы протестировать доступность порта, если нет telnet

>/dev/tcp/127.0.0.1/23
bash: connect: Connection refused
bash: /dev/tcp/127.0.0.1/23: Connection refused

#bash_tips_and_tricks

Как поставить vsphere client 6.0 на debian 9

Никак

А если серьезно, то

winetricks в стабильном апстриме с багой. и об этом явно говорит разраб. Я, говорит, пофиксил это в бастере, но тащить в стейбл не буду, нахуя, я вот например ведь ни разу не ставил .net3.5 и вам не советую. Соответственно нужно тащить winetricks не из репозитория.

А так, после этого да, можно поставить спокойно клиент