Сетевые /и не только/ заметки

Как обычно, вначале ничто не предвещало беды.
Был раскатан свежий OVZ контейнер с CentOS 7 на борту, после чего обновлен до актуального состояния.
Добавлены пару сетевых интерфейсов и установлены Apache HTTP server и nginx, которые в свою очередь были развешены на IPv4 адреса.
Беда пришла откуда не ждали - после перезагрузки контейнера оба веб-сервера не поднялись с симптомами "Cannot assign requested address". При рестарте же руками - все поднималось без каких-либо ошибок.
Причины сего безобразия достаточно просты - network.target сообщал что он ок, но при этом на сетевые интерфейсы адреса еще не были развешены.
Лечение же этой беды до ужаса простое, надо просто подождать пока сеть поднимется до конца, а уже потом стартовать веб-сервера. Т.е. просто нужно повесить зависимость на немного другой таргет - network-online.target.
Итоговые сервисы для systemd выглядят так:
nginx.service:
[Unit]
Description=nginx - high performance web server
Documentation=http://nginx.org/en/docs/
After=network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target
[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf
ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true
[Install]
WantedBy=multi-user.target

httpd.service:
[Unit]
Description=The Apache HTTP Server
After=network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target
[Service]
Type=notify
EnvironmentFile=/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
ExecStop=/bin/kill -WINCH ${MAINPID}
KillSignal=SIGCONT
PrivateTmp=true
[Install]
WantedBy=multi-user.target

С подобной проблемой сталкивались ребята из Parallels Odin Plesk, почитать про это можно у них на форуме или тех. центре

В один из моих шаблонов OpenVZ коварно пробрался tmpfs для /tmp
И все бы ничего - контейнеры на данном шаблоне разворачивались не одну сотню раз, но в тот вечер мне пришлось разворачивать приложение, которое уж больно полюбило писать в /tmp.
При этом, данное приложение настолько молодцом, что при падении с exception "no left space on device" оно вычищало все свои временные файлы. На расследование инцидента ушло около часа.
Из этого всего получаем 2 простых вывода:
1. Мониторим всё и вся. Все необходимое должно уже лежать внутри шаблона и подключаться к серверу мониторинга при старте контейнера. Даже если разворачиваем "на посмотреть" или "только один разик - дернуть данные и погасить"
2. Tmpfs коварная файловая система которая переполняется в самый неподходящий момент. Ей не место в шаблонах у меня

Сборник подсказок про все: http://overapi.com/

Обсуждение: http://forum.proxmox.com/threads/9003-something-like-quot-vzctl-exec-quot-via-API
Патч: http://pastebin.com/Yj09XELp
Пример использования:
pve:/> create /nodes/{node}/openvz/{vmid}/exec2 -execcmd 'ip a'

Все действия последовательно (обновление до актуальной версии можно пропустить)
# cd /var/lib/vz/template/cache
# mkdir /tmp/workspace
# cd /tmp/workspace
# wget http://download.openvz.org/template/precreated/contrib/altlinux-p7-ovz-generic-20150612-i586.tar.xz
# tar -x --xz -f altlinux-p7-ovz-generic-20150612-i586.tar.xz
# rm altlinux-p7-ovz-generic-20150612-i586.tar.xz
# chroot .
# apt-get update && apt-get dist-upgrade -y
# apt-get clean
# exit
# > ./root/.bash_history
# tar -c --gz -f altlinux-p7-ovz-generic-20150612-i586.tar.gz .

Символы переноса строк ^M можно получить в консоли набрав комбинацию на клавиатуре: ctrl + V + ctrl + M (ctrl + V +M)
Удалить с помощью sed
# sed 's/'"$(printf '\015')"'$//g' file1 > file2

В связи с релизом nginx 1.9.0, в котором была добавлена возможность балансировки любых приложений работающих через TCP, материал данной статьи справедлив не только к веб ресурсам, но и к любым другим работающим поверх TCP (СУБД, системам аутентификации, каталогам LDAP, VoIP-системам и т.п.).

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

Предыстория: Как-то ко мне обратились со следующим вопросом: Программа использующая в качестве СУБД MS SQL Server не видит одну из баз, причем в Management Studio база видна и данные в ней есть.

Попытка просто расставить необходимые права к ожидаемому результату не привела - при попытке установить права возникла ошибка:

Create failed for User '*'. (Microsoft.SqlServer.Smo)
User, group, or role '*' already exists in the current database. (Microsoft SQL Server, Error: 15023)

По роду занятий, мне периодически приходится сталкиваться с резервным копированием (и восстановлением) различных данных. Многие программные инструменты (например СУБД) имеют собственные механизмы создания бэкапов, но зачастую они ограничены и не достаточно гибкие.