Учим node.js делать reload

Штатно node.js вообще не умеет работать более чем в 1 поток, это лечится добавлением модуля cluster. Но штатно там нет reload, только restart всего.
Есть модуль pm2, который умеет гораздо больше. В частности, reload:
https://pm2.io/doc/en/runtime/guide/load-balancing/

Ansible: прогнать удаленный файл через шаблонизатор

Если есть некий шаблон, который например поставили из пакета, и нужно заменить в нём переменные, есть 3 варианта
1) самый корявый, через lineinfile, blockinfile или replace
2) Более правильный, через syncronize или fetch выкачиваем локально и прогоняем через template
3) прогоняем in-place через шаблонизатор jinja2, который ставится отдельно на сам хост, и envsubst
https://unix.stackexchange.com/questions/294378/replacing-only-specific-variables-with-envsubst

По 2 будет выглядеть примерно так
- name: Setup kamailio dispatcher, fetch config to ansible host
  fetch:
    src: /etc/kamailio/dispatcher.list.template
    dest: /tmp/{{ ansible_hostname }}.dispatcher.list
    flat: yes

- name: fill it
  template:
    src: /tmp/{{ ansible_hostname }}.dispatcher.list
    dest: /etc/kamailio/dispatcher.list

- name: clean after fetch
  file:
    path: /tmp/{{ ansible_hostname }}.dispatcher.list
    state: absent

(хотя тут еще правильнее завернуть в block и переместить очистку в секцию always:)

Ansible: EPEL in CentOS 7

Если нужно поставить epel в центос 7 то это делается разными путями, например так
https://github.com/geerlingguy/ansible-role-repo-epel/blob/master/tasks/main.yml
(или просто подключаем эту роль, или так, вариантов много...)
можно зайти сюда и взять отсюда ключ например
https://dl.fedoraproject.org/pub/epel/

Но можно гораздо проще.
- name: Install EPEL repo
  yum:
    name: epel-release
    state: latest

Потому что всё нужное в 7 центоси уже есть и так. Бонусом - ставятся еще epel-testing и epel-src

Moby/Docker в продакшене. История провала

2 статьи, почему с докером нужно быть осторожнее. И почему недопустимо пихать базы в докер.
https://habr.com/ru/post/332450/
https://habr.com/ru/post/346430/

Конечно, он не стоит на месте, но общий подход к разработке резко измениться не может (в лучшую сторону как минимум).
Также советую посмотреть на containerd, на него стал переходить тот же Kubernetes

github deploy keys

Работали долгое время с битбакетом, но на другом проекте используют github.
https://developer.github.com/v3/guides/managing-deploy-keys/#deploy-keys
Делаем по инструкции, добавляем ключ для деплоя на одну репу, работает. Добавляем на другую - получаем ошибку
Error: Key already in use

Эти идиоты не осилили 1 деплой ключ на несколько реп! При том что битбакет так умеет, а гитлаб вообще штатно предлагает список уже подключенных ключей, для ещё бОльшего удобства. И это при том что если завести "фейкового" юзера, которому навесить тот же ключ и через запрос invitation выдать доступы то всё работает. Так что это именно рукожопость и ничего более.

Разные варианты гуглятся по "github Error: Key already in use"

5 решений:

1) заводим отдельную почту, письма с которой можно перенаправить админам, регистрируем её в гитхабе, на нужные репы отправляем приглашения, в свойствах добавляем нужный нам ключ. Потом принимаем приглашения, работаем.

2) через ssh-keygen (можно в интерактивном режиме) создаём столько ключей, сколько у нас реп, заводим где-то табличку с публичными ключами и от чего они. Теперь можно заполнить ~/.ssh/config, вписав несколько Host секций с разными IdentityFile, и делать git clone по этим именам,
3) или выставляя переменную - в 2.10+ есть GIT_SSH_COMMAND куда передаем строку вида 'ssh -i ~/.ssh/key1', в более ранних нужно возиться через врапперы и выставлять переменную так: GIT_SSH='~/git_wrapper.sh', в котором будет
ssh -i '~/.ssh/key1' $1 $2
4) ssh_agent
5) сменить площадку на битбакет или гитлаб, где нет этого маразма.

