Администрирование системы

• Что такое администрирование системы?
• Основы инсталляции UNIX
• Запуск и останов системы
• Управление пользователями
• Управление файловыми системами и дисковым пространством
• Конфигурирование ядра
• Работа в сети
• Учет ресурсов системы
• Производительность системы и ее настройка
• Администрирование устройств
• Администрирование электронной почты
• Администрирование новостей
• Администрирование UUCP
• Администрирование FTP
• Резервное копирование и восстановление системы

Что такое администрирование системы?

• Технические концепции для начинающих системных администраторов
• Разнородность UNIX
• Задачи системного администрирования
• Источники информации
• Наиболее важные инструментальные средства

Администрирование - это планирование, установка и обслуживание вычислительных систем. Если это кажется слишком обобщенным ответом, то только потому, что вопрос "Что такое администрирование системы?" достаточно широкий.

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

ТРЕБУЕТСЯ СПЕЦИАЛИСТ: Администрирование систем SUN и IBM UNIX, управление доступом к Internet Помощь в администрировании базы данных (Oracle). "Администрирование сервера Sun и сети: управление конфигурацией системы, создание пользователей, обеспечение защиты данных, резервное копирование и обеспечение нормальной работы всех приложений. Управление доступом и службами Internet внутренняя/внешняя защита, создание и ведение пользователей, поддержка Web-сервера.

Это типичное объявление о найме системного администратора UNIX с перечнем должностных обязанностей. Из этого описания можно предположить, что системному администратору приходится устанавливать и конфигурировать операционную систему, добавлять новых пользователей, создавать резервные копии системы (систем), обеспечивать защиту системы и ее работу. Помимо этого в его обязанности входит настройка доступа к Internet и поддержка нормальной работы с Internet.

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

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

Компании перекладывают все больше задач не просто на компьютеры, но и на т.н. системы немедленной оплаты, такие как Web-коммерция и системы управления торговлей, которые непосредственно связаны с материальным учетом и финансовыми системами. Компании, возложившие материальный учет на компьютеры лет пять назад, сегодня стремятся автоматизировать получение заказов посредством Web. При этом компании, не автоматизировавшие материальный учет и систему заказов, ради конкурентоспособности добиваются того же самого. Электронная почта сейчас считается не менее важной, чем факс и телефон, поскольку все операции обслуживания клиентов, какие только могут выполняться компьютерами и системами факсимильной связи, уже автоматизированы. Такие компании почти полностью зависят от компьютеров, а системные администраторы должны разбираться в значительно более широком круге вопросов, чем разбивка диска, наращивание памяти и установка Adobe Photoshop.

В этой главе представлены некоторые основные технические и организационные понятия, с которыми должен быть знаком системный администратор. Рассматриваются также ключевые инструментальные средства администратора, которые уже содержатся в большинстве разновидностей UNIX или включены в прилагаемый к книге CD-ROM UNIX Unleashed,

Глава разбита на следующие разделы:

р Технические концепции для начинающих системных администраторов. В этом разделе представлены некоторые важные характеристики UNIX и их отличия от характеристик операционных систем Windows и Macintosh.

р Разнородность UNIX. Этот раздел описывает расхождения между версиями UNIX, а также интерфейсы пользователя, которые порой имеют внутренние противоречия.

р Задачи системного администрирования. В этой части главы представлены основные задачи и обязанности администраторов.

р Источники информации. Сама операционная система и Internet предоставляют администраторам массу разнообразной информации. В разделе приведен перечень некоторых полезных ресурсов

р Инструментальные средства. UNIX предоставляет пользователям и администраторам впечатляющий набор инструментов. В конце главы мы кратко рассмотрим некоторые из них.

СОВЕТ Вне зависимости от опыта и стажа, никто не может держать в голове все опции конфигурации, ключи командной строки, добавочные опции, всяческие хитрости и странности инструментальных средств UNIX Опытные пользователи ценят доступность интерактивной документации UNIX, тап-страниц (manual pages). Перед использованием любой программы, или утилит прочитайте их man-страницы, многие из них содержат полезные примеры Если вы устанавливаете утилиту с CD-ROM, прочитайте сопутствующие инструкции по инсталляции и не забудьте установить заодно и man-страницы этой утилиты Ниже в данной главе будут рассмотрена некоторые усовершенствованные функции системы man-страниц

Технические концепции для начинающих системных администраторов

UNIX фундаментальным образом отличается от Windows и Macintosh. Эта операционная система была изначально предназначена для многих пользователей, работающих одновременно над многими программми. (По крайней мере так было, когда она вышла из стен Bell Labs.) Феномен пользователя, работающего на недорогой рабочей станции в среде Linux или любой другой разновидности UNIX, - это новая тенденция в истории операционных систем. Тот факт, что UNIX спроектирован для работы более чем одного пользователя, отражается в его файловой системе, функциях защиты и модели программирования.

Поддержка сети - это не последующая доработка UNIX, как в случае Windows и Macintosh. Поддержка совместного доступа к файлам, удаленный доступ и выполнение приложений на удаленных машинах локальной рабочей станции не только логичны и естественны для UNIX; эти свойства у старых вepcий UNIX обладают большей мощью и стабильностью, чем у самых последних версий Windows и Windows NT

Поддержка и учет множества пользователей

Среды DOS/Windows и Macintosh в отношении защищенности и настройки являются "машинно - opентированными". Доступ к файлам и процессам (работающим в данное время программам) в той или иной мере управляется компьютером, на котором они размещены. В этом их отличие от систем, где существует понятия идентификатора пользователя и сеанса. Если человек имеет физический доступ к машине с операционной системой Windows или Mac OS, то ему доступны все ее файлы и программы. Для злоумышленника не будет препятствием даже защищенный паролем хранитель экрана. Поскольку файлы и программ принадлежат машине, а не пользователю, достаточно перезапустить систему и компьютер будет готов работе. (Даже приглашение регистрации пользователя при входе в сеанс Windows 95 можно обойти с помощью кнопки Cancel, что даст доступ к интерфейсу пользователя без сетевых ресурсов.)

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

