| Каталог документации / Раздел "Операционные системы" / Оглавление документа |
| |
|
Данная глава посвящена созданию стратегий создания единой конфигурации сайта для всей сети.
Для того, чтобы с пользой использовать все инструменты администрирования системы, необходимо точно определить ожидаемые результаты и действия, которые Вы готовы предпринять для их достижения. Необходимо решить, что будет считаться допустимым, а что полностью отвергаться. Если этого не сделать, то в случае, когда система начнёт работать не так, как предполагалось, можно остаться в полном непонимании происходящего.
Как показывает опыт, самая успешная стратегия автоматизации подразумевает максимальную простоту во всём. Чем более единообразны и схожи машины (machines) между собой, тем проще осуществлять управление ими и тем более довольны пользователи. Некоторые утверждают, что им необходима настолько высокая степень гибкости, что все машаны должны быть разными. Степень истинности такого утверждения обратно зависит от числа используемых машин и, как правило, оно справедливо только для весьма особенных сред разработки. Обычно есть необходимость только в одном двух специальных компьютерах, тогда как остальные могут быть очень похожи.
Главное в конфигурации сайта обмен и управление ресурсами. Ресурсы включают в себя файловое пространство (filespace), файлы, данные, программы и физические машины. Прежде чем планировать конфигурацию в масштабах сайта, необходимо прежде решить, как всё должно работать.
В остальных частях данной главы содержится ряд советов и подсказок по дальнейшей работе, но стоит запомнить, что на практике необходимо принимать собственные решения.
В случае использования сетевой информационной службы (CИС) в локальной сети, netgroups могут быть уже определены. Они состоят из списков хостов, принадлежащих отдельным владельцам на сайте. Эти группы могут быть использованы и при работе с cfengine. Это значит, что те же группы могут быть использованы в файле /etc/exports как при определении классов и групп монтирования (mount groups).
Netgroup представляет собой список имён хостов или имён пользователей, зарегистрированных в базе данных сетевой информационной службы (СИС) под особым именем. Нас будет интересовать только список имён хостов.
Для создания netgroup необходимо задать список в файле /etc/netgroup на СИС сервере. Пользователю, не являющемуся администратором СИС, придётся просить о возможности создания netgroup. Список хостов netgroup имеет следующую форму:
mylist-name (host1,,) (host2,,) (host3,,) (host4,,) norway-sun4-host (saga,,) (tor,,) (odin,,) foes-linux-hosts (borg,,)
Каждый элемент имеет три записи, но только первый соответствует списку хостов. Полное объяснение значения данных полей представлено в разделе netgroups приложения к руководству.
Netgroups могут быть использованы для обозначения списка имён хостов в системных файлах типа /etc/exports, что уменьшает объёмы текста в данном файле, сводя длинный список в одно имя. Также это значит, что, если при создании групп и классов в cfengine используется тот же список хостов из netgroup, то можно быть уверенным, что один и тот же список используется всегда. В частности, это значит отсутствие необходимости обновлять множество копий списка хостов.
Сейчас netgroups могут использоваться в cfengine с помощью символов + или @+ в секции groups (см. приложения к руководству).
Управление файлами и ссылками может осуществляться несколькими способами. Все действия разделяются на три категории, называющимися files, tidy и links. Первое используется для проверки существования, владения и разрешений к файлам. Второе занимается регулярным удалением ненужных файлов. Третье является менеджером ссылок, который проверяет, создаёт и разрывает ссылки. Мониторинг прав доступа к файлу или владельца может быть установлен как для отдельных файлов, так и для деревьев папок с помощью контролируемой рекурсии. Файлы, не отвечающие определённым критериям, могут быть зафиксированы, то есть автоматически направлены для правки прав доступа, либо о них может быть сообщено системному администратору с помощью предупреждения. Синтаксис таких команд выглядит следующим образом:
files: class:: /path mode=mode owner=owner group=group recurse=no-of-levels action=action
Имя файла или папки является точкой, с которой cfagent начинает поиск файлов. Начиная с неё, поиск файлов продолжается рекурсивно по подпапкам, причём максимальный предел рекурсивного спуска устанавливается директивой recurse, а также различными опциями работы с символическими ссылками и возможностями устройства. Строка mode (mode-string) определяет разрешённый режим работы с файлом (file-mode) (по аналогии с chmod), а владелец и группа могут создавать списки допустимых пользовательских id и id групп. Действие, которое будет осуществляться с файлом, не отвечающим заданному критерию, описывается в директиве action. Это может быть выдача предупреждений или непосредственная фиксация всех или только пустых файлов или папок. Для таких директив существуют отказобезопасные настройки по умолчанию, так что на практике они могут восприниматься как опции. Например,
files: any:: /usr/*/bin mode=a+rx,o-w own=root r=inf act=fixall
где (в краткой форме) будет осуществляться рекурсивный просмотр всех файлов и папок, начиная с папки соответствующей, групповому символу (например, `/usr/local/bin', `/usr/ucb/bin'). По умолчанию, fixall позволяет фиксировать права доступа и владение файлами без последующей выдачи предупреждений.
Единственная проблема, возникающая при использовании символических ссылок, состоит в том, что при удалении файлы, на которые они указывали, могут оставить висящие ссылки. Поскольку cfagent без труда может создавать огромное количество ссылок, то существует опасность, что с течением времени система заполнится ссылками, которые никуда не указывают. Чтобы решить эту проблему, можно установить опцию links=tidy в разделе files (files section). В таком случае cfagent будет удалять любую символическую ссылку, не указывающую на существующий файл (см. приложение к руководству).
Создание символческих ссылок показано на изображении 1, а алгоритм проверки описан в разделе 2. Кроме создания одиночных ссылок, одной единственной командой можно определять и множественные. Команда
links: binaryhost:: /local/elm/bin +> /local/bin
свяжет все файлы в /local/elm/bin с соответствующими файлами в /local/bin. Это предоставляет, кроме всего прочего, простой способ установки пакетов программного обеспечения в регулярные bin директории, не осуществляя при этом контроля за пользовательской переменной PATH. Следующая возможность использует знания cfagent о доступных (монтированных) бинарных ресурсах для поиска соответствий с определёнными ссылками. Подробнее с этим свойством можно ознакомиться в полной документации.
В ходе разработки cfagent стала очевидной необходимость удалять ненужные файлы. Файлы особенно быстро накапливаются в таких областях, как /tmp, /var/tmp. Множество пользователей использует эти области для получения больших ftp-файлов, так что использование ими дискового пространства остаётся незамеченным. Другой пример: всего лишь за последние несколько месяцев появление netscape World Wide Web клиента с возможностями кэширования привело к засорению жёсткого диска в Осло сотнями мегабайтов WWW фалов. Кроме того, постоянное появление файлов ядра(core)1 и скапливание побочных продуктов (файлы с расширениями .o, .log и т.д.) заполняет диски большими файлами, непонятными большинству пользователей. Эта проблема легко решается несколькими строками в конфигурации cfagent. Файлы могут быть удалены, если к ним в течении n дней не совершался доступ. Рекурсивный поиск в таком случае не только возможен, но и крайне часто используется. В следующем примере:
tidy:
AllHomeServers:: home pattern=core r=inf age=0 home/.wastebasket pattern=* r=inf age=14 home/.netscape-cache pattern=cache????* r=inf age=2 home/.MCOM-cache pattern=cache????* r=inf age=2 home/.netscape pattern=cache????* r=inf age=2
все хосты группы AllHomeServers должны осуществлять итерацию по всем пользовательским домашним папкам (использующих групповой символ home) и искать файлы, соответствующие определённым образцам. Cfagent проверяет последнее время доступа к файлам access time и удаляет только те, которые превосходят заданный предел. Поэтому, в данном примере, все файлы ядра(core files) немедленно удаляются, тогда как файлы в подпапке .wastebasket только после того, как они пролежали там без доступа 14 дней и т.д.
Безусловно, системный администратор должен проявлять особенную осторожность при создании правил, которые могут удалять пользовательские файлы. Одна описка может вылиться в правило, которое будет безвозвратно удалять файлы.
Создавая стратегии tidy, необходимо придавать особое значение дублированию (backup). Не стоит удалять файлы до того, как они были продублированы, что обеспечивает подстраховку на самый непредвиденный случай.
В определённой степени,cfagent помогает отслеживать, какие файлы были удалены. При чистке домашних папок пользователей он создаёт журнал регистрации (log файл) всех файлов, удалённых в ходе последней операции tidy. Этот файл называется ~/.cfengine.rm.
Для удаления определённых файлов лишь раз в неделю полезной может оказаться следующая команда:
tidy: AllHomeServers.Sunday:: files to tidy
Ненужные файлы, такие как coreфайлы, могут удаляться каждую ночь.
Внимание! Будьте осторожны при задании операции удаления файлов в cfagent. При написании группового символа типа core*, можно удалить важные системные файлы core.h
Администрирование системы часто требует копирования файлов. Причиной, как правило, является желание распространить копию определённого файла из некой главной точки (master location) и гарантировать, что все копии не являются устарелыми. Другой причиной может быть желание установить программное обеспечение с одной директории (возможно, с CD ROM) на другую.
Cfagent помогает осуществить этот процесс, позволяя копировать отдельные файлы или файловые деревья с одной директории на другую с возможной проверкой прав доступа и владения файлов, чтобы определённым образом упорядочить все копии. Cfagent может проверять файлы двумя способами.
Cfagent позволяет выполнять следующие операции:
Cfagent позволяет проверять существование в системе определённых процессов, посылать им сигналы (например, kill) и, возможно, перезапускать их. Типичным примером использования является отправка cron и inetd сигнала HUP после редактирования их файлов конфигурации, или прекращение ненужных процессов (таких как пользовательские программы, захватывающие огромное количество памяти системы в моменты самого активного использования).
Подробнее об этом можно прочитать в приложении.
Большинство файловых систем, которые потребуется сделать доступными в сети, попадают в одну из двух категорий. В терминологии cfengine они называются домашние директории (home directories) и бинарные директории (binary directpries). Домашние директории место, где хранятся регистрационные каталоги пользователей. Как правило, это директории /home или /users, или какие-нибудь их поддиректории. Бинарные директории место, где хранится откомпилированное программное обеспечение. Такие файлы (которые не относятся к чистым выпускам операционных систем (pure operating system release) ) часто размещаются в директориях /usr/local или просто /local.
В данной главе будут рассмотрены методы использования cfengine для того, чтобы сделать управление файловыми системами NFS наиболее простым.
Использование Network File System (NFS) в условиях крупной рабочей станции требует небольшого планирования. Задача NFS заключается в предоставлении файлов одного хоста другим. Как правило, файловые системы, которые необходимо распределять в сети, разделяются на две категории: бинарные файловые системы (в которых находится откомпилированное программное обеспечение) и пользовательские или домашние файловые системы (где хранятся регистрационные каталоги пользователей).
Самым простым способом разделить ресурсы в сети будет монтирование каждого ресурса (каждой доступной файловой системы NFS) на каждом хосте. Во избежание разногласий каждая файловая система должна иметь уникальное имя. Это первый, но не самый лучший, метод. Опытный пользователь знает, что перекрёстное монтирование (cross-mounting) слишком большого количества файловых систем NFS может вызвать самые разнообразные проблемы.
Cfengine предлагает простой механизм, который поможет выбрать из списка файловых систем NFS только необходимые ресурсы. Затем он автоматически монтирует их и редактирует соответствующие таблицы файловых систем. Он делает это за счёт определения классов хостов. Например, Вам совершенно не нужно монтировать бинарную файловую систему для системы ultrix на систему HPUX. Это совершенно не важно - бинарные ресурсы зависят от архитектуры или жёсткого-класса. Но домашние директории являются независимыми от архитектуры.
Cfengine позволяет создавать список разрешённых серверов для различных хостов так, что для монтирования будут рассматриваться только файловые системы серверов.
Первым шагом на пути превращения файловых систем NFS в ресурсы сети является создание алгоритма наименования так, чтобы каждая файловая система имела уникальное имя, по которому она может монтироваться. Если не решить эту задачу на данном этапе, то может возникнуть ситуация, когда два или более хостов имеют файловую систему, именуемую /usr/local, причём оба эти хоста необходимо монтировать, так как они содержат разное программное обеспечение.
Следующий алгоритм присваивания имён является простым, но весьма полезным1. Всегда существует возможность создания собственного алгоритма, но нижеприведённая информация однозначно говорит в пользу данного. Если точно по описанию следовать данному алгоритму, возможность возникновения проблем с точками монтирования исключена. Он будет детально описан ниже, а сейчас мы приведём несколько основных идей:
Каждая файловая система является данным именем папки, состоящим из трёх частей:
/site/host/contents
Первая директория (которая существует только для создания подходящих точек доступа) является именем локального места. Например, физический факультет университета (располагающийся отдельно) может назвать её physics. Это может быть название компании или что угодно. Вторая часть это имя хоста, к которому физически прикреплено пространство на диске (disk space). Последняя часть название файловой системы. Вот несколько стандартных примеров:
/physics/einstein/local # /usr/local for einstein@physics /physics/newton/u1 # user partition 1 for newton@physics
На машинах, которые являются домашними в локальном делении, лучше создавать ссылку к /usr/local, чем называть файловую систему /usr/local напрямую, так как это позволяет сделать процесс организации всей сети гораздо понятнее.
Стоит отметить, что при указании cfagent монтировать такой ресурс, он автоматически создаст директорию монтирования и легко может сделать ссылку на /usr/local, поэтому эта небольшая дополнительная работа является невероятно простой.
Все правила наименования(name convention) могут быть собраны вместе при определении переменной точки монтирования mountpattern. В рассматриваемой схеме она может быть определена следующим образом:
mountpattern = ( /$(site)/$(host) )
Её значением является имя хоста, открывающего файл, вне зависимости от того, кто это может быть. Эта переменная используется вместе с переменной образца homepattern, которая используется для того, чтобы различать домашние и бинарные директории (см. homepattern в приложении к руководству). Её можно считать одним из условий наименования. В данном тексте для домашних дисков используются обозначения u1 u2 u3. В равной степени можно использовать home1 home2 и т.д. Если имя уникально, то это не имеет значения.
Теперь полный список именованных ресурсов должен быть представлен в списке mountables, который просто является списком всех ресурсов, доступных в сети для монтирования.
После того, как были определены уникальные имена, как cfagent узнает, что необходимо монтировать? Теперь задача состоит в определении списка серверов для каждого класса хостов.
Предположим, что было сделано следующее объявление binserver:
binservers: mygroup.sun4:: einstein newton
Это укажет cfagent монтировать только бинарные ресурсы с хостов einstein или newton на любые хосты типа sun4 группы mygroup. Каждая файловая система, представленная в mountables и не являющаяся домашней директорией, будет монтирована.
Cfagent автоматически отдельно хранит домашние директории и бинарные ресурсы, так как имя-содержимое (contents-name) домашней директории удовлетворяет переменной образца homepattern. См Раздел 4.6.2.[Уникальные точки монтирования файловых систем], стр. 43.
Объявление homeserver:
homeservers: mygroup:: einstein newton schwinger feynman
соответствующим образом будет значить монтирование всех ресурсов домашней директории в списке всех хостов группы mygroup. Естественно, что не нужно проводить различие между типами платформ архитектуры серверов для пользовательских директорий.
В каждом случае cfagent будет монтировать файловые системы, создавать соответствующие директории для точек монтирования и редактировать таблицы файловой системы.
Как только было произведено монтирование ресурса на уникальную директорию, пользователь получает доступ ко всем файловым системам сети. Теперь для того, чтобы монтировать локальную файловую систему на /usr/local, необходимо создать ссылку:
links: any:: /usr/local -> /$(site)/$(binserver)/local
Это значит, что на любом хосте директория /usr/local должна представлять собой ссылку на ближайший локальный ресурс бинарного сервера. Переменная $(binserver), в принципе, может распространяться на любой бинарный сервер в списке. На практике это значит, что cfagent по порядку просматривает список и выбирает первый подходящий ресурс файловой системы.
Может ли это привести к каким-либо противоречиям? Предположим, что мы находимся на хосте einstein и выполняем написанную выше команду. На своём локальном диске хост einstein имеет файловую систему /physics/einstein/local, которая, по факту, является бинарным сервером для сети, поэтому, естественно, что ей не нужно монтировать какую-либо файловую систему NFS. Но это не является проблемой, так как cfagent автоматически воспринимает $(host), как бинарный сервер наивысшего приоритета для любого хоста. Это значит, что у любой локальной файловой системы всегда есть какой-то приоритет.
Тогда как, если хост schwinger выполняет написанную выше команду, он не найдёт локальной системы под названием /physics/schwinger/local, поэтому он будет просматривать список определённых бинарных серверов, найдёт einstein и начнёт всё сначала. Он найдёт einstein, только если все бинарные серверы были монтированы до того, как началось выполнение команды создания ссылок. Это значит, что последовательность действий actionsequence необходимо выстроить таким образом, чтобы все файловые системы были монтированы до того, как созданы какие-либо ссылки.
После недолгой тренировки, модель cfengine может значительно упростить работу с монтируемыми NFS ресурсами.
Внимание: cfengine не пытается экспортировать файловые системы, он только монтирует уже экспортированные. При желании автоматизировать и этот процесс, можно использовать возможности editfiles для добавления записей в /etc/exports (см. editfiles в приложении к руководству). На практике это делать очень сложно и, как правило, нежелательно.
Для примера напишем очень простую конфигурацию для сети с одним сервером, называемым hal, в которой все хосты имеют один тип операционный системы. В таком примере можно полностью избежать использования классов.
control: site = ( univ ) domain = ( univ.edu ) actionsequence = ( mountall mountinfo addmounts mountall links ) mountpattern = ( /univ ) homepattern = ( home? ) binservers: hal homeservers: hal mailserver: hal:/var/spool/mail mountables: hal:/univ/home1 hal:/univ/home2 hal:/univ/local links: /usr/local -> /univ/local
В данном примере рассматривается только один тип хостов, поэтому для каждого из них конфигурация будет одна и та же: не требуется указывать никаких классов. Если просмотреть последовательность действий action sequence, станет видно, что программа в первую очередь монтирует все файловые системы, которые уже определены на каждом хосте. Это делается, чтобы убедиться, что всё, что уже настроено для монтирования, монтировано. Предположим, что на данном этапе не возникает никаких проблем.
Следующим действием mountinfo создаёт список файловых систем, которые были успешно монтированы каждым хостом. Затем вызов addmounts заставляет cfagent проверить, не пропустил ли хост какие-либо файловые системы. В первую очередь cfagent смотрит, какие серверы определены для каждого хоста. В данном примере все хосты сети имеют лишь один сервер hol. Hal является сервером как для бинарных данных, так и для домашнихданных, то есть домашних директорий пользователей. Список mountables сообщает cfagent, какие файловые системы доступны внутри сети для сервера hal. Монтированы могут быть три системы: /univ/home1, /univ/home2 и /univ/local. Cfagent проверяет, монтирована ли каждая из этих файловых систем, и, если нет, он создаёт нужные директории, редактирует необходимые файлы и монтирует файловые системы.
Последним в списке действий идёт links, которое указывает cfagent посмотреть уже определённые ссылки. В данном случае, определена одна ссылка: с /usr/local на монтированную файловую систему/univ/local. Cfagent проверяет и в случае необходимости пытается создать ссылку. Если всё происходит правильно, то в результате каждый хост сети должен иметь по меньшей мере три монтированных файловых системы и ссылку с /usr/local на /univ/local.
Ниже приведён другой простой пример программы для проверки и автоматического монтирования работающего на NFS /usr/local и всех домашних директорий на все хосты небольшой сети. В данном примере существует несколько серверов, поэтому необходимо использовать несколько классов.
have several servers and must therefore use some classes.
#
# Mounts
#
control:
site = ( mysite )
domain = ( mysite.country )
sysadm = ( mark )
netmask = ( 255.255.255.0 )
actionsequence =
(
mountall
mountinfo
addmounts
mountall
links
)
mountpattern = ( /$(site)/$(host) )
homepattern = ( u? ) # u1 u2 u3 etc..
groups:
MyGroup =
(
host1
host2
binserver1
binserver2
)
######################################################################
homeservers:
MyGroup:: host1
binservers:
MyGroup.sun4:: server1
MyGroup.ultrix:: server2
mailserver:
host1:/usr/spool/mail
mountables:
host1:/mysite/host1/u1
host1:/mysite/host1/u2
server1:/mysite/server1/local
server2:/mysite/server2/local
##########################################################################
links:
/usr/local -> /${site}/${binserver}/local
Предположим, что мы запускает эту программу на хосте host2, который работает на Ultrix. Этот хост принадлежит классу mygroup и жёсткому классу ultrix. Это говорит о том, что его домашним сервером является host1, бинарным сервером server2, и почтовым сервером - host1. Более того, так как homepattern соответствует любой файловой системе, заканчивающейся на u-, в списке mountables он распознаёт две домашних директории и, как следствие, две бинарных директории.
Последовательность действий action sequence начинается с монтирования всех файловых систем, находящихся в настоящее время в таблице файловых систем /etc/fstab. Затем происходит просмотр списка монтированных файловых систем, чтобы определить, что уже монтировано. Поскольку домашним сервером является host1, то хост должен монтировать все домашние файловые системы с этого сервера, поэтому он проверяет только `host1:/mysite/host1/u1' и `host1:/mysite/host1/u2'. Если их не существует, они будут добавлены в /etc/fstab1. Также известно, что бинарным сервером является server1, поэтому следует проверять существование `server1:/mysite/server1/local'. Почтовый сервер также будет проверен и создан в случае необходимости. Затем cfagent ещё раз пытается монтировать все файловые системы, так чтобы были добавлены все новые файловые системы.
Обратите внимание, что в процессе добавления файловых систем в /etc/fstab, cfagent создаёт директории вплоть до и включая точку, где файловые системы должны быть монтированы. Если что-то помешает этому процессу, например, попытка монтировать на верх (mount on top) пустого файла, это приведёт к ошибке.
В заключении идёт раздел создания ссылок и процесс распространения переменных. $(site) раскрывается в mysite. $(binserver) сначала раскрывается в имя хоста (host2), но поскольку /mysite/host2/local не существует, совершается переход к списку бинарных серверов. В результате server1 заменяется на значение переменной $(binserver). Поскольку /mysite/server1/local существует и уже смонтирован, cfagent создаёт ссылку на эту директорию с /usr/ local. Теперь скрипт закончен.
При повторном запуске скрипта всё уже будет сделано, поэтому никаких действий не произойдёт. Если же по каким-то причинам первом запуске пройдёт неуспешно, то повторный также провалиться. В любом случае, он либо сделает работу один раз и целиком, либо выдаст сообщение об ошибке, которая должна быть исправлена человеком2.
Automounter это функция, созданная по принципу демона, которая позволяет заменить статичное монтирование файловых систем NFS динамичной моделью. При запуске automounter файловые системы будут монтироваться, только когда пользователь пытается осуществить доступ к файлу, находящемуся на одной из них. По прошествии заданного промежутка времени (обычно 5 минут) любая файловая система, к которой не был осуществлён доступ, демонтируется. Преимущество такого способа заключается в том, что висящие серверы не влияют на работу хостов, монтирующих их файловые системы, пока не осуществляется доступ к специальным файлам. В обоих случаях для того, чтобы файловые системы можно было монтировать, их надо экспортировать.
В данной главе мы не будем детально описывать работу automounter, а только приведём несколько подсказок для уже посвящённых по тому, как можно использовать cfengine, чтобы упростить и сделать конфигурацию automount более эффективной. Начнём со сравнения работы automounter с работой cfengine по монтированию файловых систем.
Automounter должен быть использован совместно с файлом глобальной конфигурации, распространяемым NIS (the network information service), поэтому все хосты читают одинаковый файл. Может показаться, что все хосты заканчивают монтирование всей файловой системы в базе данных конфигурации automount, но на деле это не так, потому что файловые системы будут монтированы, только если это требуется. Таким образом, система, которой не требуется файловая система, не будет пытаться монтировать её. Более того, существование файла глобальной конфигурации не влияет на то, какие хосты имеют право монтировать определённые файловые системы (что определяется в exports и share соответствующего сервера), поэтому запрос на монтирование неэкспортированной файловой системы приведёт к отказу в доступе. Automount конфигурируется локально на каждом хосте в фалах под названиями /etc/auto_master, auto_direct и т.д.
В статичной схеме монтирования cfengine определяется список бинарных и домашних серверов. В соответствии с этим модифицируется таблица файловой системы. Файловые системы добавляются, только если cfagent сочтёт нужным монтировать их на определённый хост. Главная идея сократить число монтированных файловых систем до тех, которые точно требуются. Вопрос о правах доступа здесь также решается отдельно. Эти файловые системы помещаются в директорию /etc/fstab или её эквивалент в системе.
Automount был создан для решения определённых проблем, которые на данный момент (по мнению автора) лучше решает cfengine. Например, использование карт(maps) хостов в automounter монтирует такие файловые системы, как /usr/local на разных точках монтирования с уникальными именами для каждого хоста во избежание столкновений между именами. В то время как использование cfengine т схемы уникального наименования поможет добиться того же результата гораздо более простым способом и без бессмысленного создания и удаления ссылок, который делает automounter. Более того, алгоритм, заложенный в схеме уникального наименования, лучше выполняется и поддерживается новыми глобальными файловыми системами, такими как AFS И DFS. Единственное преимущество automouter заключается в том, что он не выдаёт раздражающих сообщений об ошибках от зависнувших серверов о том, что NFS сервер не отвечает. В этом отношении вполне разумно использовать прямое монтирование и пространство уникальных имён.
Некоторые системы поддерживают группировку всех пользовательских login (домашних ) директорий под одной директорией, называемой /home или users. Automounter вынужден преодолевать различные трудности, чтобы выполнить эту задачу. При использовании схемы уникальных наименований, типа используемой здесь, это задание становиться элементарным. Необходимо просто назначить монтирование или автомонтирование всех пользовательских директорий, таких как
/site/host/home1 /site/host/home2 ... а затем связать их, как:
/home +> /site/host/home1 /home +> /site/host/home2 ...
Наконец, необходимо помнить, что automount нельзя смешивать с статическими операциями монтирования и демонтированиия. Автоматически монтированные файловые системы имеют приоритет перед статически монтируемыми, но automounter могут возникнуть проблемы, если в процессе его работы вручную монтировать или демонтировать файловые системы.
Очень положительной характеристикой систем BSD и UNIX System V является тот факт, что они сконфигурированы, в основном, с помощью понятных для чтения текстовых файлов. Это делает процесс конфигурации системы несложным, а также упрощает автоматизацию этой процедуры. Большинство файлов конфигурации это состоящие из строк текстовые файлы, что объясняет популярность таких языков программирования, как, например, Perl. Cfengine не пытается соревноваться с Perl и похожими языками. Его встроенные функции редактирования работают на более высоком уровне и созданы для обеспечения скорее понятности, нежели гибкости. К счастью, большинство операций редактирования заключаются во вставке, закомментировании или удалении определённых строк в файле.
Например, некоторые администраторы считают возможность предоставить пользователю детальную информацию о каком-либо объекте потенциально-опасной и хотят отключить её. Это можно сделать следующим способым:
editfiles:
{ /etc/inetd.conf
HashCommentLinesContaining "finger"
}
Команды, содержащие слово Comment используются для закомментирования определённых строк в текстовом файле, то есть чтобы скрыть для программы строчку, не удаляя её при этом. Изначально существовало три типа комментариев: стиль shell (решётка) #, %, который использовался в TeX и в системах AIX и стиль C++ //.
Возможен и более гибкий способ комментирования, использующий обозначения, которые сначала объявляют строку - начало комментариев, а затем окончания. Затем одна команда может быть использована, чтобы отменить комментарии. По умолчанию символом строки начала комментариев является # и строка окончания по умолчанию пустая строка. Например, для того, чтобы обозначить комментарии, как в C необходимо написать следующее:
{ file
SetCommentStart "/* "
SetCommentEnd " */"
# Comment out all lines containing printf!
CommentLinesMatching ".*printf.*"
}
Такие команды редактирования также могут использоваться для наблюдения и управления доступом к корню хоста путём внесения изменений в такие файлы, как .rhosts и установки стандартных переменных окружения в глобальных файлах ресурсов shell, например, для установки временной зоны. Возможность редактирования также можно использовать для того, чтобы обновить или распространить сообщение файла дня (message of the day file), или для конфигурации рассылки почты(см. FAQS и Подсказки в приложении к руководству).
Необычайно полезным сервисом cfagent является возможность редактировать одинаковые файлы, принадлежащие каждому пользователю сети. Например, системному администратору иногда необходимо гарантировать, что пользователи работают в прве яющем логин окружении (sensible login environment). Изменения в системе могут потребовать от всех пользователей объявить, например, новую переменную окружения. Это можно сделать с помощью псевдо-группового символа home. Если написать
{ home/.cshrc
AppendIfNoSuchLine "# Sys admin/cfengine: put next line here"
AppendIfNoSuchLine "setenv PRINTER newprinter"
}
Тогда пользовательские файлы будут один за одним проверяться на наличие определённых строк текста и при необходимости редактироваться.
Файлы загружаются в cfagent и редактируются в его памяти. Они снова сохраняются только при внесении каких-либо изменений. В таком случае старый файл будет сохранён с добавлением к его имени суффикса. При редактировании файлов cfagent выдаёт администратору предупреждения для того, чтобы он мог понять причину, по которой вносятся изменения.
Не нужно путать принцип работы cfagent с работой sed или perl. Некоторая функциональность была скопирована для удобства, но специальные функции создавались из соображений (а) их надёжности и (б) из-за частой необходимости в них. Типичный процесс редактирования файла включает в себя следующие моменты:
Для того, чтобы достичь таких же результатов эквивалентные операции в sed, состоящие из одной строчки, редактируют один и тот же файл, возможно, даже несколько раз, к тому же, без проверки безопасности.
Наличие определённых файлов может представлять опасность целостности системы, поэтому может потребоваться каким-либо образом гарантировать их отсутствие. Например, некоторые производители продают свои рабочие станции с символом + в файле /etc/hosts.equiv. Это значит, что любой пользователь в NIS домейне имеет свободный доступ к системе (без пароля). Поскольку это не лучший вариант, то, скорее всего, возникнет необходимость блокировать этот файл, переименовав, или просто удалить.
disable: /etc/hosts.equiv
Другие файлы представляют потенциальную опасность для системы, поскольку они настолько разрастаются, что занимают весь логический диск. Это особенно характерно для журналов регистрации, как, например, файлы System V /var/adm/wtmpx и `/var/lp/logs/lpsched'. Другие файлы, как /var/adm/messages сдвигаются системой, так что они не растут настолько, чтобы занять весь диск. Cfagent также может сдвигать такие файлы при задании
disable: Sunday:: /var/lp/logs/lpsched rotate=3
Таким образом, при запуске cfagent переименовал файл lpsched в файл lpsched.1. Также он переименовал lpsched.1 в lpsched.2 и так далее, пока число сдвигов не составило максимума в 3 файла. Файлы, которые уже имеют цифру 3 в своём названии, попадают в конец и навсегда удаляются. Такие действия не дают журналам регистрации слишком разрастаться. Если сохранять бэклоги (backlog) не требуется, тогда можно написать rotate-empty и cfagent будет просто опустошать журнал регистрации.
Каждый раз, когда cfagent блокирует файл (disable или links с оператором !) или сохраняет новый файл поверх старого (copy или editfiles), он всегда делает бэкап оригинала. Обычно блокированные файлы переименовываются путём добавления к их имени строки .cfdisabled, копии файлов с добавлением .cfsaved. Создание дублированных файлов в ходе действия copy можно отключить, установив переменную backup=false, но лучше использовать специальную директорию для блокированных и дублированных файлов, где будут храниться подобные файлы со всей системы. Такая директория называется хранилищем файлов (file repository) и определяется в части control программы, например: при объявлении copy, опция backup=timestamp может быть использована, чтобы разрешить множественные бэкапы. Это полезно при использовании cfengine для бэкапов дисков для пользователей, поскольку позволяет сосуществовать разным версиям.
control: repository = ( directory-name )
При определении такой переменной cfagent собирает все дублированные и блокированные файлы (за исключением сдвигаемых) в данной директории с использованием уникальных имён пути. В последствии, эти файлы можно открывать в хранилище и настроить чистку хранилища от старых фалов, которые больше не представляют интереса.
Цель cfagent прежде всего заключается в предоставлении системным администраторам простого интерфейса. Цель действий, встроенных в cfengine, - решать первоочередные, а не все подряд, задачи. Часто администраторам по-прежнему потребуется самим писать скрипты для выполнения более специфических заданий. Эти скрипты, тем не менее, также могут успешно запускаться через cfengine. Переменные и макросы, определённые в cfengine, могут использоваться и в скриптах, так что скрипты могут с максимальной пользовать использовать классовую структуруруктурус максимальной пользовайальной пользовай использовать классовую конструкцию.е специфичных задач.я, что занимаютщение о в. Также обращаем внимание, что поскольку дни недели в cfengine тоже являются классами, то вполне разумно запускать еженедельные скрипты с помощью механизмов cfengine (предполагая, что программа конфигурации выполняется ежедневно). Очевидное применение этому обновление баз данных, like fast-find database one day of the week (каждой базе данных сопоставить свой день недели, согласно которому её можно быстро найти), или запускать на дисках необходимое количество проверок.
shellcommands: myhost.Sunday:: "/usr/bin/find/updatedb"
Скрипты cfengine могут передаваться в качестве переменных c помощью обычной замены переменных.
control:
cfbin = ( /var/cfengine/bin ) backupdir = ( /iu/dax/backup ) shellcommands: "$(cfbin)/cfbackup -p -f $(backupdir) -s /iu/nexus/u1"
В случае, если необходимо написать некий особенно сложный скрипт, расширяющий возможности cfagent, может потребоваться полный доступ к уже определённым классам. Это можно сделать двумя способами:
CFALLCLASSES=class1:class2:...
Такая переменная содержит всегда обновлённый список созданных классов.
В двух предыдущих разделах был рассмотрен вопрос, как осуществлять циклический сдвиг старых лог файлов и как запускать команды shell. Если в системе хранится много старых лог файлов, то было бы хорошо иметь возможность сжимать их, чтобы они не занимали очень много места. Такая возможность реализовывается с помощью команды shell. В нижеприведённом примере происходит поиск фалов, соответствующих групповому символу shell. Имена типа file.1, file.2file.10 будут ему соответствовать и программа сжатия производит их сжатие. Результат выводится на экран(dumped) во избежание ложных сообщений.
shellcommands: "$(gnu)/gzip /var/log/*.[0-9] /var/log/*.[0-9][0-9] > /dev/null 2>&1"
Cfagent также сможет определить сдинутые файлы, если они были сжаты, с суффиксами .Z, gz, rbzили .rbz.
Списки контроля доступа представляют собой расширенные права доступа к файлу. Они позволяют предоставлять определённому списку пользователей возможность открывать и закрывать файл (не создавая при этом для них отдельную группу). Они также позволяют предоставлять такие возможности заданному списку групп. Ряд операционных систем, схожих с Unix, некоторое время имели списки контроля доступа, но в них не возникло большой необходимости.
Существует ряд объяснений таким проволочкам в прошлом. Инструменты для настройки ACL, как правило, интерактивны и не очень удобны в использовании. Из-за того, что определение списка пользователя повлечёт за собой слишком большое количество сообщений в листингах 1s -1, то ими, как правило, не пользуются. Но в связи с этим возникает опасность, что из-за скрытой информации возникнут ошибки, которые нельзя обнаружить, когда не те пользователи смогут открывать файлы. Также ACL различаются на каждой из покупаемых файловых систем и они не работают на подсистеме NFS. Несмотря на перечисленные минусы, использование ACL является весьма разумным. Здесь, в Колледже Осло, кажется, что пользователи постоянно спрашивают, как они могут разрешить открывать файл одному двум лицам, с которыми они работают. Они всегда использовали Novell/PC сети, которые стали применять технологии Apollo/NCS намного раньше. До этого Unix предлагал следующее решение их вопроса: необходимо попросить системного администратора создать для Вас отдельную группу. Затем решение заключалось в использовании chmod. После чего возник вопрос, а в чём же тогда заключается удобство использования Unix?
Решить вопрос такой недостаточной стандартизации стало задачей комитета по созданию проекта POSIX. Ряд производителей выпустили свою продукцию с использованием идей этого. Solaris 2.6 выпустил хороший вариант. Но не смотря на это, даже эти системы не предоставляли удобных инструментов работы с ACL. И никто не захочет возиться с таким вопросом, когда существует множество других, более стоящих, дел. Но несовместимость аргументов стала настоящей головной болью для производителей. Ряд организаций, которые разделяют данные в глобальном масштабе, выбрали более продвинутые решения для сетевых файловых систем, например, AFS и DFS. Такие файловые системы, как DCE и DFS широко используют файлы ACL и их работа не зависит от типа операционной системы. Но даже при этом DFS предлагает только интерактивные инструменты для анализа и установки прав доступа к файлам, что мало поможет системным администраторам, которые бы хотели, чтобы эту задачу решал скрипт, а не они.
Необходимость последнего весьма очевидна. Системы, использующие ACL для обеспечения безопасности, могут полностью развалиться, если в ACL поменять пару строк. В качестве примера можно привести операционные системы Apollo и Domain. Для того, чтобы развалить такие системы, нужно всего лишь изменить ряд ACL и забыть, какими они были раньше. Внезапно система начинает барахлить и ничего уже не работает. В случае, если нет бэкапа, единственный выход - удалить всё, что относилось к вопросу безопасности. В Unix вопросы надёжности решаются проще, когда речь идёт о файлах операционной системы, но ACL стало бы очень хорошим дополнением, обеспечивающим безопасность данных.
Базовая программа проверки файлов в cfagent выглядит примерно следующим образом:
# # Free format cfagent program # control: ActionSequence - ( files ) files: classes:: /directory/file mode=644 owner=mark,ds group=users,adm acl=zap action=fixplain # ... more below
Она просто проверяет права доступа и авторские права определённого файла. Режимный код файла, владелец и группа указаны напрямую. Новым здесь является объявление acl. На первый взгляд она может показаться очень простой, но на самом деле это необычайно мощный инструмент. Zap, конечно же, не является списком контроля доступа. За место этого для обращения к ACL cfagent использует систему алиасов. Это делается для того, чтобы множество самых разных определений ACL не повлияли на ясность команд файла. Алиас ACL задаётся в отдельной части программы, которая выглядит примерно так:
# ...contd
acl:
{ zap
method:append
fstype:solaris
user:rmz:rwx
user:len:r
}
Как видно, ACL является сложным объектом пакет информации определяет, какой пользователь, какими правами обладает. Поскольку ACL являются списками, алиасы также должны знать, следует ли добавлять элементы в существующие списки или заменить ими существующие списки. Кроме того, в связи с тем, что биты разрешений, общие параметры и интерфейс программ различаются для каждого типа файловых систем, необходимо сообщить cfagent тип используемой файловой системы.
Возможно связать несколько алиасов ACL с файлом. Когда cfagent связывает файлы с ACL, он читает существующий ACL и сравнивает его с новым. Изменения в файлах будут производиться только в том случае, если они не соответствуют спецификации в программе cfagent. Рассмотрим полный пример:
files:
$(HOME)/myfile acl=acl_alias1 action=fixall
acl:
{ acl_alias1
method:append
fstype:solaris
user:len:rwx
}
ACL рассматриваются в Solaris с помощью команды getfacl. Предположим, что до запуска программы текстовый файл имел следующие права доступа:
user:*:rwx user:mark:rwx #effective:r-x group:*:r-x #effective:r-x mask:r-x other:r-x default_user:rw- default_group:r-- default_mask:-w- default_other:rwx
После выполнения cfagent, ACL станет:
user:*:rwx user:mark:rwx #effective:r-x user:len:rwx #effective:r-x group:*:r-x #effective:r-x mask:r-x other:r-x default_user:rw- default_group:r-- default_mask:-w- default_other:rwx
Допустим, требуется удалить опцию w для пользователя jacobs или убедиться, что у него её никогда не было.
{ acl_alias1
method:append
fstype:solaris
user:jacobs:-w
}
Обратите внимание, что здесь используется метод конкатенации. Это значит, что какие бы права не предоставлялись на этот файл, пользователь jacobs (взломщик) никогда не получит разрешения на запись в него. Если бы ранее был использован метод overwrite, то можно было бы не описывать все прочие права доступа для каждого пользователя и просто добавить всё написанное выше. Если бы потребовалось полностью отстранить jacobs от пользования файлом, то есть запретить ему любые права доступа,это можно было бы сделать следующим образом:
user:jacobs:noaccess
Ключевое слово noaccess удаляет любые части определения. Обратите внимание, что это всегда совпадает с использованием rwx, поскольку некоторые файловые системы на подобие DFS имеют большее количество частей. Затем, если пользователь будет прощён, то ACL можно вернуть, записав
user:jacobs:default
В Solaris файлы унаследуют ACL по умолчанию из той папаки, в которой они находятся. Это можно изменить настройками umask для создания их собственной маски.
DFS ACL выглядит немного по-другому. Их можно проанализировать с помощью команды acl_edit или с помощью
dcecp -c acl show <filename>
Для того, чтобы внести изменения в DFS, необходимо войти в DCE, чтобы получить cookies для аутентификации. Пользователь cell_admin особенный пользовательский аккаунт для администрирования элементов DFS. Предположим, имеется файл со следующими DCE ACL:
mask_obj:r-x--- user_obj:rwxcid user:cell_admin:r--c-- #effective:r----- group_obj:r-x--d #effective:r-x--- other_obj:r-x---
Теперь требуется добавить права wx для пользователя cell_admin и добавить новые записи с правами rx для группы acct-admin и пользователя root. Это делается с помощью следующего ACL алиаса:
{ acl_alias2
method:append
fstype:dfs
user:/.../iu.hioslo.no/cell_admin:wx
group:/.../iu.hioslo.no/acct-admin:rx
user:/.../iu.hioslo.no/root:rx
user:*:-x
}
Здесь требуется локальное имя ячейки `/.../iu.hioslo.no'. Cfagent не может сам удалённо изменить ACL в других ячейках, но если программа cfengine охватывает все cell servers, тогда никаких ограничений не существует, поскольку по-прежнему можно сосредотачивать все ACL в одном месте. Выполнение и проверка происходят именно в распределённых местах. В этом и состоит одно из главных достоинств cfengine.
После выполнения cfagent с описанным выше кусочком программы ACL приобретает следующий вид
mask_obj:r-x--- user_obj:rwcid user:cell_admin:rwxc-- #effective:r-x--- user:root:r-x--- #effective:r-x--- group_obj:r-x--d #effective:r-x--- group:acct-admin:r-x--- other_bj:r-x---
Ради сохранения простоты здесь были использованы только стандартные обозначения Unix - rwx, но в DFS можно найти более сложные примеры. Такие как:
user:mark:+rwx,-cid
где разрешается чтение, запись и выполнение, но запрещается управление, вставка и удаление. В DFS файлы наследуют начальный объект ACL из их родительской директории, тогда как новые директории унаследуют начальный контейнер.
Объекты, которые в DFS обозначаются как user_obj, group_obj и т.д. ссылаются на владельца файла, то есть они эквивалентны соответствующим командам, действующим в зависимости от того, кто является владельцем рассматриваемого файла. Для того, чтобы упростить пользовательский интерфейс cfengine и сделать его более согласованным с формами в POSIX, суффиксы _objбыли выкинуты. Пользовательское поле * простое обозначение для владельца файла.
Проблема любой системы списков заключается в возможности создать такую последовательность, которая выполняет что-то, потом выполняет обратные этим действия и переделывает что-то другое, и всё это в одном несовместимом списке. Во избежание такого случайного взаимодействия, cfengine требует, чтобы каждый пользователь имел только одну ACE (access control entry запись контроля доступа), то есть, чтобы все права доступа для определённого пользователя содержались в одной записи.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |