Как настроить tftp сервер synology

Имя файла www.tftp.conf обязательно должно начинаться на www. и иметь расширение .conf , тогда конфигурационный файл будет автоматически загружен с nginx .

Пробуем в браузере открыть ссылку http://192.168.255.2/tftp/ где вместо 192.168.255.2 – IP-адрес Вашего Synology. В браузере должно появиться содержимое папки.

Добавляем PXE-загрузчики в /tftp/ папку:

Возьмём из комплекта утилиты syslinux несколько необходимых файлов:

Для BIOS-загрузки (Legacy) будем использовать файл lpxelinux.0 вместо стандартного pxelinux.0 , т.к. начиная с версии 5.10, данный загрузчик поддерживает загрузку образов по HTTP и FTP, а не только TFTP. Загрузка через HTTP происходит быстрее чем через TFTP. Дополнительную информацию по утилите syslinux читать здесь.

Добавляем файлы для загрузки Fedora CoreOS в /tftp/ папку:

Скачаем файлы kernel-x86_64 , initramfs.x86_64.img и rootfs.x86_64.img от дистрибутива Fedora CoreOS со страницы https://getfedora.org/en/coreos/download?tab=metal_virtualized&stream=stable:

Создадим конфигурационный файл для PXE-загрузчика:

Вместо 192.168.255.2 необходимо указать IP-адрес Synology. В строчках KERNEL и INITRD можно указать только названия файлов, без http://192.168.255.2/tftp/ префикса, тогда загрузка этих файлов будет проходить через TFTP, но такая загрузка будет медленнее (эксперимент показал, что при суммарном размере kernel и initramfs в 86МБ, загрузка по TFTP на 17 секунд медленнее чем загрузка по HTTP, 35 секунд против 18, т.е. почти в два раза).

Настройка DHCP-сервера на MikroTik для загрузки по сети:

Для того, чтобы компьютер (или виртуальная машина) смогли загрузиться по сети – DHCP-сервер должен передать DHCP-клиенту как минимум две опции: 66 (IP-адрес TFTP-сервера) и 67 (имя загрузчика). Добавим в настройки MikroTik две эти опции и создадим два набора опций для обычной (BIOS/legacy) и EFI-загрузки. Далее нам нужно будет только в свойствах статических адресов для конкретных компьютеров указывать необходимы набор опций: set-pxe-bios или set-pxe-efi .

Необходимые опции создали. Теперь нужно их прописать для определённого компьютера, для которого уже имеется статическая запись в блоке lease .

Можно воспользоваться первой командой, можно второй, а можно просто в WinBox открыть карточку и выбрать необходимое значение в поле DHCP Option Set. В данном примере мы указали набор опций для BIOS/legacy загрузки. Для EFI-загрузки, необходимо указывать набор опций set-pxe-efi . В идеальном мире уже после добавления этих настроек всё должно заработать. Но, к сожалению, многие DHCP-клиенты с такими настройками грузиться не будут. Опция 66 будет игнорироваться, и вместо TFTP-сервера указанного в этой опции, попытки загрузки будет предприниматься с TFTP-сервера 192.168.255.1 , т.е. с адреса нашего DHCP-сервера. Для того, чтобы направить клиентов на правильный TFTP-сервер, необходимо в настройках сети заполнить параметр next-server . Для того, чтобы указать правильный адрес TFTP-сервера в поле next-server выполним следующую команду:

Вместо [ find address=»192.168.255.0/24″ ] можно просто указать 0 , если у вас в DHCP-сервере прописана только одна сеть. Если возникнет необходимость очистить поле next-server , нужно будет выполнить эту же команду, только вместо IP-адреса TFTP-сервера указать адрес 0.0.0.0 . На форуме MikroTik пишут, что создать новую сеть с маской /32 для одного конкретного IP-адреса, и заполнить поле next-server только для этой сети. Но у меня это срабатывало только наполовину, загрузка действительно начиналась, появлялась строка PXELINUX, но дальнейшая загрузка не производилась. Итак, в поле next-server указали IP-адрес, настроенного ранее, TFTP-сервера. В свойствах статической записи указали наборы опций. Можно пробовать загрузиться. Для тестирования удобнее всего воспользоваться какой-нибудь «пустой» виртуальной машиной.

Перенос функционала TFTP-сервера на MikroTik:

К этому моменту Fedora CoreOS успешно загружается по сети, и приходит понимание, что TFTP-сервер на Synology в общем-то и не нужен. Непосредственно с TFTP-сервера загружается только PXE-загрузчик и конфигурационный файл, общим размером меньше 1МБ. Эти файлы статичны и их можно перенести на MikroTik. Т.е. перенесём функцию TFTP-сервера с Synology на MikroTik.

Затем переключаем настройки DHCP на использование TFTP-сервера на MikroTik.

После чего пробуем тестируем загрузку по сети. С загрузкой варианта BIOS/legacy проблем не возникает, а вот с EFI-загрузкой с использованием загрузчика syslinux.efi начинаются проблемы. Загрузчик загружается, по TFTP-считывает конфигурационный файл pxelinux.cfg/default , получает IP-адрес по DHCP, далее загрузчик пытается загрузить ядро по ссылке http://192.168.255.2/tftp/fedora-coreos/kernel-x86_64 , после чего появляется ошибка Loading http://192.168.255.2/tftp/fedora-coreos/kernel-x86_64 failed: No such file or directory и всё начинается сначала. Переключаем обратно загрузку на TFTP-сервер Synology – всё загружается, возвращаем TFTP-сервер MikroTik – появляется эта ошибка. В итоге, через некоторое время, благодаря Wireshark понимаем, что проблема в файле syslinux.efi . Вместо адреса web-сервера который указан в ссылке (в данном случае 192.168.255.2 ), используется IP-адрес TFTP-сервера и http-соединение устанавливается с адресом 192.168.255.1 , и естественно никакой файл /tftp/fedora-coreos/kernel-x86_64 не находился. Есть даже описание этого бага bug #907805, но он до сих пор не исправлен. Когда мы загружались с TFTP-сервера Synology, у нас IP-адрес TFTP-сервера совпадал с IP-адресом web-сервера, поэтому такая проблема не возникала, как говорится, даже сломанные часы дважды в сутки показывают правильное время. 🙂

Отказ от syslinux и переход на iPXE:

Ещё настраивая PXE-загрузчики syslinux , я смотрел в сторону iPXE. iPXE-загрузчик должен был загружаться следующим по цепочке, для того, чтобы в финале можно было задействовать matchbox . Нужно было сразу переходить к iPXE, не тратя время на syslinux . Наша задача скомпилировать два iPXE загрузчика с простейшим встроенным скриптом, состоящим из двух команд: dhcp – для того, чтобы загрузчик получил IP-адрес, и chain $ , для того, чтобы загрузчик по цепочке продолжил выполнение скрипта, ссылка на который находится в переменной $ . А в переменной $ у нас будет значение, которое мы передадим загрузчику через DCHP опцию 17.

Далее, при помощи sftp, копируем файлы bin/ipxe.pxe и bin-x86_64-efi/ipxe.efi на MikroTik (IP-адрес роутера в примере 192.168.255.1 ).

Первая команда mkdir tftp нужна, если такая папка ранее не создавалась. Следующие команды завершатся с ошибкой, в случае если папка /tftp не будет предварительно создана.

Так же можно переносить файлы на MikroTik используя веб-сервер, как мы это делали ранее.

В идеальном мире должен работать ещё и такой способ, с использованием scp . Но у меня данный вариант зависал после создания файла на удалённой стороне, и копирование не происходило.

Включим TFTP-сервер на MikroTik, если ранее его не включали:

После компиляции и переноса на MikroTik iPXE-загрузчиков, произведём необходимые настройки DHCP-сервера. Если ранее PXE не настраивали – выполняем следущие команды.

