who am i && whoami

первый скажет вам кто вы есть на самом деле, а второй - кто вы есть сейчас. Это значит, что пользователь, выполнивший команду sudo su через whoami увидит root, а через who am i - кто же он есть на самом деле - его username.

Изменяем размер образа в ceph и применяем в k8s

1. Выяснить название image:

kubectl -n NAMESPACE get pv PV_NAME -o jsonpath="{.spec.rbd.image}"

2. выполнять с хоста, с которого настроен доступ к rbd. IMAGE_NAME взять из предыдущего шага.

export IMAGE_NAME=<image_name>
export SIZE=<size, ex. 20G>

посмотреть информацию по image

rbd info $IMAGE_NAME

выполнить изменение размера:

rbd resize $IMAGE_NAME --size $SIZE

посмотреть результат

rbd info $IMAGE_NAME

3. выяснить на какой ноде запущен под (соответственно куда смонтировано блочное устройство)

kubectl -n NAMESPACE get po -o wide

4. выполнить на ноде, полученной на предыдущем шаге

получаем номер путь к блочному устройству

mount | grep IMAGE_NAME | awk '{print $1}'
# результат: /dev/rbd0

проверяем размер фс в поде:

docker ps | grep POD_NAME
docker exec -ti CONTAINER_ID df -h | grep rbd

выполняем изменение размера:

resize2fs /dev/rbd0

проверяем результат:

docker exec -ti CONTAINER_ID df -h | grep rbd

З.Ы. тут написано без какой либо конкретики - просто направление того как с этим работать, поскольку методы получения нужной информации для ключевых шагов (имя образа, пода, rbd, ноды...) может отличаться от системы к системе. А уж проверять финальные результаты можно еще как минимум двумя способами. Строго говоря k8s тут вообще не причем =)

#kubernetes #ceph #rbd

вчера ночью боролся с set_fact в ansible. присваиваю переменной значение, а при обращении к переменной она undefined. Проблема крылась в пробелах слева и справа от знака равно. Убрал пробелы и все стало чётенько...

#ansible #troubleshooting #yaml

Информация о релизе Debian

lsb_release -cs

Простой и быстрый способ узнать название релиза в Debian.

cat /etc/os-release

Детальная информация о релизе Debian.

#os #linux

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

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

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

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