Systemd automount. автоматическое монтирование файловых систем

Чем хорош SystemV

SystemV более доступен. Запуск выполняется при помощи bash-скриптов. После того как ядро запускает init — скомпилированный бинарный файл — init запускает скрипт rc.sysinit, который выполняет множество задач для инициализации системы. После завершения rc.sysinit, init запускает , который, в свою очередь, запускает различные демоны, определенные сценариями запуска SystemV в , где «X» — уровень выполнения (runlevel).

Кроме самого init, все эти скрипты и демоны — открыты и легко читаемы. Не составит никакого труда изучить эти скрипты и понять, как работает каждый из них и что конкретно происходит во время запуска системы. Однако я не думаю, что кто-то из системных администраторов часто этим занимается. Каждый запускаемый скрипт нумерован таким образом, чтобы запускать соответствующую службу в определенной последовательности. Службы запускаются последовательно и по одной за раз.

Systemd обязан своим появлением сотрудникам Red Hat — Леннарту Пёттерингу и Кэю Сиверсу. Фактически, это комплексная система больших, скомпилированных исполняемых файлов, логику которых не понять без доступа к исходному коду. Но поскольку systemd — open-source проект, проблем с «доступом к исходному коду» не возникает, просто это не очень удобно.

Однако своим появлением systemd значительно опровергает базовые принципы философии Linux. Как бинарный файл, systemd закрыт от прямого редактирования или просмотра системными администраторами. При этом он пытается «делать всё». Например, управлять запущенными службами. С другой стороны, он дает гораздо больше информации о состоянии, чем SystemV.

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

Приступим!

Стандартная
строка из /etc/fstab:

//192.168.1.10/Document
/mnt/Document cifs
noexec,noperm,iocharset=utf-8,credentials=/etc/fileserver 0 0

До
перехода на Systemd, она выполняла функцию
монтирования сетевого адреса
//192.168.1.10/Document в локальную директорию
/mnt/Document с перечисленными опциями при
загрузке ОС. В Alt Linux P7, этого не происходит
благодаря давней особенности/багу
Systemd — она пытается монтировать сетевой
диск до того, как происходит подключение
к сети. Решается это добавлением опций
noauto и x-systemd.automount в указанную выше строку
файла fstab. Всё бы хорошо, но тут мы
встречаемся с очередной особенностью/багом
Systemd — монтирование происходит 2 раза:

$
df -ha | grep Doc

systemd-1
1,9T 158G 1,7T 9% /mnt/Document

//192.168.200.10/Document
1,9T 158G 1,7T 9% /mnt/Document

В
принципе, можно было бы и забить, но мы
копнём глубже:

$
systemctl -a | grep Doc

mnt-Document.automount
loaded active running mnt-Document.automount

mnt-Document.mount
loaded active mounted /mnt/Document

mnt-Document.automount
и mnt-Document.mount — генерируемые при загрузке
ОС юниты Systemd, переводящие построчно
файл /etc/fstab в формат, понятный Systemd.
Располагаются они в директории
/run/systemd/generator/. Там же располагаются
юниты, отвечающие за монтирование
home,swap,tmp и всего остального, что имеется
у вас в fstab. Ознакомимся с содержимым
юнита mnt-Document.mount:

$
cat /run/systemd/generator/mnt-Document.mount

#
Automatically generated by systemd-fstab-generator

SourcePath=/etc/fstab

DefaultDependencies=no

After=remote-fs-pre.target

After=network.target

After=network-online.target

Wants=network-online.target

Conflicts=umount.target

Before=umount.target

What=//192.168.200.10/Document

Where=/mnt/Document

Type=cifs

FsckPassNo=0

Options=noauto,x-systemd.automount,noexec,noperm,iocharset=utf-8,credentials=/etc/fileserver

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

