• На данный момент для координирования работ используется макрос ExtractModules (тот же, что и в PspoModules). Возможно, впоследствии будет написано нечто более специфичное для данных работ.

• Над каждым модулем работает один расшифровщик (указывается первым в списке сопровождающих модуль),один переводчик (указывается вторым в списке) и минимум один технический редактор (тот, кто вычитывает, указывается третьим в списке).
• Разбивка прогресса по процентам:

  0%	Сырой конспект
  20%	Дешифрованный конспект
  50%	Конспект, переведённый на русский язык
  70%	Вычитанный конспект
  90%	Иллюстрирование, расстановка ссылок, перенос в модули
  100%	Результат работ над частью лекций проверен FrBrGeorge

• Как только Вы считаете, что закончили свою часть работы, просьба установить соответствующее количество процентов
• Промежуточное количество процентов в промежуточных сохранениях приветствуется

Пожелания к ролям

• Расшифровка — по возможности полное восстановление структуры и смысла лекции по конспектам и (если есть необходимость) по аудиозаписям. в эту задачу входит расстановка имеющихся иллюстраций (typescript, konsole.log, снимки экрана)

• Перевод на русский — выравнивание стилистки и корректировка владения русским языком. Просьба не очень самовыражаться (чтобы не создавать стилистического разнобоя)

• Вычитка — проверка получившегося текста на (1) соответствие действительности (2) доходчивость (в том числе на предмет нехватки иллюстраций)

CategoryPolicy

Установка и настройка FTP-сервера и NFS-сервера

Установка FTP-сервера

FTP-сервер позволяет организовать доступ к файлам компьютера по сети, в том числе через интернет. Обычно через FTP предоставляют доступ только на чтение информации. Для развертывания на нашей машине FTP-сервера установим для пакеты vsftpd и anonftp:

# apt-get install vsftpd anonftp

Поясним сперва, почему одного пакета FTP-сервера vsftpd недостаточно. Первая причина заключается в следующем. Программ, предоставляющих нужную нам функциональность, в хранилище более одной: это proftpd, vsftpd (которую мы и собираемся использовать), pure-ftpd. При этом дерево каталогов, которое соответствует содержимому FTP-сервера, не должно быть жестко привязано к пакету какому-то конкретного FTP-сервера, но в тоже время должно создаваться при развертывании сервера. Именно за это и отвечает пакет anonftp:

$ rpmquery -l anonftp
/var/ftp

Есть, вторая причина существования пакета anonftp. В дистрибутивах ALT Linux, уделяющих большое внимание безопасности, включено множество разных "защит от дурака". В данном случае защита заключается в следующем: установка FTP-сервера и его запуск с настойками по-умолчанию не должны приводить к его автоматическому включению в режиме доступа на запись для всех желающих.

Итак, требуемые пакеты в систему установлены. Займемся их включением. Сервер vsftpd (от Very Secure FTP Daemon) использует при своей работе сетевой метасервер xinetd. Для настройки того, какие службы запускаются в системе в процессе инициализации, используется утилита chkconfig. Используемая в ПСПО версия этой утилиты умеет управлять системными службами разного типа: как оформленными в стиле сценариев "start-stop", котореы располагаются в /etc/init.d/, так и использующими мета-сервер xinetd. При применении chkconfig из командной строки администратор избавлен от необходимости запоминать различный синтаксис для этих двух групп. Посмотрим, какие службы сейчас включены:

# chkconfig --list | grep xinetd -A 20

xinetd based services:
        chargen-tcp:    off
        chargen-udp:    off
        cups-lpd:       off
        daytime-tcp:    off
        daytime-udp:    off
        discard-tcp:    off
        discard-udp:    off
        echo-tcp:       off
        echo-udp:       off
        rsync:          off
        time-tcp:       off
        time-udp:       off
        vsftpd:         off

Как видно, все использующие мета-сервер xinetd сетевые службы в настоящее время выключены (в том числе и vsftpd). Если нужно, чтобы FTP-сервер запускался каждый раз при старте машины, нужно проделать следующие операции:

• обеспечить запуск мета-сервера xinetd:

  # chkconfig xinetd on

• включить сам FTP-сервер vsftpd:

  # chkconfig vsftpd on

После чего мы обнаружим, что мы встретились еще с одной отличительной особенностью дистрибутивов ПСПО. Дело в том, что все сетевые сервисы по умолчанию доступны только с локальной машины --- иными словами, подключиться к ним можно только с адреса 127.0.0.1. Это сделано по соображения безопасности, поскольку при таком подходе конфигурация системы по-умолчанию является безопасной. В данном случае следует при помощи текстового редактора закомментировать в файле /etc/xinetd.conf строку с параметром only_from. Для примера мы воспользуемся не обычным редактором, а утилитой sed для внесения этих изменений, добавив в качестве комментария знаки '##':

• # sed 's/^\s*only_from/##&/' -i /etc/xinetd.conf
  # grep only_from /etc/xinetd.conf
  ##        only_from = 127.0.0.1

Отметим, что файл /etc/xinetd.conf содержит настройки, общие для всех использующих xinetd сервисов. Теперь, поскольку мы изменили содержимое этого конфигурационного файла, нужно перезапустить метасервер xinetd, чтобы внесенные нами поправки вступили в силу:

# service xinetd restart

После этого локальный FTP-сервер начнет принимать входящие соединения на 21-й порт. Для проверки функционирования сервера можно воспользоваться FTP-клиентом lftp.

$ lftp localhost
lftp localhost:~> ls
lftp localhost:/> exit

Сообщений об ошибках, как видим, нет. Впрочем, файлов на сервере тоже пока нет. Скажем еще несколько слов о дисциплине организации FTP-сервера. В каталоге, который является корнем для службы FTP (в нашем случае это /var/ftp) традиционно создается подкаталог pub, файлы в котором доступны на чтение. Именно этот каталог и предназначен для работы "публичных" пользователей.

# mkdir /var/ftp/pub

Настройка и использование FTP-сервера

Поговорим немного о настройке и использовании FTP-сервера. Во-первых, использовать FTP с системными логином и паролем пользователя совершенно неразумно. Эти данные в протоколе FTP передаются по сети открытым текстом, поэтому "подслушать" их не составляет труда. По этой причине FTP-серверы чаще всего используются лишь для предоставления анонимного доступа на чтение к тем или иным данным. Некоторые FTP-клиенты, заметим, требуют при их использовании обязательного ввода логина и пароля даже при работе с "анонимными" FTP-серверами. В таких случаях используется логин anonymous (иногда ftp) и какой угодно, но содержащий символ коммерческого at (@) пароль. Последнее требование, впрочем, предъявляется не всеми FTP-серверами.

Отметим, однако, что в некоторых случаях доступ к данным по протоколу FTP все же защищается паролем. Этим могут заниматься, к примеру, владельцы FTP-серверов, распространяющие сомнительные с точки зрения лицензионной чистоты программы и данные. Трюк заключается в следующем: в случае возникновения каких-либо претензий всегда можно сослаться на использование пароля и объяснить, что защищенные таким способом файлы не являются общедоступными и, следовательно, свободно по сети не распространяются, а лежат для личного использования.

Поясним теперь, зачем в хранилище помещено более одной программы, реализующей функциональность FTP-сервера. В случае, когда аппаратная конфигурация используемой в качестве сервера машины и скорость ее канала передачи данных оставляют желать лучшего, а компьютеры-клиенты образуют несколько различных категорий пользователей, может возникнуть необходимость использовать специальные возможности таких программ. К таким возможностям относится выставление приоритетов в соответствии с IP-адресами клиентов, ограничения на число одновременных соединений, защита от множественного скачивания программами типа ReGet и пр. В случае же, когда такие возможности не требуются, разумно использовать более "легковесные" программы.

Виды FTP-соединения

С использованием протокола FTP может быть связана еще одна проблема. Дело в том, что скачивание файлов по протоколу FTP требует создание специального соединения для передачи данных. IP-адрес и порт для создания этого соединения передаются по сети в пакетах прикладного уровня (в рамках так называемого "управляющего" соединения). В случае "активного" FTP передаются адрес и порт клиента, а случае "пассивного" --- адрес и порт сервера. Понятно, что при использовании трансляции адресов (Network Address Translation, NAT) такой механизм работы может индуцировать довольно неприятные ситуации. К примеру, при работе с "пассивным" сервером строго следующий описанию протокола FTP-клиент (примером может служить Mozilla Firefox) не может проигнорировать полученный таким способом IP-адрес и, если этот адрес оказывается локальным для сети сервера, терпит неудачу при попытке соединения.

Возможным решением данной проблемы может служить тонкая настройка FTP-сервера таким образом, чтобы передаваемый IP-адрес для подключения в "пассивном" режиме различался для клиентов из разных сетей. Иногда оказывается полезным держать несколько FTP-серверов на одной машине и "разруливать" подключения к 21-му порту (ftp) с помощью средств сетевого экрана iptables. При настройке маршрутизатора хорошую службу может сослужить также специальный модуль ip_nat_ftp к iptables.

Установка NFS-сервера

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

1. Установить на сервере пакет nfs-server.

    # apt get install nfs-server

2. Проверить конфигурацию службы portmap, она не должна запускаться с ключом -l, который разрешает только локальные подключения. Пример правильного файла конфигурации /etc/sysconfig/portmap (в ПСПО по умолчанию):

   # Parameters for portmap daemon.
   # See portmap(8) for more details.
   
   # Specifies additional parameters for portmap.
   #PORTMAP_ARGS="-l"

   Если строка с ключом -l не закомментирована, требуется ее закомментировать и перезапустить службу portmap командой service portmap restart.

3. В файле /etc/exports указать, какие каталоги будет отдаваться по сети. В нашем случае он должен содержать две строчки выглядеть так:

   $ cat /etc/exports
   /srv/boot       *(ro,no_subtree_check,no_root_squash)
   /srv/home       172.16.0.0/12(rw,no_subtree_check,no_root_squash)

   Здесь 172.16.0.0/12 --- адрес локальной сети, в вашем случае он может быть другим.

4. После любых изменений /etc/exports необходимо перезапустить службы nfs, чтобы она использовала новые настройки:

   # service nfs restart

Содержимое файла /etc/exports следует прокомментировать. Во-первых, здесь раздаётся каталог /srv/boot, с которого клиенты будут загружаться, причём для них он доступен в режиме "только для чтения". Кроме того, использована опция "no root squash". По умолчанию действует обратная опция "root squash" которая все запросы от лица суперпользователя с клиента на сервере переводит в запросы от лица пользователя "nobody" для большей безопасности. Опция "no root squash" отменяет такое преобразование. В отличие /srv/boot, /srv/home (будущий домашний каталог сетевых пользователей) необходимо экспортировать на запись.

После запуска nfs можно проверить, отдаются ли каталоги, с помощью команды showmount -e:

# showmount -e
Export list for server:
/srv/boot *
/srv/home 172.16.0.0/12

Централизованный доступ к репозиториям

Допустим, у нас есть несколько компьютеров с установленным дистрибутивом из числа ПСПО ALT Linux. Пусть у нас также имеется один или несколько DVD-дисков с ПСПО. Рассмотрим, как устанавливать дополнительное программное обеспечение из состава ПСПО или из дополнительных репозиториев (из "школьной ветки", она же "school branch") с минимальными усилиями.

Очевидный вариант --- зарегистрировать все имеющиеся диски как носители, содержащие хранилища пакетов (для этого служит команда apt-cdrom add), а так же использовать настройки в каталоге /etc/apt/sources.list.d/ и ходить за дополнительными пакетами в Интернет. Это позволит использовать наши пакеты на каждом компьютере, в котором есть DVD-привод и подключение к интернет. Недостатки очевидны --- пакеты скачиваются из интернета столько раз, на сколько компьютеров они устанавливаются, кроме того нужно иметь на каждом компьютере DVD-привод и не лениться вставлять и вынимать диски с ПСПО в каждый компьютер, что является достаточно непродуктивной тратой времени.

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

Самым правильным способом решения стоящей задачи будет организация на одной из машин локального хранилища пакетов. Этот вариант позволяет переписать все нужные пакеты на эту машину и в дальнейшем, при наличии бесплатного доступа в интернет, обновлять их до актуальных версий. Отметим, что если про некоторые пакеты и группы пакетов заранее известно, что использоваться они не будут, то при обновлении их можно исключить. В любом случае после организации хранилища все машины могут обращаться за пакетами именно к этому хранилищу после настройки их /etc/apt/sources.list.d/.

Итак, будем рассматривать последний вариант. Его реализация разбивается на три этапа:

• добавление пакетов в хранилище;
• обновление метаинформации хранилища;
• настройку компьютеров на использование хранилища.

Получение пакетов

Первый этап заключается в копировании пакетов на выбранную нами машину (в дальнейшем будем называть ее сервером). Определимся, где наше хранилище будет располагаться. Выбор наш будет связан со способом дальнейшего функционирования хранилища --- иными словами, с тем, как именно пакеты будут раздаваться по сети. Мы выберем самый простой из всех доступных вариантов и предоставим доступ к хранилищу по протоколу FTP. Будем считать, что на выбранной нами машине-сервере уже запущена программа --- FTP-сервер, сконфигурированная для использования каталога /var/ftp как корневого, причем уже создан доступный для чтения любому желающему каталог /var/ftp/pub. Будем размещать наше хранилище в его подкаталоге..

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

Скажем несколько слов по поводу того, как произошло монтирование файловой системы на оптическом диске. При задвигании лотка система сама произвела монтирование находящейся на диске файловой системы и извлекла с помощью HAL (Hardware Abstraction Layer) имя тома. После этого по программно организованной системной шине DBUS было отправлено сообщение о произведенном монтировании. Слушающая эту шину программа-робот произвела анализ полученной информации и дала команду открыть ассоциированный файловый браузер, который и показал нам содержимое диска. Обратим внимание на то, как была смонтирована размещенная на носителе файловая система:

$ mount | grep iso9660
/dev/hdc on /media/cdrom type iso9660 (ro,noexec,nosuid,nodev,utf8,user=user)

Заметим, что точка монтирования могла оказаться другой (к примеру, /media/hdc). Впрочем, для нас это принципиальной важности не имеет. Если же диск не был смонтирован автоматически, это можно сделать, выполнив команду монтирования вручную:

# mount /media/cdrom

Скопируем, получив права суперпользователя, находящееся в подкаталоге ALTLinux содержимое хранилища пакетов. Ключ -a (от archive) утилиты cp указывает на рекурсивное копирование с сохранением атрибутов файлов.

# cp -a /media/cdrom/ALTLinux/ /var/ftp/pub/

Первый этап на этом завершается. Вернемся, однако, назад и опишем вкратце другие способы получения пакетов. Может оказаться, что на машине-сервере вообще нет DVD-привода, а есть, к примеру, лишь переносной USB-винчестер с образом интересующего нас диска (возможно, мы скачали его по сети или получили каким-либо иным способом). Разберемся, что делать с содержащим этот образ файлом (в нем хранится записанная "как есть" файловая система). Создадим каталог /mnt/iso, смонтируем образ при помощи команды mount и скопируем его содержимое:

# mkdir /mnt/iso
# mount -o loop disk_image.iso /mnt/iso
# cp -a /mnt/iso/ALTLinux/ /var/ftp/pub/

В принципе, такое монтирование практически неотличимо (по результату) от монтирования файловой системы с диска из привода. Обратим внимание, что команда mount сама определила тип файловой системы (iso9660), который мы могли бы указать и явно, с помощью специального ключа (-t iso9660). Для монтирования мы использовали каталог /mnt вместо /media, потому что последний предназначен для файловых систем, монтируемых автоматически, а первый --- для монтируемых вручную. Теперь в в каталоге /mnt/iso видно все содержимое диска:

$ ls -lh /mnt/iso
total 107M
-r--r--r--  1 root root  56M 2008-06-11 14:08 altinst
dr-xr-xr-x  5 root root 2.0K 2008-06-11 14:11 ALTLinux
dr-xr-xr-x 14 root root 4.0K 2008-06-11 14:11 Documentation
dr-xr-xr-x  3 root root 6.0K 2008-06-11 14:11 isolinux
-r--r--r--  1 root root 8.3K 2008-06-07 13:54 license.ru.txt
-r--r--r--  1 root root 3.7K 2008-06-07 13:54 license.txt
dr-xr-xr-x  2 root root 2.0K 2008-06-11 14:10 Metadata
-r--r--r--  1 root root  52M 2008-06-11 14:07 rescue
-r--r--r--  1 root root 205K 2008-06-07 13:54 RPM-GPG-KEY

Каталог ALTLinux, как и ранее, содержит хранилище пакетов, а вот документация на этом диске находится в каталоге Documentation. Каталог isolinux отвечает за загрузку с CD/DVD --- это часть пакета syslinux, поддерживающего множество самых разнообразных источников начальной загрузки. Файл altinst содержит образ файловой системы, но не iso9660, а squashfs. В этой файловой системе размещен установщик нашего дистрибутива. Основных причин, по которым он помещен в squashfs, две. Данная файловая система, во-первых, "упаковывает" свое содержимое, чтобы оно занимало меньше места, и, во-вторых, не обладает ограничениями iso9660 на имена файлов и права доступа к ним. (Заметим в скобках, что имена файлов в ОС Linux могут содержать любые символы, кроме косой черты /, которая является разделителем имен каталогов, и символа с кодом 0.) Для выполнения нашей задачи из содержимого диска требуется лишь хранилище пакетов в каталоге ALTLinux --- он копируется в нужный нам каталог так же, как и раньше.

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

Генерация метаинформации хранилища

Если мы сейчас попробуем использовать наше хранилище, то у нас ничего не получится. Дело в том, что простое копирование пакетов не сохраняет их внутренних связей. Посмотрим, какие каталоги попали в хранилище:

# ls /var/ftp/pub/ALTLinux
base  RPMS.base  RPMS.disk

base и disk --- это названия разделов с RPM-пакетами. Имена соответствующих им каталогов начинаются с префикса RPMS.. Каталог же base содержит метаинформацию (индексы) --- именно в ее перегенерации и заключается второй этап. Удалим base вместе со всем содержимым:

# rm -rf /var/ftp/pub/ALTLinux/base

Установим пакет apt-utils:

# apt-get install apt-utils

А теперь воспользуемся утилитой genbasedir из пакета apt-utils для перегенерации метаинформации:

# genbasedir --verbose --progress --create --topdir=/var/ftp/pub ALTLinux base disk
Components: base disk
Processing pkglists... base  1628/1628 1628/1628disk  0488/0488 0488/0488done
Processing srclists... done
Creating component releases... done
Updating global release file... done
Appending MD5Sum... base disk done
Creating legacy hashfile... base disk done
All your base are belong to us!!!

Обратим внимание на заключительную четверку параметров: topdir задает расположение дерева каталогов (/var/ftp/pub), за ним следует название нашего хранилища (ALTLinux, совпадает с именем каталога), а после --- список его разделов, или компонент (base и disk).

Объясним смысл разделения хранилища (в данном случае) на составляющие base и disk. Дело в том, что скопированное нами хранилище предназначено, среди прочего, для установщика, чья работа по установке пакетов разделена на две стадии: установка базовой системы (base) и дополнительного ПО (disk). Каждая из этих стадий использует свой раздел хранилища.

Отметим, что если хранилище входит в состав рассчитанного на несколько архитектур дистрибутива, то его название обычно соответствует имени одной из этих архитектур: i586, x86_64 и пр. Создается в таком случае также хранилище noarch для не зависящих от архитектуры пакетов. Названия разделов внутри каждого из таких хранилищ обычно отражают принадлежность его к той или иной группе пакетов в пределах одной ветки (по назначению). Типичными названиями разделов являются:

• classic --- основное хранилище;

• updates --- обновления пакетов;

• backports --- новые версии программ для старого дистрибутива.

Заметим, что иногда хранилищем называют объединение всех каталогов, предназначенных для разных архитектур, а не каждый каталог в отдельности.

Использование хранилища

Третий этап нашей работы заключается в настройке клиентских машин. Сконфигурируем на них APT для использования созданного нами хранилища. Обратим внимание, что в системе есть целых два места, в каждом из которых используемые хранилища можно указывать. Первое --- это файл /etc/apt/sources.list, а второе --- все файлы каталога /etc/apt/sources.list.d. Поясним, для чего такое разделение предназначено. Большая часть содержимого файлов в каталоге sources.list.d обычно закомментирована --- здесь удобно "включать" и "выключать" использование того или иного хранилища. Файл же sources.list чаще всего содержит настройки, специфичные для локальной машины. Редактировать этот файл автоматически не всегда удобно, а потому еще в дистрибутивах Debian (из которых система APT и была заимствована) был введен каталог sources.list.d. Изменяющие список используемых хранилищ программы могли добавлять или изменять файлы в нем и только таким образом менять список репозиториев, поскольку в Debian Policy есть пункт, запрещающий пакетам при установке модифицировать чужие конфигурационные файлы.

Итак, впишем наше хранилище в /etc/apt/sources.list, добавив туда новую строку (в силу простоты задачи воспользуемся командой echo):

# echo 'rpm ftp://172.16.0.1/pub ALTLinux disk base' >> /etc/apt/sources.list

Рассмотрим подробнее строку rpm ftp://172.16.0.1/pub ALTLinux disk base.

• rpm --- это тип пакетов (в ПСПО используются только rpm-пакеты)

• 172.16.0.1 --- адрес машины с хранилищем, у вас он модет быть другой;

• ALTLinux --- имя репозитория, disk и base --- спискок разделов.

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

Теперь обновим локальные индексы:

# apt-get update
Get:1 ftp://172.16.0.1 ALTLinux release [541B]
Fetched 2217B in 0s (3932B/s)
Get:2 ftp://172.16.0.1 ALTLinux/disk pkglist [144kB]
Get:3 ftp://172.16.0.1 ALTLinux/disk release [123B]
Get:4 ftp://172.16.0.1 ALTLinux/base pkglist [487kB]
Get:4 ftp://172.16.0.1 ALTLinux/base release [123B]
Fetched 631kB in 1s (340kB/s)
Reading Package Lists... Done
Building Dependency Tree... Done

Обновление прошло успешно, это свидетельствует о корректном функционировании нашего хранилища.

Создание класса на основе терминального сервера

Мы перебираемся к такой большой теме, как развертывание компьютерного класса. В качестве некоторого отступления от основного направления коснемся вопроса создания класса на основе терминального сервера.

В состав ПСПО входит 4 дистрибутива: Мастер (большой), Юниор (средний), Лайт (маленький, для старых компьютеров) и Терминал-сервер для ситуации, когда одна машина современная, а остальные "никакие". Терминал-сервер поддерживает концепцию организации класса, при которой никакого администрирования на клиентских машинах не производится. Более того, на этих машинах можно даже не иметь винчестера, главное --- научить их загружаться через сеть. Это можно сделать путём сетевой загрузки, используя протокол PXE, а можно использовать загрузочный CD или USB-накопитель, лишь бы это в конечном счете приводило к загрузке операционной системы по сети.

Начало работы обычного компьютера выглядит примерно следующим образом. После загрузки собственно операционной системы на клиентских машинах запускается X-сервер (та часть графической оболочки, которая умеет рисовать на экране и работает с мышью и клавиатурой), а также средства для работы с локальными к флешкам и подобными устройствами. После запуска X-сервера эти машины подключаются по протколу взаимодействия графических подсистем, который называется XDMPC, к терминальному серверу, и запуск всех приложений происходит на терминальном сервере. Сервер должен быть достаточно хорошей машиной; скорее всего, любая современная машина подойдёт для класса из 10 компьютеров. На одного пользователя в классе обычно хватает 256 Мб памяти. Если вы совсем ограничены в средствах, можно считать необъожимый объем памяти так: 256 Мб на сам сервер + 128 Мб на каждый терминальный сеанс. Восемь машин при гигабайте памяти на сервере работают достаточно легко. Если шестнадцать машин работают на 2 Гб памяти, то узким местом системы будет уже с быстродействие дисковой подсистемы. Возможный вариант в этом случае -- машина с двумя винчестерами, которые работают, как один большой (raid 0). Другой вариант -- увеличить объём памяти и, соответственно, дискового кэша, чтобы больше данных находилось в оперативной памяти.

Основное достоинство терминального сервера --- при его использовании локальные машины не нуждаются в администрировании в принципе, они просто включаются и работают. Когда-нибудь в будущем их можно вообще выбросить и купить вместо них не полноценные компьютеры, а так называемые тонкие клиенты, у которых есть монитор (хороший), клавиатура (тоже хорошая) и очень компактный системный блок без винчестера, с минимальной памятью и usb-портами. Администрирование необходимо только на терминальном сервере.

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

Более подробно о терминальном сервере можно прочитать здесь;

•  Теория использования терминальных серверов;

•  Терминальный сервер со стороны пользователя;

•  Терминальный сервер со стороны администратора.

Создание класса на основе самостоятельных компьютеров

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

Что нужно для того, чтобы происходила сетевая установка? Вначале нужно организовать сетевую загрузку машины. Для этого нужно, прежде всего, установить службу dhcpd (Dynamic Host Configuring Protocol Daemon), пакет называется dhcp-server. Он есть в дистрибутиве Мастер, подробнее процесс описан в  Настройка DHCP-сервера.

Dynamic Host Configuring Protocol в переводе с английского --- "протокол динамической настройки компьютера". При включении компьютера по определённым правилам ему по сети передается набор настроек. Вообще говоря, этот протокол очень сложен, он позволяет передавать сотни настроек разного уровня, в том числе и с точки зрения сетевых протоколов. Например, раздача IP может быть организована динамически (каждому новому компьютеру будет выдаваться очередной IP адрес из набора) --- если вас не очень волнует, что в вашу сеть включится кто-то лишний, либо по MAC-адресам (каждому MAC-адресу соответствует свой жёстко определённый IP). Бывают и другие варианты, всё зависит от того, насколько возможно решить задачу административным путём. В любом случае dhcp не помешает в классе, даже если не планируется сетевая загрузка, в особенности, если в учреждении не один сегмент сети.

Конфигурационный файл dhcpd лежит в /etc/dchp/dhcpd.conf:

subnet 10.0.2.0 netmask 255.255.255.0 {}

subnet 172.16.0.0 netmask 255.255.255.0 {
        option routers                  172.16.0.1;
        option subnet-mask              255.255.255.0;

        option domain-name-servers      172.16.0.1;

        range dynamic-bootp 172.16.0.101 172.16.0.199;
        default-lease-time 21600;
        max-lease-time 43200;
        filename "pxelinux.0";
        next-server 172.16.0.1;
}

Этот пример предполагает, что у сервера есть два сетевых интерфейса: внешний в сети 10.0.2.0/24 и внутренний с адресом 172.16.0.1. Предполагается, что на сервере развернут ретранcлятор DNS-запросов 172.16.0.1 (подробнее см.  Служба DNS (Bind)), если же его нет, следует указать адрес DNS-сервера провайдера. Обратим внимание на две вещи: все сети, к которым подключена машина, должны быть описаны. Дело в том, что dhcpd - капризный демон, и если он видит сеть, которая в нём не описана, он отказывается работать. И второе --- в одной локальной сети должен быть только один DHCP-сервер.

Какие настройки умеет отдавать DHCP-сервер:

