Ну, "на нет — и суда нет". Тем более, что NT эта самая выглядит на таких компьютерах откровенно жалко: не о чем, собственно, и жалеть. Окажется ли решение на основе Linux конкурентоспособным? Попробуем...

Теория

Разумеется, речь пойдёт об использовании клиент-серверной архитектуры. Во-первых, потому, что пресловутые "P-100 c 64МБ памяти" никак нельзя признать самодостаточными, а во-вторых, потому, что они и "в прошлой жизни" использовались только в сочетании с сервером, на что явно указывает наличие Xeon P-500 c 1ГБ памяти в составе гипотетического класса. Ясно, что максимально эффективной будет конфигурация, наиболее полно использующая ресурсы и станций, и сервера.

В первую очередь, приходит на ум LTSP (Linux Terminal Server Project), но не будем торопиться: ни отсутствие на станциях HDD (соответственно — удалённая загрузка), ни ssh-туннели между станциями и сервером нас не интересуют. А помещение своп-файла станции на сервере и некоторые другие особенности LTSP и вовсе представляются нехорошими излишествами.

Кроме того, всё-таки Linux — это "me too technology". Хочется — самому, поскольку, как написал когда-то Владимир Водолазский, "быть просто пользователем Linux — не интересно". А ещё хочется верить, что индивидуальный подход позволит выжать из этого "дарёного коня" всё, что только возможно.

Первый сервис, который можно и нужно использовать для создания подобной сети — это NFS (Network File System). Запустив nfsd (демон NFS) на сервере, мы решаем сразу три задачи:

• расширяем дисковое пространство станций (от 1ГБ собственного винчестера станции до 16ГБ, предоставляемых сервером);
• создаём единый, разделяемый всеми станциями ресурс, поскольку все они адресуются к одному и тому же серверу;
• обеспечиваем простоту и "единство" администрирования станций, поскольку только патологический трудоголик не вынесет в такой ситуации все конфигурационные файлы на сервер, заменив их на станциях символическими ссылками.

Вторым "краеугольным камнем" для создаваемой сети является клиент-серверная природа X Window. Поклонники Linux-десктопа, возможно, уже начали забывать, что используемая ими графическая система состоит из серверной и клиентской части, связанных друг с другом по TCP/IP и способных, в принципе, работать на разных хостах (как и положено, вообще-то, серверу и клиентам). Грубо говоря, нам и добавлять-то ничего не требуется, поскольку если сервис NFS, не исключено, в вашем дистрибутиве в качестве "умолчательного" и отсутствует, то уж X Window — присутствует наверняка.

Тонкое разделение функций между станциями и сервером может показаться не такой уж простой задачей: какие приложения лучше запускать непосредственно на станции, а какие — на сервере, используя станцию в качестве Х-терминала? Возможно и то, и другое, да вот только требования школьной программы таковы, что абсолютное большинство требуемых приложений не будет работать достаточно быстро, если их запускать непосредственно на станции. Желающие могут убедиться в этом, попытавшись поработать с OpenOffice, Firefox, Gimp или любым из приложений KDE на Р-100.

Таким образом, характеристики используемого оборудования и изрядная неповоротливость (чего уж греха таить?) большинства наиболее известных графических приложений под X Window, определяют выбор: станция обеспечивает работу X Window (с выбранным window-менеджером, разумеется), приложения же запускаются на сервере. Это справедливо, по меньшей мере, для приложений, используемых в рамках школьной программы.

В качестве сетевого протокола используется, конечно, TCP/IP. Адресация — статическая: все компьютеры имеют одинаковый файл /etc/hosts, в котором описаны имена и ip-адреса всех хостов. Поскольку изменение сети не предполагается, то после создания /etc/hosts вспоминать о нём, скорее всего, не придётся.

В теории — всё. Переходим к практической реализации.

Сервер

Сервер созданной сети выполняет тройную функцию:

• прежде всего это файл-сервер, обеспечивающий централизованное хранение файлов конфигурации станций и всех пользовательских файлов. Сам собой напрашивается также запуск на нём http-сервера, ПО, организующего обмен почтовыми сообщениями, и SQL-сервер (на тот случай, если образовательный процесс достигнет должной высоты);
• кроме того, сервер выступает как своего рода "сервер приложений", ведь именно на нём, собственно, и выполняется большая часть запускаемых пользователями заданий. Из чего следует, что он должен иметь пользовательские аккаунты, соответствующие пользователям станций. Причём, домашние каталоги этих пользователей должны содержать конфигурационные файлы, определяющие выполнение нужных приложений;
• и, наконец, сервер используется как единственное в составе класса рабочее место, на котором возможен запуск всех инсталлированных приложений. Фактически, алгоритм "расширения" функциональности класса таков: учитель знакомится на сервере с тем или иным приложением и, если посчитает нужным, делает его доступным для запуска на станциях.

Работа NFS сервера определяется, как известно, конфигурационным файлом /etc/exports. Вот строка, открывающая доступ станциям с ip-адресами 192.168.0.1 .. 254 к разделяемому каталогу /server:

  /server 192.168.0.0/255.255.255.0(rw,no_root_squash,sync)

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

Лидеры среди http- и SQL-серверов известны: это Apache и MySQL. Что не мешает, однако, использовать любой иной, представляющийся вам более подходящим, сервер.

А вот несколько моментов, требующих внимания, поскольку ни один дистрибутив в качестве умолчательных такие настройки не использует:

• имена всех станций нужно перечислить в файле /etc/hosts.equiv: это сделает возможным выполнение на станциях команды rsh (remote shell). rsh обеспечивает запуск команды на удалённом хосте, перенаправляя ввод и вывод последней в стандартные потоки. Если совсем просто, то именно rsh, "издаваемая" станцией, запускает приложение на сервере, при этом результат работы приложения возвращается станции;
• должен быть обеспечен запуск супер-демона, в качестве которого различные дистрибутивы используют inetd или xinetd;
• если запуск супердемона "по умолчанию" ещё встречается, то его конфигурация, позволяющая удалённый вход, а тем более запуск приложения, практически исключены. Придётся "раскомментировать" строки, разрешающие протоколы shell, login и exec в /etc/inetd.conf (если в ситеме используется inetd) или отредактировать (disable = no) файлы rlogin, rsh и rexec в каталоге /etc/xinetd.d (если используется xinetd);
• и, наконец, последнее. Если для отдельно стоящего компьютера "default  runlevel" — ваше личное дело, то для использования того же компьютера в качестве X-сервера придётся позаботиться об автоматическом старте X Window. При этом совсем не обязательно менять значение initdefault в /etc/inittab, во многих случаях предпочтительнее добавить в тот же inittab строку запуска дисплей-менеджера. Например, сохранив строку

         id:3:initdefault:
  

  добавим:

         xw:3:respawn:/usr/bin/gdm -nodaemon
  

  Сервер при этом будет загружаться в консольном многопользовательском режиме, запустив в то же время X Window и менеджер входа в систему gdm. Оговоримся, что численные значения runlevel в разных дистрибутивах определяются по-разному.

Что касается "пользовательских" функций сервера, то проще всего инсталлировать его в "полном" варианте, предоставив учителю/администратору самому в будущем определять, какие из наличных приложений предоставить ученикам, а какие — нет. Принимая во внимание наличие в составе KDE довольно обширной секции обучающих программ и сходство последней с MS Windows, именно KDE представляется оптимальной "сессией по умолчанию" для учителя.

Станция

Ну, со станцией — и того проще. Большинство дистрибутивов предлагает "базовый" вариант инсталляции, дополнить который следует только X Window и каким-нибудь window-менеджером. В качестве последнего можно рекомендовать IceWM. Этот полнофункциональный менеджер окон, со множеством конфигурируемых возможностей, отличается тем, что он... заморожен, как и подобает льду. То есть: конфигурация — конфигурацией, а обращенный к пользователю интерфейс абсолютно "непробиваем". Очень полезное качество, если в качестве пользователя выступает пятнадцатилетний непоседа, впервые столкнувшийся с IBM PC.

Специальных моментов всего два:

• обеспечить автоматическое монтирование разделяемого каталога сервера, что достигается одной строкой в /etc/fstab:

         server:/server /server nfs auto
  

  Краткий комметарий для незнакомых с nfs. В строке, по порядку:
  • server: — имя nfs-сервера
  • /server — имя разделяемого каталога
  • /server (второе вхождение) — имя каталога на станции, к которому монтируется разделяемый ресурс;
  • nfs — тип монтируемой файловой системы;
  • auto — опция автоматического монтирования при загрузке.
