LINUX.ORG.RU
ФорумAdmin

PXE загрузка бездисковых станций (Debian)


0

4

Доброго времени суток, уважаемые.

Есть задача создать систему которая будет загружаться по pxe и работать на тонких клиентах. Система должна быть миниатюрных размеров, чтобы с приемлемой скоростью грузиться по сети и содержать в себе минимальный набор софта с Xами. По сути должен получиться образ initrd, который загрузится по сети и смонтирует удаленные каталоги пользователей, которые будут доступны им для записи. Нечто подобное обсуждалось вот в этой теме [PXE boot] deb based , но к сожалению так и не известно чем закончилось. Для сборки образа я использую debootstrap из пакетной базы Debian, но образ получается достаточно большого размера (>200Mb). И во время загрузки ругается на невозможность создания файлов. Как я понял эта проблема в Ubuntu решается при помощи casper'а. Если кто то довел данную идею до ума поделитесь пожалуйста опытом.

Есть задача создать систему которая будет загружаться по pxe и работать на тонких клиентах. Система должна быть миниатюрных размеров, чтобы с приемлемой скоростью грузиться по сети и содержать в себе минимальный набор софта с Xами.

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

У меня сложилось впечатление что ты не совсем понимаешь что такое тонкий клиент.

Marchael ()
Ответ на: комментарий от Marchael

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

nuxster ()
Ответ на: комментарий от realloc

Я пробовал делать при помощи live.debian.net (live-helper), образ получается очень большой и тяжелый, по сети грузить вообще анреал. debootstrap делает гораздо более стройный набор.

nuxster ()
Ответ на: комментарий от AITap

Ситуация такая, что очень много пользователей и пользователи постоянно меняются, если раздавать по nfs то сетка колом встанет. Для некоторых пользователей будут монтироваться шары с доступом на запись.

nuxster ()
Ответ на: комментарий от nuxster

В каком виде образ достаётся клиентам? На какие файлы ругается система при запуске?

Видите ли, беда в том, что casper - это почти то же самое, что live-build, так что Вы столкнётесь с теми же проблемами слишком большого образа.

AITap ★★★★★ ()
Ответ на: комментарий от AITap

Клиенты загружаются по pxe. В настройках которого указано примерно следующее:

kernel pxe/debian/vmlinuz
append initrd=pxe/debian/initrd root=/dev/ram0 ramdisk_blocksize=4096  ramdisk_size=524288

Точные сообщения об ошибках пока не могу привести, т.к. экспериментируя в данный момент все начал с нуля. Но ругался на то что не может создать pid-файлы в /var/run, на что то в /tmp. Было что то еще но не помню уже, что именно. Сейчас заново все соберу и если будут ошибки выложу их сюда.

В /etc/fstab у меня следующее:

/dev/ram0        /       ext2     defaults        1 1
proc            /proc   proc    defaults        0 0
tmpfs           /tmp    tmpfs   defaults,noatime,mode=1777,size=100m    0 0
tmpfs           /var/run        tmpfs   defaults,noatime,mode=1777,size=100m    0 0
tmpfs           /var/lock       tmpfs   defaults,noatime,mode=1777,size=100m    0 0

nuxster ()
Ответ на: комментарий от AITap

Видите ли, беда в том, что casper - это почти то же самое, что live-build, так что Вы столкнётесь с теми же проблемами слишком большого образа.

Насчет casper я уже понял, что это не лучший выбор. Но должно же быть еще что то?!

nuxster ()
Ответ на: комментарий от nuxster

root=/dev/ram0
/dev/ram0 / ext2

Не лучше ли initramfs или squashfs? При этом, правда, придётся пересобрать ядро.

Но ругался на то что не может создать pid-файлы в /var/run, на что то в /tmp.

У себя с / в squashfs я обхожу это добавлением -n к опциям mount в /etc/init.d/mountall.sh и созданием симлинка /etc/mtab -> /proc/mounts. В fstab при этом монтируется куча tmpfs в разные места, в которые системе может понадобиться писать.