• IP-адрес; как уже было сказано, можно настроить либо динамическую выдачу IP-адреса, либо написать "машина такая-то" (MAC-адрес) и указать, какой IP выдавать ему;

• маршрутизатор по умолчанию (поле option routers);

• сервер DNS (поле option domain-name-servers), который преобразует IP-адреса в доменные имена и обратно;

• маску сети (поле option subnet-mask).

• и другие, например имя домена.

Если выпустить из внимания две другие настройки, filename и next-server, которые нужны именно для сетевой загрузки и будут рассмотрены позже, то машина будет раздавать всем компьютерам в локальной сети адреса из указанного в поле range dynamic-bootp диапазона. Любая машина с установленным ПСПО для автоматической настройки сети запускает клиент dhcp, который называется dhcpcd.

Остается напомнить, что после любых изменений файла /etc/dhcp/dhcpd.conf DHCP-сервер следует перегружать:

# service dhcpd restart

Настройка сетевой загрузки

Настройка клиента

Итак, служба протокола DHCP настроена. Есть ещё две настройки, связанных с сетевой загрузкой операционной системы: во-первых, для ее работы необходима поддержка сетевой загрузки на клиентах, и во-вторых, для нее необходима передача файлов начальной загрузки по протоколу TFTP.

Как правило, о способности клиента загрузиться по сети свидетельствуют слова в настройках BIOS о том, что загрузочным устройством является сеть, int 18 или 19, либо на сетевой карте есть плата BootROM, то есть прошивка для сетевой загрузки, и при включении компьютера с такой сетевой картой вам говорят: "нажмите Alt+B, Shift+F10 или что-то чтобы настроить параметры сетевой загрузки". В этой настройке сетевой загрузки может быть много вариантов, правильно выбирать вариант под названием "PXE". Протокол PXE включает в себя получение настроек по DHCP и некоторые другие возможности.

Клиенты, поддерживающие протокол PXE, должны быть подключены к локальной сети с работающим DHCP-сервером, и на сервере (указанном в поле next-server) должен быть специальный демон, называемый TFTP-сервер. TFTP (Trivial File Transfer Protocol) --- это специальный протокол передачи файлов, крайне упрощённый, чтобы его клиентскую часть (программу, которая умеет скачивать файлы согласно этому протоколу) можно было уместить в памяти сетевой карты. Собственно, BootROM и содержит программу, записанная в ПЗУ сетевой карты, которая загружается в оперативную память и занимается ровно одной вещью: по протоколу PXE получает настройки по DHCP/BOOTP, потом сообразно этим настройкам получает информацию о том, откуда брать специальный файл --- загрузчик, скачивает его, загружает в память и запускает. В отличие от ситуации, когда передаются только настройки сети, в протокол PXE входит стадия скачивания некой программы и запуска её. Всё это делает прошивка сетевой карты.

Настройка TFTP-сервера

Для установки TFTP-сервера требуется поставить соответствующий пакет, разрешить службу и перезагрузить метасервер xinetd, через который и работает сервер tftp:

# apt-get install tftp-server
# chkconfig tftp on
# service xinetd restart

На сервере при установке пакета tftp-server появляется каталог /var/lib/tftpboot, в который нужно поместить файлы, которые будут скачиваться по протоколу tftp, как если бы они лежали в корневой директории сервера. Для того, чтобы получить эти файлы, требуется поставить пакет syslinux:

# apt-get install syslinux

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

Нас интересует содержимое каталога /usr/lib/syslinux/:

$ ls /usr/lib/syslinux/
chain.c32      dmitest.c32         mboot.c32  pcitest.c32   vesamenu.c32
com32          ethersel.c32        mbr.bin    pxelinux.0
copybs.com     isolinux-debug.bin  memdisk    syslinux.com
cpuidtest.c32  isolinux.bin        menu.c32   syslinux.exe

Здесь мы видим файлы нескольких форматов: .bin, .com, .c32, .0 .exe, которые предназначены для загрузки в разные среды. В частности, те, которые загружаются прямо в сетевую карточку называются .0 и .c32.

Насбудет в первую очередь интересовать загрузчик pxelinux.0. В терминологии последовательности загрузки это вторичный загрузчик, то есть тот, который должен загружаться не из пзу, а непосредственно с устройства. Основная его задача --- подгрузить откуда-то ядро и стартовый виртуальный диск (initrd). Загрузка этих двух файлов --- это то, с чего начинается загрузка Linux. Ядро --- это ядро, а в стартовом виртуальном диске находится очень маленький линукс, который содержит все модули, нужные для дальнейшей загрузки и работы системы. Скопируем его в каталог TFTP:

# cp /usr/lib/syslinux/pxelinux.0 /var/lib/tftpboot/

Кроме того, нам необходим сам загрузочный CD или DVD-диск. Для его раздачи на сервере нужно настроить NFS, как описано в  Установка и настройка FTP-сервера и NFS-сервера. Скопируем содержимое диска в каталог /srv/boot сервера, а каталог isolinux (в нем, в частности, находится ядро и образ виртуального диска начальной загрузки) --- в каталог tftpboot:

# cp -a /media/cdrom/* /srv/boot
# cp -a /media/cdrom/isolinux /var/lib/tftpboot/

У pxelinux есть конфигурационный файл, в котором написано, что же ему загружать дальше. В нём можно сделать несколько разных вариантов выбора. Для удобства работы с сетью pxelinux.0 загружает конфигурационный файл по определённым правилам. Сначала pxelinux пытается загрузить конфигурационный файл, который по имени совпадает с шестнадцатеричным представлением полученного по PXE IP-адреса. Это сделано для того, чтобы при жёсткой привязки IP-адреса к MAC-адресу машины для каждой машины можно было бы иметь собственную настройку, и можно машины с одними IP-адресами загружать по одной конфигурации, а другие, из другой сети, по другой конфигурации.

Мы рассмотрим простейшую конфигурацию, общую для всех компьютеров сети. Для этого нужно создать файл /var/lib/tftpboot/pxelinux.cfg/default следующего содержания:

timeout 0
prompt 1
default install

label install
  kernel ../isolinux/alt0/vmlinuz
  append initrd=../isolinux/alt0/full.cz lang=ru_RU automatic=method:nfs,network:dhcp,server:172.168.0.1,directory:/srv/boot ai live stagename=altinst
# Все, что после "append " - должно быть записано в одну строчку

Рассмотрим синтаксис этого файла. Поле prompt означает, ожидать ли подсказки (boot:) при загрузке, поле timeout 0 означает ожидание, пока пользователь не нажмёт enter при загрузке в ответ на приглашение boot:. Тут есть один момент: если включён NumLock, pxelinux будет ждать, а если выключен --- нет. В поле default указано имя варианта загрузки по-умолчанию (в нашем файле конфигурации этот вариант единственный)

Дальше идут настройки для конкретной загрузки. Поле label задает имя варианта загрузки. Файл конфигурации может содержать несколько вариантов загрузки, и имя желаемого варианта можно указать в ответ на подсказку ("boot:"). Дальше нужно указать, где находится ядро (поле kernel) и какие у этого ядра параметры (поле append). Параметр ядра initrd разбирается загрузчиком syslinux, он загружает этот файл (стартовый виртуальный диск), а остальные параметры, которые он не понимает, он передаёт ядру.

В параметре automatic указан способ получение файлов установки (здесь NFS, так же возможен FTP), адрес сервера (172.168.0.1) и путь к файлам (/srv/boot).

В результате проделанной работы будет происходить примерно следующее.

• При загрузке клиентской машины она получает IP-адрес по DHCP, и загружает начальный загрузчик pxelinux.0 (указаный в параметрах DHCP) по протоколу TFTP.

• Загрузчик ищет подходящий файл конфигурации на TFTP-сервере. В результате анализа файла конфигурации загрузчик узнает, где находится ядро Линукс и образ начального виртуального диска (initrd), а также получает остальные параметры для ядра.

• Загрузчик загружает по TFTP ядро и образ виртуального диска, и передает управление ядру.
• Ядро после инициализации запускает процесс установки, используя уже NFS для доступа к установочному диску.

Для того чтобы установить ПСПО по сети, следует сначала разместить содержимое установочного CD или DVD-диска на FTP-сервере:

# mount /media/cdrom
# mkdir -p /var/ftp/pub/boot
# cp -a /media/cdrom/* /var/ftp/pub/boot

Затем на клиенте следует загрузить программу загрузки. Это можно одним из двух способов:

• загрузить ее по сети с помощью PXE и TFTP с этого же сервера, как описано в  Сетевая загрузка;

• использовать CD или USB-flash с ПСПО;

При выборе второго способа можно загружаться, например, с CD-Диска "Легкий Линукс", а вести установку по сети с копии DVD-диска "Линукс Мастер". При отсутствии CD-привода на клиенте можно воспользоваться загрузочным USB-накопителем, который следует подготовить следующим образом. Сначала надо установить пакет mkbootflash:

# apt-get install mkbootflash

Затем нужно вставить flash-носитель в USB-порт и узнать его имя (например, при помощи утилиты dmesg), обычно это sdg1:

# dmesg | grep 'Attached' | tail -n2
[ 1762.549556] sd 7:0:0:0: [sdb] Attached SCSI disk
[ 1762.549635] sd 7:0:0:0: Attached scsi generic sg1 type 0

Затем следует сделать его загрузочным (внимание: содержимое flash-накопителя будет безвозратно утеряно):

# mkbootflash -i /dev/sdg1

После загрузки с CD следует нажать клавишу F4, выбрать FTP в качестве источника загрузки, и ввести 172.16.0.1 в качестве ip-адреса сервера (для нашего примера) и /pub/boot в качестве ftp-каталога:

Альтернативой использованию FTP-сервера является использование сетевой файловой системы NFS (Network File System). Для того, чтобы передавать информацию по протоколу NFS, необходимо запустить службу nfs на сервере. Если этого не сделать, то установка зависнет сразу после загрузки ядра, так как не удастся получить доступ к диску с дистрибутивом. Развертывание NFS описано в  Установка и настройка FTP-сервера и NFS-сервера.

В случае установки по NFS рекомендуется использовать не ISO-образ, а каталог, в который нужно скопировать все данные с диска. Для загрузки по NFS cкопируйте на сервере в каталог /srv/boot необходимые файлы:

# mkdir /srv/boot
# cp -a /media/cdrom/* /srv/boot

Дальше установка происходит обычным способом.

Автоматическая установка

Если вы не хотите устанавливать систему вручную на каждую машину, отвечая на одни и те же вопросы, то можно воспользоваться функцией автоматической установки. Эта функция устроена следующим образом: существует каталог Metadata на установочном устройстве (CD или NFS-сервере), напимер /srv/boot/Metadata при использовании NFS. В нем находятся, в частности, следующие файлы:

• сценарий установки autoinstall.scm, в этом файле записаны те действия, которые выполняются автоматически при установке;

• файл описания различных вариантов разбиения дисклов vm-profile.scm.

Для автоматической установки первый из этих файлов можно заменить файлом /root/autoinstall.scm, который находится на локальных компьютере после завершения установки. Таким образом, данный файл копируется из любой машины с успешной ручной установкой, опционно дополняется, и затем установка остальных компьютеров пройдет аналогичным образом. Следует отметить, что после установки в этом файле лежат пароли открытым текстом (чтобы задать их такими же на новом компьютере), и правильным решением после установки будет смена паролей, особенно это касается пароля root. Также в каталоге /root существует и файл vm-profile.scm, где описаны методы разбиения для разных вариантов установки, и правкой этого файла можно добиться необходимого для ваших нужд разбиения.

Таким образом, автоматическая установка осуществляется "подкладыванием" в каталог Metadata двух файлов: файла с профилями разбивки vm-profile.scm (из этих профилей будет использован только тот, что был выбран при ручной установке) и файл сценария autoinstall.scm, в который вставлены вызовы модуля разбивки с применением соответствующего профиля.

Теперь в настройках сетевой загрузки PXE достаточно передать ядру параметр ai (autoinstall), чтобы при установке инсталлятор проверял каталог Metadata, копировал эти два файла и не делал никаких запросов к пользователю.

Примечание. В силу специфичности установки по сети после окончания установки машина может зависнуть на этапе размонтирования дисков. После этого нужно просто ее перезагрузить. При автоматической установке не стоит ставить загрузку по сети вариантом загрузки по умолчанию, так как машина может и не зависнуть, а в этом случае она снова загрузится по сети и поставит всю систему заново.

Итоги

Возвращаясь к общей теме развертывания компьютерного класса, взглянем на проделанную нами работу: создан сервер, на котором лежат все нужные пакеты, например, дистрибутив Мастер или целая ветка Alt Linux (branch). Этот сервер с помощью протокола DHCP раздает в локальной сети сетевые настройки, и на нем же, возможно, работает маршрутизатор и прокси. Фактически, мы сделали возможной не только автоматическую настройку клиентов, но и автоматическую установку какого-то набора ПО (например, нового дистрибутива). Однако кроме этого может понадобиться еще настройка устанавливаемого набора ПО под соответствующие нужды. На данном этапе автоматизация - это автоматическая установка именно какого-то одного конкретного дистрибутива с весьма фиксированным набором "задач".

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

Вступление

При установке любого дистрибутива ALT Linux (в том числе и входящего в ПСПО), чуть менее чем все шаги установки (кроме разметки диска) после успешного её завершения будут записаны в файл /root/autoinstall.scm, который с незначительными модификациями (добавлением инструкций разметки диска) можно использовать для автоматической установки этого дистрибутива с этими настройками. Но зачастую выбор настроек, предлагаемых языком autoinstall.scm, недостаточен, и необходимо вставить в процесс установки что-то своё, родное. Для этого есть как минимум два пути:

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

