Рубрика: Uncategorized

Запуск nodejs через systemd

Posted on by

Приложения nodejs собираются обычно на коленке и для них нет стандартного способа запуска как демон. Наиболее короткий и корректный способ сделать это сейчас — через systemd. Для этого создаем свежий конфиг в /etc/systemd/system/, называем по имени приложения, например /etc/systemd/system/myapp.service с содержимым:

[Service]
WorkingDirectory=/opt/myapp/
ExecStart=/usr/bin/node /opt/myapp/app.js
Restart=always
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=myapp
User=igogoo
Group=igogoo
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target

Обычно в /etc кладутся не сами конфиги, а симлинки на действительные конфиги в /lib/systemd/system/, но поскольку наш демон кастомный, а директория /etc бэкапится полностью, создадим его прямо здесь.
Далее релодим конфигурацию и включаем демона на автостарт

systemctl daemon-reload
systemctl enable node-app.service

Теперь возможны стандартные операции вроде

systemctl start myapp
systemctl stop myapp
systemctl restart myapp
systemctl status node-app.service

Перезапускаем виртуалку, проверяем, что всё работает. Готово.

Обновление с небезопасного репозитария

Posted on by

Иногда нужно поставить какой-нибудь старый или просто сторонний софт с «левых» репозитариев. Для этого apt настойчиво требует добавить в систему открытые части ключей для сверки подписей, что делать не всегда нецелесообразно. Но в последних версиях дебиановцы очень «позаботились» о пользователях и просто не позволяют качать софт и даже вообще получать его списки с левых репозитариев, что уже совсем негоже. Да, небезопасно. Да, в общем случае не правильно. Но не разрабам дистра решать как действовать в той или иной ситуации. К сожалению, приходиться обходить это отмычкой, невольно вспоминая что-то похожее в Windows стародавних версий.

Отмычка такая. Добавляем кастомный конфиг /etc/apt/apt.conf.d/99custom такого содержания:

Acquire::Check-Valid-Until "false";
Acquire::AllowInsecureRepositories "true";
Acquire::AllowDowngradeToInsecureRepositories "true";

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

Дебиановские установочные образы non-free firmware

Posted on by

Иногда возникает необходимость скачать несвежий устанвщик дебиана с версией несвободных пакетов. Свежий постоянно располагается по ссылке:
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current/amd64/iso-cd/

А «несвежий» можно загрузить по ссылке из из архива:
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/archive/

SSLError: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol

Posted on by

В новом дебиане при попытке законнектиться к очень старым сайтам из питона (и не только) периодически вылезает ошибка «SSLError: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol». Вылезает она из-за отсутствия поддержки более-менее современных протоколов серверами с теми сайтами. Работать с этими сайтами надо, а повлиять никак, поэтому единственный доступный выход — это обойти ограничение. На глобальном уровне это делается правкой секции в /etc/ssl/openssl.cnf:

