учебники, программирование, основы, введение в,

 

Конфигурационные файлы

Проектирование свойств системы
Операционная система, позволяющая задействовать все возможности компьютера, резко отличается от специализированного программного обеспечения огромным числом так называемых «вариантов использования» (use cases) и обширнейшими возможностями тонкой настройки для решения задач конкретного пользователя наилучшим способом. Достаточно сравнить какую-нибудь игровую приставку (например, PlayStation2) под управлением собственной операционной системы и ее же под управлением Linux. Вычислительная и мультимедийная мощность такого компьютера весьма высока (известно, что именно компьютерные игры определяют сейчас ресурсопотребление персонального компьютера). Однако способы управления одной и другой системами настолько различны, что неподготовленный человек просто теряется при виде возможностей Linux: на какие кнопки нажимать? А кнопок-то и нет...
Можно попытаться описать операционную систему как большой и сложный универсальный инструмент для решения любых задач. Предполагается, что пользователь, прочтя документацию, в которой описывается, как работает система и как применять ее в различных ситуациях, сможет решать и свои задачи. Правда, для этого ему придется прочесть большую часть документации по системе (в том числе и технической) и перепрограммировать некоторые части системы сообразно своим нуждам. На такой подвиг способны немногие, времени это займет немало, да и вероятность ошибки (которая тем выше, чем сложнее средства управления системой) при таком подходе недопустимо велика. Сами утилиты или службы Linux, каждую из которых можно «окинуть взором» и понять, что она умеет и чего в ней не хватает, разрабатываются именно теми из пользователей, у которых хватает времени, знаний и навыков на такое полное освоение (см. лекции 17 и 18). Вывод: пользователь – не разработчик, ему все-таки важнее быстро и качественно решить задачу, чем долго совершенствовать инструмент решения.
Можно пойти обратным путем: попытаться предусмотреть все основные способы использования операционной системы на всех основных пользовательских задачах, и на каждый такой способ создать (запрограммировать) отдельную часть, управляемую «кнопкой» или утилитой. Эту часть обычно называют «решением» (solution), и в документации пишут, что должно быть «на входе» системы, и что получается «на выходе» после применения решения. Если пользователь не умеет сам поставить задачу, или делает это в неопределенной форме («хочу, чтобы был текст», «хочу, чтобы играла музыка»), этот способ работает превосходно: та же игровая приставка – это отличное решение крайне неопределенной задачи «хочу без толку потратить время». Однако стоит пользователю захотеть чего-то конкретного, начинаются трудности. Трудности могут быстро стать непреодолимыми, как только для этого «конкретного» не окажется готового решения: внутренняя структура систем, ориентированных на «решения», столь сложна и столь плохо документирована, что сделать что-либо вручную, скорее всего, не удастся. Вывод: пользователь, понимающий суть собственных задач, – не «клиент», он должен иметь возможность быстро и качественно решать задачи самостоятельно, а не выбирать из готовых «решений» то, которое нанесет меньше вреда.
Что же нужно идеальному – достаточно подготовленному, чтобы действовать самостоятельно, и достаточно занятому, чтобы не переделывать систему – пользователю? По-видимому, механизм, с помощью которого можно сформулировать и придать операционной системе все требуемые свойства, имея возможность описывать решение задачи, по крайней мере, на том же уровне конкретности, на котором было поставлено ее условие. Большая часть других, не нужных для решения собственных задач пользователя, свойств должны быть «стандартными» и не требовать его вмешательства.
Профиль системы
Так возникает идея разделить систему на два подмножества: профиль и реализацию. Все, что не потребует вмешательства пользователя, необходимо запрограммировать и применять в готовом виде в качестве составных частей реализации. В Linux этому соответствуют программы и подпрограммы: ядро, модули, демоны, утилиты; используемые ими библиотеки и прочие разделяемые файлы и т. п. Реализация – это монолитная, неизменяемая часть системы, устроенная по типу «решений» основных задач, только задачи эти, как правило, не совпадают с задачами пользователей, а только помогают решать их, то есть служат как бы строительным материалом, деталями и инструментами сборки «больших» решений.
Все, чего может коснуться рука человека, из реализации переносится в профиль системы. Профиль задает поведение реализации на данных пользователя и должен быть устроен так, чтобы пользователь мог его беспрепятственно изменять, если понадобится. С одной стороны, это может быть вариант «высокоуровневого программирования», когда пользователь описывает алгоритм решения и структуру используемых данных на некотором высокоуровневом языке (специализированном или общем, например, на shell). С другой стороны, задание свойств может превращаться в указание модификаторов поведения, когда пользователь просто перечисляет необходимые параметры работы программы, которые изменяют ее заранее известную, но достаточно общую функциональность.
Таким образом система полностью описывается в виде набора необходимых компонентов реализации, активизированных (запущенных) с определенными профилями, вкупе с текущим состоянием каждого компонента. Поскольку компонент реализации не может изменяться, а его текущее состояние, наоборот, меняется постоянно и не управляется пользователем, можно считать, что систему задает ее профиль. Это означает, что для того, чтобы продублировать работу системы на другом компьютере, достаточно установить там стандартную реализацию и перенести профиль (обычно занимающий несравненно меньше места) и пользовательское наполнение. Наполнение (файлы пользователей, содержимое www-страниц и т. п.) может занимать много места, но оно входит в понятие «задача пользователя», поэтому забывать о нем нельзя.
Профиль. Изменяемая часть системы, определяющая ее поведение во время работы.
Как проще всего создать профиль если не всей системы, то хотя бы ее компонента (программы)? Один из вариантов такой: снабдить программу функцией «сохранить настройки», тогда можно будет эту программу запустить, любым способом добиться ее работоспособности, а после зафиксировать достигнутое состояние с помощью этой функции. При этом поначалу совершенно неважно, как выглядят эти настройки: программа-то заработала, значит, цель достигнута (проницательный Мефодий немедленно заметил, что название функции «сохранить настройки» как-то подозрительно похоже на название кнопки).
Зачастую для того, чтобы собрать более или менее отвечающий требованиям пользователя профиль, задействуется больше ресурсов, чем для работы самой программы. Утилита автоматической настройки выглядит эдаким шаманом, или кудесником, который, задав всего несколько вопросов человеку, непонятным образом приводит систему в работоспособное состояние. Такая подсистема и называется «wizard», причем в русском переводе ее отчего-то стесняются называть «шаманом», а величают уважительно «мастером».
Вот пример поведения обычного шамана-настройщика (пакет wvdial, заведующий модемным подключением к Internet):
Ни о каких наводящих вопросах даже речи не зашло! Программа проверила более полусотни устройств, не модемы ли они, но нашла всего одно – /dev/ttyS4. Его настройки определились автоматически (и хорошо, потому что Мефодий не знает, что такое «ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0»). Профиль (а wvdialrc создает именно профиль) лежит теперь в файле .wvdialrc, так что программа wvdial начнет работать с модемом, нуждаясь только в пользовательских настройках (входное имя, пароль и т. п.).
Яркий пример того, как элементы реализации связываются профилем в единую подсистему для решения определенной задачи – командная строка и сценарии командного интерпретатора. Здесь утилиты играют роль элементов реализации, их параметры – роль «настроечной» части профиля, а способ их объединения в сценарий – «программируемой» части профиля. Скажем, команда find /etc -type f 2> /dev/null | xargs -n1 file | cut -d: -f2 | sort | uniq -c задействует шесть утилит системы: командную оболочку, find, xargs, cut, sort и uniq, причем четыре из них запускаются с измененным профилем. Командная оболочка дополнительно программируется для создания конвейера между командами.

