Системное и сетевое администрирование

-->



Для начинающих Для знатоков Для души О нас	Администрирование сети на платформе Линукс Хорошую книгу о системном администрировании ещё никто не написал Автор. Олег П. Филон,Линукс Лаб,Гомель,Беларусь вер. 0.1,июль 2002 Содержание 1. Предисловие 2. Пользователи 2.1 Сопровождение БД пользователей 2.2 Исключения из правил 3. БД пользователей на основе LDAP 4. БК - Бездисковые Компьютеры 4.1 Базовые сервисы 4.2 Настройка клиента для сетевой загрузки 1. Предисловие Ядро Линукс(R) и использующие его дистрибутивы представляют собой современную реализацию многопользовательской сетевой операционной системы, известной под общим родовым именем Unix(R). С точки зрения пользователя Unix(R) предоставляет универсальную среду программирования, независимую от аппаратной платформы, и включающую как традиционные инструментальные средства, так и новые графические среды и клиентские программы. Целью этой книги является демонстрация, как на основе дистрибутива Debian GNU/Linux построить современную масштабируемую сеть, используя только свободно доступные программы с открытым исходным кодом. Мы постараемся показать, что такая сеть сама в свою очередь может рассматриваться как платформа для создания новых сетевых приложений. Администрирование считается более сложной задачей, чем обычное использование компьютера для решения отдельных задач. Тем не менее, многие пользователи время от времени сталкиваются с и успешно решают административные задачи. Например, установка и настройка новой программы, оборудования - типичная административная проблема. В сетевой среде, однако, задача администрирования значительно усложняется из-за необходимости разграничения полномочий пользователей, а также защиты системы и данных от несанкционированного доступа. Основным отличием многопользовательской системы от персональной является именно отсутствие вседозволенности, чёткое разграничение полномочий. Поэтому прошу заранее запастись терпением, быть готовыми к тому, что к сложности сетевых технологий добавятся новые измерения - иерархия прав пользователей, защита пересылаемой информации. В эпиграфе сделан намёк, что рассказать обо всех аспектах администрирования сети практически невозможно. Это невозможно как из-за необъятности самой темы, так и из-за её стремительного развития - какая-то из обсуждаемых тем может запросто устареть непосредственно во время подготовки книги. Ещё одна проблема при составлении подобного руководства - какой уровень подготовки читателя можно предполагать, как использовать имеющиеся он-лайновые документы для сокращения объёма книги, для повышения качества восприятия? Ведь то, что читатель попробует руками, запомнит на уровне комбинаций клавиш, усваивается гораздо глубже, чем прочитанное на бумаге. Опять же, очень важно подтолкнуть пользователя к открытию системы, пробудить интерес к её исследованию. Тем не менее, есть способ по крайней мере попытаться объять необъятное. В мире Линукс важное место занимает понятие дистрибутива и системы управления пакетами. Выбрав дистрибутив и освоив единственную программу - менеджер пакетов, вы получаете в незримые помощники и консультанты опытнейших администраторов, разработчиков этого дистрибутива. Особенно это относится к выбранному нами Debian/GNU Linux. Уникальность этого дистрибутива в том, что он создаётся всемирной распределённой командой разработчиков. Сообщество Debian вполне можно рассматривать как авторитетный клуб сисадминов, делящихся друг с другом (попутно с нами тоже) свободно доступными программами в специально подготовленном, упакованном виде. Так что в отличие от других книг этот курс является лишь дополнением к готовому дистрибутиву. Самая кропотливая работа по встраиванию программы в систему, подготовке документации, созданию инсталяционных скриптов, конфигурационных файлов, отслеживанию зависимостей программ друг от друга или их конфликтов, контроль за целостностью пакета или всей системы, и, немаловажно, чистому его удалению - вся эта работа сделана для нас сопроводителями Debian. От читателя данного руководства предполагается знание системы Unix(R) на уровне опытного пользователя. Подразумевается хорошее владение командным процессором bash, текстовыми, файловыми утилитами, умение читать и править скрипты на awk, perl, знание визуального редактора vi и потокового sed. Начинающий сисадмин должен иметь представление о традиционных инструментах программирования - утилите make, языке Си. Время от времени будут встречаться ссылки на документы HOWTO, более подробно освещающие отдельные темы. Конкретно о Линукс желательно уметь компилировать ядро, понимать процесс загрузки системы, механизм запуска процессов и работы сервисов. Про Debian нужно обязательно иметь представление о философии и законах этого сообщества, о дистрибутиве, архиве пакетов, уверенно владеть менеджером пакетов dpkg(8) и более высокоуровневыми средствами apt-get(8), dselect(8). В качестве награды за освоение более сложной системы вы получите надёжную масшабируемую сеть, следить за порядком в которой будет значительно проще. В идеальном случае мы будем стремиться к переходу качества в количество. Например, точная настройка серверов в сети позволит безболезненно добавлять новые клиентские станции, а достаточная квалификация сетевого администратора даст возможность сэкономить на стоимости коммерческого ПО . 2. Пользователи Пользователи в сети существуют в виде регистрационного имени или идентификатора пользователя uid, иногда просто id. Для системы важен только номер, но для людей привычнее буквенные обозначения, а также важна некоторая персональная информация, например, настоящее имя, телефонные номера, местонахождение. При регистрации нового пользователя в системе эта информация заносится в базу данных, из которой её могут извлекать другие программы некоторым стандартным образом, с помощью системного вызова getpwent(3) и иже с ним. Цифра в скобочках (3) обозначает раздел руководства, в котором подробно рассказан этот системный вызов и получаемая с его помощью информация: ... $ man 3 getpwent Нам, по счастью, пользоваться системными вызовами для запросов к БД пользователей нет никакой необходимости. Для работы с этой БД существует масса программ, так что я упомянул этот системный вызов только для того, чтобы вы поняли механизм работы системы и могли при необходимости легко найти дополнительную информацию. Прежде чем обсуждать организацию БД пользователей дальше, давайте посмотрим повнимательнее на содержимое файла /etc/passwd, а также на имеющуюся on-line документацию passwd(1) и passwd(5). Из файла я возьму только одну строку, остальные строки устроены точно так же, и сразу же разобью эту строку на отдельные поля. Этих полей в файле /etc/passwd всего 7, они отделены друг от друга двоеточием : 1. proba: 2. x: 3. 1001: 4. 1000: 5. Proba User,room,ph. work,ph. home,proba usera: 6. /home/p/proba: 7. /bin/bash В этой табличке для удобства обсуждения я вставил номера полей и оставил знак двоеточия :, который не является частью поля, а только отделяет поля друг от друга. Страница руководства passwd(5) кратко рассказывает обо всех полях, но давайте поговорим о них более подробно. Первое поле является тем самым id, логином, именем пользователя, под которым он существует в системе, а возможно и во всей Сети. Это имя пользователь вводит при входе в систему, к нему привязан его домашний каталог, почтовый адрес, остальная персональная информация. Имя пользователя удобнее всего составить из строчных английских букв, цифр и знака - (минус), желательно не более 8 символов длиной. Первой в имени обязательно должна быть буква. Можно использовать и другие символы, но лучше не рекомендовать пользователям этого делать - рано или поздно с таким именем возникнут проблемы. Имя пользователя должно быть уникальным в пределах одного хоста (компьютера), но так как мы настраиваем не один компьютер, а всю сеть, то это значит, что имя должно быть уникальным в пределах сети. Второе поле у всех пользователей одинаково - это буква x. Это значит, что в системе используется т.н. shadow passwords, или теневые пароли. Когда-то давно в этом поле помещался зашифрованный пароль, зная который, пользователь из поля 1. мог войти в систему. Увы, это простая схема авторизации оказалась недостаточно защищённой в нашем далёком от идеала мире. Пароль пользователя всегда хранится в зашифрованном виде, как результат одностороннего хеширования, свёртки собственно строки пароля. Если злоумышленник сумеет украсть файл с зашифрованными паролями, то на современном мощном компьютере вполне реально перебрать миллионы вариантов разных паролей и подобрать некоторые слабые пароли. Этот метод взлома паролей называется перебором по словарю. Мы ещё не раз обратимся к вопросу сохранения пароля в тайне, пока же скажу, что метод shadow создан как дополнительный барьер для защиты от нечестных пользователей, затрудняющий кражу файла с паролями. Третье поле также является id пользователя, но уже цифровым uid, его уникальным номером. Для системы важен именно этот номер. Все файлы пользователя, все запускаемые им задачи также получают этот uid и все связанные с ним права. Обычно администратор добавляет пользователей с помощью специальной программы, например, adduser(8). В настройках adduser.conf(5) можно задать многие параметры, в частности, диапазон значений для uid. При создании нового пользователя программа adduser(8) автоматически выберет первый свободный номер из заданного диапазона. Четвертое поле похоже на третье, предыдущее, но является цифровым значением группы gid, к которой принадлежит данный пользователь. Снова, как и в предыдущем поле, для системы важен только цифровой номер. Имя группы, соответствующее этому номеру, берётся из отдельного файла, /etc/group. Этот файл устроен весьма просто, но, тем не менее, с ним связано очень важное понятие для разграничения полномочий. Вот строка из этого файла, всего 4 поля: users:x:1000:ruslan,ophil,virt То цифровое значение поля gid, которое мы встретили в четвертом поле записи из passwd, здесь стоит в третьем поле. Самое первое поле является именем группы. Второе поле, точно как и в файле passwd, отсылает за значением пароля в отдельный защищённый файл gshadow из набора теневых паролей. В четвёртом и последнем поле записи из /etc/group стоит список имён пользователей, входящих в эту группу. Мы видим, что имена пользователей разделены запятыми, список никак не упорядочен, его длина не ограничена. Обратите также внимание, что самого юзера proba в этом списке нет. Каждый пользователь обязательно принадлежит к какой-либо группе, номер этой группы gid указывается в том самом четвёртом поле из /etc/passwd. Но пользователь может входить во много групп. Вспомним, что каждый объект в файловой системе имеет двух владельцев - владельца-пользователя и владельца-группу. Права на объект задаются для трёх категорий пользователей - самого владельца, владельца-группу и всех остальных. Таким образом, передавая права на владение объектом файловой системы в отдельную группу, а затем включая в эту группу определённых пользователей, администратор системы может разграничивать полномочия пользователей. Вернёмся, однако, к файлу /etc/passwd. Мы дошли до самого длинного поля 5. Это поле по традиции иногда называют полем gecos, но в современных Unix системах его используют для задания настоящего имени пользователя и другой персональной информации. Само это поле в свою очередь состоит из нескольких отдельных полей, разделённых запятыми. Смысл и назначение этих персональных полей не формализованы и используются отдельными программами по разному. Уже упомянутая программа adduser(8) запрашивает при создании пользователя следующую информацию: Full Name []: Room Number []: Work Phone []: Home Phone []: Other []: Поле Other [] можно использовать как комментарий, некоторую дополнительную информацию о пользователе. Программа finger(1) и соответствующий сервис in.fingerd(8) сообщают о пользователе данные из первых 4 полей gecos. Программа login(1) может использовать в поле gecos ещё 3 дополнительных поля. Для точной настройки этой программы используется отдельный конфигурационный файл login.defs(5), из которого можно активизировать особые лимиты на предоставляемые пользователю ресурсы. Более подробно о накладываемых на пользователя ограничениях можно узнать из nice(1) о приоритете запускаемых задач pri, а также из bash(1) о назначении ulimit и umask. Пятое поле gecos из /etc/passwd долго служило примитивным хранилищем персональной информации, но в современной сети с централизованной БД пользователей есть более удобные решения. Мы изучим одно такое решение на основе службы каталога LDAP, пока же посмотрим на оставшиеся 2 поля из /etc/passwd: /home/p/proba и /bin/bash. В поле номер 6 хранится т.н. домашний каталог пользователя. В этом каталоге пользователь имеет право создавать и хранить собственные файлы и каталоги, из него берутся файлы для настроек отдельных программ, в домашний каталог сохраняется прочитанная почта и т.д. В правильно настроенной системе обычному пользователю запрещается создавать файлы где-либо кроме собственного домашнего каталога и особого временного каталога /tmp. При входе пользователя в систему значение этого поля присваивается глобальной переменной $HOME, а из неё попадает во все запускаемые пользователем программы. Каталог, в котором создаются домашние каталоги пользователей, обычно называется /home. Если в системе планируется большое число пользователей, удобно сразу же разбить каталог /home по первой букве имени пользователя, как /home/p/proba в нашем примере. Настройки adduser.conf(8) позволяют сделать это автоматически, как и многое другое. Например, часто во вновь созданный домашний каталог пользователя копируется начальный набор файлов и каталогов из /etc/skel. Ещё одно обязательное действие при создании пользователя - установить ему лимит, квоту на дисковое пространство. Скрипт adduser(8) + опция QUOTAUSER="spec-user" из adduser.conf(8) автоматически скопируют настроенные лимиты пользователя spec-user для вновь создаваемого пользователя. О системе квот нужно побеспокоиться на самом раннем этапе настройки системы. При выборе типа файловой системы обязательно убедитесь, что с установкой квот для пользователей в этой системе проблем не возникнет. Также всегда надо включать поддержку квот в ядро и сразу же установить пакет quota для работы с ними. Без ограничения на дисковое пространство занять всё свободное место можно любому пользователю за считанные минуты, нарушив тем самым работу системы. Последнее, седьмое поле из каждой записи файла /etc/passwd содержит полный путь к программе, запускаемой при входе пользователя в систему. Этой программой может являтся командный процессор, например, /bin/bash. Командый процессор, т.н. шелл, это довольно высокая привилегия, даваемая пользователю. С помощью шелла юзер получает доступ практически ко всем программам и сервисам, установленным в системе и не защищённым дополнительно. Если пользователю нужны только некоторые из имеющихся сервисов, например, только почта, или только создание web-страниц на сервере, вместо настоящего шелла вполне можно задавать другую программу. Например, если задать вместо шелла /usr/bin/passwd, то пользователь, пройдя регистрацию в системе, получит возможность только изменить свой пароль. Как уже упоминалось, к первоначальной системе с использованием только двух файлов /etc/passwd и /etc/group, позже был добавлен набор программ shadow. Сейчас этот способ дополнительной защиты полностью интегрирован в систему, так что в дистрибутиве Debian, например, пакет passwd собирается из исходников shadow. Теневые пароли добавляют к двум рассмотреным нами файлам ещё пару штук: /etc/gshadow и /etc/shadow. Эти файлы недоступны для просмотра обычным пользователям, но вам, как администраторам системы, я покажу и расскажу их устройство. Первый из дополнительных файлов, /etc/gshadow, почти не отличим от оригинального файла /etc/group: users:x::ruslan,ophil,virt Первое поле, имя группы, второе поле, используемое для пароля группы, а также последнее, список членов группы, в обеих файлах совпадают. В нашем примере пароля нет, но если администратор задаст пароль для группы командой gpasswd(1), то любой пользователь, знающий пароль, может перейти в эту группу, выполнив команду newgrp(1) или её синоним sg(1). У законных членов группы пароль не запрашивается. Включение пользователей в группы или временный переход в группу открывает ещё одно измерение в разграничении полномочий. Мы помним, что второй владелец файла, каждого объекта в системе определяется номером группы, с которым связаны три типа доступа - чтение, запись, исполнение. Членство в группе также даёт право пользователю изменять группу-владельца своих файлов или каталогов, см. chgrp(1). Под своими здесь имеются в виду те объекты, к которым у пользователя есть доступ по записи - либо как единоличного владельца, либо как члена группы, либо как всех остальных. Права на объект проверяются именно в такой последовательности. Группа-владелец в некотором смысле более важна, чем собственно владелец- пользователь. Пользователь всегда один, он уникален по определению. Администратор системы, если ему важен порядок и ответственность в его сети, должен строго следить за тем, чтобы у каждого пользователя был свой бюджет, id, который ни при каких обстоятельствах нельзя передавать другому человеку. Для совместного использования файлов и программ удобно использовать объединение пользователей в группы. Для работы с группами пользователей существуют много программ. Большая их часть доступна только администраторам системы, которым, вообще говоря, и так доступно всё. Но вот программа gpasswd(1) в сочетании с третьим полем из файла /etc/gshadow, вводит новое понятие администратора группы. Если суперпользователь, root, выполнит команду ... # gpasswd -A ophil users , то изучаемая нами строка из файла /etc/gshadow примет новый вид: users:x:ophil:ruslan,ophil,virt В третьем поле появилось имя пользователя, который теперь стал администратором данной группы. Администратор группы с помощью всё той же команды gpasswd(1) может теперь управлять своей группой: добавлять или удалять пользователей из группы, менять или удалять пароль для доступа в группу не входящих в неё пользователей, либо совсем запретить вход в группу для посторонних. Иногда БД пользователей организуют таким образом, что для каждого юзера создаётся отдельная группа из него одного. По-видимому, это делается из соображений безопасности как ещё один (сомнительный?!) рубеж защиты файлов пользователя. Этой же защиты можно добиться, задав более строгую umask 077 для вновь создаваемых объектов или вручную проверив права на все свои файлы. Мне кажется, что группа из одного пользователя лишает смысла само понятие группы. Файл shadow(5) исторически возник как дополнительный рубеж защиты от кражи паролей. Он не позволяет простым способом получить зашифрованный пароль, файл /etc/shadow закрыт для обычной публики. Кроме этого, с введением теневых паролей в системе авторизации появилась возможность регулировать срок действия пароля. Для этого в файле /etc/shadow добавлены 6 новых полей, регулирующих время действия пароля, даты его обязательного изменения, за сколько дней до устаревания пароля предупреждать об этом пользователей, и прочее. Все связаные с временем поля в этом файле содержат либо количество дней со времени epoch (с 1 января 1970 года, от дня рождения системы Unix(R)), либо диапазон дней, либо число 99999, задающее дату в очень далёком будущем . 2.1 Сопровождение БД пользователей Некоторые приемы сопровождения БД пользователей мы уже обсудили: это скрипт adduser(8) и adduser.conf(8), образец /etc/skel для начального домашнего каталога пользователя. В основном программы для работы с пользовательской информацией из БД паролей собраны в пакете passwd. В Debian есть несколько способов посмотреть список файлов, входящих в пакет. Например, можно просто заглянуть в файл /var/lib/dpkg/info/passwd.list . Если установлен пакет dlocate, то можно воспользоваться командой dlocate(1). Эта программа, вызванная, например, вот так: ... $ dlocate -ls passwd\|grep bin/ , покажет нам довольно много утилит для работы с теневыми паролями, включая специальный случай вызова редактора. Обычным редактором лучше не пользоваться из-за отсутствия блокировки - может случиться, что оператор будет править файл, а пользователь или другой оператор захотят, к примеру, изменить пароль. Когда информация о пользователях, а также о группах содержится в каждом случае в двух файлах, есть определённый риск рассогласования этих файлов. Например, расхождение возникнет, если вручную из редактора добавить пользователя в группу в файле /etc/group, но забыть вставить его в файл /etc/gshadow. Поэтому всегда желательно пользоваться специальными утилитами, как, например, useradd(8), newusers(8), gpasswd(1), и прочими. Если же рассогласование между парными файлами, /etc/{group,gshadow}, /etc/{passwd,shadow}, всё же возникло, для исправления ситуации есть пара специальных утилит: grpck и pwck. Их можно вызывать по отдельности, но советую просто время от времени запускать простой скрипт, который сам сделает все необходимые вызовы: ... $ sudo shadowconfig on Этот же скрипт можно использовать для превращения теневых паролей в обычные, но делать это ни в коем случае не рекомендуется. Мы уже упоминали о риске взлома паролей перебором по словарю. Авторизация пользователей, контроль доступа в системе Unix основаны на том, что пароль известен только самому пользователю. Никто, включая администратора системы, не должен знать чужие пароли. Секретность пароля юзера является главной гарантией его ответственности за собственные действия, обязательным условием поддержания порядка в системе. Только программными средствами защитить систему невозможно, в подавляющем большинстве случаев нарушения порядка лежит человеческий фактор. Поэтому самым первым мероприятием по защите системы должно стать составление и утверждение правил работы в сети. Одним из пунктов правил должно стать сохранение пользователем своего пароля в тайне. Ещё один обязательный пункт должен запрещать работать в системе под чужим логином. Составление правил поведения в сети вопрос не только администратора системы. В современном глобальном мире с помощью компьютера могут совершаться отнюдь не виртуальные преступления. Отсутствие правил работы в сети оставляет администратора полностью неподготовленным к неизбежно возникающим проблемам. Некоторые пользователи, не предупреждённые о собственной ответственности, не могут самостоятельно спроецировать на виртуальный мир вполне обычные человеческие нормы поведения: не брать чужое, не вредить, уважать коллег. Выяснив соотношение между организационными и программными мерами защиты системы, посмотрим, что же всё же можно сделать для настоящей конфиденциальности паролей в системе. Для проверки паролей на слабость можно использовать тот же метод, который используют крэкеры, взломщики и прочее компьютерное отребье. В данном случае этот метод используется для защиты, но название пакета может ввести в заблуждение, поэтому важно чётко понимать отличие техно-шпаны от порядочных пользователей и хакеров. В данном случае использование словаря для проверки слабости пароля вполне законно. Средства перебора паролей по словарю выделены в отдельную библиотеку, в текущей версии Debian это cracklib2, проверка пароля на слабость включается установкой пакета libpam-cracklib. После установки этого пакета администратор может создавать и подключать списки слов, т.н. словари, которые _НЕ_ могут использоваться в качестве пароля. Модуль libpam-cracklib также не позволит пользователю задать слишком короткий пароль, похожий на логин или на персональную информацию из записи в /etc/passwd. Есть несколько программ, помогающих выбрать случайный пароль, например, pwgen(1). В любом случае, перед созданием пользователя в БД его нужно предупредить о сложности пароля и связанной с ним ответственности . 2.2 Исключения из правил Рассматривая права пользователей по отношению у объектам в файловой системе, мы рассмотрели три типа пользователей - сам пользователь, группа, и все прочие, а также три типа прав доступа - на чтение, на запись и на исполнение. Все права на объект пока у нас уместились в 9 битов, что изображается при просмотре содержимого каталога соответственно комбинацией из 4 знаков длиной 9. Три знака (rwx) обозначают наличие соответствующего права, а знак - (минус) означает его отсутствие. Эта простая и ясная схема разграничения полномочий в некоторых случаях недостаточна. Дело в том, что uid пользователя наследуется каждой запущенной им программой, и каждая такая программа обладает теми же правами, что и сам пользователь. Для того, чтобы изменить, например, собственный пароль, пользователь должен иметь право на запись в файл /etc/passwd или в ещё более защищённый файл /etc/shadow. Это ограничение обходится введением в список прав трёх дополнительных битов. Администратору системы нужно знать назначение и действие каждого из этих битов, к тому же они по разному действуют на файлы и на каталоги. В первую очередь обратите внимание на действие самого старшего, т.н. suid'ного бита на исполняемые файлы. Вот как выглядит этот бит в случае файла /usr/bin/passwd -rwsr-xr-x 1 root root 24104 May 18 11:15 /usr/bin/passwd* suid'ный бит в списке файлов обозначен заменой буквы x на букву s. Система Unix для файла с установленным suid битом запустит программу не с правами запустившего её пользователя, а с правами владельца файла, в данном случае root'а. В случае файла passwd это решит проблему обновления пароля, но в системе разграничения прав пользователей появилось опасное исключение. Если какая-либо из suid'ных программ позволит пользователю перехватить управление в момент исполнения, например, запустить шелл, то он получит права владельца файла. Если файлом владеет root, это приведёт к несанкционированному полному контролю над системой. В системе Debian имеется отдельная программа, позволяющая отслеживать все программы с установленным suid-битом. Это программа sxid(1) и её кофигурационный файл sxid.conf(5). Ежедневный запуск этой программы позволит следить за всеми исключениями из обычной 9-ти битовой маски прав. Одна программа с установленным suid'ным битом заслуживает отдельного обсуждения. Это программа sudo(8) и соответствующий конфиг sudoers(5). sudo(8) позволяет делегировать некоторые полномочия суперпользователя не отдавая пользователю рутовый пароль. Этот пароль иногда вполне серьёзно рекомендуют хранить в сейфе в запечатанном конверте и никогда им не пользоваться. В файле /etc/sudoers можно указать списки пользователей и списки программ, которые эти пользователи могут запускать с правами администратора. Синтаксис конфигурационного файла sudoers(5) позволяет задавать группы юзеров и группы заданий, разрешаемых выполнять этим группам. Все вызовы пользователями команды sudo записываются в системный журнал . 3. БД пользователей на основе LDAP В предыдущей части мы рассмотрели все поля, составляющие запись о пользователе в системе Unix(R), а также немного обсудили некоторые простые приемы защиты и разграничения полномочий. Этот метод достаточно надёжно работает на отдельном сервере и вполне удобен при не очень большом количестве пользователей. Давайте рассмотрим, какие проблемы могут возникнуть при развитии системы. Первая проблема возникает при создании в системе большого числа пользователей. Наш файл /etc/passwd плоский, т.е. при поиске информации и конкретном пользователе происходит просмотр почти всего файла. Время поиска будет расти как функция О(N), пропорционально количеству юзеров. Если учесть, что активность в системе также пропорциональна числу пользователей, то желательно найти более масштабируемое решение. Ещё одна проблема возникает, если мы используем много хостов в сети, но хотим дать возможность пользователю входить в сеть из любого места. В этом случае нам нужна централизованная БД пользователей с возможностью обращения к ней из любого компьютера в сети. Мы уже заметили, что набор персональной информации о юзерах весьма скуден, не позволяет хранить дополнительные сведения. Сложные запросы к нашей простой плоской БД пользователей также затруднены. Если вы не вполне можете доверять всем участкам и/или участникам вашей сети, нужно подумать ещё об одной проблеме - как защитить передаваемые по сети пароли на физическом уровне. Если кто-то из ваших пользователей сумеет установить в сети программу или устройство, перехватывающее всю передаваемую в сеть информацию, этот злоумышленник сможет подслушать в том числе и чужие пароли. Одно из решений, дающее ответ на все перечисленные вопросы - это установить в системе сервер LDAP и настроить его для хранения БД пользователей. Протокол LDAP (Lightweight Directory Access Protocol) и реализующие его сервисы были призваны реализовать БД специального назначения, иногда называемую службой каталогов. Такая БД является распределённой, иерархической, информация в ней обновляется реже, чем запрашивается. Кратковременные рассогласования между связанными экземплярами БД допустимы, но механизм репликации встроен непосредственно в протокол. В протоколе определён способ адресации уникальных записей, название и описание входящих в БД полей. В версии 3 протокола LDAP предусмотрен также механизм защиты соединения между клиентом и сервером на уровне транспортного протокола TLS (Transport Layer Security). Для низкоуровнего хранения данных могут использоваться различные механизмы и программы, от простого плоского файла /etc/passwd до реляционной SQL СУБД. Рекомендую остановиться на промежуточном варианте - использовать общедоступную библиотеку функций для работы с данными - Berkeley DB. Этот вариант используется по умолчанию в дистрибутиве Debian, и, возможно, также в других. Установка сервера slapd и всех других необходимых для его работы библиотек и пакетов выполняется обычным способом, используя принятый в вашем дистрибутиве установщик. В Debian это apt-get(8) или dpkg(8). При установке сервера slapd программа установки задаст несколько вопросов, а затем создаст простой вариант конфигурационного файла /etc/ldap/slapd.conf, создаст и инициализирует основу БД. Авто-конфигуратор сервера LDAP можно запустить отдельно, например: ... $ sudo dpkg-reconfigure slapd Если всё прошло успешно, в списке процессов появился демон slapd(8), а среди открытых на сервере TCP портов появился ещё один под номером 389. Для работы с БД в пакете slapd есть низкоуровневая утилита slapcat(8), с помощью которой можно сделать дамп содержимого БД. Похожая утилита под именем slapadd(8) восстановит БД из файла формата ldif(5), а программа под именем slapdindex(8) проиндексирует вашу БД. Давайте посмотрим на содержимое БД, созданной при установке: ... $ sudo slapcat dn: dc=gomel,dc=iatp,dc=by objectClass: dcObject dc: gomel dn: cn=admin,dc=gomel,dc=iatp,dc=by objectClass: organizationalRole objectClass: simpleSecurityObject cn: admin description: LDAP administrator userPassword:: e0NSWVBUfUFJVeHFUlg2bDZqMEU= dn: ou=People,dc=gomel,dc=iatp,dc=by objectClass: organizationalUnit ou: People dn: ou=Roaming,dc=gomel,dc=iatp,dc=by objectClass: organizationalUnit ou: Roaming Мы обнаружили, что наша БД уже имеет 4 записи в формате ldif(5). О протоколе LDAP и службе каталогов написаны подробные руководства. На основном сайте проекта OpenLDAP доступен учебник "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/). Не углубляясь в детали, заметим, что первая запись определяет домен, к которому привязаны остальные записи. Также обратим внимание, что у каждой записи есть поле dn: (Distinguished Name), однозначно адресующее эту запись во всём пространстве службы каталога. При желании нашу БД пользователей можно будет включить в глобальную службу каталога, как это делается с распределённой службой имён DNS. Ещё одно поле в каждой записи весьма важно для понимания механизма работы нашей особой каталожной БД. Это поле objectClass:, определяющее класс объекта, список допустимых в записи полей, а также их содержание и смысл. Служба каталогов глобальна, поэтому имена и назначение полей регламентируются отдельными RFC документами, а их формальное описание содержится в т.н. схемах, см. отдельный каталог /etc/ldap/schema/. Последнее, на что мы обратим внимание в автоматически созданном для нас ldif-файле - то, что наш экземпляр БД службы каталогов сам в свою очередь также организован иерархически. Самая первая запись вводит объект dcObject (domain component), в который будут далее включаться другие компоненты или объекты. Более длинные dn: адреса включают в качестве компонента ранее определённый узел древовидной иерархии объектов БД, сами становясь ветвями либо листами дерева данных. Таким образом, вторая запись в нашей БД вводит объект класса simpleSecurityObject, содержащий имя и зашифрованный пароль администратора БД. Это поясняется вторым классом объекта, присутствующим в этой записи: organizationalRole. Третья и четвёртые записи вводят новые уровни иерархии в будущую БД. Служба каталогов может быть построена не только на основе доменной организации, как это сделано в Интернет и DNS. Можно создавать каталоги на основе географического разделения, по странам, или по принадлежности к организации. Третья запись в уже созданной БД вводит иерархию People, куда мы в дальнейшем будем включать всех пользователей. Четвёртая запись вводит ещё одно подразделение пользователей, используемое, в частности, браузерами Mozilla (Netscape) для хранения персональных настроек юзеров. Взглянем теперь на конфигурационный файл slapd.conf(5), из которого задаются параметры работы сервера LDAP и самой БД. Из страницы руководства видно, что файл конфигурации состоит из опций, относящихся к отдельным секциям - общих для сервера, для транспортного уровня, для выбора типа низкоуровневой БД, и специфических для каждой из этих БД опций. В самом начале созданного для нас файла /etc/ldap/slapd.conf включены используемые будущими записями схемы. В конце файла настроены параметры доступа к записям БД. Регламентация доступа к БД, репликация данных на подчинённые сервера, защита пересылаемой информации могли бы стать темой отдельного курса. Но для нашей частной задачи - настроить сервер для хранения БД пользователей, тот конфиг, который создан по умолчанию, почти достаточен. Для простоты изложения, чтобы разрешить для начала простую авторизацию, необходимо в этот конфиг включить строку: rootdn "cn=admin" Имя admin и соответствующую запись с паролем уже создала для нас программа конфигурации пакета slapd, это запись номер два в рассмотренной выше распечатке. Опция rootdn, также как и root в Unix'е, даёт полный доступ ко всей БД LDAP. Мы уже умеем делать дамп содержимого БД, а также при необходимости восстановить БД из ldif-файла. С помощью того же ldif-формата можно и пополнять нашу БД. Но делать это будет правильно не с помощью slapadd, доступного только суперпользователю, а с помощью пакета ldap-utils, содержащего набор клиентских программ для работы со службой каталога. Давайте, пока наша БД содержит всего 4 записи, попробуем в действии утилиты для работы с БД. Первая, ldapsearch(1), позволяет делать запросы к службе каталога. Например: ... $ ldapsearch -LLLx покажет нам все четыре записи почти в том же виде, что приведен выше. Настройка сервера slapd(8) пока позволяют нам читать все поля, кроме пароля, что мы и делаем анонимно, без авторизации (ключ -x). Ключи LLL отключают вывод дополнительной информации, оставляя чистый ldif(5) формат. ... $ ldapsearch -LLLx ou=* ou выдаст нам две записи для объектов organizationalUnit и покажет только поля dn: и ou:. Таким образом, поле dn: присутствует всегда, это адрес записи, а остальные поля задаются в списке после критерия поиска в БД. Этот критерий в мире служб каталога называется фильтром. Вот пример, как строить такой фильтр: ... $ ldapsearch -LLLx '(\|(dc=)(cn=a))' Здесь мы запросили и получили две первые записи. Для экранирования от шелла спец. символов мы включили выражение фильтра в одинарные кавычки. Вертикальная черта \| означает логический оператор ИЛИ. Имеются ещё операторы ! (NOT), & (AND), операторы сравнения чисел и строк. Фильтрам посвящён отдельный документ RFC2254, но перечисленных операторов и подсказки, что фильтры надо составлять в виде обратной польской записи операндов, надеюсь, достаточно для простых запросов к БД. Попробует теперь вставить запись в БД. Обычно БД пользователей создаётся не на пустом месте, у нас уже есть пользователи в файле /etc/passwd, так что желательно постепенно перевести этих пользователей в новую БД. Для миграции от традиционной БД на основе [теневых] паролей в Debian имеется пакет migrationtools. Этот пакет можно установить в систему как обычно. Нам, впрочем, этот набор перловых скриптов понадобится только на время, до полной миграции к новому формату БД. Так что можно его скопировать в домашний каталог и начать опыты с сервером LDAP. Из пакета migrationtools возьмём для упражнений со службой каталога три файла: migrate_common.ph, а также два исполняемых скрипта migrate_{group,passwd}.pl В первом из файлов надо поправить несколько глобальных переменных, а именно $DEFAULT_BASE = "dc=gomel,dc=iatp,dc=by"; $DEFAULT_MAIL_DOMAIN = "gomel.iatp.by"; Теперь скрипты готовы к работе. На вход скрипта нужно подавать файл с паролями, но, как и всегда, возможно перенаправить стандартный ввод. Вот что сделает миграционная утилита с уже знакомой нам записью о юзере proba: ... $ grep "^proba:" /etc/passwd\|sudo ./migrate_passwd.pl - dn: uid=proba,ou=People,dc=gomel,dc=iatp,dc=by uid: proba cn: Proba User telephonenumber: ph. work roomnumber: room homephone: ph. home givenname: Proba sn: User mail: [email protected] objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: account objectClass: posixAccount objectClass: top objectClass: kerberosSecurityObject objectClass: shadowAccount userPassword:: e2NyeXB0fW84Q2dOSTl0TDNsZ3M= shadowLastChange: 11874 shadowMax: 99999 shadowWarning: 7 krbname: [email protected] loginShell: /bin/bash uidNumber: 1001 gidNumber: 1000 homeDirectory: /home/p/proba gecos: Proba User,room,ph. work,ph. home,proba usera Обратите внимание, что нам пришлось вызвать скрипт с правами суперпользователя, чтобы получить доступ к информации из файла shadow. Скрипт почти подготовил нам запись в формате ldif(5), готовую для импорта в БД LDAP. Однако, если мы попытаемся вставить эту запись в БД, выскочит сообщение об ошибке, что-то вроде "unrecognized objectClass 'kerberosSecurityObject'" и "attribute 'krbName' not allowed". Опытного администратора, конечно, такие сообщения не остановят, а только раззадорят. Один из способов решения - начать разбираться со схемами LDAP, но это сложно и долго. Другой способ, бесспорно правильный, внимательно посмотреть в скрипт и убрать сомнительные строки. Ещё один способ, наиболее подходящий в нашем случае - это удалить ошибочные строки до лучших времён, пока мы не займёмся вплотную авторизацией через kerberos. Итак, включаем ещё один фильтр и отправляем всё в БД: ... $ grep "^proba:" /etc/passwd\| > sudo ./migrate_passwd.pl -\| > egrep -v '(kerberos\|krbname)'\| > ldapadd -x -W -D "cn=admin,dc=gomel,dc=iatp,dc=by" В последней строке мы вызвали утилиту ldapadd(1) с парой новых ключей. Ключ -D со строкой, точно соответствующей dn: адресу для администратора БД, который мы рассмотрели выше и дополнительно указали в опции rootdn в slapd.conf(5). Ещё один ключ -W позволил нам пройти простую авторизацию (-x) и ввести тот самый пароль администратора БД. Нам удалось таким образом ввести в БД запись о пользователе, которая приблизительно соответствует тем полям, что мы обсуждали в первой части, рассматривая традиционную систему с файлами /etc/{passwd,shadow}. LDAP добавила к записи о пользователе некоторые новые поля, что можно увидеть, сделав дамп нашей обновлённой БД. Ещё больше информации о пользователе можно будет добавлять в дальнейшем. Стандартом предусмотрены поля для фото, для открытого GPG-ключа, и многие, многие другие. Нам, однако, пока что надо заставить наши привычные программы, ответственные за авторизацию пользователей, а точнее, системные вызовы getpwent(3), setpwent(3) и прочая, брать данные о пользователях из нового места. К счастью, система Unix для такого радикального перехода на новую схему была постепенно подготовлена. Системные вызовы проверяют т.н. Name Service Switch, nsswitch.conf(5), на предмет того, где им следует искать соответствующие данные. Для того, чтобы заставить эти вызовы использовать сервер LDAP, нам нужно установить пакет libnss-ldap. Затем нужно поправить старый файл конфигурации /etc/nsswitch.conf, задав поиск данных для авторизации в БД LDAP. Вот три строки, которые нужно изменить: passwd: files ldap group: files ldap hosts: files dns ldap У нас появился новый файл libnss-ldap.conf(5), в котором также надо заполнить как минимум две строки, указав адрес сервера и основу БД, от которой будут отсчитываться далее остальные объекты - записи: # Your LDAP server. Must be resolvable without using LDAP. host ldap # The distinguished name of the search base. base dc=gomel,dc=iatp,dc=by Ещё один сервис, собственно авторизация, также готов для перехода на новую схему. На странице руководства pam(7) рассказано о методе авторизации с использованием подключаемых модулей. В пакете libpam-doc содержится аж три руководства по администрированию и программированию PAM-модулей. Давайте, однако, доверимся разработчикам Debian и без углубления в теорию установим пакет libpam-ldap и снова займёмся конфигурационными файлами. В Debian этот пакет не переписывает по умолчанию все конфиги, относящиеся к pam-библиотекам, расположенным в каталоге /etc/pam.d/. Для перехода на авторизацию через LDAP нужно посмотреть примеры новых конфигов, входящие в документацию на этот пакет. Примеры лежат в каталоге /usr/share/doc/libpam-ldap/examples/. Как всегда, обязательно сделайте архивную копию вашего /etc. Полезно иметь наготове аварийную дискету, например, tomsrtbt (см. http://http://www.toms.net/rb). Мы покушаемся на самую основу Unix, систему авторизации. Итак, мы бесстрашно переписали все файлы в /etc/pam.d/ на рекомендованые сопроводителями пакета libpam-ldap. Эти файлы настраивают одноимённые с ними программы, использующие авторизацию пользователей. Для настройки самой библиотеки pam_ldap.so используется файл pam_ldap.conf(5). Как и в случае с libnss-ldap.conf(5), в нём нужно как минимум задать те же 2 строки: host ldap base dc=gomel,dc=iatp,dc=by Опция host, естественно, указывает на сервер LDAP. Если есть сомнения в работе DNS, можно задавать IP адрес. Если вы успешно установили оба пакета и аккуратно поправили перечисленные выше конфиги, пора проверить в действии новую схему авторизации. Мы, упражняясь с БД LDAP, уже импортировали в неё данные о юзере proba. Давайте теперь удалим этого юзера из /etc/passwd и посмотрим, войдёт ли он в систему по новой схеме. Если новый способ авторизации работает, наш следующий шаг - импортировать в БД LDAP оставшихся в /etc/passwd пользователей. Скрипты для миграции мы уже опробовали, так что осталось только подать на вход скрипта список обычных пользователей. В файле /etc/passwd есть также системные пользователи. Это фиктивные пользователи, они используются системой и некоторыми сервисами для владения файлами. У них не должно быть шелла и под этими именами нельзя войти в систему. Тем не менее, эти uid важны для работоспособности системы, иногда на раннем этапе загрузки, до включения сервиса LDAP, так что системных пользователей мы оставляем в файле /etc/passwd. Как видно из нашего nsswitch.conf(5), в первую очередь при поиске юзера просматривается файл passwd(5), а уже затем идёт обращение к сервису LDAP. Обычные пользователи при создании получают uid в заданном диапазоне. Мы уже упоминали, при настройке adduser.conf(5) можно настроить диапазон чисел, в котором будут браться эти номера. По умолчанию, юзерские uid начинаются с 1000. В Линукс используются 32-разрядные числа для идентификаторов, поэтому сверху количество пользователей практически не ограничено. Повторяем знакомую процедуру импорта для всех обычных пользователей с uid > 999: ... $ awk -F: '$3>999' /etc/passwd\| > sudo ./migrate_passwd.pl -\| > egrep -v '(kerberos\|krbname)'\| > ldapadd -x -W -D "cn=admin,dc=gomel,dc=iatp,dc=by" После успешного импорта можно удалить простых пользователей из файлов /etc/{passwd,shadow}. В случае единственного сервера переход на новую схему авторизации уже добавил нам новые возможности. Например, БД пользователей стала настоящей базой данных, с быстрым извлечением записи, с возможностью помещать в неё самую разную информацию, с ведением журнала обновления БД. Но если мы строим сеть, то новая схема авторизации даёт нам решение проблемы централизованной авторизации, единого списка пользователей и единого пароля пользователя в пределах всей сети. Теперь мы можем, в точности повторив процедуру настройки сервисов NSS и PAM, установив необходимые библиотеки, использовать централизованную БД пользователей для входа в систему на любом из настроенных клиентов службы LDAP . 4. БК - Бездисковые Компьютеры Создание БД пользователей только первый шаг в построении современной сети. Нашим следующим шагом станет настройка сервера, или, при необходимости, нескольких серверов, для обслуживания клиентских рабочих станций. Компьютеры пользователей должны быть бездисковыми по многим причинам. Вот не полный и не упорядоченный перечень выгод, диктующих такой выбор: администрирование компьютера на самом деле представляет собой администрирование его жёсткого диска. Если нет диска и отдельного набора программ, то нет и лишних проблем у сисадмина. БК позволяет изменить облик настольного компьютера. Нет более нужды в громоздком корпусе, мощном источнике питания, шумных вентиляторах и мешанине проводов. Высокоинтегрированная мат. плата со встроенным процессором вполне поместится в корпусе монитора или в небольшом отдельном блоке. централизованное хранение данных пользователя делает каждое рабочее место универсальным и взаимозаменяемым. единое дисковое пространство серверов решает проблему архивации данных, их защиты, добавления новых дисков. быстрый старт системы, отсутствие движущихся деталей, малый нагрев и энергопотребление, бесшумность работы. опционно в БК можно оставить CD-ROM как один из способов загрузки системы, считывания данных, создания он-лайновой библиотеки CD. при той же цене, что у полноразмерного ПК, можно приобрести бездисковый компьютер гораздо лучшего качества. Разумнее потратить лишние деньги на хороший монитор, качественный звук, web-камеру для видеоконференций. Жёсткий диск одно из самых дорогих устройств в ПК, он же основной источник проблем, а флоппи-диск безнадёжно устарел. если строить сеть из стандартных типовых компьютеров, добавление новых рабочих мест также станет типовым, сложность администрирования не будет зависеть от размера сети. Это же относится к аппаратному сопровождению - замена БК сводится к замене блока и правке нескольких строк файлов настроек. централизация ресурсов сети даёт возможность ими свободно маневрировать, от запуска программ на отдельном мощном сервере вплоть до организации вычислительных кластеров из БК. отношения пользователей и администраторов переходят на качественно новый уровень. Программы, установленные на сервере, мгновенно доступны каждому пользователю, обновления выполняются также централизовано. при необходимости использовать коммерческий софт установка ПО на сервере приложений также даёт значительную экономию средств. Сомнительные программы можно собрать на одном единственном сервере, не беспокоясь более о стоимости лицензий для рабочих мест. Пожалуй, хватит перечислять достоинства бездисковых рабочих мест. Стоит сказать о возможных проблемах. Во-первых, самостоятельно собрать БК из отдельных компонентов сложнее, чем обычный ПК. Во многих случаях проще и дешевле приобрести готовый, специально спроектированный для этой цели. К сожалению, в наших условиях выбор готовых бездисковых станций не так богат, как это должно быть. Вторая проблема - изменение стиля работы пользователей, миграция от персональной системы к коллективной работе в сети. К новой модели вычислений предъявляются более высокие требования надёжности. Если в новой сети оставить обычные ПК, сеть становится гетерогенной, более сложной и менее надёжной . 4.1 Базовые сервисы Для совместного использования централизованных ресурсов нам понадобится настроить несколько базовых сервисов. Это сервисы, без которых работа сети будет невозможна или неэффективна. К таким сервисам относятся: DNS, сервер доменных имён DHCP, динамическое распределение адресов Для сети из бездисковых рабочих станций необходимо настроить дополнительные сервисы: TFTP, упрощённый (Trivial FTP) протокол передачи файлов NFS, сетевая файловая система Для двух последних сервисов необходимо также подготовить образы системы - ядро для сетевой загрузки, корневую файловую систему, другие экспортируемые каталоги. При более тонкой настройке сети могут понадобиться дополнительные сервисы. Первое, что нужно сделать при построении сети, или при подключении вашего компьютера к глобальной сети - это настроить службу DNS. Обращение к любому хосту в сети по имени вызывает механизм поиска адреса, соответствующего этому имени. Программы работают только с адресами, имена используются только людьми. Системный вызов для разрешения имени в адрес называется gethostbyname(3). В последней версии Debian для сервера DNS используется пакет bind9. О настройке этого сервиса коротко рассказать невозможно. Список документов RFC, имеющих отношение к службе именования доменов, включает на лето 2002г. 63 номера. В последних предложенных стандартах предусмотрены меры авторизации и защиты обменов. Появился новый облегчённый (lightweight resolver) протокол. Не имея возможности углубляться в теорию этого сервиса, нам придётся снова довериться сопроводителям проекта Debian и установить на сервере необходимые пакеты. Команда ... $ sudo apt-get install lwresd bind9 bind9-doc bind9-host сама найдёт и установит все необходимые программы. По умолчанию устанавливается только кэширующий сервер для внешних запросов. Если у нас имеется собственный домен или внутренняя сеть, нам придётся заполнить файлы конфигурации для своих доменов, советуясь время от времени с примерами из документации, с работающими настроенными серверами DNS. Давайте глянем для примера в список хостов с помощью последнего из установленных пакетов - утилиты host(1): ... $ host -lv iatp.gomel.by Управляя доменными именами, можно свести к минимуму настройку клиентов сети. На каждом клиенте должен быть указаны адреса главного, нескольких запасных DNS-серверов, порядок просмотра доменов. Всё это задаётся в файле resolv.conf(5) приблизительно вот так: search gomel.iatp.by iatp.local sys.local local nameserver 10.2.4.200 nameserver 193.232.248.45 nameserver 193.232.248.2 Если клиенты настроены правильно, так что обращение по имени, к примеру, mail приводит на нужный сервер, то в дальнейшем распределение сервисов по отдельным компьютерам можно будет регулировать с помощью DNS-сервера, не трогая настройки на клиентах. Сервис DHCP устанавливается командой ... $ sudo apt-get install dhcp3-server В дистрибутиве Debian одновременно присутствуют несколько версий серверов DHCP. Указанная выше версия позволяет обслуживать сразу несколько сетевых карт. Без правки конфигов сервис не заработает, но в пакет входит прокомментированный пример файла конфигурации и подробная страница руководства dhcpd.conf(5). Сервер DHCP позволяет конфигурировать клиентов сети, выдавая им динамические или статические IP адреса, указывая адрес сервера DNS, шлюза в другие сети, прочую служебную информацию. Оба эти сервиса, DNS и DHCP, позволяют полностью управлять адресами и именами компьютеров и сетей. Мы будем использовать сервис DHCP на нескольких уровнях. Первый уровень, или первая версия конфига, пусть предоставляет фиксированные, статические IP адреса машинам в локальной сети, а также резервирует и отдаёт диапазон адресов для временно подключающихся клиентов, например, через модем . 4.2 Настройка клиента для сетевой загрузки Мы ещё вернёмся к настройке DHCP сервера, а пока пора заняться клиентом - рабочей станцией. Если ваши клиенты не готовые к употреблению БК, то нам предстоит довольно низкоуровневая возня с сетевыми картами и разными системными загрузчиками. Увы, в этот ответственный момент мы не можем более расчитывать на авторитет сопроводителей Debian, как это было до сих пор. Среди десятка с лишним тысяч пакетов для такой специфической задачи готового рецепта для сетевого загрузчика нет и быть не может. Сетевые карты и способы загрузки системы слишком разнообразны. В процессе создания из обычного ПК с жёстким и флоппи дисками нам поможет другой дистрибутив. Среди многих мини-дистрибутивов, умещающихся на одном флоппике, остановим свой выбор на Tom's Root Boot (tomsrtbt), доступному по адресу http://www.toms.net/rb/ Этот мини-дистрибутив вмещает на специально отформатированном флоппе размером 1.7МБ удивительно много. Кроме чисто административного применения tomsrtbt для починки системы, у этого дистрибутива Линукс есть ещё одно полезное применение. На столь крохотном дисковом пространстве собраны самые необходимые программы и утилиты. В каждой из этих утилит оставлены только наиболее употребительные опции и ключики. В некотором смысле это возврат к истокам, когда и сам Unix, и все его компоненты были маленькими и простыми. Так что tomsrtbt может быть полезным учебным пособием для сисадмина. Проект, позволяющий превратить обычный ПК с сетевой картой в загружаемую по сети бездисковую станцию называется etherboot и расположен по адресу http://etherboot.sourceforge.net . Есть и другие проекты, но давайте остановимся на этом. Он динамично развивается, на лето 2002г. доступна версия 5.0.6, снабжён подробной документацией для пользователей и программистов, поддерживает множество сетевых карт и вариантов загрузки. К сожалению, придётся прибегнуть к ручной работе, компилировать модули, читать документацию. Необходимо также точно знать модель сетевой карты в подопытном ПК. Для начала давайте разархивируем исходники и войдём в каталог src. Набрав команду make, мы дадим задание компилятору собрать модули сетевой загрузки для всех имеющихся сетевых карт. После компиляции в каталоге bin32/ появились загрузчики для 33 разных сетевых карт. Точнее, это 33 разных сетевых чипсета, моделей карт, скорее всего, гораздо больше. Для каждого из чипсетов подготовлены пара файлов, с расширениями .rom и .lzrom. Это образы сетевых загрузчиков, готовых для прошивки в netboot микросхему на сетевой карте. Кроме уже готовых модулей для прошивки, в исходном Makefile есть возможность сделать из этого объектного кода модули для загрузки с дискеты, из древней DOS системы, из lilo (linux loader) и через загрузчик PXE. Выберем загрузку через lilo, для примера возьмём карту ne-совместимую на шине ISA: ... $ make bin32/ne.lilo Если всё прошло успешно, у нас появился модуль ne.lilo. Документация утверждает, что этот бинарник позволит нам выполнить сетевую загрузку как если бы мы действительно прошили загрузчик в сетевую карту. Не будем, однако, спешить переписывать ближайший lilo.conf, перед походом на клиента надо снарядиться получше. Давайте приготовим загрузчики для всех имеющихся в проекте etherboot чипсетов: ... $ for i in bin32/.img;do n=${i%.img};make $n.lilo;done ... $ cd bin32; rename 's/lilo/li/' .lilo ... $ tar czvf netboot.tgz .li Мы переименовали четырёхбуквенные расширения .lilo в двухбуквенное .li, дабы быть готовыми к встрече с самой примитивной файловой системой, например FAT с её ограничением 8.3 на имена файлов. Документация ещё советует нам иметь под рукой статически слинкованный загрузчик lilo. Нет проблем, были бы исходники. Берём тарболл из Debian'а, разархивируем, читаем Makefile. В строке LDFLAGS= исправляем пустую строку параметров на: LDFLAGS= --static Теперь делаем: ... $ make;strip lilo;./lilo -V -v ... $ mkdir ~/netboot ... $ cp lilo boot-.b chain.b os2_d.b ~/netboot ... $ cp sample/*.bmp ~/netboot Порядок. Мы приготовили статически слинкованую свежую версию системного загрузчика lilo, способного запускать несколько операционных систем, а теперь, с помощью заранее приготовленных модулей netboot.tgz, выполнять также сетевую загрузку. Можно переименовать на всякий случай используемые при загрузке бут-секторы в короткие имена. Нам, собственно, понадобится один, boot-bmp.b, выводящий графическую картинку в формате bmp. Возможность выбирать загружаемую систему из меню появилась в более поздних версиях lilo, как и поддержка произвольно больших дисков. В мини-дистрибутиве tomsrtbt версия lilo более старая, поэтому мы и затеяли эпопею со статически слинкованным lilo. tomsrtbt поддерживает много файловых систем, но для себя использует minix. Отформатируем дискету в эту фс: ... $ mkfs.minix /dev/fd0 ... $ sudo mount /dev/fd0 /mnt/floppy Теперь записываем содержимое ~/netboot на дискету, добавляем netboot.tgz, заранее создаём конфигурационный файл lilo.cfg. Кроме обычной загрузки с жёсткого диска и выводимой картинки добавляем строки для загрузки через сеть: image = /boot/ne.li label = netboot read-only Мы готовы к походу на клиента. Не забудьте размонтировать /dev/fd0 и взять также дискету с tomsrtbt.