Системы UNIX являются многопользовательскими. Пользователи должны регистрироваться. Каждый имеет собственные области для сохранения файлов, собственный начальный каталог (home directory). Файлы о обладают свойствами, определяющими, кто имеет или не имеет доступа к ним, иначе говоря кодом прав доступа. Все работающие программы связаны с пользователем и, подобно файлам, могут запускаться останавливаться лишь определенными пользователями. Если кто-либо не может зарегистрироваться к. привилегированный пользователь, то не получит доступа к чужим файлам, пока их хозяин не разрешит это одним из прямых или косвенных методов. Только суперпользователь может перезапустить машину (б выключения питания) или остановить процессы другого пользователя. Даже после перезапуска системы в функции защиты сохраняются.

"Сетецентричный" подход UNIX

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

Если конфигурация позволяет, то все, что может выполняться за консолью (клавиатурой и монитором выполнимо и на другой системе посредством сетевого соединения. В дальнейшем такие системы мы будем называть удаленными узлами (remote nodes) или удаленными системами (remote systems). Многие серверные системы, такие как Web-серверы и файловые серверы, поддерживают консоли с крайне ограниченными возможностями (вроде простых текстовых терминалов) и специально разработаны для выполнения возможно большего числа управляющих функций с удаленных узлов.

Для обеспечения этих возможностей служат два механизма - удаленные (или псевдо-) терминалы и удаленные оболочки. Удаленные терминалы эмулируют реальные сеансы, как будто пользователь работает терминалом, соединенным с системой посредством последовательной линии, где сеть - это линия, а приложение (обычно Telnet) - это терминал. (Удаленные терминалы обычно называют Telnet-сеансами, поскольку Telnet - наиболее распространенное приложение такого рода.)

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

Удаленные оболочки (или удаленные входы в систему) ~ это сеансы доступа с удаленной системы ( которой находится пользователь) к локально системе. При этом на удаленной системе запускается оболочка (remote shell), а из нее запускаются команды на локальной системе. Использование удаленной оболочки обеспечивает доступ к дисковым ресурсам как удаленной, так и локальной машины. Работа с удаленными оболочками часто используются администраторами в сценариях, позволяя им выполнять команды сразу на нескольких системах и объединять результаты в одном месте. Примером такого рода задач служит сбор статистических данных об использовании дискового пространства или автоматизация создания резервных копий.

Различия между удаленной оболочкой и сеансом Telnet очень существенны. Сеансы Telnet используют эмуляцию терминала и работают как отдельные приложения. Поэтому результаты не могут предоставляться другим приложениям без применения механизма вырезания и вставки. Удаленные оболочки могут распространять результаты посредством локальных команд.

Таким образом, можно создать резервную копию каталога рабочей станции на магнитной ленте или другом устройстве с помощью простой команды оболочки:

tar cvfb - tgt_dir | rsh -n bilbo dd of=/dev/rmt/0

Команда tar создает архив каталога tgt_dir и отправляет его на стандартное устройство вывода. Этот поток данных перенаправляется командой rsh. Эта команда выполняет соединение с хостом bilbo, выполняет dd и передает ему вывод tar. Команда dd может сохранить архив на магнитной ленте в dev/nnt/0. (Это может показаться сложным. В конце главы все станет яснее.) Итак, две программы на двух различных машинах связаны в одну безо всяких специальных требований к конфигурации или дополнительных программ.

Если удаленные сеансы и оболочки обладают такой мощью, то зачем используют Telnet? Одна из причин в том, что Telnet намного более устойчив на линиях связи с низким быстродействием, например, при работе в Internet и вообще при использовании асинхронных соединений. Другая причина - защищенность. Мы рассмотрим позже некоторые вопросы риска, связанного с удаленными оболочками.

Другой пример мощи сетевых функций UNIX - Х Window. Х-среда предоставляет графический интерфейс пользователя, во многом подобный Windows или Macintosh. Ключевое отличие Х-среды ~ в ее разбивке на клиента (приложение) и сервер (отображение). Сервер - это процесс, который управляет клавиатурой, мышью, экраном и соединяется с приложениями, используя сокеты (сетевые соединения). Поскольку сетевое соединение - это метод обмена данными между двумя программами, приложение может работать не на той рабочей станции, где находится управляющая система отображения. (Если приложения работают на той же рабочей станции, где установлен сервер, сетевое соединение чаще всего замещается более скоростными методами передачи данных. Эти усовершенствования являются частными, закрытыми расширениями, и их реализация значительно отличается у разных производителей ПО.)

Функции удаленного выполнения среды Х Window ~ очень важное преимущество, особенно когда речь идет о массивной базе данных. Web- или файловых серверах, которые обычно устанавливаются в центрах данных или производственных помещениях, но имеют графическое управление и приложения конфигурации. Другая возможность состоит в установке менее дорогих рабочих станций меньшей производительности в качестве настольных систем. При этом сохраняется способность выполнять ресурсоемкие приложения на более мощных компьютерах общего пользования.

Обмен файлами - еще одно расширение, ставшее естественной и неотъемлемой частью вычислительных систем UNIX. Все основные разновидности UNIX поддерживают NFS (Network File System - сетевая файловая система). При этом обеспечивается обмен файлами между системами с разными версиями UNIX.

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

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

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

Клиенты определяют, где именно в локальном дереве каталогов будут смонтированы удаленные файловые системы. Например, локальная система может смонтировать удаленный каталог /export/applications в локальный каталог /mnt/apps.

Сетевые функции UNIX - обмен файлами и информацией

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

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

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

Программа automount конфигурируется с помощью таблиц (maps ~ этот модный термин используется по отношению к файлам конфигурации), где каждая запись в таблице определяет каталог верхнего уровня. Так, если система automount создает пять каталогов, то главная таблица (master map), содержащаяся в файле /etc/auto/_master, должна выглядеть подобным образом:

/share auto_share

/home auto_home

/gnu auto_gnu

/apps auto_apps

/opt auto_opt

Этот файл предоставляет программе automount имена каталогов, которые будут созданы, и файлов, описывающих содержание этих каталогов.

Рассмотрим организацию, в которой принято все каталоги пользователей помещать в каталоге /home. (Таким образом файлы пользователя dan находятся в каталоге /home/dan.) Первые тридцать исходных каталогов размещались на файловом сервере gandalf в каталоге /export/home.

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

Программа automount упрощает такое распределение, позволяя создавать виртуальный каталог /home на каждой рабочей станции, где запущен демон automount. Фрагмент таблицы (файла конфигурации) для начальных каталогов пользователей /etc/auto_home, ссылка на которую содержится в файле /etc/auto_master, будет выглядеть следующим образом:

eric gandalf:/export/home/eric

dan gandalf:/export/home/dan

mike balrog:/export/home/michael

В этой таблице eric, dan и mike называются ключами (keys) каталогов. Каталоги называются значениями (values). Когда программа обращается впервые к каталогу /home/eric, система распознает ключ eric и монтирует каталог /export/home/eric сервера gandalf к каталогу /home/eric на сервере balrog. Поскольку система automount выполняет простую подстановку ключ/значение, каталоги пользователей Erie и Dan могут находиться на сервере gandalf, в то время как каталог пользователя Mike - на сервере balrog. Кроме того отметим, что имена каталогов на сервере и виртуальных каталогов системы automount не обязаны совпадать, как в случае balrog. После определенного неактивного периода система automount выполняет отсоединение каталога.

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

Компания Sun Microsystems определила autofs как новый тип файловой системы в среде Solaris 2.х и создала многопоточную систему automount. Это обеспечивает исключительную производительность смонтированной с ее помощью файловой системы в среде Solaris, поскольку ядро "знает" о существовании этой системы и может устранять узкие места программы automount с помощью потоков.

HP-UX Hewlett Packard и AIX IBM применяют свою версию программы automount. Она совместима с различными разновидностями UNIX, так как использует NFS.

Более новые версии automount (и amd) позволяют также назначать для каталога более одного сервера файлов, чтобы обеспечить резервную копию на случай, когда сервер недоступен или перегружен. Немного планирования, и система упростит работу в распределенной сети и даже немного повысит ее надежность.

Это не отменяет необходимости отслеживания корректности map-файлов и установки их на все рабочие станции. Для выполнения этой задачи можно применять ftp и даже nfs, но для большой сети такой способ может оказаться слишком утомительным. Существует два очень элегантных решения, которые служат примерами того, как опытные системные администраторы выходят из подобных положений.

Первый способ предусматривает использование утилиты rdist. Она служит для распределения идентичных копий программ между удаленными хостами. Инструмент может принимать имена файлов с командной строки или использовать файл конфигурации (обычно называемый distfile), который содержит перечень с указанием, какие файлы на какие хосты копировать.

Для распределения набора mар-файлов программы automount можно использовать distfile, как в следующем простом примере:

HOSTS = (bilbo frodo thorin snowball)

FILES = /etc/auto_master /etc/auto_home /etc/auto_apps

${FILES}->${HOSTS)

install;

distfile - очень мощный механизм. В данном примере используется возможность создавать переменные. Можно легко добавлять обновляемые хосты и пересылаемые файлы, занося их в списки. После определения переменных $FILES и $HOSTS следует указание, что списки файлов должны соответствовать перечисленным хостам. Однострочная команда install является одной из многих команд rdist. Она указывает, что утилита должна обеспечить соответствие файлов локальным копиям. Более полная информация о многочисленных директивах и опциях distfile содержится в man-странице.

Для применения утилиты можно добавить distfile в каталог /etc хоста, где хранится основной комплект файлов конфигурации automoimter. При любом внесении изменений можно выполнить команду:

rdist -f /etc/auto_distfile

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

Недостаток rdist в том, что к нему приложимы те же требования защищенности, что и для любой другой команды удаленной оболочки. Пользователь, выполняющий команду rdist, должен иметь возможность соединиться с удаленным хостом и выполнять команды без пароля. (Это раскрывается в следующем подразделе "Вопросы защищенности сети".)

Если rdist невозможно использовать из-за проблем с защитой, как распределять файлы конфигурации?

Альтернативой может служить сетевая служба информации (NIS - Network Information Service) компании Sun Microsystems, ранее имевшая название "YP", или yellow pages - желтые страницы. NIS предоставляет общую информацию о конфигурации, такую как IP-адреса, номера портов для различных сервисов и файлы конфигурации для выполнения программой automount соединений между хостами и сервером (или набором серверов).

Сервер(ы) NIS содержат мастер-копии файлов, к которым необходимо обеспечить доступ. Вместо копирования файлов в системы клиентов эти файлы по мере необходимости распространяются по сети. Таким образом, клиенты получают информацию с сервера вместо чтения локальных файлов.

NIS применяется для файлов конфигурации программ hosts, services, automount и некоторых других. Конфигурирование сети для NIS выходит за рамки данной главы и неодинаково для каждой разновидности UNIX, поскольку многие производители вносят свои "усовершенствования" в систему Sun. Внимательно изучайте документацию по используемой платформе и выявляйте все изменения, сделанные производителями. Рассмотрим некоторые преимущества и недостатки NIS.

Главное преимущество NIS состоит в ее удобстве. Служба позволяет вносить изменения в файл конфигурации и почти мгновенно делать их доступными пользователям, что обычно реализуется выполнением единственной команды после редактирования файла. Несомненное удобство заключается в возможности хранить всю подобную информацию в одном месте (или в нескольких, если используются вторичные серверы), особенно когда для устойчивой работы сети важна синхронизация регистрационных имен пользователей, IP-адресов и портов.

Существуют и серьезные недостатки.

Рабочая станция, использующая NIS для разрешения IP-адресов, не может использовать DNS в тех же целях без некоторых существенных доработок. NIS+ компании Sun решает эту проблему, но эта служба пока не поддерживается другими версиями UNIX, она считается экзотической и очень сложной в использовании системой (причины этого здесь не рассматриваются).

Если файл passwd распространяется посредством NIS, то зашифрованное поле пароля может быть прочтено каждым, кто присоединяется к NIS. Это может широко использоваться хакерами для преодоления защиты, так как взлом пароля эффективнее грубой лобовой атаки с помощью общедоступных программ.

NIS не располагает механизмом для отслеживания пользователей, соединяющихся с сервером и читающих файлы конфигурации. Это создает дополнительные проблемы защиты и служит одной из причин, по которой в Internet не содержится ни одного NIS-сервера. (NIS+ решает проблему защиты посредством сложной системы идентификации.)

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

Итак, система NIS создает свои проблемы и требует интенсивного изучения, прежде чем ее можно будет применять в качестве инструмента администрирования.

Проблемы защищенности сети

Мы уже рассматривали некоторые вопросы защищенности, связанные с UNIX и работой в сети. Эти моменты очень важны для администраторов и часто оказывают существенное влияние на конфигурацию сети.

Как уже говорилось, Telnet используется гораздо чаще удаленных оболочек. Удаленные оболочки допускают неинтерактивные входы в систему, как было ранее показано в примерах, где используются команды tar, dd и rdist. Эта очень удобная функция может оказаться и довольно опасной при отсутствии должного администрирования.

Функция автоматического входа в систему реализуется с помощью пары текстовых файлов. Один из них, /etc/hosts.equiv, контролирует пользователей на системном уровне. Другой, .rhosts, управляет доступом для отдельных пользователей. Каждый файл содержит перечень систем по именам, которые пользователь может вводить без указания пароля, если идентификатор пользователя на целевом хосте существует. Все основные разновидности UNIX обрабатывают эти файлы одинаково.

Файл hosts.equiv обеспечивает такой доступ ко всей рабочей станции, кроме привилегированного бюджета. Очевидно, применять этот файл надо очень осторожно, а то и не пользоваться им вовсе. Файл .rhosts предоставляет доступ для отдельных пользователей и размещен в собственном каталоге пользователя. Вместо hosts.equiv можно обращаться к нему. Если корневой бюджет какого-либо из перечисленных хостов содержит один из таких файлов, то из него возможен вход в рабочую станцию безо всякой идентификации, поскольку .rhosts практически заменяет файл hosts.equiv.

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

Возможны следующие меры предосторожности:

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

• избегайте применения rlogin там, где можно использовать telnet;

• если приходится применять rlogin, то старайтесь не использовать rhosts или hosts.equiv;

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

• удаленные входы в систему не должны применяться в любых системах, имеющих прямое подключение к Internet. (Заметьте, что собственная система, соединяющаяся с Internet посредством ISP, не считается имеющей по-настоящему прямое подключение.)

Первое правило требует дополнительных разъяснений. Привилегированный бюджет root в повседневных операциях должен использоваться как можно реже. Многие начинающие пользователи UNIX считают необходимым применять привилегированный доступ для любых сколько-нибудь значимых операций, хотя это далеко не так. Нет причин это делать для выполнения, к примеру, резервного копирования, просмотра log-файлов или выполнение сетевого сервиса. (Если службы не используют порты с номерами менее 1024. Исторически сложилось, что UNIX для управления такими портами допускает только привилегированный режим выполнения процессов.) Чем чаще используется привилегированный доступ, тем больше вероятность неожиданных, а возможно и разрушительных результатов.

Помимо удаленных входов в систему, UNIX предлагает множество сетевых сервисов. Обмен файлами, электронная почта, Х Window и информационные службы, такие как DNS и NIS, составляют только часть гибких и мощных средств, предоставляемых сетью. Однако применение многих из них связано с риском, порой неоправданным, а то и неприемлемым.

Будет правильным определить самые необходимые из этих служб и задействовать только их. Многие сетевые службы управляются процессом inetd. Этот демон ожидает запросы на сетевые службы и в ответ на них выполняет нужные программы.

Например, демон inetd управляет сервисом ftp. После приема запроса на этот сервис (номер служебного порта - 21) inetd согласуется с конфигурационной информацией и запускает ftpd. Его потоки ввода и вывода присоединяются к источнику запроса.

Сетевые сервисы идентифицируются по номерам портов. Распространенные службы, такие как ftp и telnet, имеют широко известные номера портов, которые требуется знать всем потенциальным клиентам. Процесс inetd связывает и прослушивает эти порты на основе данных о конфигурации, содержащихся в файле inetd.conf.

Типичный файл конфигурации выглядит следующим образом:

# Файл конфигурации для inetd(lM). См. inetd.conf (4).

# Для изменения конфигурации выполняющегося процесса inetd

# редактируйте этот файла, затем отправьте процессу inetd сигнал

# SIGHUP.

#

# Синтаксис служб Internet, использующих механизм сокетов:

#<service_name> <socket_type> <proto> <flags> <user>

#<server_pathname> <args>

f tp stream tcp nowait root /usr/sbin/in.ftpd in.ftpd

telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd

#

# Tnamed обслуживает устаревший протокол IEN-116

#

сервера имен.

name dgram udp wait root /usr/sbin/in.thamed in.thamed

#

#Shell, login, exec, comsat и talk - протоколы BSD.

#

shell stream tcp nowait root /usr/sbin/in.rshd in.rshd

login stream tcp nowait root /usr/sbin/in.rlogind in.rlogind

exec stream tcp nowait root /usr/sbin/in.rexecd in.rexecd

comsat dgram udp wait root /usr/sbin/in.comsat in.comsat

talk dgram udp wait root /usr/sbin/in.talkd in.talkd

Как сказано в комментарии, информация для inetd содержится в двух различных man-страницах.

Каждая запись о конфигурации указывает имя порта сервиса, которое расшифровывается с помощью файла /etc/services (или NIS-карты), другую информацию о соединении, имя пользователя, для которого должна выполняться программа и, наконец, имя самой программы. С точки зрения защищенности два наиболее важных аспекта файла конфигурации: он определяет пользователя-владельца выполняющихся служб, а также то, какие службы выполняются вообще. (Подробности сетевых соединений рассматриваются в главе 20.)

Каждое имя службы соответствует некоторому числу - номеру порта. Порты с номерами менее 1024, которые используют службы ftp, telnet и все входы в систему, доступны только программам с правами root, поэтому процесс inetd сам по себе должен выполняться с правами привилегированного пользователя, но это дает возможность выполнять сервисные программы с правами других пользователей. Зачем это нужно? Если защита выполняемой программы с правами root каким-либо образом устранена, взломщик получает привилегии root. Например, если сетевая служба, выполняемая с правами root, имеет "черный вход", позволяющий пользователям модифицировать файлы, взломщик теоретически может использовать программу для чтения, копирования или модификации любого файла хоста, который подвергся несанкционированному доступу.

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

Большинство разновидностей UNIX поставляются производителями в конфигурациях, включающих ненужные, а в некоторых случаях и нежелательные, службы, такие как rexecd, которые используются для удаленного выполнения программ, зачастую безо всякой идентификации. Как уже говорилось, служба по умолчанию настроена производителем с правами доступа root. Многие администраторы конфигурируют ключевые системы, исключая использование всех сетевых служб, кроме той, которую они должны по своему назначению обеспечивать, например Internet Web- или ftp-серверы.

Качественное сетевое программное обеспечение учитывает рассмотренные проблемы. Например, Web-сервер Арасhе обычно сконфигурирован на прослушивание порта http, имеющего номер 80, а следовательно, может быть запущен только с правами root. Вместо обработки запросов клиентов в качестве пользователя root, что очень опасно с точки зрения защищенности, Арасhе принимает сетевые соединения как root, но обрабатывает реальные запросы только как пользователь nobody, который практически не имеет никаких прав, кроме чтения Web-страниц. Это выполняется путем выполнения программой нескольких копий самой себя для пользователя nobody и использования связи между процессами для передачи запросов пользователя "усеченным в правах" процессам.

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

Более подробные сведения и инструкции по обеспечению надежной защиты системы содержатся в главе 20.

Разнородность UNIX

UNIX часто критикуют за отсутствие согласованности между версиями, системами разных производителей и даже приложениями. UNIX не является продуктом какой-либо одной корпорации или группы, что оказывает значительное влияние на его особенности. Пожалуй, Linux является высшим выражением коллективного характера UNIX. Когда Linus Torvalds создал ядро Linux и заявил о нем через Internet, люди всего мира начали принимать участие в развитии того, что получило название операционной системы Linux. Хоть и существует центральная группа из нескольких разработчиков, играющих главную роль в разработке системы, они не работают на одну компанию и даже не живут в одной стране. Очевидно, что Linux отражает несколько различных взглядов на то, как компьютеры должны работать. То же можно сказать и о UNIX.

Инструменты администрирования

Все производители UNIX предлагают собственные GUI- инструменты администрирования, что обычно полезно, если вам не требуется выполнять операции, не предусмотренные производителем. Эти инструменты имеют много отличий в работе и способе реализации.

Операционная система UNIX компании IBM - AIX - комплектуется сложным инструментальным средством SMIT. Администраторы могут использовать SMIT для конфигурирования системы, добавления и удаления пользователей и модернизации ПО. Общепризнано, что SMIT является лучшей и наиболее зрелой из систем администрирования, так как она может настраиваться и работать как в среде Х Window, так и в терминальном сеансе. Она также позволяет просматривать эквивалент командной строки для каждой задачи перед ее выполнением. К недостаткам (по крайней мере, так считают некоторые системные администраторы) можно отнести то, что применение SMIT почти обязательно для кое-каких основных задач администрирования.

Система HP/UX компании Hewlett-Packard располагает подобным инструментальным средством под названием SAM, которое обеспечивает большинство функций SMIT, но менее сложно и не такое мощное. Для администрирования системы его применение необязательно.

Система Solaris компании Sun не комплектуется инструментом, аналогичным SMIT или SAM. Но отдельные инструменты Sun для модификации и установки ПО, администрирования NIS+, довольно функциональны и просты в освоении. К сожалению, инструмент системы Solaris для администрирования пользователей, принтеров и NIS/NIS+ требует среды Х Window. Но для администрирования системы в целом использовать Х Window не обязательно.

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

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

UNIX исторически подразделялся на две основных разновидности - UNIX System V компании АТ&' и BSD UNIX Калифорнийского университета. Большинство главных производителей сейчас склоняются системе System V, но сохраняется и множество расширений BSD.

Независимо от деятельности производителей (и их заявлений), разнородная природа UNIX являете неоспоримым фактом и, вероятно, одной из сильнейших сторон системы. Эта особенность дала нам некоторые из важнейших инструментов Internet, такие как Perl, электронная почта. Web и служба новостей Usenet. Она также предоставляет большое разнообразие возможностей администрирования систем. Мало какие задачи UNIX решаются только одним способом.

Графические интерфейсы

Macintosh и Microsoft Windows сильны стандартным интерфейсом пользователя. Как правило, набор приложений, работающий в любой из этих систем, характеризуется не только унифицированным видом элементов управления, но и одинаковыми клавишами быстрого доступа, меню и операциями с мышью.X Window не обладает таким преимуществом.

Х Window - это набор приложений, а не составная часть операционной системы. Такая структура предполагает значительные отличия от оконных систем Macintosh или Microsoft Windows. Как следствие, взаимодействие между Х-приложениями и операционной системой не такое тесное, как на этих платформа

Одной из отличительных особенностей настольной системы Х является window manager (диспетчер окон) Это приложение, которое предоставляет каждому окну рамку, позволяет перемещать окна и накладывать их друг на друга. Но это просто приложение, а не часть системы Х Window. Это дает пользователям возможность выбирать диспетчер (manager) по своему усмотрению, точно так же, как и оболочку. Кроме того, разные пользователи одной системы могут использовать различные диспетчеры окон. Различия между отдельными диспетчерами окон значительны, они оказывают большое влияние на вид рабочего стола, операции с мышью, а иногда на вид приложений, которые могут выполняться.

Диспетчер окон OpenLook, распространяемый Sun и включаемый во многие выпуски Linux, имеет много индивидуальных расширений, легок и быстр в работе. По виду он не очень похож на Macintosh или Microsoft Windows. (Например, интенсивно используется правая кнопка мыши, что лишь недавно стало применяться в Microsoft Windows и полностью отсутствует в Macintosh.) Пакет OpenWindows компании Sun комплектуется диспетчером OpenLook и набором инструментов для чтения почты, управления файлами и некоторых других общих задач.

В последние несколько лет возросла популярность системы Motif, которая имеет много схожего с Microsoft Windows. Это связано с тем, что большинство главных производителей ПО согласились стандартизировать Common Desktop Environment (CDE - базовая среда настольных систем), которая в значительной мере основана на Motif. CDE обладает дополнительными функциями, такими как графический диспетчер файлов (file manager), панель инструментов и поддержка виртуальных экранов. CDE также комплектуется набором пользовательских приложений.

Диспетчеры окон также комплектуются библиотеками программ для создания меню и других задач программирования. В результате можно создать приложение, которое плохо работает под управлением некоторых диспетчеров окон или требует наличия библиотек, которыми данная версия UNIX не располагает. Это обычная беда Motif-приложений на Linux, поскольку библиотеки не распространяются бесплатно. По этой причине многие приложения предоставляются в не-Motif-версии или со статически связанными библиотеками, то есть встроенными в приложение. (Это обычно считается нежелательным, так как увеличивает размер приложения, требует больше памяти и дискового пространства.)

Windows З.х имеет систему файлов win.ini и system.ini; Windows 95 и Windows NT располагают системным реестром (system registry). И то и другое служит центральным хранилищем конфигурационной информации о приложениях. Х Window обладает собственным стандартным интерфейсом для конфигурационной информации, называемым Х-ресурсы (X resources). Х-ресурсы во многом обеспечивают большую гибкость, чем механизмы Windows.

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

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

Интерфейсы командной строки

Именно в командной строке проявляется длинная история UNIX и различия версий. Иногда кажется: каждая утилита написана своим программистом и для своих целей, что может быть недалеко от истины.

Что касается интерфейсов, между инструментами командной строки обнаруживается не слишком много соответствий. Для опций командной строки вызова списка каталогов Is применяется почти весь алфавит. При этом команда find для опций использует сокращения вместо букв, что создает видимость ее принадлежности к другому языку. Большинство команд требуют для разграничения аргументов вводить знак "-", остальные - нет. Некоторые команды используют слегка отличающиеся диалекты стандартных выражений (шаблоны).

Часто одна и та же команда имеет две версии: одна из System V, а другая из BSD. В качестве примера я обычно привожу команду mail. Это простой, основанный на тексте и почти лишенный дополнительных функций инструмент чтения и отправки почты. Но существует две версии этой команды, что может быть неудобно при создании наиболее общих программ чтения почты.

Обе команды mail могут использоваться для отправки электронной почты с командной строки и неоценимы для неинтерактивных сценариев, так как могут предупредить администраторов о проблемах по электронной почте. Версия BSD позволяет указывать в командной строке предмет послания подобно следующему:

mail -s "Backup Results" (hyperlink mailto:eric@niftydomain.com} < backup.txt

Здесь -s - это опция для определения предмета сообщения. Версия команды mail System V (стандартная для Solaris) эту опцию игнорирует без сообщений. Это мне доставляет немало неприятностей, поскольку по крайней мере в трех случаях в почтовом отправлении отсутствует тема сообщения.

Другим ярким примером различия двух главных версий может служить команда ps. Обе команды предоставляют одну и ту же информацию о работающих программах. Аргументы же командной строки обеих версий не имеет ничего общего.

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

р UNIX

существует уже более 25 лет. Велики ли шансы, что вашу проблему еще никто не решил? Прежде чем тратить массу времени и усилий на решение проблемы, уделите внимание страницам руководства, посвященным вашей задаче и инструментам, с которыми вы работаете.

р Многие инструменты UNIX также существуют уже 25 лет. Если ПО так долго применяется, значит оно чего-то стоит.

р Экспериментируйте с инструментами и пытайтесь решить задачу всякий раз другим методом. Иногда удается найти новые приемы, которые в будущем сэкономят многие часы.

Задачи системного администрирования

Системное администрирование можно обобщенно разделить на две широких категории: поддержка пользователей и поддержка системы.

Поддержка пользователей

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

Создание бюджетов пользователей

Наиболее фундаментальная услуга, предоставляемая администратором пользователю, это создание его бюджета. Бюджета UNIX содержатся в файле /etc/passwd. Реальный зашифрованный пароль содержится либо в файле passwd, либо в файле /etc/shadow, если система реализует теневые (shadow) пароли.

Когда пользователь создан, бюджет должен быть включен в файл passwd. (Подробности о бюджетах пользователя изложены в главе 17.) Это очень простая задача, выполняемая за минуту с помощью любого текстового редактора. Но если ваша версия UNIX располагает инструментом для добавления пользователей, возможно, имеет смысл пользоваться им.

Обычно эти инструменты могут:

• Добавлять пользователей к файлу passwd (и файлу shadow, если он используется). Поскольку все пользователи должны иметь уникальный идентификатор, очень удобно при администрировании большого числа пользователей поручить присвоение номеров компьютеру.

• Создавать начальные каталоги для пользователей с необходимыми правами доступа к файлам.

• Копировать исходные скелетные файлы (skeleton files) в бюджет, что дает пользователю базовую рабочую среду. Эти файлы могут создаваться администратором, так что пути приложений общего применения и необходимые переменные среды могут передаваться пользователям по мере их создания.

• Регистрировать новые бюджета в сетевых системах, подобных NIS и NFS, если необходим доступ к собственному каталогу с других хостов.

Эти инструменты могут предотвращать распространенные ошибки и немного экономить время. Большинство разновидностей UNIX располагают также инструментом командной строки useradd, выполняющим все или большинство из перечисленных функций. Если применение инструмента с графическим интерфейсом неудобно или невозможно, можно встроить useradd в оболочку или сценарий Perl.

Предоставление помощи

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

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

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

Старайтесь внедрять формальный метод выдачи запросов на изменения в системе и получения справки. Если пользователи привыкнут получать немедленный ответ на вопросы, то будут раздражены, когда вы не сможете оставить свои дела, чтобы помочь им. Попытайтесь установить электронную почту или основанную на Web справочную систему. Заставлять пользователей применять эти системы, возможно, несколько бюрократично, но это поможет разгрузить рабочий день от бесконечных контактов и позволит регистрировать запросы. (Вам не случалось забывать отреагировать на запрос из-за занятости? Создайте себе автоматический список задач.)

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

Если вы располагаете доступом к Internet, я уверен, что пользователи часами не могут оторваться от броузеров. Пользуйтесь этим. Может оказаться, что большая часть требуемой пользователям информации уже существует, так что есть возможность связывать их с источниками данных, а не генерировать их самому. (Некоторые из источников информации мы рассмотрим в разделе "Ресурсы администрирования".)

Поддержка систем

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

Добавление узлов

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

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

Когда системы разрабатываются и оцениваются, перед администратором могут стать следующие вопросы:

• Пользователи будут иметь доступ ко всем или только к некоторым системам? Нужен ли пользователям доступ к более чем одной системе? Существуют ли системы, к которым пользователи никогда не должны обращаться?

• К какой файловой системе сети потребуется доступ каждой рабочей станции? Достаточно ли будет использования утилиты automount?

• Какие сетевые службы (вроде telnet, удаленных входов в систему, систем обмена файлами и электронной почты) требуется предоставить рабочим станциям? Будет ли оправдано применение каждой службы?

• К каким сетям рабочие станции должны иметь доступ? Существуют ли сети, которые должны быть недоступны для других?

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

Резервные копии

Файлы могут портиться, теряться, случайно переписываться или удаляться. Единственной защитой от этих проблем служит резервное копирование, так как UNIX не располагает командой undelete.

UNIX

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

Ранее в этой главе мы рассматривали пример копирования каталога, с применением команд tar и dd, на удаленный накопитель на магнитной ленте. В этом примере dd использовалась просто как способ копирования потока данных на ленту, a tar - как команда выполнить копирование.

Утилита tar (tape archive - архив на ленте) часто используется для создания резервных копий.

tar -с -f /dev/rmt/0 /home/eric

Приведенная выше команда создает резервную копию содержимого каталога /home/eric на первое устройство записи на магнитную ленту, установленное в систему Solaris. Команда tar автоматически обходит весь каталог, чтобы архивировались все файлы каталога /home/eric и его подкаталогов.

Имя устройства для накопителей на магнитной ленте в каждой разновидности UNIX свое. В производных от BSD системах эти устройства обозначаются как /dev/rsti, где 0 - первое устройство, 1 - второе и т.д. (То же касается Linux, HP-UX и SunOS 4.1-х.) Производные System V обычно подобным образом используют имя /dev/nntl. (Эту же модель использует AIX.) Но в системе Solaris 2.x, основанной на System V, к пути добавляется каталог: /dev/nnt/1.

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

cd /home/eric tar -cf /dev/rmt/0 ,

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

cpio - еще один стандартный инструмент UNIX для резервного копирования. Его интерфейс несколько сложнее, чем у tar, но обладает некоторыми преимуществами.

Инструмент cpio обычно используется с командой Is или find.

find . -print | cpio -о > /dev/rstO

Команда find выводит полный путь всех файлов в текущем каталоге на стандартное устройство вывода. cpio принимает эти имена файлов и архивирует их для стандартного вывода. Результат переадресовывается накопителю на магнитной ленте, где создается архив. Эта команда служит прекрасным примером комбинирования команд UNIX для создания нового инструментального средства.

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

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

• Создавать резервные копии специальных файлов, вроде обозначений устройств, например /dev/rstO.

• Размещать данные на ленте эффективнее, чем это делают инструменты tar или dd.

• Пропускать испорченные области на ленте или дискетах при восстановлении. В таких случаях команда tar просто перестает работать. Инструмент cpio, по крайней мере, дает возможность восстановить часть поврежденного архива.

• Создавать резервные копии на дискетах, включая распределение одного архива на несколько дискет. Инструмент tar может только помещать один архив на один диск.

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

Приведенный пример также демонстрирует переадресацию стандартного вывода на указанное устройство и предоставление возможности драйверу этого устройства разместить на нем данные.

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

Существуют и другие инструменты резервного копирования. Среди них наиболее примечателен dump или ufsdump, как он назван в Solaris 2.x. Эти инструменты ориентированы на резервное копирование целых областей диска, а не файлов. Они рассматриваются в главе 28.

Для более крупных узлов с более жесткими требованиями к резервному копированию может быть необходим коммерческий пакет. Пакет NetWorker компании Legato предоставляет усовершенствованную систему резервного копирования и восстановления, которая поддерживает автоматическое резервное копирование без вмешательства оператора систем UNIX, Windows и рабочих станций NT, Macintosh, PC и даже серверов баз данных. Процесс планирования создания копий, выбора файлов для сохранения и подтверждение целостности архивов выполняется автоматически. Графический интерфейс значительно облегчает восстановление файлов и файловых систем.

Sun дополняет программой NetWorker свою серверную систему Solaris 2.x.

Помимо выбора инструмента резервного копирования важно разработать стратегию копирования.

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

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

• Имеют ли пользователи важные файлы, которые ежедневно модифицируются?

• Сгруппированы ли пользователи в один-два каталога одной системы или нужно сохранять системы по всей сети?

• Если нужно восстановить только один файл, требуется ли это выполнять быстро? Позволяет ли используемая система копирования находить один файл?

• Какова частота и продолжительность периодов, когда пользователи не работают в системе? (Лучше архивировать каталоги, пока они не используются.)

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

Загрузка и производительность системы

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

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

Контролю подлежат использование дискового пространства, ресурсов центрального процессора, области подкачки и памяти. В следующих нескольких главах части III рассматриваются служащие для извлечения этой информации инструменты, такие как du и df (информация о диске), top и vmstat (остальные данные).

Ресурсы администрирования

Системному администратору необходима любая доступная информация и, что не любят признавать производители UNIX, сопроводительная документация, которая иногда отсутствует. К счастью, этим источники информации далеко не ограничиваются.

Man-страницы

Страницы руководства (manual pages, или, как их часто называют, man-страницы) содержат документацию и инструкции почти к каждой команде UNIX, вызовам функций С и файлам данных системы.

Команда man выполняет поиск документации в соответствии с указанной командой или названием раздела. Так, команда

man ls

предоставляет документацию по команде ls, которая находится в первом разделе.

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

Компоновка раздела имеет вид, подобный следующему:

• User commands (команды пользователя), такие как ls, tar, cpio.

• System calls (системные вызовы) - функции С-программирования, которые считаются системными вызовами, например открытие и закрытие файлов.

• С library functions (функции С-библиотеки) - функции С-программирования, которые не считаются системными вызовами, например печать текста.

• File formats (форматы файлов) - описания внутренней структуры файлов, таких как hosts.equiv и inetd.conf.

• Headers, Tables, and Macros (заголовки, таблицы и макросы) - разнообразная документация, такая как таблицы символов и файлы заголовков, что мы еще не рассматривали.

• Games and Demos - игры и демонстрационные программы. (Даже DOOM для UNIX имеет man-страницы!)

Это обобщенное содержание. Системы BSD и System V поначалу имели несколько отличные структуры разделов, а производители ПО склонны добавлять собственные разделы и вносить свои "усовершенствования". (Может ли быть иначе?)

Для просмотра информации по каждому разделу можно вызвать man-страницу введения. Чтобы просмотреть информацию о первом разделе, нужно выполнить следующую команду:

man -s 1 intro

Опция -s выбирает раздел страниц руководства для поиска с помощью команды man версии System V. В версиях BSD номер раздела принимается в качестве первого аргумента без ключа, а версия Linux выбирает раздел по значению переменной среды или с помощью опции -s.

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

Страницы руководства могут индексироваться и предварительно форматироваться с помощью инструмента catman. Предварительное форматирование обеспечивает более быстрый вывод страниц, что не так важно, как индексация, позволяющая использовать более мощные инструменты извлечения информации, такие как whatis и apropos.

apropos отображает номер раздела, имя и краткое описание любой страницы, которая содержит указанное ключевое слово, whatis выводит man-страницу и номер раздела.

Например, применим команду apropos для ключевого слова nfs:

apropos nfs

Часть отображаемой в ответ информации имеет следующий вид:

automount (8) Automatically mount NFS file systems

exportfs (8) Exports and unexports directories to NFS clients exports,

xtab (5) Directories to export to NFS clients nfs,

NFS (4P) Network file system nfsd,

biod (8) NFS daemons

(Вывод отредактирован, так как реальный запрос генерирует 12 ответов.) Теперь применим команду whatis:

whatis nfs

nfs, NFS (4P) Network file system

Выводится только название man-страницы по nfs и номер раздела для нее. Кроме man-страниц, Sun сопровождает Solaris системой Answerbook. Это основанная на графическом интерфейсе интерактивная справочная система, которая поддерживает полнофункциональный поиск текста и почти устраняет потребность в бумажной документации.

IBM поставляет со своими системами Infoviewer - тоже основанную на графическом интерфейсе интерактивную справочную систему. Стандартная инсталляционная программа AIX устанавливает Infoviewer вместо man-страниц, что неудобно для пользователей, не использующих Х Window.

Информационные ресурсы Internet

Internet

также предоставляет администраторам море информации.

1. Usenet. Будучи не такой полезной службой, как раньше (из-за перенасыщенности, приближающей сигнал к уровню шумов), Usenet поддерживает дискуссионные группы по всем разновидностям UNIX и всем их аспектам. В качестве примеров можно привести соmp.sys.sun.admin, соmp.os.linux.setup и comp.unix.admin. Из-за большого потока информации Usenet некоторые узлы не поддерживают эту службу. Если вам не удастся получить к ней доступ, попробуйте воспользоваться службой поиска, такой как http://www.dejanews.com, для получения нужной информации. Иногда поиск статей по интересующей теме вместо просмотра разделов быстрее приводит к желаемому результату. Deja News предоставляет возможности поиска и просмотра.

2. FAQ Lists (Frequently Asked Question Lists - список часто задаваемых вопросов) предоставляет большое разнообразие информации Большинство групп Usenet имеют собственные списки FAQ. Они периодически пересылаются в группы и на ftp-сервер rtfm.mit.edu. Многие списки FAQ также предоставляются в формате HTML.

3. Web-документация в формате HTML очень часто предоставляется производителями UNIX, а также специалистами и группами, связанными с Linux. Многие пользователи и разработчики также передают много полезной информации. Для пополнения знаний пользуйтесь службами поиска.

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

Наиболее важные инструментальные средства

Толковый администратор в полной мере использует инструменты системы UNIX. Для непосвященных UNIX кажется трудной в освоении системой, но, раз попробовав, вы никогда не захотите пользоваться другой.

Оболочка

Ранее демонстрировалось, как инструмент cpio использует вывод команды find для выявления подлежащих архивации файлов. Это иллюстрирует использование каналов, которые перенаправляют вывод одной команды к другой. Этот принцип также применялся для создания резервных копий файлов на накопителе на магнитной ленте, размещенном на другом хосте.

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

Оболочки UNIX также поддерживают сложные программные конструкции, такие как циклы, и операторы сравнения (равно, больше, меньше).

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

Perl и другие инструменты автоматизации

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

задач:

• I Анализ log-файлов (журнальных файлов) и предупреждение администратора о нештатных ситуациях по электронной почте или пейджеру.

• Автоматическая конвертация статистических данных системы в Web-страницы.

• Автоматизация процесса создания бюджетов пользователей, добавление и распространение таблиц automounter, резервное копирование систем и создание HTML-страниц.

• Создание сетевых соединений и осуществление связи через них.

Это лишь несколько примеров выполняемых с помощью этого языка задач. Более углубленно Perl рассматривается в главе 5 книги "Редакции для Internet".

Заслуживают также внимания инструменты TCL/TK, на которых написано большинство инструментов администрирования RedHat. Подробно об этом написано в главе 4 книги "Редакции для Internet".

Инструменты для создания сетей intranet

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

Резюме

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

Прямо отвечая на вопрос, можно сказать, что администраторы отвечают за:

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

Короче говоря, администрирование - это процесс поддержки системы или систем, который обеспечивает достижение компанией своих целей.

Остаток этой части книги посвящен углубленному изучению поддержки системы. В главах 15 и 16 описывается установка системы UNIX, ее запуск и останов системы.

В главе 17 вопросы поддержки пользователей раскрыты подробнее, чем здесь. В главе 18 рассматриваются файловые системы и конфигурация диска, а в главе 19 - конфигурация ядра.

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

Информация о производительности системы и ее повышении изложена в главе 22. Кроме того, в главе 23 рассматривается добавление и поддержка новых компонентов системы, таких как накопители на магнитной ленте или модемы.

Управление почтой, новостями Usenet и другими сетевыми службами описаны в главах с 23 по 27. Последняя глава этой части, 28, посвящена резервному копированию и восстановлению системы.

К оглавлению

---

---