А если ранее PXE уже настраивали, то вместо добавления опций, отредактируем имеющиеся.

Теперь пропишем наши dhcp-опции для определённого компьютера, для которого уже имеется статическая запись в блоке lease (нужную запись можно определять по IP-адресу или MAC-адресу).

Осталось создать файл fedora-coreos.ipxe и разместить его на web-сервере Synology, для того, чтобы он был доступен по адресу http://192.168.255.2/tftp/fedora-coreos.ipxe

Обратите внимание, что в строке kernel – присутствует запись initrd=$ , она должна быть обязательно, иначе при загрузке появится kernel panic с ошибкой VFS: Unable to mount root fs on unknown-block(0,0) . Этой записью мы говорим, что файл, который мы загружаем строкой initrd – это и есть наш Initial RAM Disk. Теперь можно загружать наш компьютер или виртуальную машину. Сначала загрузчик iPXE обратится к конфигурационному файлу, который мы вкомпилировали в загрузчик: dhcp && chain $ , затем iPXE получит IP-адрес по DHCP и по цепочке перейдёт к конфигурационному файлу, ссылка на который находится в переменной $ , а в эту переменную попадает то, что указано в 17-й опции DHCP, т.е. ссылка http://192.168.255.2/tftp/fedora-coreos.ipxe . Далее загрузка будет проходить по этому скрипту.

Создание Ignition файлов для первоначальной настройки Fedora CoreOS:

В Fedora CoreOS, так же как и в RedHat Enterprise Linux CoreOS (RHCOS) для инициализации дисков и первоначальной установки и настройки используется утилита Ignition . Ignition – это утилита для манипулирования дисками во время загрузки initramfs . Это включает в себя разбиение дисков, форматирование разделов, запись файлов и настройку пользователей. При первой загрузке Ignition считывает свои настройки из конфигурационного файла и применяет эту конфигурацию. Создадим простой файл для Ignition, в котором мы пропишем ssh-ключ для пользователя core , включим автологин для консоли tty1 , пропишем часовой пояс и отключим debug-сообщения в консоли.

Для того, чтобы данный файл был обработан при загрузке CoreOS, необходимо в файл fedora-coreos.ipxe добавить необходимые опции ядра для работы с файлом Ignition.

Теперь можно перезагружать компьютер или виртуальную машину.

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

На официальном сайте Ignition можно посмотреть различные варианты настроек, включая автоматическое присвоение имени хоста. Но так же имя хоста для CoreOS можно передавать через DHCP-опцию 12 и оно будет автоматически прописано после загрузки. На MikroTik эту опцию можно прописать таким образом:

Настройка автоматического обновления образов CoreOS:

Для автоматического обновления образов Fedora CoreOS я написал небольшой скрипт, который запускает Task Scheduler на Synology раз в сутки. Когда появляется новое обновление – по почте приходит письмо от Task Scheduler.

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

в веб-интерфейсе Synology открываем Control Panel, выбираем в блоке System пункт Task Scheduler;
открываем вкладку TFTP и ставим галочку напротив пункта Enable TFTP service;
нажимаем на кнопку Create и выбираем в меню пункт Scheduled Task \ User-defined script;
во вкладке General в поле Task пишем Fedora CoreOS Updater ;
во вкладке Schedule выбираем время для запуска скрипта и ежедневный тип запуска;
во вкладке Task Settings отмечаем галочкой отправку уведомлений по почте, вводим свой почтовый адрес и отмечаем галочкой пункт Send run details only when the script terminates abnormally;
далее в пункте User-defined script пишем команду /volume1/docker/tftp/fedora-coreos/get-fedora-coreos.sh /volume1/docker/tftp/fedora-coreos ;
нажимаем на кнопку OK для сохранения задачи.