Скопировать
этот юнит в директорию /etc/systemd/system/ или
/lib/systemd/system/ (первая — предпочтительнее).
Добавить
в него секцию со строкой
WantedBy=remote-fs.target, для того, чтобы можно
было его активировать при загрузке
системы, привязав к цели, стартующей
после активации сетевого подключения.
Активировать
его командой systemctl enable mnt-Document.mount.
Закомментировать
строку отвечающую за данный сетевой
диск в файле fstab.
Перезагрузиться.

Конечный
файл выглядит так:

$
cat /etc/systemd/system/mnt-Document.mount

#
Automatically generated by systemd-fstab-generator

SourcePath=/etc/fstab

DefaultDependencies=no

After=remote-fs-pre.target

After=network.target

Wants=network.target

After=network-online.target

Wants=network-online.target

Conflicts=umount.target

Before=umount.target

What=//192.168.200.10/Document

Where=/mnt/Document

Type=cifs

FsckPassNo=0

Options=noauto,x-systemd.automount,noexec,noperm,iocharset=utf-8,credentials=/etc/fileserver

WantedBy=remote-fs.target

После
перезагрузки, обнаруживаем смонтированный
средствами Systemd, без задействования
fstab, ОДИН раз, сетевой диск. Для управления
диском используются стандартные команды
Systemd — systemctl start/stop/enable/disable/status
mnt-Document.mount.

Таким
же способом можно смонтировать например
/home или любой другой раздел.

Корневые файловые системы

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

Вот если бы только у людей уже была такая же проблема и они собрали набор системных файлов, в целом достаточный, чтобы служить базой прямо из коробки для большинства программ? К счастью, есть много проектов, что реализовали это! Одним из них является проект Alpine Linux (его основное предназначение, это когда вы начинаете свой с ). Alpine предоставляет корневые файловые системы, которые мы можем использовать для наших целей. Если вы последуете инструкциями, то сможете получить копию их минимальной корневой файловой системы () для здесь. Последней версией на момент написания поста и которую мы будем использовать, является .

В каталоге есть знакомые файлы, прям как в нашей собственной корневой файловой системе в , но убедитесь, насколько он минимален — многие из этих каталогов пусты:

Отлично! Мы можем дать команду, которая запустится в копии этого окружения, и она может быть даже , но нас это не будет волновать, а никто другой не пострадает.

Редактирование юнитов

Напрямую юниты не редактируются. Для редактирования существует команда edit:

root@dedicated:~ systemctl edit --full nginx.service

Выше мы говорили про автоматический перезапуск служб. Давайте рассмотрим этот пример. Добавим в секции два параметра

Restart=on-failure
RestartSec=60s

Чтобы изменения вступили в силу, перезапустим конфигурацию:

root@dedicated:~ systemctl daemon-reload

Проверим, что у нас получилось. Узнаем PID процесса:

root@dedicated:~ systemctl status nginx.service | grep PID
Main PID: 12567 (nginx)

Завершим его:

root@dedicated:~ kill -9  12567

Известной уже командой проверим его статус

root@dedicated:~ systemctl status nginx.service

…ждем 60 секунд. И проверяем снова:

PID Namespaces

Мы уже несколько раз упоминали каталог в этой серии постов, и если вы были знакомы с ним, то, вероятно, не будете удивлены тому, что вывод оказался пустым, поскольку мы видели ранее, что каталог был пуст в этом mount namespace (когда мы получили его из корневой файловой системы alpine).

Каталог в Linux обычно используется для доступа к специальной файловой системе (называемой файловой системой proc), которой управляет сам Linux. Linux использует его для предоставления информации обо всех процессах, запущенных в системе, а также другой системной информации, касающейся устройств, прерываний и так далее. Всякий раз, когда мы запускаем такую команду, как , выдающую сведения о процессах в системе, она обращается к этой файловой системе для получения информации.
Другими словами, нам нужно завести файловую систему . К счастью, в основном для это потребуется лишь сообщить Linux, что она нам нужна, причем желательно смонтированная в /proc. Но пока мы не можем этого сделать, поскольку наш командный процесс всё ещё зависит от той же файловой системы , что и и любой другой обычный процесс в системе. Чтобы избавиться от этой зависимости, нам нужно запустить его внутри собственного namespace.

