shurshur

Внутри контейнера надо отдельно сгенерировать эту локаль:

localedef -i ru_RU -f IBM866 ru_RU.IBM866

(тут локаль будет названа ru_RU.IBM866, но можно назвать как угодно, в том числе ru_RU.CP866 upd: лучше так не делать и оставить имя с названием кодировки по умолчанию, см. комментарии).

Рецепт работает в любом Linux, но в минималистичных образах обычно много чего вырезают для уменьшения размера, поэтому каталог /usr/share/i18n пустой или значительно подчищен. В случае с opensuse нужно доустановить пакет glibc-i18ndata.

Образец Dockerfile:

FROM opensuse/tumbleweed

RUN zypper in -y glibc-i18ndata && localedef -i ru_RU -f IBM866 ru_RU.IBM866
ENV LC_ALL=ru_RU.IBM866

По поводу этого лучше всего начать с 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) перекидываем в другую таблицу маршрутизации.