Конфигурационный файл
Задание профиля с помощью командной строки – метод далеко не всегда удобный. Даже при работе с самой командной строкой используется окружение для сохранения настроек, чтобы не задавать их всякий раз и для всякой команды. Что уж говорить о сложных системных службах, свойства которых должны сохраняться не от сеанса к сеансу, а постоянно (в том числе при перезагрузке системы). Вывод прост: профиль необходимо держать в файле, вроде того, что создается по команде «сохранить настройки».
Однако сам подход к хранению профиля в файле, при котором пользователь не может изменять этот файл напрямую, а пользуется «умными» конфигураторами, удобен только в случаях, когда настроек много, а цена ошибки невелика (например, при настройке внешнего вида рабочего стола). В общем случае довольно сложно задать поведение системы на основании описания (часто неявного) свойств того, что эта система должна получать в результате. Иными словами, из описания того, что должно получиться, далеко не всегда можно автоматически сделать вывод, как оно должно получаться.
Конфигурационный файл. Текстовый файл, содержащий настройки какой-нибудь части системы (утилиты, демона и т. п.). Как правило, считывается ею при запуске. Типичный для Linux способ организации профиля.
Одним словом, если есть конфигурационный файл, то должны быть и средства редактирования этого файла. Учитывая, что в Linux реализована высокоразвитая система хранения и переработки (как ручной, так и автоматической) данных в текстовом виде, изобретать какой-то новый формат – все равно что изобретать велосипед. Тем более, что именно текст, разделенный на строки и слова, лучше всего подходит тогда, когда есть четкое деление профиля на объекты управления и их свойства (например, настройки какого-нибудь демона и значения этих настроек). Вдобавок, именно со структурированными текстами отменно управляются текстовые редакторы Linux: Vi, Emacs и др:
methody@localhost:~ $ cat .vimrc
so $VIMRUNTIME/vimrc_example.vim
" Some mappings
map  :wall!^M
map!  ^O:wall!^M
" Tune up
set shiftwidth=2 tabstop=8 history=200 viminfo='50
set showmode showmatch showcmd ruler modeline
set autoindent ignorecase smartcase
set nohlsearch noincsearch
set dir=/var/tmp
set wildmode=list:longest,full
set wildmenu
" Colouring
syntax on
colorscheme desert
Вот как выглядит конфигурационный файл для Vim, написанный Мефодием на основе файла, взятого у Гуревича. Легко заметить, что файл состоит из команд режима командной строки Vi с комментариями (в отличие от большинства утилит Linux, в Vi комментарии начинаются на «"»). Символы "^O" и "^M" – это именно соответствующие управляющие символы (вставленные в текстовый файл с помощью "^V", см. лекцию 9). Такой конфигурационный файл легко понимать и изменять.
Как уже было замечено, набор переменных окружения составляет особенный профиль, к которому чувствительны все запускаемые программы – в этом его достоинство. Задаются переменные окружения обычно в командном сценарии, который тоже можно рассматривать как конфигурационный файл). Например, во многих дистрибутивах используется конфигурационный файл .i18n для настройки языковых особенностей клавиатуры, языка вывода сообщений и т. п.):
methody@localhost:~ $ cat .i18n
LANG=ru_RU.KOI8-R
LANGUAGE=ru_RU.KOI8-R
SYSFONTACM=koi8-r
SYSFONT=UniCyr_8x16
DICTIONARY=russian
MPAGE="-CKOI8-R"
export DICTIONARY MPAGE
Однако хранить настройки специфической программы (не нужные всем остальным) в окружении – не самое удачное решение: синтаксис, задающий переменную окружения, слишком прост (имя_переменной=значение), а самих переменных становится слишком много, поэтому при просмотре трудно выделить, какая из них к какой группе настроек относится. Если пытаться упаковать все настройки в значение одной переменной, это значение окажется трудночитаемым, и все преимущество текстового формата сойдет на нет. Например, стандартный конфигурационный файл утилиты ls (точнее, только ее цветовых предпочтений) – /etc/DIR_COLORS (его можно подменить личным файлом ~/.dir_colors) занимает около ста строк вместе с комментариями. Команда ls использует не этот файл, а создаваемую утилитой dircolors переменную LS_COLORS, значение которой – 600-символьная строка без всяких комментариев.
Если профиль слишком велик, держать его в одном конфигурационном файле – значит, доставлять пользователю сомнительное удовольствие разбирать этот файл целиком даже при необходимости внести минимальное изменение. Методов борьбы с неудобочитаемостью несколько. В частности, уже известный по лекции 10 механизм «.d»: файл разделяется на несколько независимых друг от друга файлов так, что редактировать приходится только один из файлов, а программа во время самонастройки считывает все.
Другой способ опирается на то, что изменения, которые пользователь вносит в профиль, как правило, существенно меньше объема всего профиля. Поэтому может быть выгодно хранить все настройки по умолчанию в каком-нибудь файле, менять который вообще не надо, а файл пользовательских настроек использовать как бы «поверх», изменяя профиль в соответствии с ними после того, как выставлен профиль по умолчанию. Дополнительное преимущество такого способа – в том, что пользователь всегда может подглядеть в «большой» файл, чтобы узнать, как оформляется та или иная настройка. Например, утилита updfstab, которая изменяет содержимое /etc/fstab при появлении или удалении съемного дискового носителя (например, лазерного диска), считывает данные из конфигурационного файла /etc/updfstab.conf. Сам этот файл состоит из единственной строки: include /etc/updfstab.conf.default, что приводит к чтению файла с настройками по умолчанию, где задан способ работы со многими съемными устройствами системы. Если администратору нужно как-то изменить поведение updfstab в отношении определенного устройства, он копирует соответствующую группу настроек из updfstab.conf.default в updfstab.conf после строчки include... и исправляет их. То, что эти группы настроек читаются дважды, не играет особой роли: чтение коротких файлов выполняется быстро.
Наконец, третий способ сделать конфигурационный файл удобочитаемым — секционирование профиля, когда все настройки разбиваются на группы, каждой группе дается собственное имя, и синтаксис конфигурационного файла проектируется так, чтобы границы групп хорошо различались при просмотре. В сущности, этот способ – предок схемы «.d», где группе соответствует отдельный файл, однако нередки ситуации, когда разбивать на файлы неудобно (например, если группы не полностью независимы, поэтому может понадобиться редактировать их сразу несколько). Конфигурационный файл утилиты дозвона wvdial, например, секционируется по адресату (провайдеру) плюс отдельная секция «по умолчанию». Сами секции отделяются друг от друга заголовками, заключенными в квадратные скобки:
root@localhost:~> cat .wvdialrc
[Dialer Defaults]
Modem = /dev/modem
Baud = 115200
Init1 = ATZ
Init2 = ATQ0 L0 M4 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Auto DNS = on
Modem Type = Analog Modem
[Dialer hotspace]
Phone = 0123456
Username = fireman
Password = Fire!Fire!
TOnline = true
[Dialer warlock]
Phone = 0246813
Username = cop-120
Password = gimmethegun
Force Address=10.0.0.120
Утилита wvdial обладает высокоразвитым искусственным интеллектом: она самостоятельно догадывается, какой именно тип идентификации используется на сервере. Например, «с той стороны» может оказаться терминал Linux, которому требуется сначала ввести обыкновенное входное имя и пароль, затем надо получить командную строку, запустить на сервере сетевой демон pppd, и только после этого запустить pppd на собственной машине. Другой вариант: pppd на сервере уже запущен, а настройки «Username» и «Password» означают идентификационную информацию протокола CHAP, используемого pppd. Обо всем этом и о многом другом wvdial способна догадаться,так же как wvdialconf умел определять, какое же из устройств является модемом.
Однако на любой искусственный интеллект найдется непостижимая ему жизненная ситуация. На одном из серверов (секция «Dialer hotspace») тоже стоит программа с зачатками искусственного интеллекта, которая тоже пытается определить, каким способом хочет идентифицироваться позвонивший. Оттого эти два кудесника, созвонившись, все ждут, пока кто-нибудь не проявит себя... Помогает настройка TOnline, которая заставляет wvdial немедленно задействовать протокол ppp, на что сервер, подумавши «ах, ppp!», с облегчением запускает pppd. Остается вопрос: почему эта полезная настройка никак не отражена в документации (ее нашел в исходных текстах программы Гуревич)? Не потому ли, что пара wvdialconf-wvdial не по-Linux-овски стремится все делать за пользователя, а стало быть, пользовательская документация для разработчиков этой программы – не главное?
Идею чтения настроек по умолчанию можно развить. Оказывается, бывает удобно, когда описание настройки помещено не в руководство, а непосредственно в конфигурационный файл в виде комментариев. Тогда при изменении этой настройки пользователь сразу видит, что она собой представляет, при этом отпадает необходимость сначала находить строчку в файле, а потом искать ее же в руководстве. Такой распространенный способ оформления называется самодокументированием профиля. Например, файл /etc/man.conf, управляющий работой команды man, оформлен в самодокументированном стиле:
methody@localhost:~ $ cat /etc/man.conf
. . .
# NOCACHE keeps man from creating cache pages ("cat pages")
# (generally one enables/disable cat page creation by
# creating/deleting the directory they would live in – man
# never does mkdir)
#
# NOCACHE
# The command "man -a xyzzy" will show all man pages for xyzzy.
# When CMP is defined man will try to avoid showing the same
# text twice. (But compressed pages compare unequal.)
#
CMP  /usr/bin/cmp -s
. . .
Мефодий, может быть, и не понял бы сразу, зачем команде man использовать утилиту cmp, однако в поясняющем комментарии написано: когда нужно показать несколько руководств разом, они предварительно сравниваются, и показываются только несовпадающие.
Если пойти еще дальше, то можно создать несколько различных файлов с примерами настроек, чтобы пользователь мог взять один из них и довести до нужного ему состояния. Именно такую – демонстрационную – настройку Мефодий и включил в качестве настройки по умолчанию в свой .vimrc (в первой строке). Кстати, на самом деле профиль Vim весьма сложен, но большинство его настроек по умолчанию находятся в различных файлах дерева каталогов /usr/share/vim – эдакая «схема .d/.d», где файлы профиля, соответствующие подгруппам настроек, лежат в подкаталогах, соответствующих группам. Включение определенного настроечного файла может происходить неявно: например, строчка colorscheme desert из .vimrc приводит к чтению /usr/share/vim/colors/desert.vim.
Конфигурационные файлы могут иметь довольно замысловатый синтаксис, если соответствуют сложным структурам данных (таковы, например, настройка irc-клиента irssi) или содержать в себе дополнительные средства самодокументирования (например, файл настройки текстового www-броузера lynx не просто хорошо документирован, но и размечен теми же средствами, какие используются в самом броузере для представления HTML).