PID namespace изолирует ID процессов в системе. Одним из следствий тут является то, что выполняющиеся в разных пространствах имён PID процессы могут иметь одинаковые идентификаторы процесса, не конфликтуя друг с другом. Допусти, мы изолируем это пространство имён потому, что мы хотим обеспечить как можно большую изолированность нашей запущенной команде. Однако более интересная причина, по которой мы рассматриваем это здесь, заключается в том, что монтирование файловой системы требует привилегий пользователя root, а текущий PID namespace принадлежит пользователю root, где у нас нет достаточных привилегий (если вы помните из предыдущего поста, у командного процесса на самом деле не root). Итак, мы должны работать в PID namespace, владельцем которого является пользователь пространства имён, которое считает наш командный процесс запущенным от root.

Мы можем создать новый PID namespace, передав для :

Затем мы добавляем функцию , которая настраивает файловую систему proc, монтируя её в текущих пространствах имён mount и pid.

Наконец, мы вызываем функцию прямо перед размонтированием в нашей функции , после того, как мы настроили mount namespace и перешли в корневой каталог.

Мы можем воспользоваться для очередного запуска:

Это выглядит намного лучше! Шелл считает себя единственным процессом, запущенным в системе и работающем с PID 1(поскольку это был первый процесс, запущенный в этом новом PID namespace)

Маскировка юнитов: третий уровень

$ sudo systemctl mask httpd.service
Created symlink from /etc/systemd/system/httpd.service to /dev/null.

Обратите внимание на то, что аналогичного эффекта можно достичь, выполнив следующую команду:

$ sudo ln -s /dev/null /etc/systemd/system/httpd.service

Теперь попытайтесь запустить веб-сервер вручную:

systemctl start httpd.service

Вы увидите следующее сообщение об ошибке:

Failed to start httpd.service: Unit httpd.service is masked

Это в рамках systemd. Если вы загрузите систему с замаскированным юнитом, он не будет запущен даже для удовлетворения зависимостей. По этой причине механизм маскировки юнитов является достаточно мощным

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

Для демаскировки юнита следует использовать следующую команду:

systemctl unmask httpd.service

Надеюсь, теперь вы можете еще лучше оценить всю мощь и гибкость механизмов systemd для работы с юнитами и разрешения зависимостей между ними. Для ознакомления с дополнительной информацией о механизме маскировки юнитов рекомендую обратиться к из серии «systemd для системных администраторов«. До встречи в следующей статье серии!

На нашем сайте вы можете прочитать большую серию переводов, посвященных системе инициализации systemd:

Paul W. Frields, перевод: А.Панин, «systemd: работа с системным журналом»
В комплекте поставки systemd содержится большое количество программных компонентов, которые
выполняют различные функции помимо запуска системы и управления системными службами. Одним из таких
программных компонентов является демон journald, который осуществляет запись информации о состоянии
вашей системы, а также запущенных в ней служб в системный журнал. Навыки работы с утилитой для
просмотра системного журнала облегчат процесс поиска информации о системе и ее отладки в случае
необходимости.
Jon Stanley, перевод: А.Панин, «systemd: преобразование сценариев sysvinit для работы с systemd»
В данной статье рассматривается методика преобразования устаревших сценариев инициализации,
которые вы могли модифицировать в соответствии со своими потребностями, для работы с systemd.
Bryan Sutherland, перевод: А.Панин, «systemd: основные приемы работы с юнит-файлами»
Система инициализации systemd разделена на множество программных компонентов, что значительно
упрощает процедуру управления компонентами вашей системы. systemd использует юнит-файлы для
конфигурации и управления системными ресурсами, такими, как процессы и ваша файловая система.
Благодаря этим файлам вы можете использовать systemd для конфигурации вашей системы в
соответствии с вашими пожеланиями.
Ryan Lerch, перевод: А.Панин, «systemd: что такое система инициализации?»
systemd является набором инструментов для выполнения широкого спектра системных задач, включая
инициализацию системы, а также для управления и отслеживания состояния системных служб и демонов
как в процессе загрузки системы, так и в процессе ее работы.
Carla Schroder, перевод: Н.Ромоданов, «Управление сервисами в Linux с systemd»
Вы уже читали все о systemd, новом демоне Linux init. Вы знаете, что он делает, и почему.
Теперь пришло время окунуться глубже и узнать, как он себя ведет — или, по крайней мере, как
запускает, останавливает и выдает информацию о сервисах.
Carla Schroder, перевод: Н.Ромоданов, «Знакомимся с уровнями запуска Systemd и командами управления сервисами»
В прошлом у нас были статические уровни запуска. Вместо уровней запуска, systemd позволяет
создавать различные состояния, предоставляя вам гибкий механизм создания различных конфигураций
загрузки.
Carla Schroder, перевод: Н.Ромоданов, «Изучаем и используем Systemd»
Ценность systemd является спорной по нескольким причинам: он заменяет то, что, как думают
многие пользователи Linux, заменять не требуется, и все гримасы разработчиков systemd не
завоевывают сердца и умы.
Carla Schroder, перевод: Н.Ромоданов, «Проходим еще раз, еще один Linux Init: введение в systemd»
В течение очень многих лет в системе Linux для управления запуском системы хватало механизма
sysvinit. Затем появились две новых системы инициализации Linux: Ubuntu’s Upstart, впервые
выпущенная в 2006 году, и systemd, появившаяся в 2009 году. Что же это за штуковина systemd,
и какие преимущества она даст нам, простым пользователям Linux? Н.Ромоданов перевел 4 статьи
о systemd, первую из которых вы можете прочесть сегодня.

Юниты systemd.

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

root@dedicated:~ /etc/init.d/nginx status

Общая команда будет иметь следующий вид:

root@dedicated:~ sudo service nginx status

…или выполнить тоже самое с помощью systemd:

root@dedicated:~ systemctl status nginx.service

Посмотреть список всех запущенных юнитов можно командой:

root@dedicated:~ systemctl

Мы увидим список всех запущенных юнитов, а так же их статус.

UNIT — имя юнита

LOAD — информирует нас о успешной загрузке конфигурации.

ACTIVE — Активный ли юнит.

SUB — более детальная системная информация о юните.

DESCRIPTION — краткое описание.

На скриншотах выше, в колонке UNIT, после префикса, указан тип юнита. Например *.service указывает, что юнит указывает на службу (nginx, apache и т.д.). Существует несколько возможных видов юнитов (socket, device, mount, swap, automount, target, snapshot, timer и другие)

На данный момент многие из них нам не пригодятся, потому рассмотрим базовый *.service, на которые стоит обратить внимание. Задача на данный момент — указать путь, а не запутать читателя

Ссылка на руководство по углубленному изучению будет предоставлена в конце статьи.

Отфильтруем только службы:

root@dedicated:~ systemctl list-units --type=service

Отфильтруем неактивные юниты:

root@dedicated:~ systemctl list-units --all --state=inactive

Существуют следующие статусы: active, inactive, running, exited, dead, loaded, not-found, plugged, mounted, waiting, listening.

Посмотреть самую полную информацию, включая юниты, которые система по какой-то причине не загрузила:

root@dedicated:~ systemctl list-units --all

Отобразить список зависимостей определенного юнита

root@dedicated:~ systemctl list-dependencies nginx.service

Используя флаги, одной только командой systemctl вы можете получить представление о системе для анализа ее работы. Так же опытный администратор может отключить необязательные службы с автозагрузки, тем самым выполнив оптимизацию загрузки сервера.

Спор вокруг систем инициализации в Linux

System V init (или просто «SysV») — это система инициализации, которая существует со времен операционной системы System V, которая была выпущена в 1983 году. SysV оставалась системой инициализации в течение почти трех десятилетий (за некоторыми исключениями). Многие IT-специалисты и программисты в силу своей привычки не хотели отказываться от SysV, да и к тому же она была очень простой для понимания.