[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=1

на

[system_default_sect]
MinProtocol = None
CipherString = DEFAULT

Серьезный недостаток такого «чита» это общее снижение безопасности системы, т.к. приложениям теперь глобально разрешается выходить по старым протоколам. Но это можно локализовать используя чит только в виртуалке на старые сайты.

Обновления security для Debian

Posted on by

Часто возникает необходимость обновить систему только из security-репозитариев, так чтобы поправить критичные уязвимости, но в тоже время не затронуть основную часть софта, обновление которого может потребовать дополнительного тестирования всей системы. Одним из способов удобного обновления пакетов только из security-репозитариев является явное указание списка источников, из которых брать пакеты.

На практике это работает следующим образом. Обычно security-ветки уже есть в /etc/apt/sources.list. Мы на основе его создадим отдельный файл, в который поместим только ветки безопасности:

cd /etc/apt
cp sources.list sources.list.d/security.list

Далее из первого файла удалим security-источники, а во втором только их и оставим. Если в исходном файле нет security-источников совсем, тогда просто добавляем их в новый файл /etc/apt/sources.list.d/security.list. Нужны будут security-ветки для нужных репозитариев, обычно это stable.

Далее можно обновлять пакеты или все или из только из списка безопасности. В последнем случае это делается так:

apt-get update
apt-get upgrade -o Dir::Etc::SourceList=/etc/apt/conf.d/security.list

Таким образом можно своевременно фиксить критичные уязвимости, но при этом не рисковать обновлением всего ПО.

Управление supervisorctl без рутовых прав

Posted on by

Для разных самописных процессов, которые нужно запускать как демон, есть прекрасный инструмент supervisor. Управление запуском процесса в нём происходит с помощью конфигов предельно простого синтаксиса (и в тоже время покрывающих почти все необходимости) в /etc/supervisor.d/ и команд наподобие:

supervisorctl start myapp
supervisorctl stop myapp
supervisorctl restart myapp

т.е. интерфейс полностью аналогичный управлению демонами в ОС.

Во многих случаях процесс, который запускают как демон, запускается от непривелигерованного пользователя. И от этого же пользователя работают реальные пользователи/разработчики, которым может понадобится управление демоном. Стандартный способ сделать это — через sudo:

sudo supervisorctl restart myapp

Но если это виртуальная машина, в которой supervisor нужен именно для приложений от этого пользователя, то можно сделать и в обход root совсем. Для этого необходимо поправить в /etc/supervisor/supervisord.conf:

[unix_http_server]
file=/var/run/supervisor.sock
chmod=0770
chown=someuser:someuser

После этого supervisor будет управляться из под пользователя. У способа есть недостаток, что теперь supervisor заточен на приложения этого пользователя/группы, но часто это не является препятствием.

Ускорение raid5 md-массивов на запись

Posted on by

RAID5/6-массивы дисков — типичное решение для файловых архивов, к которым много запросов на чтение и мало на запись. Их слабое место: медленные операции записи, в которых для расчёта контрольной суммы требуется чтение со всех томов данных массива. Это приводит не только к медленной записи на массив новых данных, но и к медленному исполнению всех операций предполагающих модификацию раздела, в частности операции удаления. А если ещё и используется дешёвый вариант рейда на основе mdadm, без всяких батареек, кешей и специализированного софта для рейдов, то удаление большого количества файлов становится ну оочень медленной задачей.

Отчасти это можно исправить. raid5 при записи много читает, читает даже больше чем пишет. При удалении модифицируемые данные это структуры затрагиваемых файлов и директорий, в общем-то небольшого количества данных, но изменяемых многократно. Учитывая, что XFS (и другие устойчивые файловые системы тоже) делают это безопасно для отключения питания, т.е. собственно коммитом и через журнал. Поэтому, хороший прирост скорости удаления даёт изменение кеша чтения mdadm:

    echo 16384 > /sys/block/md?/md/stripe_cache_size

Параметр stripe_cache_size по умолчанию имеет значение 256 (страниц по 4Kb), что в большинстве случаев достаточно мало. Максимальное значение — 32768, при этом скорость достаточно хорошая уже при значениях 8192-16384. При увеличении параметра надо учитывать, что это значение в страницах для каждого устройства в рейде и он в результате может занимать весомую часть ОЗУ. Тем не менее, даже если ОЗУ не много, увеличение чаще имеет смысл.

Кроме этого способа, можно увеличить производительность вынесением журнала на отдельный раздел (и тогда раздел данных становится несколько зависимым от другого) или включением разных опций вроде nobarrier, которые сделают ФС быстрой но потенциально нерабочей в случае отключения питания. Это скорее не для продакшн-систем.

Поддомены по маске в CORS

Posted on by

В веб-проектах в последнее время всё активнее и активнее используется размещение разного контента по разным поддоменам. Например, типична ситуация, когда статические файлы размещают на отдельных поддоменах для работы с CDN или использование поддоменов для разных языковых версий сайта, или же для разных географических локаций. Основная часть ресурсов обычно едина для всех отдельных сайтов, как правило это картинки css/js и прочая статика. Чтобы кросс-запросы между поддоменами корректно принимались браузером в плане безопасности, необходимо настроить для CORS заголовки в ответе веб-сервера.

Домены с которых разрешено загружать контент указываются на ресурсе-источнике в заголовке Access-Control-Allow-Origin. В нём можно перечислить явно домены, с которых можно запрашивать контент, или разрешить со всех астериском ‘*’. К сожалению, разрешить поддомены по маске, например *.example.com, простым укаазанием этой маски в заголовке не удастся. Т.е. можно разрешить или всё или перечислять все домены. Что делать если этих доменов много или их неопределённый список и логичнее включить доступ по маске?

В случае использования Nginx как фронтэнда возможно решение, когда необходимый заголовок формируется в зависимости от источника запроса. То есть, будем отдавать разрешающий заголовок только если запрос приходит именно с наших поддоменов. Код для реализации этой идеи получается такой:

  set $cors "";
  if ($http_origin ~* (\.example\.com|\.example\.ru)) {
      set $cors "true";
  }

  if ($cors = "true") {
    add_header 'Access-Control-Allow-Origin' "$http_origin";
    add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, OPTIONS, DELETE';
    add_header 'Access-Control-Allow-Credentials' 'true';
    add_header 'Access-Control-Allow-Headers' 'User-Agent,Keep-Alive,Content-Type';
  }

  proxy_pass http://backend:8080/;

Его целесообразно вынести в отдельный snippet и включать в те location, с которых берёрется контент для остальных поддоменов. При этом мы не затрагиваем бэкэнд, что экономит производительность.

libmariadbclient18 perl

Posted on by

После обновления MariaDB до версии 10.2 в debian-дистрибутивах в perl-приложениях возникает ошибка

install_driver(mysql) failed: Can't load '/usr/lib/x86_64-linux-gnu/perl5/5.24/auto/DBD/mysql/mysql.so' for module DBD::mysql: /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18: version `libmariadbclient_18' not found (required by /usr/lib/x86_64-linux-gnu/perl5/5.24/auto/DBD/mysql/mysql.so) at /usr/lib/x86_64-linux-gnu/perl/5.24/DynaLoader.pm line 187

Оказывается, это баг MariaDB, о котором можно прочитать в соответствующей статье, в ней же есть и решение. Практическое решение это откат библиотеки libmariadbclient18 до предыдущей версии, в которой она слинкована правильно. При использовании apt/apt-get и официальных репозитариев Марии для этого нужно добавить в файлик /etc/apt/preferences строки

Package: *
Pin: release o=MariaDB,n=stretch
Pin-Priority: 1001

Package: libmariadbclient18
Pin: release o=Debian,n=stretch
Pin-Priority: 1002

и после этого даунгрейдить libmariadbclient18.

PS: Ошибка точно затрагивает мониторинг параметров mysql от Munin, поэтому если «потерялись» графики базы после обновлениях, то причиной является наверняка та, что описана выше.

Port forward to another server

Posted on by

При переезде сайтов или другого постоянно используемого извне ресурса возникает потребность его доступности как со старого, так и с нового местоположения, пока по сети распространяются новые записи DNS. Сделать это без нарушения целостности данных можно с помощью перенаправления порта. Например, если на NEW_IP_ADDR поднят https-сервер, все актуальные данные уже на нём, то на время переключения DNS редиректить со старого адреса на новый можно так:

iptables -P FORWARD ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -F
iptables -X
iptables -F -t nat
iptables -X -t nat

iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination NEW_IP_ADDR:443
iptables -t nat -A POSTROUTING -j MASQUERADE

Этот же способ помогает зеркалировать нужные на другом сервере.

perl5 unescaped left brace deprecated

Posted on by

После частичного обновления дебиановского софта где-то между jessie и stretch при установке пакетов начинает возникать ошибка.

Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/^(.*?)(\\)?\${ <-- HERE ([^{}]+)}(.*)$/ at /usr/share/perl5/Debconf/Question.pm line 72.
Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ([^}]+)}/ at /usr/share/perl5/Debconf/Config.pm line 30.

