Перейти к основному содержанию
Рецепты Linux

Main navigation

  • Основы
  • Система
  • Команды
  • Программы
  • Дистро
  • Интерфейсы
  • Устройства
  • Доки
User account menu
  • Войти

Строка навигации

  1. Главная
  2. Linux: Введение
  3. Конфигурационные файлы

Системные конфигурационные файлы

Подсистема учётных записей

Несколько конфигурационных файлов и способы работы с ними заслуживают отдельного рассмотрения. В первую очередь Мефодий заинтересовался системой учётных записей, о которой упоминалось сразу в нескольких предыдущих лекциях. Итак, существует два файла, доступных для чтения всем пользователям: /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:

Пример 6. Файлы /etc/passwd и /etc/group

Оба файла состоят из строк, поля которых разделяются двоеточиями. В файле passwd — семь полей. Первое из них определяет входное имя пользователя — то самое, что вводится в ответ на «login:». Второе поле раньше, в ранних версиях UNIX, использовалось для хранения ключа пароля. В Linux пользовательские пароли не хранятся нигде, ни в явном виде, ни в зашифрованном. Вместо этого хранится ключ (hash) пароля — комбинация символов, однозначно соответствующая паролю, из которой, однако, сам пароль получить нельзя. Иными словами, существует алгоритм превращения пароля в ключ, а алгоритма превращения ключа в пароль нет. Когда пользователь регистрируется в системе, из введённого им пароля изготавливается ещё один ключ. Если он совпадает с тем, что хранится в учётной записи, значит, пароль правильный.

Авторы UNIX предполагали, что, раз пароль из ключа получить нельзя, ключ можно выставлять на всеобщее обозрение, однако выяснилось, что, узнав ключ, пароль можно попросту подобрать на очень мощной машине или в предположении, что пароль — это английское слово, год рождения, имя любимой кошки и т. п. Если подбор пароля сопровождается неудачными попытками входа в систему, это отражается в системных журналах и может быть легко замечено. А завладев ключом, злоумышленник сможет заняться подбором втихомолку на каком-нибудь суперкомпьютре. В конце концов, ключ не нужен никому, кроме подсистемы идентификации, поэтому его, вместе с другими полями учётной заиси, о которых знать всем не обязательно, из /etc/passwd перенесли в «теневой» файл учётных записей /etc/shadow. На месте ключа в Linux должна быть буква «x»; если там стоит что-то другое, идентификация пользователя не сработает, и он не сможет войти в систему.

Третье и четвёртое поля passwd — идентификатор пользователя и идентификатор группы по умолчанию. Как уже говорилось в лекции Права доступа именно идентификатор пользователя, а не его входное имя, однозначно определяет пользователя в системе и его права. Вполне возможно создать несколько учётных записей с одинаковыми 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, описанная ранее). 

[root@localhost root]# useradd -g users -G proc,cdrom -c "Incognito" incognito
[root@localhost root]# id incognito
 uid=504(incognito) gid=100(users) groups=100(users),19(proc),22(cdrom)
[root@localhost root]# userdel -r incognito
[root@localhost root]# id incognito
 id: incognito: No such user

Пример 7. Добавление и удаление пользователя

Здесь был добавлен пользователь incognito, группа по умолчанию — users, член групп proc и cdrom, полное имя — «Incognito». Стоит заметить, что пароль для этой учётной записи установлен не был (чтобы создать пароль, стоило запустить команду passwd incognito), и, даже если бы пользователя тут же не удалили (userdel -r удаляет также и домашний каталог, и почтовый ящик), зарегистрироваться в системе под имененем incognito было бы всё равно невозможно.

Подсистема идентификации

Подсистемой учётных записей пользуется подсистема идентификации, которая в Linux имеет модульную структуру и называется PAM (Pluggable Authentication Modules, т. е. Подключаемые Модули Идентификации). Идея PAM — в том, чтобы унифицировать и, вместе с тем, сделать более гибкой любые процедуры идентификации в системе — начиная от команды login и заканчивая доступом к файлам по протоколу, скажем, FTP. Для этого недостаточно просто написать «библиотеку идентификации» и заставить все программы её использовать. В зависимости от того, для чего производится идентификация, условия, при которых оня будет успешной, могут быть более или менее строгими, а если она прошла успешно, бывает нужно выполнить действия, связанные не с определением пользователя, а с настройкой системы.

В большинстве дистрибутивов PAM обучен схеме «. d», и настройки каждой службы, которая использует идентификацию, лежат в отдельном файле: 

