Вход:  Пароль:  
FreeSource: Dokumentacija?/LTSP ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |

См. тж. http://www.altlinux.org/LTSP


LTSP4 в ALTLinux

всё, что касается установки, настройки и работы 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

Дела локальные

NBD swap

Не берите жуткую сборку 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

Из 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:

sound

Со звуком: 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” выключенной.

Ссылки


Страницы, ссылающиеся на данную: AltLinux/Dokumentacija/OpenVZ/NFS
Dokumentacija/LTSP5
ТЗ/ТерминальныеРешения


 
Файлов нет. [Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]