Она неопасна, однако, несколько достаёт. Исправляется обновлением debconf до последней версии используемого релиза:

apt-get update
apt-get install debconf

Быстрая установка VNC на Debian Jessie

Posted on by

Иногда на Linux бывает полезна графическая оболочка, причём в режиме удалённого доступа. Подключение к графике удалённо типично производят с помощью VNC. Рассмотрим простую настройку VNC-сервера на Debian Jessie для эпизодических графических сессий.

В качестве сервера будем использовать tightvncserver, в качестве рабочего стола XFCE. Для начала ставим необходимый софт

apt-get install xfce4 xfce4-goodies gnome-icon-theme tightvncserver

Стартуем VNC

$ vncserver

при первом старте (в случае пустой директории с конфигурацией ~/.vnc) он запросит пароль на соединение и создаст конфигурацию. В конце скрипта ~/.vnc/xstartup добавляем запуск XFCE4

xfce4-session &

Завершить VNC-сервер можно 

$ vncserver -kill :1

и это имеет смысл сделать для последующей настройки.

Проверяем, что VNC-сервер запускается и корректно работает. Для этого его запускаем

$ vncserver -geometry 1024x600

проверяем, что соответствующий процесс действительно слушает 5901 порт

netstat -tpan | grep :59

и подключаемся к нему. В случае успеха мы увидим рабочий стол созданной сессии.