Собственно говоря, минимальной необходимостью для сетевой установки являются две машины, соединённые в сеть, причём: одна из них умеет загружаться по PXE, а на другой настроены некоторые службы и лежат некоторые файлы. Некоторыми службами являются демоны nfsd, tftpd, dhcpd, xinetd и rsync, а файлами --- развёрнутый установочный образ дистрибутива с теми самыми некоторыми модификациями.

В общих чертах о процессе

Загрузка "клиентской" машины, то есть той, на которую устанавливается система, будет происходить следующим образом. Первое --- при включении она получает от DHCP-сервера (предоставляемого dhcpd) специальный пакет с указанием её адреса и адресом к образу загрузчика pxelinux.0. Далее, этот самый pxelinux.0 скачивается по TFTP (его отдаёт, как нетрудно догадаться, tftpd), и сразу же начинает исполняться, а именно: загружает ядро, и монтирует по NFS необходимый для установки каталог (соответственно, раздаваемый unfsd). После чего запускается Alterator, в зависимости от настроек PXE, в ручном или автоматическом режиме, и начинает установку.

Маленькие модификации

Немного о том, как устроен установочный диск дистрибутива ALTLinux. К примеру, посмотрим в корень установочного DVD с ПСПО Линукс Мастер:

altinst  ALTLinux  Documentation  isolinux  license.ru.txt  license.txt  Metadata  rescue  RPM-GPG-KEY

Самое интересное всмысле модификации установки находится в двух местах --- каталоге Metadata и файле altinst. В первом могут находиться конфигурационные файлы Alterator для автоматической установки (тот самый autoinstall.scm и произвольные другие файлы, которые могут потребоваться установщику (в частности, именно в этом каталоге должны находиться файлы, которые могут потребоваться модифицирующим скриптам), среди них --- описание разбивки диска при установке), а второй --- это образ файловой системы squashfs, который являет собой полную систему, из котороый, собственно, и исполняется Alterator, производящий установку.

У любопытного читателя, наверное, возник вопрос --- нельзя ли дописать желаемые модификации в исполняемый установщиком autoinstall.scm? Ответ на этот вопрос скорее отрицателен, ибо в autoinstall.scm записываются только те действия, которые может выполнять установщик, как-то: разбивка диска, настройка и установка загрузчика, установка групп пакетов. Вставить собственный код непосредственно в этот файл, к сожалению, невозможно.

Но в процессе своей работы --- вернее даже, перед её завершением --- установщик выполняет скрипты, которые находятся в /usr/share/alterator/postinstall.d/, просто в порядке их нахождения в этом каталоге.

Этот каталог располагается внутри образа squashfs, из которого разворачивается минимальная система для исполнения Alterator, а пересборка оного образа не сильно лучше пересборки всего дистрибутива.

Обходная хитрость --- распаковать образ в одноимённый каталог в том же месте в дереве. Тогда установка будет происходить с использованием этого каталога вместо образа. А в этот-то каталог (вернее, в его подкаталог usr/share/alterator/postinstall.d/) и стоит внедрять всякие модификации.

Пример модификации

Модификациями в данном случае будут сценарии на shell, которые работают с некоторыми определёнными установщиком функциями и созданными установщиком каталогами. Для примера рассмотрим сценарий, задача которого --- распаковать в целевую систему некоторый архив:

#!/bin/sh -efu

. install2-init-functions

cp-metadata $destdir/root/synchrone.tar
exec_chroot tar xf /root/synchrone.tar --no-overwrite-dir --no-same-owner -C /
exec_chroot chkconfig --add synchrone

Строка . install2-init-functions включает в сценарий заданные установщиком функции и переменные. Среди которых cp-metadata --- позволяет взять данные из каталога Metadata, о котором было сказано выше, и exec_chroot --- выполнить команду внутри целевой системы. Переменная destdir определяет каталог, в котором находится целевая система в процессе установки.

 Развертывание компьютерного класса — Подробная инструкция по разворачиванию конкретного решения на базе подобных модификаций.

Как сделать школьный веб-сайт

Когда вы заходите по протоколу HTTP на сервер, он в ответ на ваш запрос посылает вам некий текст, обычно в формате HTML. HTML — это язык разметки для организации гипертекстовых данных. Для просмотра этого документа пользователем используется программа, называемая веб-браузером («навигатором»), которая умеет показывать HTML-страницы описанным в них образом и обрабатывать разного рода деятельность пользователя: например, вы нажимаете мышкой на ссылку, и она содержимое страницы по этой ссылке показывает. Возникает вопрос: откуда берутся эти массивы данных в виде HTML-страниц? Для ответа на этот вопрос создадим собственный веб-сайт, который будет являться источником HTML-документов.

Веб-сервер Apache

Для создания веб-сайта в начале необходимо установить веб-сервер — программу, общающуюся с клиентами по протоколу HTTP. В связи с тем, что на момент начала создания ПСПО в веб-сервере Apache версии 2.0 были определенные проблемы с безопасностью при включении модуля mod_proxy, а версия 2.2 ещё не была доступна, в ПСПО используется старая, но испытанная версия Apache 1.3, хотя в большинстве дистрибутивов сейчас используется Apache 2.2.

Для развертывания веб-сервера достаточно установить пакет apache и запустить службу httpd. В случае ПСПО веб-сервер будет работоспособен сразу после установки. Установим и запустим сервер Apache следующей командой:

# apt-get install apache && service httpd start

Теперь при попытке зайти на доменное имя или IP-адрес используемой машины по протоколу HTTP (например, при помощи браузера) будет показано следующее:

По умолчанию сервер Apache использует в качестве корневого каталога сайта (DocumentRoot) каталог со своей документацией. То, что мы видим приведённую выше страницу, означает, что веб-сервер работает, однако у нас отсутствует собственно веб-сайт, поскольку нет никакого содержания.

Создания HTML-страниц с помощью Bluefish

Для создания сайта можно использовать специально предназначенную среду разработки — Bluefish. Перед созданием каких-либо страниц создадим подкаталог в месте, предназначенном для размещения файлов контента веб-сервера, /var/www, и для простоты разрешим изменять его содержимое всем локальным пользователям:

# mkdir /var/www/site
# chmod o+w /var/www/site

Создадим с помощью редактора Bluefish HTML-страницу:

1. Откроем bluefish

2. Откроем диалог создания новой HTML-страницы

   • 

3. Зададим заголовок страницы и удалим лишние заголовки

   • 

4. Сгенерируем страницу и добавим содержимое страницы

5. Добавим содержимое страницы.

   • 

6. Сохраним полученный результат

   • 

Сохраним её под именем index.html в свою домашнюю директорию и скопируем её в /var/www/site/.

Затем отредактируем файл конфигурации /etc/httpd/conf/httpd.conf. Поменяем в нём поле DocumentRoot следующим образом:

# DocumentRoot: The directory out of which you will serve your /Root
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "/var/www/site"