Изменение конфигурационных файлов
Как правило, конфигурационный файл считывается программой при запуске, отражая, таким образом, ее состояние на момент старта. Изменения настроек работающей программы в конфигурационном файле, как правило, не отражаются. Тому есть несколько причин: не стоит превращать файл, изредка редактируемый пользователем, в файл, изменение которого происходит постоянно; не стоит держать конфигурационный файл всегда открытым; тяжело, изменяя файл автоматически, не испортить структуру комментариев (интерпретируемых не машиной, а пользователем) и т. д. Впрочем, многие утилиты, особенно использующие графическую среду, могут записывать настройки в файл по окончании работы. Большинство конфигурационных файлов весьма удобно редактировать вручную, с помощью Vi или Emacs (для файлов, более или менее похожих, используется общая подсветка синтаксиса, а для наиболее популярных существуют и собственные варианты подсветки).
В /etc хранятся настройки системных служб, в том числе настройки по умолчанию, настройки по умолчанию пользовательских утилит, профили командных интерпретаторов, а также настройки, используемые в процессе загрузки системы (например, modules.conf). Там же располагаются и стартовые сценарии, о которых рассказано в лекции 10. Чего не стоит искать в /etc, так это разнообразных примеров настройки той или иной службы. Считается, что пример – это часть документации, и их следует помещать, например, в /usr/share/doc/название_службы/examples.
Файлы, имеющие отношение к процессу досистемной загрузки, обычно лежат не там, а в /boot; это стоит иметь в виду, так как /boot/grub/menu.lst – тоже часть профиля системы, хотя и довольно специфическая. В профиль системы входит содержимое каталогов etc из так называемых «песочниц», расположенных обычно в /var/lib.
Смысл термина «песочница» вот в чем. В Linux есть замечательный системный вызов chroot() и использующая его утилита chroot, формат командной строки которой chroot каталог команда. Эта утилита запускает команду, изменив окружение таким образом, что та считает каталог корневым. Соответственно, все подкаталоги каталога представляются команде каталогами первого уровня вложенности, и т. д. Если необходимо во что бы то ни стало ограничить область действия некоторой утилиты (например, по причине ее небезопасности), можно запускать ее с помощью chroot. Тогда, даже имея права суперпользователя, эта утилита получит доступ только к каталогу и его подкаталогам, а /etc и прочие важные части системы окажутся в неприкосновенности. Сам каталог как раз и играет роль «песочницы», в которую утилиту «пустили поиграть», позволяя вытворять что угодно. Часто бывает, что в «песочнице» есть и свой каталог etc, содержащий необходимые для запуска утилиты (или системной службы) настройки. Вот этот-то etc из «песочницы» также входит в список каталогов, хранящих профиль системы.
В /etc могут находиться не только файлы, но и подкаталоги (особенно в стиле «.d») и целые поддеревья каталогов. Например, в некоторых дистрибутивах Linux используется подкаталог /etc/sysconfig. Этот каталог создается и заполняется файлами при установке системы или при запуске специального «конфигуратора» – программы-кудесника, задающей наводящие вопросы. Некоторые стартовые сценарии, использующие полученные настройки, также лежат в этом каталоге или его подкаталогах. Если в системе есть каталог /etc/sysconfig, там должны оказаться настройки, относящиеся не к самим службам или утилитам, а к способу их запуска при загрузке, а также языковые и сетевые настройки, тип мыши и т. д.
Подсистема учетных записей
Несколько конфигурационных файлов и способы работы с ними заслуживают отдельного рассмотрения. В первую очередь Мефодий заинтересовался системой учетных записей, о которой упоминалось сразу в нескольких предыдущих лекциях. Итак, существует два файла, доступных для чтения всем пользователям: /etc/passwd, хранящий учетные данные пользователей, и /etc/group, определяющий членство пользователей в группах (во всех, кроме группы по умолчанию):
methody@localhost:~ $ cat /etc/passwd
root:x:0:0:System Administrator:/root:/bin/bash
bin:x:1:1:bin:/:/dev/null
daemon:x:2:2:daemon:/:/dev/null
adm:x:3:4:adm:/var/adm:/dev/null
lp:x:4:7:lp:/var/spool/lpd:/dev/null
. . .
nobody:x:99:99:Nobody:/var/nobody:/dev/null
shogun:x:400:400:Лев Гуревич:/home/shogun:/bin/zsh
methody:x:503:503:Мефодий Кашин:/home/methody:/bin/bash
methody@localhost:~ $ cat /etc/group
root:x:0:root
bin:x:1:root,bin,daemon
daemon:x:2:root,bin,daemon
sys:x:3:root,bin,adm
adm:x:4:root,adm,daemon,shogun
wheel:x:10:root,shogun
. . .
proc:x:19:root,shogun
shogun:x:400:
methody:x:503:
Оба файла состоят из строк, поля которых разделяются двоеточиями. В файле passwd – семь полей. Первое из них определяет входное имя пользователя – то самое, что вводится в ответ на «login: ». Второе поле в ранних версиях UNIX использовалось для хранения ключа пароля. В Linux пользовательские пароли не хранятся нигде – ни в явном виде, ни в зашифрованном. Вместо этого хранится ключ (hash) пароля – комбинация символов, однозначно соответствующая паролю, из которой, однако, сам пароль получить нельзя. Иными словами, существует алгоритм превращения пароля в ключ, а алгоритма превращения ключа в пароль нет. Когда пользователь регистрируется в системе, из введенного им пароля изготавливается еще один ключ. Если он совпадает с тем, что хранится в учетной записи, значит, пароль правильный.
Авторы UNIX предполагали, что, раз пароль из ключа получить нельзя, ключ можно выставлять на всеобщее обозрение, однако выяснилось, что, узнав ключ, пароль можно попросту подобрать на очень мощной машине или в предположении, что пароль – это английское слово, год рождения, имя любимой кошки и т. п. Если подбор пароля сопровождается неудачными попытками входа в систему, это отражается в системных журналах и может быть легко замечено. А завладев ключом, злоумышленник сможет заняться подбором пароля втихомолку на каком-нибудь суперкомпьютере. В конце концов, ключ не нужен никому, кроме подсистемы идентификации, поэтому его вместе с другими полями учетной записи, о которых всем знать не обязательно, из /etc/passwd перенесли в «теневой» файл учетных записей – /etc/shadow. На месте ключа в Linux должна быть буква "x"; если там стоит что-то другое, идентификация пользователя не сработает, и он не сможет войти в систему.
Третье и четвертое поля passwd – идентификатор пользователя и идентификатор группы по умолчанию. Как уже говорилось в лекции 6, именно идентификатор пользователя, а не его входное имя, однозначно определяет пользователя в системе и его права. Можно создать несколько учетных записей с одинаковыми UID, которые различаются другими полями. Тогда при регистрации в системе под именами из этих записей пользователи могут получать разные домашние каталоги и командные оболочки, разное членство в группах, но иметь один и тот же UID. Пятое поле отводится под «полное имя» пользователя; это единственное поле passwd, содержимое которого ни на что не влияет. Наконец, шестое и седьмое поля содержат домашний каталог и стартовый командный интерпретатор пользователя. Если седьмое поле пусто, подразумевается /bin/sh, а если его содержимое не встречается в файле /etc/shells, содержащем допустимые командные интерпретаторы, неизбежны трудности при идентификации пользователя.
Строки файла /etc/group состоят из четырех полей, причем второе – ключ группового пароля – обычно не используется. Первое поле – это имя группы, третье – это идентификатор группы, а четвертое – это список входных имен пользователей, которые в эту группу входят (более точно – для которых эта группа является дополнительной, так как группа по умолчанию указывается в /etc/passwd, хотя никто не мешает продублировать группу по умолчанию и в /etc/group). Таким образом, определение членства пользователя в группах зависит не от его UID, а от входного имени.
Упомянутый выше файл /etc/shadow, доступ к которому имеет только суперпользователь, также состоит из полей, разделяемых двоеточиями. Помимо входного имени и ключа пароля там указываются различные временные характеристики учетной записи: нижняя и верхняя граница времени жизни пароля, самой учетной записи, дата последнего изменения и т. п. Ключ пароля (второе поле) указывается в одном из поддерживаемых форматов, а если формат не опознан, вся учетная запись считается недействительной. Поэтому один из способов запретить регистрацию пользователя в системе – добавить один символ (например, "!") прямо в поле ключа, отчего все поле становится синтаксически неправильным. Вновь разрешить пользователю входить в систему можно, удалив из поля лишний символ. Именно так работает (с ключами "-L", lock, и "-U", unlock) утилита usermod, изменяющая учетную запись. С помощью этой утилиты можно отредактировать и все остальные поля как passwd, так и shadow.
Добавить и удалить пользователя или группу можно с помощью утилит useradd, userdel, groupadd и groupdel соответственно. Не стоит пользоваться текстовым редактором, так как он не гарантирует атомарности операции добавления/удаления, хотя бы потому, что изменению подлежат сразу два файла – passwd и shadow. Даже если необходимо отредактировать /etc/passwd или /etc/group (например, для добавления пользователя в группу или удаления его оттуда), стоит запускать не просто редактор, а vipw или vigr (именно их поведение, позволяющее соблюсти атомарность, копирует утилита visudo, описанная ранее):
Здесь был добавлен пользователь incognito, группа по умолчанию – users, член групп proc и cdrom, полное имя – «Incognito». Стоит заметить, что пароль для этой учетной записи установлен не был (чтобы создать пароль, стоило запустить команду passwd incognito), и, даже если бы пользователя тут же не удалили (userdel -r удаляет также и домашний каталог, и почтовый ящик), зарегистрироваться в системе под именем incognito было бы все равно невозможно.