• занести в файл /etc/X0.hosts имя сервера (при необходимости — создать этот файл). Назначение этого файла — разрешить Х-клиентам хостов, перечисленных в файле, подключаться к 0-дисплею X-сервера, запущенного на данной машине. Витиевато? Согласен, но — верно. Чуть подробнее: серверная часть системы X Window, запущенной на станции, принимает данные клиентов. Что приняла — то и отобразила. Обычно такими клиентами являются приложения, запущенные на станции же. Клиент, запущенный на другом хосте (в нашем случае — на сервере), уже знает, что вывод нужно направлять X-серверу станции. Осталось предупредить последний, что клиент, обращающийся с сервера, имеет право на подключение. Как раз это и делает файл X0.hosts. "0", в данном случае, означает нулевой (в "человеческой" нумерации — первый) дисплей (возможно, кто-то уже забыл, что X Window может поддерживать одновременно несколько дисплеев).

Вообще-то, запуск на станции графического приложения, выполняемого на сервере, довольно сложный процесс. Запрос нужно направить на сервер, сообщив при этом имя пользователя, команду, которую нужно выполнить, и имя хоста, серверная часть X Window которого будет визуализировать вывод приложения. Ничего не знать о реально выполняющейся при этом rsh, номере используемого дисплея и особенностях авторизации позволяет нам команда:

  xon server application

где server — имя нашего сервера, а application — приложение, которое мы хотим запустить.

Таким образом, для запуска на станции приложений, список которых вы определите сами, в случае icewm достаточно внести в файлы меню пользователей (~/.icewm/menu) строки, аналогичные приведенной выше —.

"Последними штрихами" для станции могут стать выбор темы и фонового изображения для icewm, инсталляция fbxkb (индикатор раскладки клавиатуры, отсутствующий в составе icewm) и замена пиктограммы "IceWM" (на кнопке StartMenu) на что-нибудь более содержательное ("Пуск", например, если посчитаете нужным).

Особенности конфигурирования

Вид десктопа станции определяется конфигурацией её window-менеджера (icewm, в нашем случае). В то же время, содержимое окон формируется приложениями, запускаемыми на сервере. Из этого следует, что весьма желательно обеспечить идентичность настроек десктопов пользователей на станциях и сервере. Перечень этих настроек сравнительно невелик: используемые шрифты и их размер, настройки антиалиасинга, актуальное значение DPI, "умолчания" для gtk- и qt-приложений, css-файлы для приложений семейства mozilla. Описание всех этих настроек выходит за рамки данной статьи, но рекомендации "вкратце" можно свести к настройке "Шрифтов" (Центр управления — Внешний вид и темы — Шрифты) в KDE на сервере (с монитором, аналогичным используемым на станциях) и использовании полученного в результате ~/.fonts.conf на станциях. Разумеется, настройки gtk (~/.gtkrc и ~/.gtkrc-2.0) должны указывать на те же шрифты.

Практически, конфигурационные файлы пользователей всех станций в конечном счёте можно заменить символическими ссылками на одни и те же файлы на сервере: icewm, которым мы "осчастливили" учащихся, всё равно не предоставляет средств модификации настоек десктопа.

Точно так же можно поступить с конфигурационными файлами пользователей на сервере, только не нужно забывать, что KDE или Gnome, которые, в отличие от станции, могут использоваться теми же пользователями на сервере, средства модификации настоек десктопа имеют. То есть при их использовании вместо первоначальных символических ссылок будут созданы новые "индивидуальные" конфигурационные файлы.

Напомним, что автоматический запуск X Window на сервере мы осуществляем запуском дисплей-менеджера. Ясно, что для сервера предпочтительнее gdm или kdm - они и тип сессии позволяют задать, и выключение или перезагрузку компьютера обеспечивают. Иное дело — станция. Если, в соответствии с рекомендациями, мы не инсталлировали на ней ни KDE, ни Gnome, то и соответствующих менеджеров входа на станции не имеем. Придётся вспомнить о xdm, входящем в состав X Window. Поскольку этот дисплей-менеджер по популярности явно уступает своим более молодым конкурентам, то напомним, что вид окна приглашения определяется содержимым /etc/X11/xdm/Xresources, строка запуска (куда, возможно, вам захочется добавить опцию "-dpi 96") находится в файле /etc/X11/xdm/Xservers, а файл /etc/X11/xinit/xinitrc задаёт тип открываемой сессии и, в нашем случае, должен заканчивается командой exec /usr/X11R6/bin/icewm-session.