Теперь, после перезапуска apache командой service httpd restart, в браузере при обращении к данной машине можно будет увидеть только что созданную страницу.

Подходы к автоматизированному созданию веб-сайтов

Продемонстрированный подход к созданию HTML-страниц вручную, хоть и полезен для знакомства с языками разметки, но является устаревшим. Практика создания HTML-страниц вручную на данный момент по большей части ушла в прошлое. Дело в том, что при таком подходе требуется очень много усилий для поддержания сайта в актуальном состоянии. Ранее существовала даже специальная профессия — «контенщик», человек, которому платили за регулярные обновления сайта (она существует и сейчас, но имеет несколько иную специфику). Задача создания осмысленной структуры сайта так же не слишком проста. В дополнение ко всему, вручную очень легко случайно или по незнанию написать HTML-код, который будет отображаться некоторыми браузерами некорректно.

В какой-то момент произошло осознание того, что дизайн сайта и его наполнение информацией, и представление его виде HTML — это различные задачи, которые стоит решать по отдельности. Появилось два подхода к решению задачи наполнения сайта информацией:

• Сайт может представлять собой ответственную структуру. Информация, в таком случае, попадает на сайт после прохождения непростого жизненного цикла: какой-нибудь отдел пишет запрос, запрос обрабатывается службой контента, которая обращается к авторам; авторы пишут текст, текст вычитывается редактором, шеф утверждает текст, и лишь затем текст попадает в нужное место на сайте. Иногда этапов намного меньше, их может быть всего два — один человек готовит информацию, другой размещает её. В любом случае, до появления на сайте информация должна пройти сколько-нибудь этапов обработки.
• Может существовать сообщество людей (к примеру — учителя, ALT Linux team, любители пива). Члены сообщества могут не быть ни веб-дизайнерами, ни веб-программистами, однако им может быть надо оперативно пополнять информацию на сайте наиболее простым способом. В этом случае, когда речь идет о совместном использовании и редактировании контента, важнее всего простота работы.

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

• CMS (Content Management System, системы управления контентом). Это инструменты людей, занимающихся сайтостроением. В них есть уже готовые большое количество готовых модулей, например, системы поддержки блогов, документооборота, внедрения оригинального дизайна.

  • Одним из наиболее развитых инструментов такого плана является движок (точнее, application server) Zope, написанный на Python. Под него существуют специальные программы, например, реализации системы управления содержимым сайта.

  • Сайт ALTLinux использует другой аналогичный движок — Joomla.

  • Сайт fosscenter.ru сделан на движке Drupal. Drupal интересен легкостью установки и удобством управления, однако написан на PHP и в некоторой степени функционально и архитектурно перегружен.

  • Существует и движок, ориентированный на сайты поддержки учебного процесса — Moodle. Сайты, сделанные на нем, выглядят как система управления учебными курсами.

  • В любом случае, портальный движок обязательно должен сопровождаться ответственным системным администратором, который в этом движке разбирается. Кроме того, существует множество коммерческих портальных движков.
• Вики (Wiki). Это технология, упрощающая групповую работу с информационным наполнением сайта. На гавайском языке «wiki» означает «быстро». Основная концепция этой технологии — создание веб-страницы должно занимать времени не больше, чем просто набор текста. Кроме того, должна быть максимально упрощена процедура отмены изменений. В отличие от портальных решений, значительная часть которых не бесплатна, существуют десятки свободных wiki-движков.

Использование Wiki

В качестве движка Wiki рассмотрим движок MoinMoin. Он написан на Python и является разумным компромиссом между готовой работающей программой и гибко настраиваемой системой, которую так же и удобно перепрограммировать и расширять. На самих дисках с ПСПО moin отсутствует, однако установить его достаточно просто, если подключить школьный репозиторий и выполнить следующую команду.

# apt-get update && apt-get install moin

Следующим шагом будет создание экземпляра wiki-сайта, для чего существует специальный сценарий moin-instance-setup. Его следует запустить с именем вики-узла (последнее должно включать только английские буквы, цифры и дефис):

# moin-instance-setup school
Checking configuration sanity for httpd: DONE
Stopping libhttpd.ep service: DONE
Starting libhttpd.ep service: DONE
Moin-Moin school installation is finished:
        Wiki pages: /var/www/wiki/school
        Wiki url: http://localhost.localdomain/school
        Additional Apache config file: /etc/httpd/conf/addon-modules.d/moin-school.conf
Edit /var/www/wiki/school/cgi-bin/wikiconfig.py to set your site up.

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

После этого следует зайти с помощью браузера на адрес http://localhost/school и завести там учётную запись, например с именем Admin (для этого так же можно перейти по адресу http://localhost/school/UserPreferences).

Для задания суперпользователя Wiki нужно изменить файл /var/www/wiki/school/cgi-bin/wikiconfig.py, где необходимо задать переменной superuser в качестве значения список имен супер-пользователей. Например, следующая команда дает права супер-пользователя пользователю с именем Admin:

# sed 's/#superuser = \[u"YourName", \]/superuser = [u"Admin", ]/' -i /var/www/wiki/school/cgi-bin/wikiconfig.py

(данная команда заменяет закомментированную по умолчанию строку #superuser = \[u"YourName", \] на строку superuser = [u"Admin", ])

После того, как в MoinMoin появилась учетная запись суперпользователя, можно установить необходимые пакеты локализации и сменить интерфейс системы на русский. Это можно сделать на странице http://localhost/school/SystemPagesSetup:

Для запрещения создания новых пользователей в MoinMoin, входящем в состав ПСПО, проще всего создать необходимых пользователей, а затем запретить изменения в каталоге, где MoinMoin хранит информацию о пользователях:

# chmod u-w /var/www/wiki/school/data/user

(Подробнее про это можно прочитать на сайте MoinMoin)

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

# chmod u+w /var/www/wiki/school/data/user

После заведения пользователей следует установить стартовую страницу wiki-сайта. Для одноязычной вики следует раскомментировать (и, при необходимости, отредактировать) следующую строчку в файле /var/www/wiki/school/cgi-bin/wikiconfig.py:

page_front_page = u'MyStartingPage';

Теперь можно приступать к редактированию содержимого wiki-сайта. При переходе на адрес http://localhost/school появляется сообщение об отсутствующей странице. Это ситуация достаточно типична для содержимого wiki-сайтов: ссылка на страницу есть, а страницы ещё нет.

Для создания страницы выберем вариант «Создать страницу с нуля» и введем некоторый текст, содержащий ссылку на другую страницу. Для идентификации страниц wiki используется CamelCase.

Теперь у wiki-сайта есть главная страница, содержащая ссылку на (ещё не созданную) страницу НашаШкола. Нажав на эту ссылку, можно создать страниу с информацией о школе — и так далее.

MoinMoin позволяет создавать страницы с ссылками, таблицами, рисунками, поддерживает персональные страницы пользователей и страницы категорий, а также поддерживает (как и все wiki) историю изменения страницы. Внешний вид MoinMoin при необходимости полностью настраивается.