Вышеперечисленные операции старта-остановки целесообразно несколько автоматизировать. Для этого создаем скрипт по аналогу демоновских скриптов из /etc/init.d/ с содержанием вроде:

#!/bin/bash
PATH="$PATH:/usr/bin/"
DISPLAY="1"
DEPTH="16"
GEOMETRY="1280x1024"
#GEOMETRY="1024x768"
OPTIONS="-depth ${DEPTH} -geometry ${GEOMETRY} :${DISPLAY}"

case "$1" in
start)
/usr/bin/vncserver ${OPTIONS}
;;

stop)
/usr/bin/vncserver -kill :${DISPLAY}
;;

restart)
$0 stop
$0 start
;;
esac
exit 0

и помещаем его в директорию локальных скриптов /usr/local/bin/mvnc.

Тогда VNC-сервером можно управлять командами, полностью по аналогии с демонами:

mvnc start
mvnc stop
mvnc restart

Делать это можно из под простого пользователя, что в случае простой конфигурации вполне достаточно. При желании можно сделать более сложный init.d-скрипт и поместить его в /etc/init.d/ в автостарт, но это не всегда нужно, если VNC используется эпизодически.

Windows GodMode

Posted on by

В Windows версий выше 6.0 есть отличный способ получить доступ к огромному списку настроек из одного окна. Для этого создаем папку с именем

GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}

Часть названия до точки может быть любой, а после точки — это GUID соответствующей фичи. После создания «папки» у неё меняется иконка и она ведёт в очень удобную управлялку.

Причём этот способ не является каким-то волшебством, его механизм описан очень давно. Похожим образом можно создать «ярлык» для многих других управлялок, что подробно описано в справке Майкрософта. Интересно, что в этой справке нет GUID для вышеупомянутой панели, несмотря на то, что она даже успела засветиться в Википедии.

Смена кодировки файлов в utf8

Posted on by

В поддержке legacy-кода и обновлении скритов нередко возникает задача их перекодирования в utf-8. Это хорошо выполняется стандарной утилитой iconv, вот её использование для одного файла:

iconv -f cp1251 -t utf8 orig-in-cp1251.php -o out-in-utf8.php

При этом не удастся указать одинаковое входное и выходное названия: iconv начнёт писать до получения входа и получится файл нулевой длины. В этом случае станартный вывод полезно «замочить в губке» с помощью sponge. Сделаем однострочный скрипт, который делает всё сразу, он понадобится далее (назовём его to-utf8.sh):

#!/bin/sh
/usr/bin/iconv -f cp1251 -t utf8 "$1" | sponge "$1"

В качестве единственного аргумента он берет имя файла и рекодит его полностью.

Обычно требуется сконвертить все файлы определённого расширения в целой директории. Подключаем ещё find:

find /here-is-my-files/ -type f -iname "*.js" -exec to-utf8.sh "{}" \;

На часть файлов iconv может ругнуться в STDERR и эти файлы целесообразно проверить/перекодировать вручную.

Ещё более сложный (и достаточно частый) случай, когда есть файлы в разных кодировках и их необходимо перевести в одну. iconv в этом случае может сконвертировать ещё раз и испортить файл. То есть, нужно распознать исходную кодировку и рекодить только «не те» файлы.

Тогда помогает самый лучший вариант: утилиты enca/enconv. Из них первая только распознаёт кодировку, а вторая ещё и перекодирует.Интерфейс enconv до безобразия простой: в случае одного параметра она перекодирует файл из исходной (ЛЮБОЙ распознанной!) кодировки в ту, что указана в locale. Кодировку можно указать явно, тогда вся задача решается одной строкой

find /here-is-my-files/ -type f -iname "*.js" -exec enca "{}" \;