Последнее, что нужно обеспечить, — это возможность выключения и перезагрузки сервера и станций без root-привилегий. Если на сервере такую возможность предоставят gdm или kdm, то о xdm станции этого не скажешь. Здесь придётся "научить" выключаться icewm, создав в каталоге /usr/X11R6/share/icewm файлы: shutdown и restart (ну, и startup уж заодно). Содержимое файлов элементарно: /sbin/poweroff и /sbin/reboot, соответственно. Что касается файла startup, то его мы используем для запуска индикатора переключения клавиатуры (упомянутой выше fbxkb).

Не получилось? Бывает. Возможно, у пользователей нет прав на запуск poweroff и reboot. В этом случае можно воспользоваться возможностями sudo, дополнив содержимое /etc/sudoers строкой:

  %users  ALL=NOPASSWD: /sbin/poweroff

Строка для reboot — аналогична. Исходим из предположения, что пользователи принадлежат группе users. Не забудьте соотвественно изменить файлы shutdown и restart в /usr/X11R6/share/icewm (командам теперь должна предшествовать "sudo").

Особенности администрирования

В нашем случае, по просьбе учителя вход с "пустым" паролем на станциях был обеспечен пользователям class8 .. class11. Таким образом, учащиеся каждой "параллели" имели свои настройки, отличающиеся, фактически, только составом меню. Состав меню, в свою очередь, определяется школьной программой — с одной стороны, и наличием нужных приложений — с другой. На всякий случай можно напомнить, что "пустые" пароли обеспечиваются "пустым" же полем пароля в строке соответствующего пользователя в /etc/shadow.

Точно так же, как символические ссылки заменяют файлы пользовательской конфигурации Xft на станциях и на сервере, общими для всех пользователей всех станций могут быть и файлы конфигурации icewm: preferences, menu, toolbar и theme. И администрировать легче, и вероятность повреждения на станциях сводится к нулю.

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

Таким образом, после окончательной настройки сервера и станций администрирование сводится к восстановлению настроек приложений (если последние будут неудачно изменены учащимися) и периодическому удалению файлов, создаваемых в ходе обучения. Никакие операции, относимые обычно к сфере администрирования, учителю выполнять не придётся: появление ни новых пользователей, ни новых приложений не предусмотрено. Новые станции, при необходимости, создаются клонированием из эталонного образа, единственные изменяемые характеристики — ip-адрес и имя хоста. Средства клонирования включены в ПО станции.

Есть, однако, задача, решить которую без участия учителя возможным не представляется. Речь идёт о расширении списка приложений, предлагаемых учащимся. Заметим, что тысяча-другая приложений, входящих в состав современного дистрибутива Linux, необходимость расширения этого списка делают, практически, маловероятной. Не уверен, однако, что учителя это порадует, поскольку для того, чтобы продемонстрировать, например, компьютерную обработку изображений, ему предстоит выбрать один из пяти-шести графических редакторов, присутствующих в системе. Практически, учителю предлагается следующий алгоритм работы:

• познакомиться c присутствующими в дистрибутиве приложениями требуемого класса. Для этого ему следует воспользоваться рабочим местом администратора на сервере, задав тип сеанса — KDE;
• выбрать наиболее подходящее для учащихся приложение и определить строку запуска для него (с помощью "Редактора меню", например);
• внести нужную строку запуска в файл, определяющий состав приложений, доступных для запуска нужным пользователем на станциях (непосредственно строке запуска всегда предшествует команда xon и имя сервера server).

С этого момента выбранное приложение появляется в меню запуска пользователя (класса) на станции. Если приложение нуждается в индивидуальных настройках, то следует выполнить их от имени соответствующего пользователя (класса) на станции или на сервере. Поскольку все ученики одного класса выступают по отношению к серверу как один и тот же пользователь, то однажды сохранённые настройки будут актуальны для всех.

Некоторые выводы

