Comments 28
Эта вторая часть поинтереснее, да.

откажемся от использования оконного менеджера и остановимся на простейшем окружении рабочего стола — openbox
openbox это и есть типичнейший оконный менеджер.
Это так.

Вынужден был представить его только в качестве создателя окружения рабочего стола. Здесь мы работаем без менеджера как такового, а сразу авторизуемся под именем конкретного пользователя и запускаем исключительно openbox. Он маленький и умеет всё, что нужно. Возможно, вы посоветуете более лёгкое окружение рабочего стола, которое сможет нарисовать окошки, иконки и экранные клавиатуры?
Вам же сказали, Openbox — оконный менеждер (window manager), а не окружение рабочего стола (desktop environment).
Всё исправлено, благодарю за замечание. Почему-то display manager я назвал словом window manager, и понеслось…
Да, спасибо! Именно их я в начале почему-то назвал 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 Мбит сети без заметной потери скорости загрузки.
А ведь если пускать это все по 1Gbit каналу с SSD диска, то вполне неплохо можно так десяток тонких клиентов запускать, всмысле бездисковые машины.
1 Gbit канал только ускорит время загрузки, да обычный жёсткий диск справится с забиванием такого канала под завязку. Часто нет необходимости загружать десятки машин одновременно. Можно загрузить пару-тройку, затем следующую группу и так далее. 100 Мбит сеть выдержит рассматриваемый сценарий использования даже с 50 одновременно работающими бездисковыми клиентами.

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

Почему же. Например Debian (и походные) без проблем устанавливаются через debootstrap. У других дистрибутивов, я уверен, существуют схожие решения.
Спасибо за замечание. Я просто хотел акцентировать внимание на том, что Archlinux устанавливается даже с установочной флешки тем же самым способом (bootstrap). Сейчас переформулирую фразу в статье.
Флешка с установочным образом Арча это одна из самых полезных в хозяйстве вещей. Выручала неоднократно после эксперементов с рабочими машинами (те машины на Убунте/Дебиане).
По жизни пользовался (пока была нужда) thinstation (15 МБ) + TFtpd (16 МБ). Файлы конфигурации прописываются индивидуально (+ 170 байт). Получался удаленный рабочий стол за 30-40 сек на достаточно старой машине (800МГц, 256 ОЗУ, -HDD)
Спасибо за статью, как раз интересовался загрузкой по сети.

Следовал вашим инструкциям и встретил пару небольших проблем:

mkdir -p /etc/systemd/system/tftpd.service.d && echo -e '[Service]\nExecStart=\nExecStart=/usr/bin/in.tftpd -s /srv/nfs/boot' > /etc/systemd/system/tftpd.service.d/directory.conf

Во-первых, в итоговом файле будет две строчки ExecStart, на что systemd будет ругаться и не будет запускать tftpd. Исправление файла и многократный вызов systemctl daemon-reload почему-то не помогали. Перезагрузка помогла. Так и должно быть?

Во-вторых, у вас указан путь /srv/nfs/boot, а нужен /srv/nfs/diskless/boot. Иначе, опять же, tftpd не запускается. Возможно, имеет смысл переписать на echo -e "[Service]\nExecStart=\nExecStart=/usr/bin/in.tftpd -s $root/boot", во избежание опечаток в будущем.

И совсем мелочь: systemctlt enable tftpd.socket tftpd.service dhcpd4 rpcbind nfs-server — лишняя буква T на конце systemctl.

Еще раз спасибо за статью.
Спасибо за интерес и внимательность. Действительно должно быть так:
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
В этом случае юниты перезапускаются строго в указанном порядке.
Пустая строка «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

Ах вот оно как! Я-то решил, что первый ExecStart это опечатка. Спасибо за разъяснение!
Не получается как по писаному:
на запуск сервиса
systemctl start tftpd.socket tftpd.service
TFTP выдаёт:

● tftpd.service — hpa's original TFTP daemon
Loaded: loaded (/usr/lib/systemd/system/tftpd.service; disabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/tftpd.service.d
└─directory.conf
Active: failed (Result: exit-code) since Чт 2016-04-21 03:43:34 NOVT; 1min 29s ago
Process: 7055 ExecStart=/usr/bin/in.tftpd -s /srv/nfs/diskless/boot (code=exited, status=74)

апр 21 03:43:34 ArchServer systemd[1]: Starting hpa's original TFTP daemon…
апр 21 03:43:34 ArchServer systemd[1]: tftpd.service: Control process exited, code=exited status=74
апр 21 03:43:34 ArchServer systemd[1]: Failed to start hpa's original TFTP daemon.
апр 21 03:43:34 ArchServer systemd[1]: tftpd.service: Unit entered failed state.
апр 21 03:43:34 ArchServer systemd[1]: tftpd.service: Failed with result 'exit-code'.
journalctl -xe
— Процесс остановки юнита tftpd.socket был завершен.
апр 21 03:43:34 ArchServer systemd[1]: Starting hpa's original TFTP daemon…
— Subject: Начинается запуск юнита tftpd.service
— Defined-By: systemd
— Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
— — Начат процесс запуска юнита tftpd.service.
апр 21 03:43:34 ArchServer in.tftpd[7055]: recvfrom: Socket operation on non-soc
апр 21 03:43:34 ArchServer systemd[1]: tftpd.service: Control process exited, co
апр 21 03:43:34 ArchServer systemd[1]: Failed to start hpa's original TFTP daemo
— Subject: Ошибка юнита tftpd.service
— Defined-By: systemd
— Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
— — Произошел сбой юнита tftpd.service.
— — Результат: failed.
апр 21 03:43:34 ArchServer systemd[1]: tftpd.service: Unit entered failed state.
апр 21 03:43:34 ArchServer systemd[1]: tftpd.service: Failed with result 'exit-c
апр 21 03:52:30 ArchServer systemd[1]: Listening on hpa's original TFTP daemon.
— Subject: Запуск юнита tftpd.socket завершен
— Defined-By: systemd
— Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
проблема собственно в этом:
апр 26 17:25:00 ArchServer in.tftpd[1476]: recvfrom: Socket operation on non-socket

Как так получается?
Если мне не изменяет память, то ещё в конце прошлого года изменился синтаксис запуска 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


Рекомендую проверять работоспособность на каждом этапе. Информация стареет очень быстро.
Добрый день!
А разве параметр --listen не запускает сервис в режиме standalone server без использования сокета?
Насколько помню раньше именно отсутствие данного параметра --listen указывало сервису, что сервис должен работать в режиме с использованием сокета. В таком случае если не ошибаюсь он не будет постоянно висеть в памяти на прослушке порта, а будет работать только когда данные будут поступать через сокет.
Или он теперь постоянно в этом режиме работает, используя tftpd.socket?
К сожалению, я давно переключился на немного иные проекты. Вам придётся самостоятельно разбираться с возникающими проблемами. Советую вам обратить внимание на строку 'Type=forking', возможно, это наведёт вас на какие-то мысли.

Ещё посмотрите вот эту публикацию LTSP: Терминальный сервер на Linux. Возможно, что использовать готовое решение окажется намного удобнее и проще.
Only those users with full accounts are able to leave comments. Log in, please.