Для улучшения точности язык также можно «подсказать», с помощью параметра (-L ru).

Последний, enca-способ, похоже самый оптимальный для большинства задач.

Вырезание заголовков в exim4

Posted on by

exim4 — отличный почтовый сервер для исходящей почты. По умолчанию он сохраняет заголовки полностью и добавляет ещё свои. В большинстве случаев эти заголвки делают письмо излишне информативным для получателя и этого желательно избежать.

Первое, что стоит сделать в типовой конфигурации сервера — скрыть внутреннюю структуру сети в отправляемых сообщениях, поскольку exim оставляет в заголовках оригинального отправителя. В типичном случае получатель увидит примерно следующее:

Received: from srv12 ([10.0.0.12])
	by mymail.example.com with esmtp (Exim 4.84)
	(envelope-from )
	id 1cPEo3-0003N7-Jj
	for user@example.com; Thu, 05 Jan 2013 20:38:39 +0000

или следующее

x-originating-ip: [10.54.14.36]

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

Если письмо генерируется автоматически, некоторые интерпретаторы по умолчанию добавляют информацию о себе и о запускаемом скрипте. В частности, этим отличается PHP:

X-PHP-Originating-Script: 0:myscript.php

Поэтому, также вырезаем заголовок X-PHP-Originating-Script.

Если же почтовый сервер обслуживает офис, то из заголовков можно узнать используемый почтовый клиент. Например,

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0)
 Gecko/20100101 Thunderbird/45.5.1

или

X-Mailer: Microsoft Outlook 14.0

Обычно, эта информация вполне безопасна. Информацию о клиенте оставляют многие публичные почтовые сервисы. Однако, её тоже не всегда имеет смысл раскрывать. Особенно, если это веб-клиент или внутренняя CRM. Таким образом, можно ещё срезать заголовок User-Agent.

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

system_filter = /etc/exim4/filter

А в самом /etc/exim4/filter прописать вырезаемые заголовки. Например:

headers remove X-PHP-Originating-Script
headers remove Received

После этой доработки, количество заголовков заметно уменьшается и излишняя информация не раскрывается. Естественно, это происходит с сохранением DKIM-подписи (подписывает сервер), поскольку заголовки вырезаются до её формирования.

Копирование с сохранением жёстких ссылок

Posted on by

Ранее я описывал отличную схему инкрементных резервных копий, основанную на использовании жёстких ссылок. Схема позволяет хорошо сохранять место на разделе для бэкапов и на уровне приложений резервные копии видны полностью. Обратной стороной такого удобства является сложность переноса таких бэкапов с одного раздел на другой в случаях, когда это потребуется, например, при физической смене жёстких дисков или рейда для резервирования. Стандартные утилиты вроде cp воспринимают всю директорию с бэкапами как «нормальную» директорию и копируют полностью, что в результате даёт копию большого, примерно n*[размер одного бэкапа] размера. Кроме объёма, такое копирование занимает огромное количество времени.

Как скопировать быстро и сохранением симлинков? Задача, оказывается, хорошо решается всё той же проверенной утилитой rsync, которая может работать как локально, так и удалённо. При запуске ее с ключами:

rsync -aH /src-path /dst-path

она выполняет в точности, что и требуется.

Наиболее оптимальным набором параметров для локальных копий показал себя следующий

rsync -aH --delete --numeric-ids /src-path /dst-path

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

Естественно, утилита может копировать и по сети, что делает способ ещё более удобным, особенно со сжатием (-z).

Копирование пользователей и прав MySQL

Posted on by

В ряде случаев бывает необходимо скопировать пользователей и их права (привилегии) на другой сервер БД. Типичная ситуация, когда это требуется — подготовка чистого сервера БД в качестве реплики, при этом пользователи берутся с мастера. Гугл предлагает готовым решением Percona Toolkit, однако, это дополнительно устанавливаемый софт, попробуем обойтись без него. Для этого скрипт, который вытягивает пользователей из базы-источника и формирует sql-файл для импорта.

#!/bin/sh
mysql -e"SELECT DISTINCT CONCAT('SHOW GRANTS FOR ', '\'', user, '\'@\'', host, '\';') AS QUERY FROM mysql.user" | sed '1d' | while read query; do
	mysql -e"$query" | sed '1d' | awk '{print $0";"}'