AITap ★★★★★ ()
Ответ на: комментарий от nuxster

Посмотрите, как это делается у меня: https://github.com/aitap/minigparted

Я преследую немного другие цели, но в результате всё равно получается система с иксами, завернутая целиком в squashfs.

Обратите внимание, приходится монтировать /proc, /sys, tmpfs /dev и создавать /dev/null и /dev/console до запуска настоящего /sbin/init.

AITap ★★★★★ ()
Ответ на: комментарий от AITap

Большое спасибо! Сейчас попробую сделать на вашем примере.

nuxster ()

Если ты хочешь X'ы, да еще с приложениями, и еще не хочешь запускать проги через сеть, то образ меньше 200Мб не получится.

Другие варианты:
1) взять маленький дистрибутив (например Puppy или Slax)
2) грузить тока ядро и прогу терминального подключения (rdesktop), после загрузки чтобы подключалось к серверу (xrdp) автоматом и юзер уже на сервере работал. Эти варианты в инете тоже обсуждались.

Novator ★★★★★ ()
Ответ на: комментарий от Novator

Сильно зависит от приложений, тулкитов, DE и драйверов. DSL в 50 метров укладывается (squashfs, ЕМНИП). Тот же Qt4 больше 50 метров весит.

gadfly ★★ ()
Ответ на: комментарий от nuxster

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

С сеткой ничего не будет, если ты не гонишь траффик через маршрутизаторы, конечно. Раком скорее всего станет запись на винчестер. Говносвитч даст тебе 100мегабит от каждого клиента до сервера. На сервере поставишь гигабитный сетевой тырфейс, а вот сможешь ли ты с такой скоростью записывать данные на винчестер?

Топикстартер, короче, рут монтируй по NFSv3, в ридонли. Придётся немного попилить дебьян для этого. Монтируй поверх udp: производительность в 4 раза выше (я мерял).

Гостевую систему сделай при помощи debootstrap, прямо внутри chroot настрой, затем расшарь по NFS. Подними dhcpd и tftpd, если сетка маленькая - сойдёт dnsmasq, он и то и то умеет. Сценарий примерно такой: тонкий клиент посылает dhcp-запрос и получает айпишник и адрес tftp-сервера, с которого сливает бинарник pxelinux (возьми из пакета syslinux), который сливает и загружает в память ядро linux (и initrd) и передаёт ему параметры и управление, а дальше linux (точнее дебьяновский initrd, который нужно перегенерить будет в том chroote, посмотри /etc/initramfs-tools/initramfs.conf и сделай там BOOT=nfs). Все инитскрипты лежат на расшаренном каталоге. Придётся подмонтировать /tmp и некоторые каталоги в /var чтобы тонкие клиенты не конфликтовали.

Для ядра параметры что-то вроде: root=/dev/nfs nfsroot=serverip:/exported/path,rsize=8192,wsize=8192,intr,acregmin=30,acregmax=300,acdirmin=30,acdirmax=300,noposix,noacl,cto,ac,udp,soft

Далее, как собственно работают пользователи: есть два пути: тёмный и светлый. Тёмный - это когда у тебя на тонком клиенте установлены все приложения и они работают на тонком клиенте, а хомяк пользователя монтируется по sshfs. Не используй этот путь. Светлый путь - когда на тонком клиенте только иксы, настроенный оконный менеджер и ssh-клиент. Тогда пользователь через ssh (см опцию -X в мане) запускает гуёвое приложение на сервере, где оно и работает, а на клиенте только отрисовывается окно. Тут кстати могут быть тормоза - растровую графику с большим разрешением не посмотришь (прощай гимп, да и браузер с большими картинками притормаживает), и видео не посмотришь. Ещё придётся форвардить USB от тонких клиентов на сервер. Но имхо это лучший путь: потому что так очень легко организовывать и бекапить пользовательские катклоги. Можно даже организовать raid0 через tcp и даже если у тебя выгорит один сервер - тонкие клиенты могут спокойно продолжить работу на другом. Плюс тонкие клиенты не требуют вычислительных мощностей для тяжёлых офисных приложений.