Нет смысла спорить о том, каким должен быть десктоп IBM PC вообще, но можно смело утверждать, что в условиях компьютерного класса стоит стремиться к его простоте и защищённости. Даже ценой некоторой потери гибкости и небольшого усложнения администрирования. Вряд ли поддержание порядка нескольких десятков десктопов, ежечасно испытываемых "на прочность" неуёмной фантазией современных школьников, — менее трудоёмкая задача, чем ручное редактирование (да и то только в случае необходимости) четырёх конфигурационных файлов.

Описанная конфигурация отличается от LTSP, прежде всего, отсутствием средств обеспечения сетевой безопасности, но так ли они нужны в отсутствие выхода в Интернет? Даже если таковой выход имеет место, то есть серьёзные сомнения в том, что предоставление этой возможности учащимся оправдано. Знакомство с работой браузера, почтового клиента или службы обмена мгновенными сообщениями начинать всё-таки проще в локальной сети.

Возможно, Open Office, предлагаемый в составе класса, в чём-то уступает настойчиво навязываемому школьной программой MicroSoft Office. Но если принять во внимание стоимость последнего и его требовательность к ресурсам, то замена выглядит вполне оправданной. Добавим к этому десяток обучающих программ из состава KDE, free pascal (в качестве замены TurboPascal), три-четыре интерпретатора, традиционно входящих в состав Linux-дистрибутива — и набор получается достаточно внушительным.

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

Во времена повсеместного доминирования KDE/Gnome на Linux-десктопах, как-то стали забываться программы, обеспечивающие индикацию текущей раскладки клавиатуры. А, между тем, работа этих самых раскладок (XKB groups) обеспечивается исключительно X Window и ни в каких KDE/Gnome не нуждается. Существование независимых от window-менеджера программ индикации раскладки, стало быть, совершенно естественно. Причём, если xkbind (http://xkbind.sf.net) обеспечивает независимость раскладок для разных окон, то fbxkb (http://fbxkb.sourceforge.net) Анатолия Асвияна (Anatoly Asviyan) использует "глобальный", в терминологии KDE, режим переключения. В случае со школьниками последняя представляется более подходящей: аналогия с индикатором "языка" в MS Windows практически полная.

Крошечное замечание. При использовании раскладки en_US (для многих клавиатур эта раскладка предпочтительнее раскладки us, поскольку не имеет "мёртвых клавиш") fbxkb вместо ожидаемого американского флажка выводит вопросительный знак, намекая на то, что файла en_US.png в каталоге /usr/share/fbxkb/images не существует. Способов преодоления данного обстоятельства можно придумать несколько: например, заменить файл zz.png (изображение того самого вопроса) ссылкой на us.png.

Клонирование станции (диск-диск) может быть обеспечено включением в состав её ПО замечательной утилиты partimage (http://www.partimage.org). Использование partimage, однако, предполагает знакомство пользователя, как минимум, с семантикой обозначения дисков и их разделов под Linux (то же самое можно сказать о любых других средствах клонирования из мира Linux). Если на такое знакомство рассчитывать не приходится (что вполне вероятно), то придётся воспользоваться какой-нибудь более известной утилитой. Например - ghost.exe (проприетарный продукт Symantec Corp., зачастую помещаемой на CD, прилагаемых к материнским платам).

Загружаемая дискета MS-DOS создаётся под MS Windows. Образ её можно получить с помощью популярной rawwrite.exe (http://uranus.it.swin.edu.au/~jn/linux). Редактирование образа (уже под Linux) не представляет трудностей после монтирования:

    mount dosdisk.image /mnt/image -o loop

Редактирование заключается в удалении из образа всех файлов кроме системных и добавлении файла ghost.exe.

Загрузка образа обеспечивается следующими строками в /boot/grub/menu.lst:

    title Ghost Image
    root (hd0,0)
    kernel /boot/grub/memdisk
    initrd=/boot/grub/dosdisk.img

При этом предполагается, что каталог /boot/grub/ расположен в первом разделе и именно в нём находится файл dosdisk.img.

Поскольку станции отличаются только именами и ip-адресами, то после клонирования нужно "персонифицировать" полученный диск. Cпособы задания сетевого имени и ip-адреса хоста различны в разных дистрибутивах, то есть, к сожалению, более подробно описывать этот процесс смысла не имеет.

Автор: Владимир Попов
Источник: www.linuxformat.ru