[root@localhost root]# ls /etc/pam.d
 chpasswd           groupdel  other   system-auth                 userdel
 chpasswd-newusers  groupmod  passwd  system-auth-use_first_pass  usermod
 crond              login     sshd    user-group-mod
 groupadd           newusers  su      useradd

Пример 8. Подключаемые Модули Идентификации (PAM)

В PAM определено четыре случая, требующие идентифкации: auth — собственно идентификация, определние, тот ли пользователь, за кого он себя выдаёт, account — определение, всё ли хорошо с учётной записью пользователя, password — изменение пароля в учётной записи, и session — дополнительные действия непосредственно перед или непосредственно после того, как пользователь получит доступ к затребованной услуге. Эти значения принимает первое поле любого файла настройки из pam.d, а в третьем поле записывается модуль, который проверяет какой-нибудь из аспектов идентификации. Второе поле определяет, как успех или неуспех проверки одного модуля влияет на общий успех или неуспех идентификации данного типа (например, required означает, что в случае неуспеха модуля проверка пройдена не будет). Четвёртое и последующие поля отведены под параметры модуля.

[root@localhost root]# cat /etc/pam.d/login 
 auth     include        system-auth
 auth     required       pam_nologin.so
 account  include        system-auth
 password include        system-auth
 session  include        system-auth
 session  optional       pam_console.so
[root@localhost root]# cat /etc/pam.d/system-auth
 auth     required       pam_tcb.so shadow count=8 nullok
 account  required       pam_tcb.so shadow
 password required       pam_tcb.so use_authtok shadow count=8 write_to=tcb
 session  required       pam_tcb.so

Пример 9. Настройка PAM для login

Такие настройки login обнаружил Мефодий на своём компьютере. Во всех четырёх случаях используется включаемый файл system-auth (к нему обращаются и другие службы), с некоторыми дополнениями: во время идентификации pam_nologin.so дополнительно проверяет, не запрещено ли пользователям регистрироваться вообще (как это бывает за несколько минут до перезагрузки системы), а перед входом в систему и после выхода из неё pam_console.so выполняет описанную в лекции Права доступа «передачу прав на владение устройствами» (и, соответственно, лишение пользователя этих прав).

Каталог /etc/pam.d — замечательный пример того, как профиль определяет поведение системы. В частности, четыре первых строки из system-auth показывают, что в этом дистрибутиве используется не просто «теневой» файл паролей, а схема TCB, описанная в лекции Права доступа. (Как уже известно Мефодию, в этой схеме вместо общего для всех /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

Пример 10. Настройка системных журналов

В первом поле строки указываются профили сообщений, разделённые символом «;», а во втором — хранилище сообщений (файл, терминал, есть способы отдавать их на обработку программе и пересылать по сети). В примере в файл /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

Пример 11. Настройка cron

Первые пять полей этого файла определяют время запуска команды: минуту, час, число месяца, месяц и день недели. Символ «*» означает, что соответствующая часть даты не учитывается. Шестое поле — имя пользователя, от лица которого зпускаются команда, указанная в остальных полях строки. Так, в примере команда run-parts /etc/cron.weekly будет запускаться в 4 часа 22 минуты каждое воскресенье (нулевой день) любого числа любого месяца.

Как видно из примера, обычно /etc/crontab невелик: чаще всего он состоит из почасового, подённого, понедельного и помесячного запуска специального сценария (в примере — run-parts). Этот сценарии реализует упрощённую схему «. d», он попросту запускает отсортированные в лексикографическом порядке сценарии из соответствующего каталога (например, из /etc/cron.daily):

То есть в таком порядке, в котором они были бы расставлены в словаре. Причём цифры предшествуют алфавитным знакам, а между собой сортируются по возрастанию, от 0 до 9. Отсюда «000anacron» — такое имя обеспечит, чтобы этот сценарий был выполнен самым первым.

[root@localhost root]# ls /etc/cron.daily 
 000anacron  logrotate  makewhatis  osec  stmpclean  updatedb

Пример 12. Сценарии, запускаемые ежедневно

Вот что происходит каждый день на машине Мефодия: запуск 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 никогда не выполнится в четыре часа ночи) — или запускать отдельную службу, которая будет выполнять некоторые задачи не по расписанию, а потому что их давно уже пора запустить.

Название этого демона пародирует cron с намёком на анахронизм, то есть несвоевременность выполнения заданий.