anonymous ()
Ответ на: комментарий от anonymous

Тоесть по сути - система действительно минимальна - дебьян, иксы, оконный менеджер ssh-клиент. Это нужно чтобы подконнектиться к серверу. Всё. В оперативке образ не нужно хранить, он на NFS-шаре, даже обновляться можно на лету (заходишь в chroot, aptitude update-бла-бла). Хотя на оперативке советую не экономить, потому что оно в свободной оперативе будет кеш, и система не будет каждый раз бегать по NFS за файлами - очень повышает производительность и понижает нагрузку на сеть.

Да, на клиентской системе из загрузки выкинь(!) nfs-common, пользы от него нет (ну или поставь NEED_STATD=no NEED_IDMAPD=no в /etc/default/nfs-common).

И да, рикамендую на тонких клиентах в sysctl.conf добавить:

# Увеличенные буфера для сокетов и прочий tcp-тюнинг net.core.rmem_default = 256960 net.core.rmem_max = 256960 net.core.wmem_default = 256960 net.core.wmem_max = 256960 net.ipv4.tcp_timestamps = 0 net.ipv4.tcp_sack = 1 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_fin_timeout = 20 net.ipv4.tcp_keepalive_intvl = 20 net.ipv4.tcp_keepalive_probes = 5 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_tw_reuse = 1

# Предпочитать кешировать inodы вместо содержимого файлов vm.vfs_cache_pressure = 500

# Не свопиться vm.swappiness = 0

# Подольше держать изменения в файлах в оперативной памяти vm.dirty_background_ratio = 30 vm.dirty_ratio = 50 vm.vm_dirty_expire_centisecs = 6000 vm.dirty_writeback_centisecs = 1000 vm.laptop_mode = 5

Писал всё по памяти, мог где-то накосячить.

anonymous ()

Кстати, если решишь таки загружать образ, подчисти перед его сборкой /var/cache/apt/archives и установи localepurge.

anonymous ()
Ответ на: комментарий от anonymous

С сеткой ничего не будет, если ты не гонишь траффик через маршрутизаторы, конечно. Раком скорее всего станет запись на винчестер. Говносвитч даст тебе 100мегабит от каждого клиента до сервера. На сервере поставишь гигабитный сетевой тырфейс, а вот сможешь ли ты с такой скоростью записывать данные на винчестер? ...

Спасибо за советы! На сервере и так гигабитный интерфейс + все клиенты подключены через гигабитный свитч. Также на сервере 5й рейд из SAS'овских дисков. Количество клиентов около 100 и когда они одновременно начинают грузить образ (размером в >200мб) с сервера, в первую очередь ложится сетка. Механизм загрузки по PXE мне тоже прекрасно известен и уже давно настроен и работает (установка винды, Debian'а, загрузка Backtrack и SystemRescueCd). Меня интересует создание минимального образа с X'ами (xserver+icewm) и rdesktop'ом, (+ опционально Writer и Calc). Набор драйверов тоже весьма мал, все клиенты идентичны и построены на интеловских чипсетах.

nuxster ()
Ответ на: комментарий от beastie

что у вас за сеть? 10Mbit на коаксиале?

Думаю такие сети уже редкость ))) Хотя я знаю где они до сих пор активно используются.

nuxster ()
Ответ на: комментарий от nuxster

Я не использую initramfs. Система целиком из target заворачивается в squashfs и подаётся ядру как initrd.

initramfs.conf у меня нет.

AITap ★★★★★ ()
Ответ на: комментарий от nuxster

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