Как видно из настроек Task Scheduler, уведомление по почте Synology может отправлять или каждый раз при запуске задачи, или только при появлении ошибок. Поэтому в последней строчке скрипта специально выполняется команда exit 255 для симуляции ошибки, для того, чтобы уведомление приходило каждый раз, как будут обновлены образы Fedora CoreOS.

В следующей заметке настроим matchbox , для того, чтобы каждая нода кластера kubernetes получала свой собственный iPXE скрипт и конфигурационный файл Ignition.

Источник

intrudo

в борьбе с машиной

Tag Archives: Synology

Windows Deployment Services, PXE и другие

Сегодня хочется поболтать о такой замечательной штуке, как Preboot Execution Environment (PXE). Использовать ее, на мой взгляд, одно удовольствие. И не важно, домашняя у нас сеть или продакшен. Особенно приятно, если мы балуемся виртуалками: одно дело — выбрать нужную ОС из списка при загрузке и совсем другое — искать на шаре соответствующий ISO-файл, а потом аттачить его к CD/DVD/BD-приводу.

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

Жил да был BOOTP протокол. Предназначался он для получения клиентом IP-адреса при загрузке машины. BOOTP поддерживал BOOTP расширения (BOOTP Extensions или их еще называли — BOOTP Vendor Extensions). BOOTP расширения могут передаваться клиентом в запросе и отсылаться BOOTP сервером при ответе.

Всем известный DHCP протокол является ничем иным, как развитием BOOTP протокола и обратно совместим с ним. Ясное дело, что BOOTP расширения тоже были унаследованы, только они теперь называются DHCP опции (DHCP Options). Каждая DHCP опция идентифицируется числовым идентификатором, называемым тэгом (DHCP Option Tag).

Вообще говоря, в связи с такой бурной историей, наименования одних и тех же вещей в разных RFC постоянно менялись («Как только меня не называли: и Жора, и Юра, и Гоша, и Гога, Георгий.» (С) Москва слезам не верит).

PXE протокол основан на DHCP протоколе с определенным набором DHCP опций, называемыми PXE опциями (PXE Options) и на TFTP протоколе. PXE опций довольно много. Вот самые интересные:

6 — настройки обнаружения загрузочного сервера
8 — тип загрузочного сервера
9 — меню для выбора загрузочного сервера
10 — строка приглашения
43 — информация производителя (#6, #8, #9, #10, #71, …)
55 — список необходимых клиенту параметров (#1, #3, #43, #60, #128-#135)
60 — идентификатор класса вида «PXEClient:Arch:xxxxx:UNDI:yyyzzz»
61 — идентификатор клиента Universally Unique Identifier (UUID), в терминологии Microsoft — Global Unique Identifier (GUID)
66 — имя загрузочного сервера
67 — имя загрузочного файла Network Bootstrap Program (NBP)
71 — тип загрузочного сервера и уровень
93 — тип архитектуры клиента (x86, x64, …)
94 — версия Universal Network Device Interface (UNDI)
128-255 — специализированные опции производителя

Опции #1 и #3 — это стандартные опции DHCP:

1 — маска подсети
3 — таблица маршрутизации

Кстати говоря, опцию 61 можно увидеть при загрузке машины:

Вопросы, что такое GUID, теперь снимаются

Таким образом, чтобы PXE протокол заработал, нужно, чтобы наш DHCP поддерживал PXE опции. И тут нас поджидает коварность. Дело в том, что поддержка PXE обычно реализована в суровых взрослых железяках, а производители домашнего оборудования крайне редко грешат этим.

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

Это не так. Дело в том, что есть такая штука как DHCP прокси (proxy DHCP). PXE опции могут поддерживаться как DHCP, так и DHCP прокси, а самое замечательное, что DHCP прокси может располагаться как на DHCP, так и на отдельном сервере. Если у нас нет родной поддержки PXE, достаточно развернуть в сети DHCP прокси с соответствующей поддержкой.

Как видим, комбинаций довольно много. Рассмотрим как будет работать PXE протокол для самого интересного случая: при наличии DHCP без поддержки PXE и DCHP прокси с PXE:

BIOS после прохождения POST передает управление Initial Program Load (IPL)
IPL формирует PXE опции #60, #61, #93, #94
IPL отправляет широковещательный DHCPDISCOVER запрос с PXE опциями на порт 67
DHCP выдает обычный DHCPOFFER без PXE опций
IPL понимает, что PXE протокол не поддерживается на DHCP
DHCP прокси выдает DHCPOFFER без PXE опций и IP-адресом вида «0.0.0.0»
IPL понимает, что имеет дело с DHCP прокси
IPL отправляет широковещательный DHCPREQUEST запрос с PXE опциями на порт 4011
DHCP прокси выдает DHCPACK с PXE опциями, включая #66, #67
IPL загружает указанный NBP по протоколу TFTP
IPL передает управление NBP

Вот, собственно и все. Подробнее можно прочитать о PXE протоколе в этом документе: /ссылка/. Теперь можно поговорить о софте.

Существует достаточное количество продуктов, поддерживающих PXE. Обычно они содержат DHCP/DHCP прокси и TFTP. Но, как всегда, возникает куча вопросов в производителям.

Продукты Synology, думаю, известны многим (кто не общался — прошу сюда: /ссылка/). Начиная с прошивки DSM 4.2, Synology стала поддерживать PXE. Все бы хорошо, но чтобы оно завелось, нужно установить на Synology DHCP пакет, фактически превратив NAS в DHCP сервер! Самое неприятное то, что DHCP прокси не поддерживается (во всяком случае — пока).

Интересно, найдутся ли люди, которые решат использовать NAS еще и в качестве DHCP сервера? Они наверняка найдутся, ну а раз так, что и PXE функционалом смогут легко воспользоваться. Но лично я — не готов.

Легко выкачивается отсюда: /ссылка/. Компактная, имеет кучу настроек. Кроме DHCP прокси и TFTP поддерживает кучу других протоколов: HTTP/FTP/DNS/DHCP/SNMP/SYSLOG. Позволяет устанавливать не только Windows-системы, но и Linux.

Основные проблемы у Serva следующие:

Это десктоп-приложение, каких-либо настроек для запуска в виде сервиса я не нашел
Настройки довольно запутанные, требуется много ручной работы (создать и расшарить папки, прописать операционные системы и пр.)
Стабильность далека от идеала, я бы сказал — далека от стабильности вообще

Если требуется иногда устанавливать ОС по сети — вполне можно воспользоваться. Для более серьезной работы, имхо, не очень подходит.

WINDOWS DEPLOYMENT SERVICES

Устанавливается включением соответствующей роли в Windows Server. Работает как сервис. Так как это Microsoft, то у нас есть определенное качество, но и определенная путаница.

Практически все обзоры по Windows Deployment Services (WDS) начинаются с того, что WDS требует Microsoft Active Directory и Microsoft DHCP Service. Естественно, прочитав такое, хочется сказать: «Ой ё!» и пойти поискать кого-нибудь попроще, например, Serva.

На самом деле — это не так! WDS может работать в режиме standalone, в котором не требуется ни AD, ни DHCP (уже становится ясно, что WDS в таком режиме будет работать как DHCP прокси).

Немного поигрался с WDS и решил использовать его.

У Acronis есть очень интересные решения. Почитал, почереповал, решил, что хочу бесплатно и хочу попробовать WDS.

Основной минус Serva и WDS в том, что они не поддерживают ISO-файлы напрямую. Это означает, следующее: представьте, что у нас есть куча ISO-файлов, закаченных с MSDN или TechNet. Те системы, которые нужно будет устанавливать через PXE, придется распаковать, а потом зарегистрировать в соответствующем продукте! Ну не бред ли?

Рассмотрим какими путями можно идти:

Распаковать ISO-файлы. Минус: сотня распакованных ISO-файлов по 4 Гб каждый потребуют 400 Гб дискового пространства. Довольно серьезный объем, особенно в домашней инфраструктуре, самое обидное, что сами-то ISO у нас уже хранятся и удалять их не айс: возможно потребуется их замонтировать в VMware или Hyper-V или просто прожечь на болванки. Плюс: если нужна производительность и у нас выделенный сервер, то и обид нет.
Смонтировать ISO-файлы. Минус: потеря производительности по чтению по сравнению с распакованными файлами. Если ISO-файлы лежат на сетевой шаре, то мы вообще можем упереться рогами в сеть или в сетевой диск. Плюс: мы сильно экономим дисковое пространство.

Что касается распаковки, то в мире Windows это можно легко сделать — софта навалом, хоть WinRAR’ом. С монтированием же есть приколы.

Если говорить про Synology, то он умеет монтировать ISO. Правда поддерживается всего 16 точек, поэтому сложно представить, кому это надо.

Если говорить про Windows, то монтировать ISO умеют многие («А теперь откиньтесь на спинку кресла…» (С) Microsoft, в смысле что у них теперь есть софтина для Windows 7 и встроенная поддержка в Windows 8).

Но все производители софта с упорством, достойного моего непонимания, монтируют на виртуальные приводы CD/DVD/BD. Соответственно, если нам нужно смонтировать, скажем, 40 ISO, то понятное дело, что нас будет ждать большой облом — виртуальные диски в системе закончатся.

Ну почему никто не монтирует ISO на reparse points? Или все таки есть такие?

Оказывается, что есть. Встречаем Pismo File Mount Audit Package или PFM — /ссылка/.

Признаться, когда я нашел PFM, я понял, что задача с монтированием ISO решена. Эта штука умеет монтировать ISO-файлы на папки, причем поддерживается как локальная файловая система, так и сетевая. Монтирует довольно оригинально — файл превращается в папку с именем файла, в которую можно зайти и увидеть ISO контент (к слову — можно монтировать еще и ZIP-файлы).

Продукт меня немного застремал: для монтирования на виртуальные папки используются самописные драйвера, а они, как известно, могут положить машину на лопатки, в смысле — загнать в BSOD. Тем не менее, мне показалось, что PFM более чем стабилен: я периодично развлекался с ним в течении дня и все работало отменно. Пользовательский интерфейс мог бы быть посовременнее, но у многих он гораздо хуже.

Что же произошло далее? А далее произошла мелкая неприятность, из-за которой я отказался от PFM. Начну с того, что PFM не поддерживает auto mount. Т.е. перегружаемся и опа, нужно все монтировать заново.

Нас, конечно, этим не испугать. Быстро было обнаружено, что в комплект PFM входит консольная утилита с одноименным названием, которая умеет делать все, что умеет делать UI. Следовательно, можно сбацать какой-нибудь PowerShell-скриптец, да включить его в автозагрузку. Список ISO-файлов хранить в текстовом файле или в простенькой БД… Вот тут и пришла печаль…

Ребята, вы сделали для работы с консолью утилиту PFM.EXE, отлично! Но какого фига она возвращает любые ошибки через MessageBox? Например, указанного для монтирования файла нет, хопа, MessageBox с ошибкой и висим… Ждем реакции пользователя… А слабо просто писать ошибки в Events Log или в STDERR и возвращать код ошибки? У вас же консольная утилита!

Мелькнула мысль, что ребята из Pismo могут быть круты и запуск из под Local System или в виде сервиса приведет к использованию Events Log, но надежда умерла после соответствующих экспериментов.

Резюме: использовать в серверном окружении нельзя. Решил написать об этом продукте только потому, что в целом впечатление осталось приятным, возможно, что кому-нибудь на десктопе да и пригодится.

Теперь мы можем сформировать задачу:

У нас есть куча ISO-файлов на локальной или сетевой файловой системе (ISO-репозиторий)
У нас есть WDS сервер
Нужно смонтировать ISO-файлы и потом зарегистрировать их в WDS

Известно, что Linux умеет монтировать ISO-файлы на файловую систему из коробки (отвлеченно: на Synology тоже крутится Linux). Возникла мысля сделать «переходник»: небольшую виртуальную машину с Linux, замонтировать на нее файлы из ISO-репозитория, расшарить маунты, а далее уже регистрировать их в WDS. Все, что было сказано выше — это предварительная словесная лабуда, сам пост задумывался как описание полученного решения… Сразу оговорюсь, что я не линуксоид. Возможно, что я изобрел педали для велосипеда или прорыл параллельный тоннель, у кого есть что сказать — милости просим.

Ставить будем Debian 7.0 (Debian GNU/Linux 7.0.0 «Wheezy» — Official amd64 NETINST Binary-1 20130504-14:43) на виртуалку Hyper-V 3.0 (Windows Server 2012).

Параметры виртуалки такие:

1 виртуальный процессор
256 Мб оперативки
8 Гб диск

Народ в инете пишет, что нужно использовать Legacy Network Adapter вместо Network Adapter, потому что последний не поддерживается Debian. Судя по всему, это верно для предыдущих версий Debian, в выбранном дистрибутиве есть поддержка интеграции с Hyper-V (работает Network Adapter и Shutdown). Перечисленные фишки крайне важны: Network Adapter быстрее Legacy, а без корректного «гашения» виртуалки — вообще дело труба.

Установка проходит довольно быстро и гладко, когда дело дойдет до Software selection — рекомендую снять все галки, включая Standard system utilities:

Минимализм в данном случае — благо

Итак, операционка поставлена, теперь нужно немного ее поднастроить… Сразу ставим Midnight Commander:

Отключаем IPv6 (не пользуюсь):

Теперь можно обнаружить, что машины не пингуются по именам, а сам «переходник» не виден в сети из Windows-окружения. Ставим пакеты:

Все, машинка готова к бою.

Итак, наша исходная точка — ISO-репозиторий. Назовем путь до директории репозитория — SOURCEDIR. Он может располагаться:

на локальной файловой системе «переходника»
на какой-то сетевой шаре

В случае локальной файловой системы, у нас есть путь к директории репозитория — SOURCEDIR. В случае сетевой шары у нас есть путь до репозитория — CIFSDIR, который нужно смонтировать на локальную файловую систему, после чего мы получаем тот же SOURCEDIR. Для монтирования нам могут потребоваться креды — USERNAME и PASSWORD.

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

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

Теперь у нас есть окончательный путь к SOURCEDIR. Это «вход» для «переходника». Теперь разберемся с «выходом».

Монтировать ISO файлы мы будем в директорию, которую назовем TARGETDIR. Ее нужно создать:

А затем расшарить для Windows (мне вполне будет достаточно guest и RO):

Вот такая подготовительная работа…

Сценарий монтирования ISO-файлов из репозитория:

Выбираем рекурсивно все файлы *.iso из директории SOURCEDIR. Рекурсивно — потому что ISO-файлы могут быть разбросаны по папкам. Получаем линейный список вида SOURCEDIR/FILENAME, где FILENAME — имя ISO-файла. Основное требование — отсутствие повторов, файлы с одинаковыми именами, разбросанными по разным папкам — беда.
Для каждого ISO-файла будем создавать одноименную директорию в TARGETDIR. Если папка уже существует, считаем это аварийной ситуацией.
Последовательно монтируем каждый ISO-файл в точку TARGETDIR/FILENAME.

Смонтировать ISO можно командой:

Для монтирования ISO используется loop device. По-умолчанию, в системе их всего 8. Убедиться в этом можно вот так:

Таким образом, смонтировать мы сможем только 8 ISO-файлов, а потом — получим ошибку « mount: could not find any free loop device «. Чтобы убрать это ограничение, можно прописать необходимое число loop device в конфиг и перезагрузить систему:

Еще одно ручное подкручивание системы…

Сценарий размонтирования ISO-файлов (считаем, что владеем директорией TARGETDIR эксклюзивно — там только наши данные и их преспокойно можно грохать):

Размонтируем все точки TARGETDIR/*
Удаляем все директории из TARGETDIR

Команды для размонтирования ISO и удаления директорий:

Удаляемые директории должны быть пустыми, иначе завалимся. Будем считать, что это вполне нормальная защита от удаления чужих данных.

С размонтированием есть один забавный момент. Если не сделать размонтирование сетевых ISO-файлов, то при выключении/перезагрузке машины мы будем висеть на «Unmounting local filesystem…» 5 минут, а потом — повалят ошибки:

Причина в том, что сетевой интерфейс гасится до «Unmouting local filesystem».

При изменениях в ISO-репозитории необходима синхронизация между SOURCEDIR и TARGETDIR (например, в репозитории добавились новые ISO-файлы). Для синхронизации можно придумать какой-нибудь умный механизм (монтировать новые файлы, размонтировать удаленные), но пока вполне достаточно все размонтировать, а потом все заново смонтировать.

Описанные сценарии были воплощены в жизнь в виде скриптов:

isorep.conf — конфигурационный файл
isorep.sh — скрипт со сценариями монтирования, размонтирования и синхронизации
isorepd.sh — скрипт для автозапуска isorep.sh при старте и останове/перезагрузке системы

Пока что предполагается ручная установка файлов в систему.

Копируем файл isorep.conf в директорию /etc. Все настройки конфига совпадают с параметрами, описанными ранее. Нужно только прописать свое родное.
Копируем файл isorep.sh в директорию /bin. Устанавливаем для него пермиссии:

Копируем файл isorepd.sh в директорию /etc/init.d. Тоже устанавливаем для него пермиссии. Чтобы прописать автоматический запуск скрипта при загрузке системы (монтирование) и при останове/перезагрузке (размонтирование), воспользуемся командой:

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

Файл isorepd.sh уже настроен так, чтобы автозапуск происходил в определенных точках (например, до гашения сетевых интерфейсов и т.п.). Основной скрипт isorep.sh можно запускать руками в любое время.

Итак, пришло время посмотреть, что у нас получилось. Запускаемся:

Скрипт отработал, все ISO-файлы из репозитория замонтированы и видны в Windows Explorer:

Посмотрим, какая получилась скорость передачи ISO-файлов из ISO-репозитория и файлов из маунтпоинтов. Понятное дело, что сравнивать чтение монолитного файла и «рассыпухи» не совсем корректно, но все же интересно. В качестве ISO-файла возьмем какой-нибудь дистрибутив Windows 7, там есть несколько больших файлов, например, install.wim, на них и замерим… Использовать будем FAR 3.0 x64 с отключенной опцией «Use system copy routine».

Чтение монолитного ISO-файла из CIFSDIR — 34 Мб/с в пике (у меня довольно древний Synology)
Чтение содержимого ISO-файла из TARGETDIR — 24 Мб/с в пике

Похоже, что «просадка» составляет около 10 Мб/с. К слову надо сказать, что чтение через PFM дает результаты похуже — около 20 Мб/с.

Теперь осталось сделать последний шаг: развернуть WDS и добавить в него нужные Boot Images (boot.wim) и Install Images (install.wim), которые находим в соответствующих директориях в TARGETDIR.

Создаем Hyper-V виртуалку, выставляем загрузку по сети:

Загружаться будем через PXE

WDS прекрасно подцепился

Вот из-за чего был весь «сыр-бор» — задача решена:

Когда есть выбор — это хорошо

Что можно сказать в заключение. Полученное решение вроде рабочее. Но было бы гораздо лучше, если бы:

WDS научился работать с ISO-файлами напрямую
Microsoft или кто-то другой сделал утилиту для монтирования ISO-файлов на reparse points или ребята из Pismo довели бы PFM до ума

Источник