См. тж. http://www.altlinux.org/LTSP
всё, что касается установки, настройки и работы LTSP 4.2 в Альте; некоторые моменты являются общими для LTSP3/4/5 и других применений сетевой загрузки
(openvt выдирается из чего-нить совместимого, тут нашёлся от RH9)
выдрать и положить для свободного скачивания
Внимание! Если клиент пытается загрузиться, при этом в логе dhcpd видны повторяющиеся сообщения DHCPDISCOVER и DHCPOFFER (т.е. нас спрашивают, мы выдаём адрес, но его игнорируют и спрашивают опять) — сервер «неправильный» в более подробно указанном ниже смысле, поскольку не умеет загружать клиентов. (насколько понимаю, сделано для того, чтобы «случайно» запущенный левый dhcpd не смог уложить загрузку всей бездисковой сети — mike@)
Из документации LTSP применительно к /etc/dhcp/dhcpd.conf:
Здравствуйте! Aleksander N. Gorohovski wrote: >>> А просто загрузкой с дискеты (или с Lilo / com-файла) нельзя обойтись. >> В данном случае да. Либо загрузчиком с дискеты надо >> указывать ядру, откуда ему брать nfsroot. Правда, bootrom > > А как обычно можно это сделать? > Вроде DHCP уже передаёт эту информацию. Передает, но см. ниже. > Возможно я не до понимаю всю глубину и тайный замысел > создателей этой технологии, но как себе представлял > должно было бы быть не сильно сложно, а именно: > 1. > Не важно с какого устройста произошла загрузка терминала-клиента > (дискета, hdd, BOOT-ROM сетевой), он обращается на сервер к DHCP > чтобы получить свой IP (и пр. сетевые настройки), а также адрес > ядра и своей будущей корневой файловой системы. > 2. > Дальше, с этим адресом (корневой файловой системы) обращается > к TFTP чтобы загрузить ядро и корневой файловой системы > (или основную её часть) к себе в ОЗУ (или HDD, если есть) > 3. > Передать управление загруженному ядру. Наверное, как-то можно сделать и так (насчет дискеты и hdd), но в случае с бутромом есть отличия: 1. Код бутрома, который сидит в бутром-микросхемке на сетевой или в биосе, посылает широковещательный запрос: "а нет ли тут кого-нибудь, кто сможет меня загрузить?" 2. DHCP-сервер, который знает, что он умеет кого-то грузить (allow-booting, вроде, отвечает за это в dhcpd), отвечает: да, грузись. Вот тебе твой IP-адрес, вот тебе адрес файла, который надо грузить (вообще говоря, может лежать на другом хосте). Этот файл в моей конфигурации – загрузчик pxelinux (вроде может даже grub быть? не пробовал). 3. Бутром вытягивает загрузчик (по tftp), и передает управление на _него_. Тот лезет (опять по tftp!) на сервер, и пытается найти нужные настройки в pxelinux.cfg/... Порядок посика – в мануале на pxelinux. Если нашел, то в настройках указано ядро и параметры, которые надо ему передать. 4. Загрузчик вытягивает (и снова tftp!) ядро, и _возможно_ (не обязательно!) initrd (тоже указывается в конфиге pxelinux). После чего передает управление на ядро, указав ему соотв. параметры. В принципе, этого может быть достаточно, если всю корневую FS упихнуть в initrd, но так ее очень неудобно модифицировать. Поэтому 6. Ядру, среди прочего, могут быть переданы настройки nfsroot'а в виде root=/dev/nfs nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>] ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>, причем последнее автоматом прописывается, если pxelinux'у дана опция IPAPPEND 1. 7. Ядро у меня монолитное, так что initrd ему не нужен. Оно спокойненько вытягивает по NFS корневую систему по мере надобности, запускает /sbin/init и живет долго и счастливо. > Странно, но получается, что это можно решить только > через PXE-загрузку. Вообще, хороший источник информации – http://syslinux.zytor.com/pxe.php. Там описано также, как обойтись без PXE-загрузки :) With best regards, LVU. _______________________________________________ Community mailing list Community@lists.altlinux.org https://lists.altlinux.org/mailman/listinfo/community
Здравствуйте! По поводу загрузки с дискеты: я сегодня наконец-то попробовал посмотреть, что за зверь etherboot, так вот, он умеет делать в том числе и загрузочные дискетки с PXE (и не только). Т.е., процесс загрузки полностью аналогичен описанному мной ранее, только код PXE грузится не из bootrom'а сетевой карты, и не из биоса, а просто с дискеты. Подобная конфигурация должна вам понравиться :) Смотреть здесь: http://www.etherboot.org/ – информация, исходники; http://rom-o-matic.net/ – online собиралка загрузочных образов. With best regards, LVU. _______________________________________________ Community mailing list Community@lists.altlinux.org https://lists.altlinux.org/mailman/listinfo/community
Не берите жуткую сборку ltsp-server-pkg-fedora, в incoming (Sisyphus и backports/3.0) уже уехал пакет ltsp-server-pkg и всё, что он должен вытянуть, аккуратно собранное и проверенное на 3.0.
Swap по NFS в LTSP4.2 уже не поддерживается (судя по диагностике — предположительно сборка ядра без CONFIG_NFS_DIRECTIO). Вместо него предлагается своп по NBD на специальным образом перепиленный NBD-сервер по имени ltspswapd. Детали, кроме ужасов про установку, см. ltsp wiki. Собственно кроме пакетов — они сводятся к включению в /opt/ltsp/i386/etc/lts.conf опции USE_NBD_SWAP = Y.
Да... своп в основном нужен для Xorg, которого надувают всяческие Firefox. См. тж. это сообщение и обратите внимание на параметр lts.conf, значение которого задействуется в попытке посадить Xorg под ulimit -v — например, можно ограничить 85%:
Из local devices заработали floppy и usb flash (монтирование происходит в /Drives/<что-то>/ на TS); cdrom незаметен udev'у даже после прямого указания /dev/hdc в 15-ltsp-block.rules. Пока непонятно, в какую сторону его допинывать. Подробнее (опять же, зажмуриваемся при виде ужасов в рекомендациях по установке) — здесь.
NB: с кодировочками на FAT-носителях из коробки есть проблемы, см. здесь. Решаются методом захакивания /opt/ltsp/i386/etc/udev/scripts/ltsp-device.sh с добавлением в опции чего-то вроде iocharset=utf8,codepage=866 (для cdrom — только iocharset, если локаль с другой кодировкой — соответственно koi8-r, koi8-u или cp1251). Наводка была здесь.
Если используются нормальные файловые системы и/или на USB-диске (флешке) более одного раздела, придётся ltsp-device.sh дорабатывать (вешайте патчи, кого угораздит).
PS: cdrom пока упинали грязным хаком вида добавленного в /opt/ltsp/i386/etc/rc.localdev перед запуском ltspfsd принудительного вызова пробрасывалки устройства для /dev/hdc:
Со звуком: nas завести на скорую руку не вышло, с esd есть изумительная грабля, когда по netstat оказалось, что слушает он на клиенте аж 127.0.0.1. Пришлось изменить строку его запуска в /opt/ltsp/i386/etc/rc.sound таким образом (export ESD_SPAWN_OPTIONS="-public" чуть выше оказалось недостаточно — странно):
Также потребовалось нарисовать /etc/profile.d/esd.sh (в хост-системе, не /opt/ltsp) следующего вида:
xmms'ный плагин для вывода на esd умеет смотреть в эту переменную, если не конфигурировать его специальным образом, бишь оставить галку “Use remote server” выключенной.