Проблема с SysV заключалась в том, что в её основе лежали концепции, существовавшие много лет назад. SysV не хватало возможности нативно обрабатывать многие вещи, такие как: обнаружение съемных носителей, корректное обнаружение аппаратного обеспечения и загрузка встроенного ПО, загрузка различных модулей и пр. Кроме того, при использовании данной системы, инициализация процессов происходит последовательно, т.е. одна задача запускается только после успешного завершения предыдущей. Часто это приводило к задержке и длительному времени загрузки. Задачи, подобные монтированию файловых систем, выполняются один раз во время загрузки, после чего «забываются». Но такого подхода недостаточно для автоматизированного управления сервисами, требующими к себе постоянного внимания.

В попытке привнести больше возможностей в процесс инициализации Linux-систем, компания Canonical в 2006 году вместе с релизом Ubuntu 6.10 (Edgy Eft) выпускает систему инициализации Upstart, которая с самого начала разрабатывалась с учетом обратной совместимости. Она может запускать демоны без каких-либо изменений в их скриптах запуска.

Другой системой инициализации, восходящей своими корнями к операционной системе 4.4BSD, является rc.init. Она применяется в таких дистрибутивах, как: FreeBSD, NetBSD и Slackware. В 2007 году разработчики Gentoo выпустили улучшенный вариант данной системы инициализации, сделав её модульной и назвав OpenRC. Большинство других дистрибутивов Linux исторически продолжало использовать SysV.

В 2010 году инженеры компании Red Hat Леннарт Пёттеринг и Кей Сиверс приступили к разработке новой системы инициализации — systemd, которая разрабатывалась с учетом недостатков, имеющихся в SysV. В состав systemd, помимо прочего, также входят и различные пакеты, утилиты и библиотеки, позволяющие производить параллельный запуск процессов, сокращая тем самым время загрузки системы и количество необходимых вычислений. Весной того же года Fedora 15 стала первым дистрибутивом, в котором по умолчанию использовалась система инициализации systemd. После чего, на протяжении следующих трех лет, большинство дистрибутивов массово перешли на systemd.

Но, если все остальные дистрибутивы отдают предпочтение systemd и считают её лучшей системой инициализации, как для предприятий, так и для любителей, почему так много споров вокруг нее?

systemd, по сравнению с SysV и Upstart, содержит большое количество различных улучшений, а также предлагает и другие компоненты, имеющие более тесную интеграцию с системой, с помощью которых разработчики могут уменьшить объем выполняемой работы. Что в этом плохого? Ну, поскольку разработчики создают программное обеспечение, которое зависит от systemd и/или от любой из её многочисленных служб (journald, udevd, consoled, logind или networkd), то такое ПО становится менее совместимым с системами, в которых systemd не применяется. По мере того, как количество служб, предоставляемых проектом systemd, продолжает расти, systemd сама становится все более зависимой от них.

В результате systemd становится самостоятельной платформой, и её повсеместное распространение непреднамеренно препятствует разработке программного обеспечения, которое является переносимым и совместимым с операционными системами, не поддерживающими systemd. Но действительно ли всё так печально? Конечно, нет. Прежде всего, это проект с открытым исходным кодом, и у людей есть выбор: использовать его или нет. Пользователи и разработчики могут извлечь выгоду из наличия нескольких конкурирующих систем инициализации, и нет вины systemd в том, что основные дистрибутивы переключились на нее из-за её плюсов.

Монтирование файловой системы

Для подключения файловой системы к конкретному местоположению (точке монтирования) команда mount используется в следующей форме:

mount  имя_устройства директория

После подключения точка монтирования становится корневой директорией смонтированной ФС. Например, смонтировать жесткий диск /dev/sdb1 в директорию /mnt/media можно следующим образом:

$ sudo mount /dev/sdb1 /mnt/media

Обычно при монтировании устройства с распространенной ФС, например, ext4 или xfs, команда mount автоматически определяет ее тип. Однако, некоторые ФС не распознаются. Их тип нужно указывать в явном виде. Для этого используется опция -t:

mount -t тип имя_устройства директория

Чтобы указать дополнительные опции монтирования, используется флаг -o:

mount -o опции_монтирования имя_устройства директория

Можно указать несколько опций, разделенных запятыми (после запятых не должно быть пробелов). Ниже предоставлены основные опции команды

-V — вывести версию утилиты;-h — вывести справку;-v — подробный режим;-a, —all — примонтировать все устройства, описанные в fstab;-F, —fork — создавать отдельный экземпляр mount для каждого отдельного раздела;-f, —fake — не выполнять никаких действий, а только посмотреть что собирается делать утилита;-n, —no-mtab — не записывать данные о монтировании в /etc/mtab;-l, —show-labels — добавить метку диска к точке монтирования;-c — использовать только абсолютные пути;-r, —read-only — монтировать раздел только для чтения;-w, —rw — монтировать для чтения и записи;-L, —label — монтировать раздел по метке;-U, —uuid — монтировать раздел по UUID;-T, —fstab — использовать альтернативный fstab;-B, —bind — монтировать локальную папку;-R, —rbind — перемонтировать локальную папку.

Полный список опций можно получить, выполнив команду man mount.

Точки монтирования

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

Мы можем видеть точки монтирования, видимые для процесса с id посредством файла — его содержимое одинаково для всех процессов, принадлежащих к тому же mount namespace, что и :

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

Давайте начнём с запуска терминала в его собственном mount namespace:

Хммм, мы всё еще можем видеть тот же самый список, что и в корневом mount namespace. Особенно после того, как в предыдущем посте стало ясно, что новый user namepace начинается с чистого листа, может показаться, что флаг , который мы передали , не дал никакого эффекта.
Процесс шелла фактически выполняется в другом mount namespace (мы можем убедиться в этом, сравнив файл симлинка с файлом другой копии шелла, работающей в корневом mount namespace). Причина, по которой мы все еще видим тот же список, заключается в том, что всякий раз, когда мы создаем новый mount namespace (дочерний), в качестве дочернего списка используется копия точек монтирования mount namespace, в котором происходило создание (родительского). Теперь любые изменения, которые мы вносим в этот файл (например, путём монтирования файловой системы), будут невидимы для всех других процессов.
Однако изменение практически любого другого файла на этом этапе будет влиять на другие процессы, поскольку мы всё ещё ссылаемся на те же самые файлы (Linux только делает копии особых файлов, таких как список точек монтирования). Это означает, что сейчас у нас минимальная изолированность. Если мы хотим ограничить то, что будет видеть наш командный процесс, мы должны сами обновить этот список.

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

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

Хорошо, в теории это звучит хорошо и для реализации этого мы сделаем следующее:

Создадим копию зависимостей и системных файлов, необходимых команде.
Создадим новый mount namespace.
Заменим корневую файловую систему в новом mount namespace на ту, которая содержит копии наших системных файлов.
Выполним программу в новом mount namespace.

Заключение

Уже много лет не утихают споры, нужен ли systemd как замена init. Доводы двух сторон имеют право на существование, однако они всё дальше уходят от конкретики в дебри философии Linux. Systemd многие популярные дистрибутивы сделали системой инициализации по умолчанию, это уже та причина-минимум, почему стоит её освоить. Фактически она стала стандартом. В рамках одной статьи невозможно сполна раскрыть тему, потому мы старались своими словами и доступно объяснить читателю азы, которые уже можно применить на практике и которые поспособствуют старту к углубленному изучению systemd. Залог стабильной работы сервера — глубокое понимание работы его служб, их взаимодействия и тонкая конфигурация под свои задачи. Для более глубокого изучения, мы рекомендуем прочитать замечательный перевод книги Леннарта Пёттеринга, разработчика systemd.

В дата-центре FREEhost.UA Вы можете арендовать выделенный сервер или виртуальный сервер с OS семейства Linux или FreeBSD. Сервер Вы получаете полностью настроенным и готовым к работе. Если в процессе использования услуги у Вас возникнут вопросы, мы будем рады на них ответить.