done
echo -e "FLUSH PRIVILEGES;\n";

На выходе получится sql-код для исполнения на слейве. Естественно, по файлу стоит пройтись вручную и удалить пользователей, которых добавлять не надо.

Confluence + nginx

Posted on by

Стандартная установка Atlassian Confluence вешает его по умолчанию на 8090 http-порт. Софтину в целях совместимости и безопасности целесообразно ставить в виртуалку и обращаться к ней по http, при этом сама виртуалка может находится в недоступной извне локальной сети. Поэтому, возникает задача проксировать траффик 8090 порта конфлюенса вовне. Ниже описывается, как это меньшими средствами сделать с помощью nginx.

В документации Atlassian рассматривается вариант проксирования траффика, в том числе энжинксом. Предлагаемый в документации способ предполагает правки в xml-конфиге самого Confluence, что есть не лучшее решение. Можно обойтись настройкой только nginx, без правок оригинального конфига конфлюенса, что обычно намного разумнее. Вот пример проксирования:

	location / {
		proxy_set_header X-Forwarded-Host $host;
		proxy_set_header X-Forwarded-Server $host;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $remote_addr;
		port_in_redirect off;
		proxy_pass http://confluence-vhost:8090;
		proxy_redirect http://confluence-vhost:8090/ /;
		proxy_connect_timeout 600;
		#proxy_redirect off;
	}

Аналогичным способом можно завернуть траффик в SSL и отдавать его через https, что существенно повышает безопасность работы.

/etc/network/if-up.d/ в CentOS

Posted on by

На Debian-based операционках есть очень удобная директория /etc/network/if-up.d/, в которой находятся скрипты, запускаемые системой при интерфейса. В CentOS и других RHEL-based системах подход директорий conf.d не такой популярный и запуск скриптов после поднятия интерфейса реализован по другом. А именно, внимательным глазом в конце скрипта /etc/sysconfig/network-scripts/ifup-post можно обнаружить строки:

if [ -x /sbin/ifup-local ]; then
     /sbin/ifup-local ${DEVICE}
fi

Таким образом, если создать файл /sbin/ifup-local, в него можно прописать собственный firewall или что-то иное, необходимое в сети. Можно (и обычно удобнее) пойти и дальше, и запускать из этого скрипта готовые стандартные скрипты:

test -x /usr/local/bin/fw && /usr/local/bin/fw
test -x /usr/local/bin/fw6 && /usr/local/bin/fw6

Так можно реализовать в центе модульность, которой изначально нет.

Загрузка на разваленном mdadm-RAID массиве

Posted on by

Типичным решением для создания отказоустойчивых систем является установка корня Linux на зеркальный RAID. Это решение позволяет защитить как данные на корневом разделе, так и возможность загрузки в случае отказа одного из дисков.

В случае использования для этой цели mdadm настройка массива производится ещё при установке. К сожалению, установщик Debian ставит загрузчик grub только на первый (hd0) из физических дисков, второй при этом остается незагрузочных (хотя и зеркалирует данные). Если разметка диска делается через GPT, то стандартная команда grub-install /dev/sdb хотя и прописывает загрузчик на второй диск, но загрузочным разделом все равно указывает hd0, а значит система без hd0 не грузится и задача резервирования загрузчика проваливается.

Для резервирования нужно на каждом из физических дисков прописать в качестве загрузочного раздела — раздел с того же физического диска. Штатным путем в grub-install указать загрузочный раздел не получается, но можно пойти следующим обходным путем. Изначально по установке ОС имеет корректный загрузчик на /dev/sda (hd0), и этот загрузчик указывает на тот же hd0. Сделаем то же для sdb. Это можно сделать «обманув» grub-install. А именно:

  1. Создаем с помощью grub-mkdevicemap файл /boot/grub/device.map.
  2. Подменяем в device.map диски (hd0) и (hd1) местами так, чтобы (hd0) теперь указывал на /dev/sdb.
  3. Делаем grub-install /dev/sdb.
  4. Удаляем device.map (или, в качестве альтернативы, прописываем в нем (hd0) на оба диска sda и sdb).

Всё! В результате при отказе любого из загрузочных sda или sdb система загрузится с массивом в degraded-режиме, но полностью сохранит работоспособность.