Дополнительно anacron рассчитывает запуск задач так, чтобы не перегрузить компьютер работой, если их накопилось слишком много. Конфигурационный файл anacron называется /etc/anacrontab.

«Прокручивание» системных журналов

Ещё изучая работу syslog, Мефодий не расставался с мыслью, что файл, в котором записывается системный журнал, постоянно растёт. Это значит, что каков бы ни был размер файловой системы /var, она в конце концов заполнится журналами под завязку — если как-то их не укорачиваить. К сожалению, в Linux укоротить файл от начала, отрезав самые старые записи, нельзя, как нельзя и добавлять новые записи в начало файла. Эти операции легко реализовать с помощью копирования нужной области в новый файл и последующего переименования, но, во-первых, соблюсти атомарность таких составных операций нелегко, а во-вторых, они требуют удвоенного места в файловой системе на время работы (и, стало быть, каких-то аварийных процедур на случай нехватки места).

Поэтому в Linux принят другой, существенно менее ресурсоёмкий алгоритм, позволяющий избежать переполнения /var: т. н. «прокручивание» системных журналов. Суть алгоритма в следующем: когда настаёт пора укоротить журнал (например, раз в неделю или если файл журнала достиг определённого размера), этот файл переименовывают, и открывают новый пустой файл с тем же именем. Если хранить несколько (скажем, семь) переименованных старых файлов, с ними уже можно произвоить операцию «отбрасывния старого»: самый старый — седьмой — файл удаляется, шестой переименовывается в седьмой, пятый — в шестой, и т. д. до первого (моложе которого только текущий журнал), который переименовывается во второй. Только тогда можно переименовать текущий журнал в «первый старый», и открыть новый. Получается очередь устаревающих файлов, пополняемая с одной стороны и усекаемая с другой.

Как правило имя «первого старого» журнала получается добавлением к имени журнала суффикса «.1», второго — «.2» и т. д.: 

[root@localhost root]# ls -l /var/log/syslog/messages*
-rw-r-----  1 root adm 292654 Dec 15 14:01 /var/log/syslog/messages
-rw-r-----  1 root adm  34452 Dec 13 01:09 /var/log/syslog/messages.1.bz2
-rw-r-----  1 root adm  35892 Dec  6 09:38 /var/log/syslog/messages.2.bz2
-rw-r-----  1 root adm  60806 Nov 28 10:59 /var/log/syslog/messages.3.bz2
-rw-r-----  1 root adm  61063 Nov 21 10:47 /var/log/syslog/messages.4.bz2
-rw-r-----  1 root adm  60079 Nov 14 21:18 /var/log/syslog/messages.5.bz2

Пример 13. Системный журнал messages

Прокручиванием системных журналов занимается утилита logrotate, которая тоже управляется и конфигурационным файлом /etc/logrotate.conf и «. d»-каталогом /etc/logrotate.d/. Согласно настройкам, старые файлы можно сжимать упаковщиками bzip2 (как в примере) или gzip, можно задавать им определённые права доступа, можно посылать сигнал некоторой службе (чтобы она заметила подмену журнала, если она сама, а не syslogd занимается его пополнением) и т. п.

Перекрёстные ссылки книги для Системные конфигурационные файлы

  • Проектирование свойств системы
  • Вверх
  • Конфигурационные файлы в домашнем каталоге

Book navigation

  • Предисловие
  • Сеанс работы в Linux
  • Терминал и командная строка
  • Структура файловой системы
  • Работа с файловой системой
  • Доступ процессов к файлам и каталогам
  • Права доступа
  • Работа с текстовыми данными
  • Возможности командной оболочки
  • Текстовые редакторы
  • Этапы загрузки системы
  • Работа с внешними устройствами
  • Конфигурационные файлы
    • Проектирование свойств системы
    • Системные конфигурационные файлы
    • Конфигурационные файлы в домашнем каталоге
  • Управление пакетами
  • Сеть TCP/IP в Linux
  • Сетевые и серверные возможности
  • Графический интерфейс (X11)
  • Прикладные программы
  • Политика свободного лицензирования

Последние материалы

  • Эмулятор терминала Terminator
    1 hour 34 minutes ago
  • Приложение scanimage
    5 days 23 hours ago
  • Утилита sensors
    1 week 2 days ago
  • Сканер Rkhunter
    2 weeks 3 days ago
  • Программа resize2fs
    3 weeks 2 days ago
RSS feed

Secondary menu

  • О проекте

© 2008–2025 Олег Меньшенин mensh@yandex.ru