shurshur

По поводу этого лучше всего начать с LARTC HOWTO.

Если кратко, маршрутищация в iproute2 устроена так. Есть несколько таблиц маршрутизации, из которых 3 есть всегда (local, main, default), но можно создать ещё. По правилам (команда ip rule) перебираются таблицы, подходящие под условия, в соответствии с приоритетами (preference, первое число в выводе команды). И в каждой таблице есть свои маршруты. Таблицу local изменять нельзя и перед ней ничего маршрутизировать нельзя (это можно обойти через nat в PREROUTING, но это уже другой вопрос).

Самый простой вариант - это source routing. Впервые мне это понадобилось, когда я подключил дома второго провайдера с внешним IP, и мне потребовалось отвечать с обоих внешних адресов со всего интернета. Делается так:

1. В /etc/iproute/rt_tables описываем псевдонимы для новых таблиц (необязательно - можно использовать числовые идентификаторы - но так удобнее). Например, 10 - isp1, 20 - isp2.

2. Задаём правила, которые приведут к выбору таблицы в зависимости от source address:

ip rule add pref 10 from IP1 lookup isp1
ip rule add pref 20 from IP2 lookup isp2

3. В каждую таблицу добавим маршрут default через нужного оператора:

ip route add default via GATEWAY1 table isp1
ip route add default via GATEWAY2 table isp2

4. В таблице main (которая используется по умолчанию, если не указать таблицу в команде явно) описываем маршрут "по умолчанию" - через того оператора, через которого будет идти исходящий трафик (не ответный на входящий), в данном случае пусть будет isp1:

ip route add default via GATEWAY1

Всё это иногда можно в той или иной степени засунуть в конфиги сети (зависит от дистрибутива Linux весьма существенно), а иногда приходится делать скриптами, в том числе, возможно, вызываемыми через hook системы инициализации сети (я, например, обновлял маршрутизацию через postup-хук dhcp-клиента и из скрипта, который поднимал pptp-vpn).

В дальнейшем всё это обросло кучей других особенностей, например, ip rule fwmark по меткам, которые ставилилсиь в iptables по connmark и иногда другим условиям, но это уже следующий уровень сложности и более специфичне задачи. И LARTC HOWTO почитать всё равно рекомендую, ибо там основа основ и все гуру по нему учились.

И не будет, ведь такая команда будет исполняться в одном shell, а не в двух разных. После первого exit дальше уже всё, остаток будет проигнорирован.

Способы есть:

1. Из суперпользователя убить shell пользователя. Некрасиво и неудобно, но закроет оба шелла.

2. Переключение в суперпользователя оформить сразу с выходом, тогда выход из внутреннего сделает выход и из внешнего, например:

sudo -i; exit

Недостаток - если не удастся правильно ввести пароль - сразу же и выкинет. Ну, можно поразбираться с кодами возврата, чтобы не делать exit.

3. Вместо предыдущего можно сделать exec, тогда запускаемая команда заместит текущий shell, а не будет запущена как дочерний процесс:

exec sudo -i

Недостаток тот же - если не ввести правильно пароль, то выкинет.

Но в целом я не вижу во всём этом смысла. Выход можно делать комбинацией Ctrl-D. Нажать дважды Ctrl-D ничто не мешает, это даже удобнее.

Да, можно, используя debugfs:

$ dd if=/dev/zero of=test.img bs=1M count=10
$ mkfs.ext4 test.img
$ debugfs -w test.img
debugfs: write my_file.txt new_file.txt

Большинство вещей - без проблем. Например, можно использовать таск authorized_keys для аккуратного прописывания ключа вместо ручного его закидывания на сервер. Есть таски для создания пользователей и групп, установки софта, копирования файлов и создания их по шаблону...

Некоторые вещи можно делать косвенным путём, копируя и генерируя конфиги, запуская свои кастомные команды через таск shell, итд итп. Например, конфигурить sudo можно через создание файла с нужным содержимым в /etc/sudoers.d, не трогая основной конфиг.

В общем, даже если останутся некоторые задачи, которые ansible не сможет автоматизировать достаточно хорошо, во всём остальном он очень сильно облегчит сопровождение серверов, особенно подготовку новых.

Запись

- src:/var/www/html

создаёт именованный том src в хранилище (docker volume ls). Надо указывать путь к каталогу, например, как относительный: ./src.

В образе по-хорошему ничего не надо заранее класть в этот каталог. Если нужно, чтобы в том попали какие-то данные, то их можно туда, например, распаковать при первом запуске контейнера из заготовленного архива. Но это в принципе считается антипаттерн, докер предполагает, что контейнер - не обёртка для запуска снаружи подсунутого содержимого - а законченное приложение.

Лучше не "ставить из пакета". Это лишает смысла проверку целостности пакета по контрольным суммам, усложняет установку обновлений. Поэтому правильнее иметь некую "эталонную" базу, которую копировать в целевое размещение. Как вариант, в пакете держать .sql (.sql.gz) для инициализации базы. Саму инициализацию делать скриптом (как initdb в postgres) или описать в инструкции что куда скопировать/выполнить. К слову, для процесса обновления тоже может потребоваться механизм, так как структура данных может меняться в новых версиях. Процесс первичной инициализации и последующего обновления можно сделать частью post-install скрипта пакета.

Базу следует класть не в /usr (в классической теории UNIX-систем /usr может вообще монтироваться в read-only, например, по nfs), а в /var, лучше /var/lib/имя_программы. Сделать специальную системную группу без пользователей вполне нормально, так делают. В инструкции следует описать, что пользователей надо в неё добавлять. Соответственно, на файл права 660, на каталог 770.

Если пользователи будут работать с этой базой параллельно-одновременно, а не строго по очереди, то потребуется ещё механизм блокировок. В этом случае лучше рассмотреть полноценную СУБД или хотя бы вынести работу с базой в отдельный сервис, с которым программа будет взаимодействовать.

В данном конкретном случае намного более адекватным было бы использовать include в nginx.conf отдельного конфига, который генерировать скриптом.

iptables -m owner -h

Маркируем пакет от пользователя (-j MARK) и затем policy routing (ip rule add fwmark XXX lookup vpn) перекидываем в другую таблицу маршрутизации.

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

Если отмонтирование не выполнено корректно (например, система была перезагружена без завершения как надо или флешка была резко выдернута), то fsck будет пытаться восстановить файловую систему. При этом на файловых системах с журналированием это может быть сделано достаточно быстро с помощью replay journal. Если же восстановить легко не получилось, то система выкинет в Shell с предложением прогнать fsck самому. В принципе, если файловая система ещё не превратилась в мелко нашинкованные макароны, это может пройти весьма успешно даже с жёсткими флагами fsck -f -y. Но тут уж пользователь сам берёт на себя ответственность.

В общем, проверка файловой системы при запуске происходит по сложным правилам, в том числе на основе указанных в fstab параметров. Кроме того, с помощью fsck.*-параметров загрузки ядра (в данном слуаче через grub) можно явно попросить systemd изменить поведение по умолчанию и, например, принудительно проверить файловую систему, даже если она была отмонтирована корректно. Если эти параметры передать в загрузчик вручную через редактирование в самом grub при загрузке, то на последующие перезагрузки это изменение не повлияет.

tcpdump -i ens18 -w file.pcap фильтры
tshark -r file.pcap -T fields -e ip.dst | sort | uniq

Можно сразу всё сделать wireshark'ом, но у него формат фильтров отличается.