Илья Назаров Roshalsky

К сожалению, я давно переключился на немного иные проекты. Вам придётся самостоятельно разбираться с возникающими проблемами. Советую вам обратить внимание на строку 'Type=forking', возможно, это наведёт вас на какие-то мысли.

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

Если мне не изменяет память, то ещё в конце прошлого года изменился синтаксис запуска TFTP. Подобные неожиданности периодически случаются в archlinux. В предыдущий раз разработчики сломали NBD, и пришлось добавлять костыль, описанный в статье.

Создайте файл /etc/conf.d/tftpd

TFTPD_ARGS="--secure /путь_к_папке"

Файл /etc/systemd/system/multi-user.target.wants/tftpd.service должен выглядеть так:

[Unit]
Description=hpa's original TFTP daemon
After=network.target

[Service]
Type=forking
EnvironmentFile=/etc/conf.d/tftpd
ExecStart=/usr/bin/in.tftpd --listen $TFTPD_ARGS

[Install]
WantedBy=multi-user.target

Рекомендую проверять работоспособность на каждом этапе. Информация стареет очень быстро.

Я понял ваш вопрос.

Изначально в статье не ставилась задача запустить все мониторы.

Udev привязан к событию «появления головы с подключенным монитором» и срабатывает столько раз, сколько мониторов подключено. Каждый раз запускается скрипт $root/etc/default/xdevice, который заполняет шаблон и записывает его в один и тот же конфигурационный файл обычным перенаправлением вывода ">". В итоге остаётся только самый последний. На какую видеокарту он показывает, та и работает.

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

Можно в мой скрипт добавить код, который при первом срабатывании будет удалять старый конфигурационный файл из папки /etc/X11/xorg.conf.d. Но придётся много писать для того, чтобы понять, какой раз был первым, т. к. скрипт запускается в стольких копиях, сколько подключено мониторов, а сам запуск при этом происходит практически параллельно благодаря udev. Кроме того, в случае двух видеокарт в конфигурационном файле должны присутствовать только два блока «Device», а не сколько есть мониторов. Соответственно, придётся проверять и этот момент перед записью шаблона, чтобы не повторяться. Задачи решаемы, но проще их решить не при параллельном запуске, а запустив немного изменённый скрипт один единственный раз перед, getty, например. Но как в этом случае продемонстрировать пример с правилами udev?

Сегодня специально протестировал такой компьютер: i5 на чипсете Z77 с видеокартой GTX680. К внешней видеокарте подключены монитор через DisplayPort и проектор через HDMI. Загрузил компьютер по сети.

Включился проектор. Lspci показал в системе только nVidia.

Включил встроенную видеокарту через BIOS (назовём его так). Картинка с nVidia исчезла совсем, т.к. сначала инициализируется встроенная видеокарта, куда сразу же был подключен монитор через D-Sub. Информация о загрузке отобразилась на нём, и на нём же система вышла в графический режим. Это предсказуемое поведение, т. к. внешняя видеокарта до сих пор была неактивна и пребывала в статусе disabled. Поправил правило вот таким образом:

nano /etc/udev/rules.d/10-graphics.rules
...
KERNEL=="card*", SUBSYSTEM=="drm", ATTR{status}=="connected", RUN+="/etc/default/xdevice %n %k"

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

Информация во время загрузки отображалась на D-Sub встроенной видеокарты, а графический режим включился на выходе HDMI внешней. Отключил кабель проектора и заново перезагрузил. Изображение появилось на мониторе, подключенном к DisplayPort GTX680.

Всё запустилось и работало как предполагалось. Не произошло ничего неожиданного.

Вот все устройства (card0 — intel):

ls /sys/class/drm/ | grep card
card0
card0-DP-1
card0-DP-2
card0-HDMI-A-1
card0-HDMI-A-2
card0-VGA-1
card1
card1-DP-3
card1-DVI-D-1
card1-DVI-I-1
card1-HDMI-A-3

lspci | grep -i vga
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 680] (rev a1)

В данном случае card0 — встроенная видеокарта, а card1 — внешняя. Они легко могут поменяться местами после перезагрузки. На работоспособность решения из статьи это никак не повлияет.

Если нужно быть уверенным, что смены имени не произойдёт, то можно сделать так (пример для случая с внешней картой AMD):

nano /etc/modules-load.d/persistent-drm-devices.conf
radeon
i915

В этом случае всегда card0 — AMD, а card1 — Intel.

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

Из Intel не будут работать только D2500 series и D2700 series.

Если при старте X на каких-то системах возникает ошибка «xf86OpenConsole: VT_ACTIVATE failed: Operation not permitted», то в файле ~/.bash_profile нужно убрать перенаправление "&>/dev/null"

Спасибо за замечания. Я исправлю это в статье. Теория меня на момент создания решения интересовала только как систематизация практических знаний.

Сравниваю выводы только для того, чтобы показать, что без разницы каким из них пользоваться, чтобы узнать вендора. Использую udevadm info для того, чтобы рассказать о правилах udev и получить информацию о подключенных мониторах, которую lspci не даёт. Оригинальный скрипт запускался один раз перед agetty и сканировал /sys/class/drm.

Что касается i915 и nouveau, то из них можно сделать даже «трехголовый» мультисит, если на материнской плате есть хотя бы два видеовыхода. Хотя я бы предпочёл поставить видеокарту radeon и использовать как минимум 4 головы, т. к. на nvidia мне их не удалось разделить. Попробуйте использовать предложенное решение на практике. Зачем гадать?

У Intel есть один чипсет, который в рассматриваемой системе. Это встроенные процессоры серий Atom D2500 — Atom D2700. С момента их первого появления я ждал, когда в линукс появится драйвер для их поддержки. Такой был в MeeGo, но вытащить его оттуда не получилось, а потом было не надо, т. к. вышли ещё несколько поколений Atom с того момента.

В моей практике сервером мог стать любой из соседних компьютеров с жёстким диском на 20 Гб и 1 Гб оперативной памяти, «раздавающий» по сети сам себя. Диски не демонтировались в силу их сомнительной ценности и не использовались в силу сомнительной работоспособности. Одновременная загрузка 3-4 компьютеров забивала 100 Мбит сеть почти до предела даже без помощи ngnix, а дальнейшее включение новых компьютеров с каждым новым случаем сильнее наталкивало на мысль, что всё просто зависло, хотя этого ни разу не случилось.

К моему стыду никогда не сталкивался в работе с HTTP, поэтому даже про iPXE узнал только из комментариев к предыдущей статье, и решил сразу попробовать уменьшить время загрузки отдельно взятой машины VirualBox и некогда любимого ноутбука с Core 2 Duo. С использованием iPXE и HTTP ноутбук всегда загружался по сети с виртуальной машины, подключенной по wi-fi. Тогда как TFTP в схожих условиях периодически отваливался. При разработке решения, естественно, такой вариант использования не тестировался, ведь проводные сети на практике доступнее и часто обходятся дешевле. К сожалению, iPXE очень странно ведёт себя в VirtualBox, поэтому с ним не удалось как следует познакомиться.

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

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

Если вы имеете в виду загрузочную флешку в самом конце статьи, то я просто показал способ клонирования системы, который для флешек и жёстких дисков выглядит абсолютно одинаково. Просто демонстрация на примере флешек. При этом система с включенным обработчиком live будет работать в режиме «только для чтения», и её можно разместить даже на флешке, которую обычно быстро убивает режим постоянной записи мелких файлов, характерный для Linux.

Пустая строка «ExecStart=» отменяет действие предыдущей команды из модифицируемого юнита /usr/lib/systemd/system/tftpd.service/.

Попробуйте убрать строку «ExecStart=» и перезапустите. Сервис не запустится по причине:

tftpd.service has more than one ExecStart= setting, which is only allowed for Type=oneshot services. Refusing.

Есть единственный на данный момент тип сервиса — Type=oneshot, в котором можно указывать несколько команд ExecStart=, и все эти команды будут выполняться одна за другой. Сейчас я сделаю пояснение в тексте статьи.

И я опечатался в предыдущем сообщении в слове tftpd (нужно указывать tftpd, а не tftp). Вот исправленная связка:

systemctl stop tftpd.socket tftpd.service && systemctl start tftpd.socket tftpd.service

Спасибо за интерес и внимательность. Действительно должно быть так:

cat /etc/systemd/system/tftpd.service.d/directory.conf
[Service]
ExecStart=
ExecStart=/usr/bin/in.tftpd -s /srv/nfs/diskless/boot

В случае нескольких юнитов в одной строке команда:

systemctl restart tftpd.socket tftp.service

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

systemctl stop tftpd.socket tftp.service && systemctl start tftpd.socket tftp.service

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