Вероятно, в случае более сложной системы, как у Вас, разумно использовать aufs. Это не должно быть очень сложно: всего лишь смонтировать tmpfs, aufs и сделать pivot_root (посмотрите, как это сделано в SliTaz).

AITap ★★★★★ ()
Ответ на: комментарий от AITap

Наткнулся на (судя по всему замечательную вещь) buildroot . Но при сборке выдает ошибку:

make[1]: Entering directory `/bootimg/buildroot/output/toolchain/uClibc-0.9.33.2'
  HOSTCC extra/locale/gen_ldc
In file included from extra/locale/gen_ldc.c:45:
extra/locale/locale_mmap.h:46: error: '__LOCALE_DATA_WCctype_II_LEN' undeclared here (not in a function)
extra/locale/locale_mmap.h:46: error: '__LOCALE_DATA_WCctype_TI_LEN' undeclared here (not in a function)
extra/locale/locale_mmap.h:46: error: '__LOCALE_DATA_WCctype_UT_LEN' undeclared here (not in a function)
extra/locale/locale_mmap.h:47: error: '__LOCALE_DATA_WCuplow_II_LEN' undeclared here (not in a function)
extra/locale/locale_mmap.h:47: error: '__LOCALE_DATA_WCuplow_TI_LEN' undeclared here (not in a function)
extra/locale/locale_mmap.h:47: error: '__LOCALE_DATA_WCuplow_UT_LEN' undeclared here (not in a function)
extra/locale/locale_mmap.h:48: error: '__LOCALE_DATA_WCuplow_diffs' undeclared here (not in a function)
extra/locale/gen_ldc.c: In function 'main':
extra/locale/gen_ldc.c:195: error: '__LOCALE_DATA_WCctype_data' undeclared (first use in this function)
extra/locale/gen_ldc.c:195: error: (Each undeclared identifier is reported only once
extra/locale/gen_ldc.c:195: error: for each function it appears in.)
extra/locale/gen_ldc.c:196: error: '__LOCALE_DATA_WCuplow_data' undeclared (first use in this function)
extra/locale/gen_ldc.c:197: error: '__LOCALE_DATA_WCuplow_diff_data' undeclared (first use in this function)
make[1]: *** [extra/locale/gen_ldc] Error 1
make[1]: Leaving directory `/bootimg/buildroot/output/toolchain/uClibc-0.9.33.2'
make: *** [/bootimg/buildroot/output/toolchain/uClibc-0.9.33.2/.configured] Error 2

Я так понимаю, что то с языками? Ни кто не сталкивался?

nuxster ()
Ответ на: комментарий от AITap

К стате, у SliTaz отличная документация по сборке образа!

nuxster ()
Ответ на: комментарий от Skolotovich

когда то давно делал нечто похожее на дебиане https://github.com/skolot/ladoshka

там есть вариант бута с tftp и rsync

Большое спасибо! Нашел кое что интересное для себя.

nuxster ()
Ответ на: комментарий от nuxster

Можно ли как то в подобную систему воткнуть udev?

так он там и так запускается из scripts/init-premount/udev

Skolotovich ★★★ ()
24 июля 2012 г.
Ответ на: комментарий от beresk_let

как я поборол локали :)

make[1]: *** [extra/locale/gen_ldc] Error 1 make[1]: Leaving directory `/bootimg/buildroot/output/toolchain/uClibc-0.9.33.2' make: *** [/bootimg/buildroot/output/toolchain/uClibc-0.9.33.2/.configured] Error 2

Вы это видите, значит ещё неделали конфиг юклибца, поэтому buildroot>$make uclibc-menuconfig появляется знакомое окошко менуконфига, только уже для uClibc несмущаясь идём в раздел что-то Stdio и ищем пункт типа Заюзать локали выключаем локали к чертям (ибо этот моммент разрабы нагло ещё недопилили) EscEsc Сохраняем конфиг

$make опа, процесс пошёл дальше..

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.