Более развернуто например тут
https://superuser.com/questions/232373/how-to-tell-git-which-private-key-to-use

letsencrypt wildcard

Letsecrypt c 13 марта 2018 года уже умеет wildcard сертификаты, но пока только с верификацией через dns (до сих пор)
https://medium.com/@saurabh6790/generate-wildcard-ssl-certificate-using-lets-encrypt-certbot-273e432794d7

https://blogs.msdn.microsoft.com/mihansen/2018/03/15/creating-wildcard-ssl-certificates-with-lets-encrypt/
https://kostikov.co/pereezzhaem-na-wildcard-sertifikaty-lets-encrypt

UPD
Пример использования с яндексом
https://github.com/actionm/certbot-dns-pddyandex
НО: яндекс можно сказать не работает
https://goodprogrammist.ru/posts/dns-yandex-bag/
Чтобы наверняка сработало, надо ставить ожидание записи несколько часов, можно сутки. Час - работает примерно никогда.

и памятка, строка для генерации по доке выглядит так

./letsencrypt-auto certonly --manual-public-ip-logging-ok --agree-tos --email info@site.com --renew-by-default -d site.com -d *.site.com --manual --manual-auth-hook ../certbot-dns-pddyandex/authenticator.sh --manual-cleanup-hook ../certbot-dns-pddyandex/cleanup.sh --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory

Understanding jinja in salt

https://pastebin.com/ceLS8Lr3

(links only)
#UNDERSTANDING JINJA
https://docs.saltstack.com/en/latest/topics/jinja/index.html#jinja-in-states

#Cool document about how to write TRUE salt states on jinja:
https://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.jinja.html#

#Jinja loading utils to enable a more powerful backend for jinja templates
https://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.jinja.html#module-salt.renderers.jinja

#SLS TEMPLATE VARIABLES REFERENCE (salt, grains, pillars, и т.д.)
https://docs.saltstack.com/en/latest/ref/states/vars.html#sls-template-variable-reference

#Official doc
http://jinja.pocoo.org/docs
http://jinja.pocoo.org/docs/2.10/templates/#builtin-filters

https://docs.saltstack.com/en/latest/topics/jinja/index.html#debugging
Context is: {{ show_full_context()|yaml(False) }}


https://docs.saltstack.com/en/latest/topics/jinja/index.html#logs
{%- do salt.log.error('testing jinja logging') -%}

Пара трюков salt

1)
salt-run git_pillar.update
salt-run fileserver.update
salt-call state.apply

2) Clear cache
почистить на мастере
salt-call saltutil.clear_cache

на миньоне
salt myminion saltutil.clear_cache

3) check state
с мастера
salt myminion state.sls mystate

Быстрое введение в salt

В паре слов.
Это система деплоя софта на python+yaml+jinja (привет ansible), но в отличии от ансамбля предпочтительна установка агента (есть salt-ssh, но говорят с ним не очень). Синтаксис похожий. Общение между нодами через RabbitMQ.

Про установку.
Ставим мастер, на нужные ноды миньонов, снимаем с мастера хэш ключа и пишем в конфиги миньонов, потом с обоих сторон одобряем взаимодействие. Странно выглядит для автоматизированной настройки, да?

(в роли введения в системы деплоя вообще)
Принудительное введение в системы управления конфигурациями

https://habr.com/post/315012/
https://blog.talpor.com/2014/07/saltstack-beginners-tutorial/
https://docs.saltstack.com/en/getstarted/
https://www.youtube.com/watch?v=yWhvgLqgYR0

saltstack restart service
salt.states.service
salt.modules.service
How to restart a systemd service with salt?

Есть там такая чепухня как pillar

SaltStack: использование шаблонов jinja и хранилища pillar для гибкой настройки конфигураций / Хабр
SaltStack: управление произвольным количеством файлов конфигураций / Хабр

Чтение smart в vmware (esxi)

Основной линк
https://www.virten.net/2016/05/determine-tbw-from-ssds-with-s-m-a-r-t-values-in-esxi-smartctl/

Теперь по получению данных
Логинимся на esxi хост под рутом и смотрим список дисков
esxcli storage core device list