Подсистема идентификации
Подсистемой учетных записей пользуется подсистема идентификации, которая в Linux имеет модульную структуру и называется PAM (Pluggable Authentication Modules, т. е. «Подключаемые модули идентификации»). Идея PAM – в том, чтобы унифицировать и, вместе с тем, сделать более гибкими любые процедуры идентификации в системе – начиная от команды login и заканчивая доступом к файлам по протоколу, скажем, FTP. Для этого недостаточно просто написать «библиотеку идентификации» и заставить все программы ее использовать. В зависимости от того, для чего производится идентификация, условия, при которых она будет успешной, могут быть более или менее строгими, а если она прошла успешно, бывает нужно выполнить действия, связанные не с определением пользователя, а с настройкой системы.
В большинстве дистрибутивов PAM обучен схеме «.d», и настройки каждой службы, которая использует идентификацию, лежат в отдельном файле:
В PAM определено четыре случая, требующие идентификации: auth – собственно идентификация, определение, тот ли пользователь, за кого он себя выдает, account – определение, все ли хорошо с учетной записью пользователя, password – изменение пароля в учетной записи, и session – дополнительные действия непосредственно перед или непосредственно после того, как пользователь получит доступ к затребованной услуге. Эти значения принимает первое поле любого файла настройки из pam.d, а в третьем поле записывается модуль, который проверяет какой-нибудь из аспектов идентификации. Второе поле определяет, как успех или неуспех проверки одного модуля влияет на общий успех или неуспех идентификации данного типа (например, required означает, что в случае неуспеха модуля проверка пройдена не будет). Четвертое и последующие поля отведены под параметры модуля:
Такие настройки login обнаружил Мефодий на своем компьютере. Во всех четырех случаях используется включаемый файл system-auth (к нему обращаются и другие службы), с некоторыми дополнениями. Так, во время идентификации pam_nologin.so дополнительно проверяет, не запрещено ли пользователям регистрироваться вообще (как это бывает за несколько минут до перезагрузки системы), а перед входом в систему и после выхода из нее pam_console.so выполняет описанную в лекции 6 «передачу прав на владение устройствами» (и, соответственно, лишение пользователя этих прав).
Каталог /etc/pam.d – замечательный пример того, как профиль определяет поведение системы. В частности, четыре первых строки из system-auth показывают, что в этом дистрибутиве используется не просто «теневой» файл паролей, а схема TCB, описанная в лекции 6. (Как уже известно Мефодию, в этой схеме вместо общего для всех /etc/shadow задействованы файлы вида /etc/tcb/входное_имя/shadow, причем права доступа к ним устроены таким образом, чтобы при выполнении команды passwd можно было обойтись без подмены пользовательского идентификатора на суперпользовательский).
Подсистема системных журналов
Проста и остроумна в Linux подсистема ведения системных журналов – демон syslogd, управляемый конфигурационным файлом /etc/syslog.conf и «.d»-каталогом /etc/syslog.d. Если какой-нибудь демон или служба желают сообщить системе о том, что наступило событие, которое стоит запомнить, у нее есть два пути. Во-первых, можно просто добавлять очередную запись в файл, который сам этот демон и открыл; этот файл будет журналом его сообщений. Во-вторых, можно воспользоваться системным вызовом syslog(), который переадресует текстовое сообщение специальному демону – syslogd – а уж тот разберется, что с этим сообщением делать: записать в файл, вывести на 12-ю консоль или забыть о нем. Второй путь (централизованная журнализация) предпочтительнее почти всегда; исключение составляет случай, когда сообщения по какой-то причине не могут быть текстовыми или этих сообщений предполагается посылать так много, что syslogd просто не справится.
Все события, о которых сообщается syslogd, подразделяются горизонтально – по типу службы (facility), с которой это событие произошло, и вертикально – по степени его важности (priority). Типов событий насчитывается около двадцати (среди них auth, daemon, kern, mail и т. п., а также восемь неименованных, от local0 до local7). Степеней важности всего восемь, по возрастанию: debug, info, notice, warning, err, crit, alert и emerg. Таким образом, каждое событие определяется парой значений, например, mail.err означает для syslogd событие, связанное с почтой, притом важности, не меньшей err. Из таких пар (с возможной заменой типа или важности на "*", что означает «любые», или none, что означает «никакие») составляется конфигурационный файл /etc/syslog.conf:
[root@localhost root]# cat /etc/syslog.conf
*.notice;mail.err;authpriv.err  /var/log/messages
authpriv.*;auth.*               /var/log/security.log
*.emerg                         *
*.*                             /dev/tty12
mail.info                       /var/log/maillog
В первом поле строки указываются профили сообщений, разделенные символом ";", а во втором – хранилище сообщений (файл, терминал, есть способы отдавать их на обработку программе и пересылать по сети). В примере в файл /var/log/messages попадают все сообщения важности не меньшей, чем notice, за исключением сообщений типа mail и authpriv, которые попадают туда, только если имеют важность не ниже err. Сообщения типа authpriv и auth любой важности попадают в файл /var/log/security.log, а типа mail и важности не ниже info – в файл /var/log/maillog. Сообщения типа emerg (наивысшей важности) выводятся на все терминалы системы, и, наконец, все сообщения выводятся на 12-ю виртуальную консоль.
Во многих системах используется основательно доработанный syslogd, позволяющий фильтровать сообщения не только по типу/важности, но и, например, по отправителю, задавать точные (а не «не меньшие») значения priority и т. п., однако такие доработки нужны для того, чтобы либо вести практически нефильтрованную журнализацию (получаются системные журналы совершенно нечитаемого объема), либо отводить поток сообщений определенной службы в отдельный журнал, опять-таки, не для чтения, а для последующей обработки.
Стоит заметить, что каталог /etc/syslog.d в новых версиях syslogd предназначен для хранения не профильных конфигурационных файлов в стиле «.d», а сокетов, из которых демон может получать сообщения так же, как из сети или в результате системного вызова syslog().

Выполнение действий по расписанию
Другой пример типичной для Linux службы, управляемой конфигурационным файлом, – демон cron, регулярно выполняющий в заданное время заданные действия. Время от времени в системе необходимо обновлять разнообразные файлы, например, базы данных антивирусов (вирусов в Linux нет, а антивирусы есть!), базу данных whatis или список всех доступных на чтение файлов системы, locatedb (поискать по этому списку можно командой locate); нужно собирать статистику по работе системы, анализировать цельность системы (этим занимаются службы OSec, TripWire или AIDE) и производить множество других регулярных действий. Всем этим и занимается демон cron.
Конфигурационный файл демона cron называется /etc/crontab.
[root@localhost root]# cat /etc/crontab
#minute (0-59),
#|     hour (0-23),
#|     |     day of the month (1-31),
#|     |     |     month of the year (1-12),
#|     |     |     |     day of the week (0-6 with 0=Sunday).
#|     |     |     |     |     user
#|     |     |     |     |     |     commands
01     *     *     *     *     root    run-parts /etc/cron.hourly
02     4     *     *     *     root    run-parts /etc/cron.daily
22     4     *     *     0     root    run-parts /etc/cron.weekly
42     4     1     *     *     root    run-parts /etc/cron.monthly
Первые пять полей этого файла определяют время запуска команды: минуту, час, число месяца, месяц и день недели. Символ "*" означает, что соответствующая часть даты не учитывается. Шестое поле – имя пользователя, от лица которого запускается команда, указанная в остальных полях строки. Так, в примере команда run-parts /etc/cron.weekly будет запускаться в 4 часа 22 минуты каждое воскресенье (нулевой день) любого числа любого месяца. Как видно из примера, обычно /etc/crontab невелик: чаще всего он состоит из почасового, поденного, понедельного и помесячного запуска специального сценария (в примере – run-parts). Этот сценарий реализует упрощенную схему «.d», он попросту запускает отсортированные в лексикографическом порядке сценарии из соответствующего каталога (например, из /etc/cron.daily):
[root@localhost root]# ls /etc/cron.daily
000anacron logrotate makewhatis osec stmpclean updatedb
Вот что происходит каждый день на машине Мефодия: запуск anacron и «прокручивание» системных журналов (об этом речь пойдет далее), обновление базы whatis, проверка цельности системы с помощью osec, прореживание старых и неиспользуемых файлов в /tmp (утилита stmpclean) и, наконец, обновление базы locatedb.
Пользователям системы можно разрешить иметь собственные расписания, также обрабатываемые демоном cron. Эти расписания имеют тот же синтаксис, что и crontab, только шестое поле («user») в них отсутствует. Редактировать пользовательские таблицы рекомендуется с помощью команды crontab -e (чтобы не подсунуть демону синтаксически неверный файл). Сами таблицы могут храниться, в зависимости от версии и настроек cron, в /var/spool/cron/crontabs, /var/spool/cron, /var/cron/tabs или еще где-нибудь.
Служба anacron появилась в Linux-системах в то время, когда их начали активно использовать на персональных рабочих станциях. Такие станции, в отличие от серверов, не обязаны работать круглосуточно. Скорее всего, на ночь, на праздники и на время отпуска их выключают. Это значит, что все настройки cron надо менять в соответствии с графиком включений/выключений (иначе cron.daily никогда не выполнится в четыре часа ночи) – или запускать отдельную службу, которая будет выполнять некоторые задачи не по расписанию, а потому что их давно уже пора запустить. Дополнительно anacron рассчитывает запуск задач так, чтобы не перегрузить компьютер работой, если их накопилось слишком много. Конфигурационный файл anacron называется /etc/anacrontab.
«Прокручивание» системных журналов
Еще изучая работу syslog, Мефодий не расставался с мыслью, что файл, в котором записывается системный журнал, постоянно растет. Это значит, что каков бы ни был размер файловой системы /var, она в конце концов заполнится журналами под завязку – если как-то их не укорачивать. К сожалению, в Linux укоротить файл от начала, отрезав самые старые записи, нельзя, как нельзя и добавлять новые записи в начало файла. Эти операции легко реализовать с помощью копирования нужной области в новый файл и последующего переименования, но, во-первых, соблюсти атомарность таких составных операций нелегко, а во-вторых, они требуют вдвое больше места в файловой системе на время работы (и, стало быть, каких-то аварийных процедур на случай нехватки места).
Поэтому в Linux принят другой, существенно менее ресурсоемкий алгоритм, позволяющий избежать переполнения /var: так называемое «прокручивание» системных журналов. Суть алгоритма в следующем: когда настает пора укоротить журнал (например, раз в неделю или если файл журнала достиг определенного размера), этот файл переименовывают, и открывают новый пустой файл с тем же именем. Если хранить несколько (скажем, семь) переименованных старых файлов, с ними уже можно производить операцию «отбрасывания старого»: самый старый – седьмой – файл удаляется, шестой переименовывается в седьмой, пятый – в шестой, и т. д. до первого (моложе которого только текущий журнал), который переименовывается во второй. Только тогда можно переименовать текущий журнал в «первый старый» и открыть новый. Получается очередь устаревающих файлов, пополняемая с одной стороны и усекаемая с другой.
Как правило, имя «первого старого» журнала получается путем добавления к имени журнала суффикса ".1", второго – ".2" и т. д.:
Прокручиванием системных журналов занимается утилита logrotate, которая тоже управляется и конфигурационным файлом /etc/logrotate.conf, и «.d»-каталогом /etc/logrotate.d/. Согласно настройкам, старые файлы можно сжимать упаковщиками bzip2 (как в примере) или gzip, можно задавать им определенные права доступа, можно посылать сигнал некоторой службе (чтобы она заметила подмену журнала, если она сама, а не syslogd занимается его пополнением) и т. п.
Конфигурационные файлы в домашнем каталоге
Немало конфигурационных файлов находится в домашнем каталоге пользователя. Этими файлами практически любая утилита может быть перенастроена по сравнению с обычным поведением, или поведением, задаваемым конфигурационным файлом из /etc. В Linux принято предоставлять пользователю возможность задавать профиль любого используемого им инструмента, начиная от простой утилиты и заканчивая графической подсистемой управления «рабочим столом» (см. об этом лекцию 15). Как правило, имена таких файлов или каталогов начинаются на ".", т. е. считаются скрытыми – для того, чтобы не засорять выдачу ls. Если пользователю нужно работать не со своими файлами, а именно с настройками, он всегда может применить ключ "-a" или "-A":
Многие утилиты создают конфигурационный файл при запуске, если его в домашнем каталоге пользователя нет, поэтому со временем объем ls -A становится все больше. Файл .lpoptions задает параметры подсистемы печати, .pinerc – это настройки почтового клиента pine, .viminfo – файл истории команд редактора Vim, а файл .Xauthority и каталог .xsession.d управляют запуском графической подсистемы X11, описанной в лекции 15. Из файлов в примере некоторые вообще не являются «стандартными»: так, .aliases и .i18n просто «втягиваются» стартовым командным сценарием bash, потому что упомянуты в нем явно; строго говоря, они могли бы называться и по-другому. Все конфигурационные, стартовые и прочие вспомогательные файлы принято делать скрытыми, даже если никаких требований к их названиям нет.
Файл .pythonstartup (настройки интерпретатора языка программирования Python) выполняется потому, что имя этого файла задано в переменной окружения PYTHONSTARTUP. Мефодию пришлось дописать строку PYTHONSTARTUP="/home/methody/.pythonstartup"; export PYTHONSTARTUP в ~/.bash_profile и "C-i": complete в ~/.inputrc, чтобы достраивание заработало и в этом интерпретаторе. Еще один файл, .pyhistory, используется в самом .pythonstartup:
methody@localhost:~ $ cat .pythonstartup
import atexit, os, readline, rlcompleter
historyPath = os.path.expanduser("~/.pyhistory")
def save_history(historyPath=historyPath):
import readline
readline.write_history_file(historyPath)
if os.path.exists(historyPath):
readline.read_history_file(historyPath)
atexit.register(save_history)
del os, atexit, readline, rlcompleter, save_history, historyPath
 
Подавляющее большинство конфигурационных файлов предназначено для того, чтобы их мог редактировать пользователь. Эти файлы часто имеют самодокументированный формат и/или сопровождаются руководством, нередко вынесенным в отдельный от руководства по самой утилите документ.

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика