Unix як Standard Operating Environment

Цей матер╕ал з'явився як вдумливо написаний Дмитром Ковальовим лист у розсилц╕ linux@linux.org.ua (див. також http://www.linux.org.ua) -- на мою думку, це вже тягне на editorial та не повинно залишитися лише там ;-)

Конверс╕я у HTML виконана Михайлом Шигор╕ним за допомогою txt2html.


Багатенько ви понаписували, поки я спав. Тож з деяким зап╕зненням включаюсь ╕ я.

On Wed, 26 Dec 2001 11:09:44 +0200 Yuriy Khylchuk <khylchuk@sec.rovno.ua> wrote:

YK> витрибеньки. Бажання мати якийсь один "правильний" дистрибутив який
YK> можна поставити натиском одн╕╓╖ кнопки - параф╕я Василя Х. Коли
YK> людин╕ саме це потр╕бно то ╖й краще залишатись з win.

Абсолютно нев╕рний п╕дх╕д. Якраз юн╕кс/л╕накс -- це т╕ системи, як╕ на сьогодн╕шн╕й день можлив╕сть мати повн╕стю сконф╕╜уровану систему, настро╓ну п╕д власн╕ вимоги, розтиражовану в тисячах прим╕рниках. П╕д "власними" вимогами розум╕╓ться або д╕йсно сво╖ власн╕ ("для дома для с╓м'╖"), або ж корпоративн╕ вимоги (SOE -- Standard Operating Environment) для користувач╕в. ╤ саме юн╕кс ставиться натиском одн╕╓╖ кнопки, ╕накше б я перейшов на в╕ндовс, якби я користувався методом "тут п╕дстругав, там п╕дрихтував" п╕сля установки кожно╖ окремо╖ системи.

>>>>> On Wed, 26 Dec 2001, "vesna" == vesna wrote:

vesna> Це все класно працю╓ для себе коханого. А що робити коли таких
vesna> машинок+користувач╕в з п╕всотн╕? Для мене це конкретне питання.
vesna> Зараз перетягую свою контору з одн╕╓╖ халепи до ╕ншо╖ :) Хто
vesna> проходив цей етап -- в╕дгукн╕ться.

Я мав досв╕д к╕лькох под╕бних ╕нфраструктур побудови систем. По к╕лька сл╕в про кожну з них:

> Serhiy Brytskyy <sbryt@softservecom.com> wrote:
>>Якщо машини одинаков╕, ╕нсталю╓ш одну, а дал╕ клону╓ш диски.

Дал╕ залиша╓ться т╕льки питання як саме ╖х клонувати? Якщо вони д╕йсно однаков╕ -- найпрост╕ший вар╕ант, це dd.

Якщо диски однаков╕

Bohdan Vlasyuk <bohdan@bodq.vstu.vinnica.ua>: > dd або tar або ╕ те ╕ ╕нше. На смак.

>>>>> On Wed, 26 Dec 2001, "Leon" == Leon Kanter wrote:
Leon> init 1; dd if=/dev/hda of=/dev/hdc

Але все одно морока -- для кожно╖ машини потр╕бно витягнути диск, перенести його на машину для клонування, там зробити dd з робочо╖ машини на чистий диск, в╕дключити в╕дклонований диск, вставити його ... ╕ т.д. Тобто, все одно для нормально╖ побудови треба придумати, як робити клонування через мережу. Для dd це можна робити приблизно так:

Якщо диски р╕зн╕

"Andriy Dobrovol's'kii" <dobr@iop.kiev.ua>:

> Р╕зне зал╕зо? Р╕зний софт збира╓тесь ставити? Р╕зне розбиття
> диск╕в? Що р╕зне?
> Коли все, то н╕чого не допоможе.

Не зовс╕м так.

Диски

Можна мати к╕лька конф╕╜урац╕й для стандартного розбиття диск╕в на п╕дрозд╕ли (в залежност╕ в╕д розм╕ру диску розбива╓ться так чи ╕накше -- установочн╕ скрипти мають якусь невелику базу даних з приблизно такою в╕дпов╕дн╕стю:

Розм╕р диску: / мб

              swap мб
              /var мб
              /tmp мб
              /usr мб

Мережа

Конф╕╜урац╕я мереж╕ фактично дуже слабо залежить в╕д типу зал╕за. ╢дине -- вставити потр╕бний модуль ethernet'у. Про в╕деоплату вже писалось -- мати к╕лька конф╕╜урац╕й для X ╕ п╕дставляти потр╕бну.

Дал╕ к╕лька модиф╕кац╕й до техноло╜╕╖ подано╖ вище.

    for FS in / /usr /var ...[що ще]; do #для кожного п╕дрозд╕лу
    find $FS \ 
    -mount \ # Don't descend directories on other filesystems 
    | cpio [...] | \
    rsh new_host "(mkdir -f ${FS}; cpio ... ${FS})" #(розарх╕вову╓ться на такий самий п╕дрозд╕л)
    done

Насправд╕, в одн╕й ╕з ф╕рм, де я працював, приблизно так було побудовану структуру для побудови наст╕льних кл╕╓нт╕в. На той час це був SunOS 4.3. ╢дина в╕дм╕нн╕сть, що sparc може вантажитись просто з мереж╕ без дискети.

Але вся ╕нша структура залишалась такою ж самою:

Новий кл╕╓нт вантажиться з мереж╕ з / на NFS, ╕ дал╕ в д╕ю вступа╓ звичайний perl-скрипт, який робить все, що описано вище. Т╕льки з в╕дм╕нн╕стю, що еталонна система (╖х насправд╕ було 4 - щоб можна було одночасну будувати до 4 кл╕╓нт╕в -- синхрон╕зувалися м╕ж собою за допомогою rdist) збер╕га╓ться насправд╕ на tftpboot сервер╕.

Побудова кл╕╓нта займала б╕ля 35--40 хвилин (тод╕ ще на мереж╕ 10baseT).

>>>>> On Wed, 26 Dec 2001, "Eugene" == Eugene Onischenko wrote:

Eugene> Користуйтесь програмами dump та restore.

Не знаю, наск╕льки dump/restore в л╕накс╕ зараз ╓ справд╕ робочими конями.

> http://www.cableone.net/ccondit/cdbackup/
> ========================================
> WARNING! When using this program under Linux, be sure not to use
> dump with kernels in the 2.4.x series. Using dump on an ext2
> filesystem has a very high potential for causing filesystem
> corruption. As of kernel version 2.4.5, this has not been resolved,
> and it may not be for some time.

Кр╕м того, вс╕ програми типу dump/restore залежать в╕д файлово╖ системи -- добре, якщо вс╕ кл╕╓нти плану╓ться будувати з одн╕╓ю файловою системою. ╤накше -- це не п╕дходить.

Kickstart ╕ типу нього

Про нього вже тут писалось, мабуть достатньо. Тому я особливо продовжувати не буду.

╢дине. Мен╕ не подоба╓ться дискета, зроблена на основ╕ syslinux для kickstart'а. Я зробив свою власну на основ╕ grub.

Проблема в тому, що syslinux -- дуже проста р╕ч, яка може вантажити ядро з т╕льки з дискети (фактично т╕льки MS-DOS форматовано╖ дискети). Але за рахунок сво╓╖ простоти сам syslinux дуже малий. Тому на дискету влазить ╕ ядро, ╕ initrd.img. Але. П╕сля побудови системи, якщо раптом забудеш витягнути дискету -- вона почина╓ перебудову знову :( ╕ буде ╖╖ будувати, аж поки диски не повил╕тають.

Тому я й зробив свою дискету - яка ма╓:


$ pwd
/mnt/floppy/boot
$ ls -lR
.:
total 755

drwxr-xr-x    2 root     root          288 Dec 14 14:40 grub
-rwxr-xr-x    1 root     root       768391 Dec 14 13:43 initrd.img

./grub:
total 106

-rw-r--r--    1 root     root          374 Dec 14 14:40 menu.lst
-rw-r--r--    1 root     root          512 Dec 14 11:15 stage1
-rw-r--r--    1 root     root       104484 Dec 14 11:13 stage2

$ cat grub/menu.lst
timeout 15
color black/cyan yellow/cyan
default 0

title linux
root (fd0)
kernel (hd0,0)/vmlinuz-2.4.9-13 root=/dev/hda2 devfs=nomount lang=ja initrd (hd0,0)/initrd-2.4.9-13.img
boot

title build
dhcp
tftpserver 1.2.3.4
root (nd)
kernel (nd)/vmlinuz ks=nfs:1.2.3.4:/export/kickstart/ks.cfg devfs=nomount ramdisk_size=7168 initrd (fd0)/boot/initrd.img


Тобто: з дискети неявно вантажиться ядро з диску, а якщо мен╕ потр╕бно побудувати систему, я повинен явно вибрати в мен╕ "build".

╤дея для подальшого розвитку (цього я ще не робив, але не бачу н╕яких принципових перешкод для того, щоб це можна було зробити):

Недол╕ком мо╓╖ дискети ╓ те, що п╕дтримку для мережево╖ плати треба вкомп╕льовувати в сам grub. Тобто, якщо в орган╕зац╕╖ ╓ к╕лька тип╕в плат мереж╕, потр╕бно або мати к╕лька р╕зних дискет, або мати ун╕версальний grub. Кр╕м того, "однаков╕" плати не завжди "однаков╕". Наприклад, я з╕ткнувся з ситуац╕╓ю, коли одна ╕ та ж плата epro100 (в середин╕ л╕накса використову╓ться один ╕ той же модуль - або eepro100 або e100) при завантаженн╕ з дискети на одних системах ╕н╕ц╕ал╕зу╓ться нормально, в ╕нших не може ╕н╕ц╕ал╕зуватись.

cachefs

>>>>> On Wed, 26 Dec 2001, "Eugene" == Eugene Onischenko wrote:

Eugene> 1. Якщо мережа >=100Mbit, то можна користуватись X-
Eugene> терм╕налами, _великий_ плюс цього це ц╕на терм╕нал╕в
[...]

Eugene> 2. Встановити все на сервер, ╕ / на кл╕ентах п╕дключати через
Eugene> nfs (майже теж саме що ╕ 1. але в╕д сервера майже н╕чого не
Eugene> потр╕бно).

Ще одним вар╕антом ╓ щось середн╓ м╕ж / на NFS ╕ / на локальному диску: cachefs. Я сумн╕вався, чи ╕сну╓ щось таке для л╕накса, але сьогодн╕ пошукав, ╕ виявля╓ться що вже ╓ якась розробка cachefs для л╕накса: http://www.cs.helsinki.fi/linux/linux-kernel/2001-22/0677.html Можливо це ще дуже бета стад╕я, але в близькому майбутьному щось з цього може вийти.

Суть проблеми в чому:
/ на NFS працю╓ досить пов╕льно. Щоб цього не було - локальн╕ робоч╕ станц╕╖ мають / на cachefs - який монту╓ться на вершин╕ локального swap'а. А вже swap зроблено на локальному диску. Тобто файлова система сервера кешу╓ться на локальному диску ╕ в результат╕ ма╓мо переваги обох систем. cachefs працю╓ пов╕льно т╕льки п╕сля побудови кл╕╓нта, до того часу поки не заповниться кеш - перш╕ к╕лька десятк╕в хвилин. П╕сля цього швидк╕сть роботи - така ж, як ╕ у кл╕╓нта з нормальним локальним диском.

На сервер╕ ми ма╓мо нормальний л╕накс з окремою директор╕╓ю для кожного кл╕╓нта, якому цей сервер нада╓ його /. Тобто щось типу:

/client-root -> /client-1 -> /etc ->...

                          -> /sbin
                          -> /bin
                          -> ...
             -> /client-2 -> /etc ->...
                          -> /sbin
                          -> /bin
                          -> ...

╕ так дал╕. Кожна директор╕я п╕д /client-X ма╓ як hard-link'и на файли самого сервера (наприклад, вс╕ /etc/init.d/ однаков╕ на вс╕х кл╕╓нтах, так само, як ╕ /etc/resolv.conf тощо), так ╕ окрем╕ файли, ун╕кальн╕ для кожного кл╕╓нта - /etc/sysconfig/network, тощо.

Це на практиц╕ означа╓, що будь-як╕ зм╕ни файл╕в (як╕ використовуються сп╕льно) на сервер╕ одразу ж видим╕ на вс╕х кл╕╓нтах. Зм╕ни розпихуються на кл╕╓нти через cachefs, як т╕льки система бачить, що локально кешована верс╕я файлу в╕др╕зня╓ться в╕д ори╜╕налу на сервер╕.

Тобто, побудова кл╕╓нта в цьому випадку вилива╓ться в створення тако╖ директор╕╖; наповнення директор╕╖ файлами чи жорсткими посиланнями на файли; конф╕╜урац╕╓ю arp/rarp/bootparams/tftpboot ╕ завантаженн╕ кл╕╓нта. Ця техноло╜╕я була в╕дома на Соляр╕с╕ п╕д назвою autoclient. "Була" тому, що Сан оф╕ц╕йно п╕дтримував autoclient до верс╕╖ 2.6, ╕ п╕сля цього перестав.

Зараз я працюю на такому cachefs-кл╕╓нт╕. Побудова нового кл╕╓нта займа╓ б╕ля 10 хвилин. Якщо в кл╕╓нт╕ треба зам╕нити диск (вилет╕в диск), кл╕╓нт перебудовувати не треба. Просто треба перевантажити кл╕╓нт з опц╕╓ю перебудови кешу (в Соляр╕с╕ boot -rvf). Завантаження займа╓ трохи довше, н╕ж звично (б╕ля 5 хвилин), але п╕сля завантаження ма╓ш точн╕с╕нько такий же самий комп'ютер, як ╕ був до цього (але з ╕ншим диском).

vesna> Це все класно працю╓ для себе коханого. А що робити коли таких
vesna> машинок+користувач╕в з п╕всотн╕? Для мене це конкретне питання.

На ц╕й техноло╜╕╖ в нас зараз працю╓ понад тисячу кл╕╓нт╕в на Соляр╕с╕ 2.5.1.

╤нш╕ вар╕анти

> mkCDrec makes a bootable (El Torito) disaster recovery image
> (CDrec.iso), including backups of the linux system to the same
> CD-ROM (or CD-RW) if space permits, or to a multi-volume CD-ROM set.
> Otherwise, the backups can be stored on another local disk, NFS disk
> or (remote) tape. After a disaster (disk crash or system intrusion)
> the system can be booted from the CD-ROM and one can restore the
> complete system as it was (at the time mkCDrec was run).

Теж дуже просто може використовуватись для клонування систем.

FAI (Fully Automatic Installation) for Debian GNU/Linux

> FAI is a non interactive system to install a Debian GNU/Linux
> operating system on a PC cluster. You can take one or more virgin
> PCs, turn on the power and after a few minutes Linux is installed,
[...]

> FAI's target group are system administrators how have to install
> Debian onto one or even hundreds of computers. Because it's a
> general purpose installation tool, it can be used for installing a
> Beowulf cluster, a rendering farm, a web server farm or a linux
> laboratory or a classroom.

З цих додаткових не користувався н╕ т╕м, н╕ ╕ншим. Але обо╓ виглядають досить об╕цяюче.

Ну от, це зда╓ться ╕ все. Якщо щось забув, пот╕м допишу. Звиняйте, що може, занадто багатосл╕вно.

Дмитро.

--
Dmytro Koval'ov
mailto:kov@tokyo.email.ne.jp
http://www.asahi-net.or.jp/~as9d-kvlv
Linux Ukrainian: http://linux.org.ua