1 Gbit канал только ускорит время загрузки, да обычный жёсткий диск справится с забиванием такого канала под завязку. Часто нет необходимости загружать десятки машин одновременно. Можно загрузить пару-тройку, затем следующую группу и так далее. 100 Мбит сеть выдержит рассматриваемый сценарий использования даже с 50 одновременно работающими бездисковыми клиентами.

Фокус в том, что загрузка производится только один раз, и именно в этот момент по сети гуляет наибольший трафик (причём есть подозрение, что TFTP-сервер даже 100 Мбит сеть не может раскачать до максимума). Во время обычной работы, если корневой раздел подключен через NFS, нагрузка на сеть небольшая, т. к. большая часть данных всегда находится в оперативной памяти. В следующей статье я покажу способ помещения «живого» образа в оперативную память целиком, тогда нагрузки на сервер во время работы не будет совсем. Теоретическое количество одновременно работающих бездисковых клиентов, загруженных с одного сервера, приблизится таким образом к бесконечности. Думаю, что получится ужать систему из этой статьи мегабайт до 250-300, так что 1 Гб оперативки для нормальной работы без серверов и дисков будет вполне достаточно.

Спасибо за замечание. Я просто хотел акцентировать внимание на том, что Archlinux устанавливается даже с установочной флешки тем же самым способом (bootstrap). Сейчас переформулирую фразу в статье.

Да, спасибо! Именно их я в начале почему-то назвал window manager, когда утверждал, что он нам не нужен.

В текущем воплощении VirtualBox загружается за 45-50 секунд. Железо, думаю, около 2-х минут.

На реальном железе проверял нечто близкое к тому, к чему придём в конце следующей статьи.

Время инициализации BIOS до начала работы PXE — это 15-20 секунд (с UEFI вроде бы было быстрее).

16:27:44.735923 отправка DHCPDISCOVER
16:27:46.880359 подключение к TFTP
16:28:12.520943 подключение корневой файловой системы
16:28:16.514296 окончена авторизация пользователя
Этот этап занимает примерно 32 секунды и за это время проходит около 110 MiB трафика.

Сюда нужно добавить время на инициализацию графической оболочки и запуск Firefox — ещё секунд 10-20.

Одновременно можно будет загружать 3-4 компьютера по 100 Мбит сети без заметной потери скорости загрузки.

Всё исправлено, благодарю за замечание. Почему-то display manager я назвал словом window manager, и понеслось…

Это так.

Вынужден был представить его только в качестве создателя окружения рабочего стола. Здесь мы работаем без менеджера как такового, а сразу авторизуемся под именем конкретного пользователя и запускаем исключительно openbox. Он маленький и умеет всё, что нужно. Возможно, вы посоветуете более лёгкое окружение рабочего стола, которое сможет нарисовать окошки, иконки и экранные клавиатуры?

Сейчас я перечитываю «Learning Python» Марка Лутца — огромное количество теории в отрыве от практики. К середине книги начинаешь забывать о том, что читал в начале. Мой опыт подсказывает, что ответы не имеют значения, пока в них нет нужды, пока не сформировались вопросы. А чтобы появились вопросы, нужна практика, на которую будет нанизываться теория, с повтором фундаментальных вещей хотя бы по 3 раза разными словами и в разных ситуациях. Подход в вики — как у Лутца. По вики тяжело учиться, её нужно читать, когда уже что-то знаешь. Я ставлю перед собой цель научить как можно большему с единственного прочтения.

В моей статье я на практическом и полезном примере установки ArchLinux рассказываю о том, как использовать systemd. Привожу почти все известные мне варианты запуска стандартных и собственных служб, даже с использованием параметров и внешних файлов (к сожалению, systemd в качестве cron здесь рассмотреть не могу, т. к. в рамках статьи в этом нет практической пользы). Теорию о systemd я даю максимально сжато, и ничего не говорю о журнале и способах отладки запуска — это выходит за рамки заголовка моей статьи. В статье об установке и вики ничего не говорится о systemd, а в статье о systemd приводится только сухая теория в отрыве от практики.

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

Далее по тексту я постепенно подвожу к тому, чтобы появился вопрос: «Как настраивать сеть?» — и развёрнуто на него отвечаю. Выбранный мной способ не указан в вики. На практическом примере я ввожу понятие обработчиков, про которые в вики практически ничего не сказано, но с которыми ещё предстоит встретиться в продолжении.

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

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