хотя можно просто заглянуть в /dev/disks/

И смотрим основные показатели

esxcli storage core device smart get -d naa.[drive]

Может быть ошибка

esxcli storage core device smart get naa.5000c5007a4df6b6

Error: Unknown command or namespace storage core device smart get naa.5000c5007a4df6b6

Скорее всего, это невозможность получить данные с PERC H730

Переводим “naa.” (ESXi) в “Sas Address” (iDRAC) (например чтобы найти проблемный диск в сервере)

http://vsebastian.net/vmware-en/check-physical-disk-bay-using-naa-identifier-in-esxi/

CentOS7: монтируем ufs разделы

После переезда с фряхи на центос бывает необходимость получить доступ к старым данным, варианты там - zfs и ufs. Рассмотрим случай под ufs
Под центос 6 в elrepo была сборка dkms-ufs, но под 7 версию её уже нет. Увы, SRPM от 6 тоже недоступно, нужно собрать самим.

Работа с контроллерами на базе LSi

https://serverfault.com/questions/589070/how-to-monitor-the-hard-disk-status-behind-dell-perc-h710-raid-controller-with-c

Во фре есть очень удобная утилита mfiutil, увы но тут её нет.

Вариант первый, для мазохистов (или у кого уже были скрипты): MegaCLI. Аццкая хрень, придуманная то ли индусами, то ли инопланетянами. В общем, это дерьмо работает, хоть и не обойтись без помощи гугла.

http://blog.ispsystem.info/2017/04/megacli-centos-7.html

И чуть о вариантах запуска
получить информацию о контроллере
megacli -AdpAllInfo -aAll

Информация по дискам

megacli  -PDList -aALL

Вариант второй, omreport и подобное
http://linux.dell.com/repo/hardware/omsa.html

Вариант третий, говорят сами инженеры lsi поняли какое говно они сделали и добавили поддержку storcli

В случае c Dell есть нюанс, просто добавить группу дисков через iDRAC невозможно без перезагрузки, при том что megacli это умеет, как и сам контроллер. Но что ещё хуже, порой даже ребут не поможет, добавляем группу дисков, ребутаемся, а задача так и висит в Queue Job. И ещё добавим трагедии, гуглинг показывает что иногда для очистки queue job не помогает даже выключение по питанию, сбросу конфгигурации контроллера итд. Так что желательно поставить ещё perccli
https://www.dell.com/support/home/us/en/04/drivers/driversdetails?driverid=f48c2

git clone: github+2FA

Суть в том, что при использовании https после ввода пароля (правильного) будет ошибка

remote: Invalid username or password.

Причина:

https://help.github.com/articles/accessing-github-using-two-factor-authentication/#authenticating-on-the-command-line-using-https

"After you've enabled 2FA, you must create a personal access token to use as a password when authenticating to GitHub on the command line using HTTPS URLs."

Ну или более простой вариант - добавить ssh ключ

https://github.com/settings/keys

и потом делать git clone git@github.com:/user/repo

debian: php5 + apache2-mpm-worker

Суть в том, что это не работает.
https://serverfault.com/questions/772298/configuring-apache2-mpm-worker-with-php5

Ubuntu's PHP5 module will only work with the single-threaded mpm_prefork. In order to use the Apache module with the threaded mpm_worker, you will need to compile a threadsafe version of PHP yourself (which requires disabling all of the features and modules of PHP that are not threadsafe, which are a lot of them).

Instead of using libapache2-mod-php5 you should consider using FastCGI/php-fpm. There is a guide to the steps needed to install and configure libapache2-mod-fastcgi and php5-fpm here: https://askubuntu.com/a/527227 Part of configuring FPM is to create "pools" of php processes, each of which have their own limits and INI files, so you will need to be sure that the limits in FPM are reasonable for your site's expected load.

This arrangement will allow you to use the multi-threaded worker MPM in Apache while handing off the PHP requests to individual PHP processes handling a single request each.

Mint: "Could not display "network:/// Nautilus cannot handle "network" locations "

По какой-то причине штатно не ставится gvfs-backends
фикс:
sudo apt-get install gvfs-backends

вероятно, актуально для всех debian и ubuntu дистрибутивов.