Управление пользователями. Команды su и sudo. Настройка X-сервера. Использование chroot.

Управление пользователями

Хранение регистрационной информации

Большая часть регистрационной информации о пользователях хранится в файле /etc/passwd. Этот файл доступен на чтение всем пользователям системы, поэтому сведения о паролях (заметим в скобках, что сами пароли вообще не хранятся открытым текстом), времени их жизни и некоторые другие данные из этого файла исключены и находятся либо в файле /etc/shadow (в большинстве дистрибутивов ОС Linux), либо в /etc/tcb/имя_пользователя/shadow (в дистрибутивах ПСПО и некоторых других). И в том, и в другом случае доступ к этой информации существенно ограничен с помощью механизма разграничения прав доступа в Unix-подобных ОС.

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

$ head /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
mail:x:8:12:mail:/var/spool/mail:/dev/null
news:x:9:13:news:/var/spool/news:/dev/null
uucp:x:10:14:uucp:/var/spool/uucp:/dev/null
games:x:12:100:games:/usr/games:/dev/null
ftp:x:14:50:FTP User:/var/ftp:/dev/null

Опишем в двух словах, что означает каждое поле.

  1. Первое поле в каждой строке содержит регистрационное имя пользователя.

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

  3. Третье поле --- это идентификатор пользователя (User ID, UID).

  4. Четвертое поле --- идентификатор основной (первичной) группы пользователя. Пользователь, разумеется, может входить и в другие группы, однако сведения об этом хранятся не здесь, а в файле /etc/group.

  5. Пятое поле по историческим причинам носит имя GECOS и содержит так называемое "полное имя" пользователя. Давным-давно создателям UNIX Кену Томпсону и Деннису Ритчи нужно было хранить информацию о том, какой пароль нужно использовать при регистрации в системе, к которой был подключен принтер. Управлялся доступ к принтеру операционной системой GECOS, поэтому именно такое название получило соответствующее поле в /etc/passwd. В наше же время в этом поле чаще всего хранится разнообразная дополнительная информация о пользователе: полное имя, номер комнаты, телефон и, возможно, что-либо еще. Соответствующие "подполя" при использовании такой структуры разделяются запятыми. Отметим, что такая возможность, однако, используется не слишком часто, и обычно в это поле заносят только настоящее имя пользователя.

  6. Шестое поле содержит имя домашнего каталога пользователя.
  7. Последнее, седьмое поле содержит имя программы, запускаемой в качестве пользовательской оболочки (Shell).

Сделаем следующее важное замечание. По значению седьмого поля в /etc/passwd зарегистрированных в системе учетные записи пользователей можно разделить на три группы.

  • Если в качестве оболочки указан один из интерпретаторов командной строки, перечисленных в файле /etc/shells, то пользователь считается "настоящим": он может "войти" в систему и полноценно ее использовать.

  • Если в качестве оболочки указано специальное значение /sbin/nologin (иногда --- другое), то пользователь не сможет зарегистрироваться в системе обычным способом (с помощью программы login). Тем не менее, если это значение указать в списке допустимых оболочек (/etc/shells), то все подсистемы будут считать, что соответствующий пользователь --- "настоящий", а потому разрешат, например, подключение по SSH без запуска оболочки.

  • Если же в качестве оболочки указано имя несуществующей программы или, скажем, /dev/null, то зарегистрироваться в системе (с помощью программы login) пользователь не сможет вовсе. Возможность заведения в системе таких пользователей позволяет контролировать разделение прав доступа к разным частям системы. Дело в том, что при работе различных служб разумно ограничить использование учетной записи суперпользователя, а потому для каждой такой службы заводится специальная учетная запись. С одной стороны, "по-настоящему" зарегистрироваться в системе с ее помощью невозможно (нет пароля и корректной пользовательской оболочки), с другой --- в случае атаки на эту службу под угрозой окажутся лишь ее собственные файлы. Соответствующих таким учетным записям пользователей обычно называют "псевдопользователями", или "системными пользователями". Псевдопользователей в системе бывает довольно много, обычно --- более 40 (это число зависит от набора установленных служб).

Посмотрим теперь в файл /etc/group. В нем содержится список зарегистрированных в системе групп пользователей. Каждый пользователь может состоять в нескольких группах, а каждая группа --- содержать несколько пользователей: 

$ head /etc/group
root:x:0:
bin:x:1:root
daemon:x:2:root
sys:x:3:root,bin,adm
adm:x:4:root
tty:x:5:
disk:x:6:root
lp:x:7:
mem:x:8:
kmem:x:9:

Сведения о членстве пользователей в группах оформляются следующим образом:

  1. Первое поле --- имя группы.

  2. Второе --- зашифрованный пароль группы (практически никогда не используется; x, как и для соответствующего поля в passwd, означает, что сведения находятся в другом месте).

  3. Третье поле --- числовой идентификатор группы.
  4. Четвертое поле --- имена пользователей --- членов группы (через запятую).

Опишем теперь, как используется информация о членстве в группах. Каждый раз, когда от имени пользователя запускается тот или иной процесс, автоматически выясняется его "первичная" группа (обычно она соответствует полученному при входе в систему GID), а членство в процесса в остальных группах определяется с помощью просмотра файла /etc/group. Этот файл просматривается в поисках регистрационного имени (не UID!) пользователя --- подходящие строки и определяют результат. Заметим, что можно создать в системе учетные записи разных пользователей с одинаковым UID и организовать для них членство в разных наборах групп. Пользоваться этой возможностью, однако, следует с большой осторожностью.

Управление учетными записями

Создадим нового пользователя. Зададим ему регистрационное имя admin и "описание" Newly Added Admin (оно будет занесено в поле GECOS): 

# usearadd -G wheel -c "Newly Added Admin" admin

Ключ -G отвечает за список "дополнительных" групп, в которые создаваемый пользователь вступает (в данном случае это группа wheel). Поскольку мы не указали ключ -g, то была создана также основная группа для нашего пользователя. Ее имя совпадает с именем пользователя (admin), а идентификатор выбирается первый из доступных (свободных). Точно так же, поскольку мы не указали ключ -u, то и идентификатор пользователя выбирается первый из доступных. Отметим, что нельзя предполагать, что идентификаторы создаваемых пользователя и группы обязательно совпадут.

Сделаем еще одно важное замечание. В современных дистрибутивах ОС Linux принято создавать для каждого "настоящего" пользователя отдельную группу, а все группы с более чем одним пользователем считать "дополнительными". Это даёт некоторые преимущества всмысле безопасности и возможность по числу строк в /etc/passwd оценивать количество пользователей.

Посмотрим, как при добавлении пользователя изменились файлы /etc/passwd и /etc/group: 

$ grep admin /etc/passwd /etc/group
/etc/passwd:admin:x:501:501:Newly Added Admin:/home/admin:/bin/bash
/etc/group:wheel:x:10:root,user,admin
/etc/group:ftpadmin:x:51:
/etc/group:cvsadmin:x:53:
/etc/group:netadmin:x:104:
/etc/group:wineadmin:x:57:
/etc/group:admin:x:501:

Как мы видим, в /etc/passwd появилась новая запись для нашего пользователя (UID = 501), а в /etc/group была создана новая группа (GID = 501). Кроме того, в соответствии с нашим указанием пользователь admin был добавлен в группу wheel. Отметим, что при заведении пользователя был также создан его домашний каталог, куда сразу же скопировались файлы из каталога /etc/skel. Данный каталог обыкновенно содержит минимальный, "базовый" набор конфигурационных файлов для создания комфортного пользовательского окружения и, естественно, может быть модифицирован администратором системы.

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

$ id admin
uid=501(admin) gid=501(admin) groups=501(admin),10(wheel)

Уделим теперь внимание проблеме удаления пользователей из системы. За выполнение этого действия отвечает утилита userdel, манипулирующая перечисленными выше файлами. У этой утилиты есть ключ -r, соответствующий удалению не только учетной записи пользователя, но и его домашнего каталога и почты (обычно лежащей в каталоге /var/mail). Однако всегда ли оправдано использование userdel? Работа этой утилиты приводит к освобождению идентификатора пользователя (UID), который впоследствии может быть присвоен другому, вновь созданному пользователю. Это приведет к тому, что все не удаленные из системы пользовательские данные (к примеру, содержащиеся в сохранившемся на диске домашнем каталоге) окажутся доступны новому пользователю. Понятно, что такой результат, вообще говоря, не может считаться удовлетворительным.

Как же стоит поступить в такой ситуации? Одним из решений может стать запрет на вход (логин) вместо удаления. За такое действие отвечает команда passwd(8) с ключом -l (--lock) (то же самое можно сделать при помощи usermod -L). Стоит, однако, обратить внимание, что в такой ситуации не исключается возможность входа по SSH (например, если в конфигурационном файле sshd_config отключена опция UseLogin). Разумеется, заблокированного таким способом пользователя можно впоследствии разблокировать.

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

Управление паролями

Скажем несколько слов и о пользовательских паролях. При заведении пользователей с помощью useradd пароли не создаются, поэтому, чтобы обеспечить возможность входа в систему, нужно создать (вообще говоря, сменить) пароль. Проще всего это сделать с помощью команды passwd. Заметим, что в дистрибутивах ПСПО ALT Linux существуют две утилиты с таким именем: пользовательская из /usr/bin и администраторская из /usr/sbin. Первая позволяет любому пользователю системы сменить пароль на свою учетную запись, а второй мы сейчас воспользуемся для задания пароля созданному нами пользователю admin.

Отметим, что пароль на вход команды passwd можно задать разными способами. Первый способ --- задать пароль интерактивно (с клавиатуры, по запросу самой утилиты), второй --- воспользоваться ключом -p и задать в командной строке хэш пароля. Остановимся на втором способе чуть подробнее.

Чтобы получить возможность получить BlowFish-хэш (значение именно такой функции используется для хранения паролей в дистрибутивах ПСПО), можно написать специальную программу на языке C, использующую функцию стандартной библиотеки crypt(3), а можно воспользоваться средствами Python. Пойдем по второму пути и установим пакет с модулем bcrypt: 

# apt-get install python-module-bcrypt

Теперь можно воспользовать двумя нужными нам функциями из этого модуля. Первая из них --- gensalt, генерирующая salt для пароля, вторая --- hashpw, возвращающая хэш по заданным паролю и salt'у. Простейший вариант совместного использования этих функций выглядит так: 

$ python -c 'import bcrypt; print bcrypt.hashpw("mypassword", bcrypt.gensalt(8))'
$2a$08$FxyUan62aD2P9rWSJzEcdO1JApy8m/YHYDaHbgCiKVZAykI/XdoOC

Именно полученный таким способом хэш и задается в качестве параметра командной строки утилиты passwd (после ключа -p).

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

Покажем, как работает упомянутая нами утилита pwgen. Вначале установим соответствующий пакет: 

# apt-get install pwgen

А теперь просто дадим команду pwgen: 

$ pwgen
oi1Sieg1 Coovah3o chi1Et7t zei0Ub0A aeQua4Sh Oyei6aij aebe3Eod uafai1Pa
vu1AiFiu Phe4Eep5 aZiesh4o pheeBi2a Ahvo5cu8 Jei9Efae giK2aide Nohf6bah
Gi2heira eis7te6Z rai4eeSh GeeK9ui5 aesh6Ud6 nuiCe5im aphai8oX oChoo9Sh
UChek0He akei6Ien Reib8ahk xooJ3sai vaeL7miu up4saeSo wiith9Es choD7iex
pheV2ohf ahY0ooCh uekohv9A ood8Awae ekaiHah9 Chif5toH iF4ga1es ePhah0Ai
jaiShee7 Asa6GeeB iezou1Do bie7eeRe Luxieng3 keiZee5A Pach3Voo Iish5Wie
aiv5ra5O Quahgo8s deeXae2f ohVa7OhD pieh8aeH HahGhae6 eebai6Je iZooch9I
Bub7pee1 ep9NaPhe Bahveiv5 Eechee8g Wae6jogh Uch8eoxe Mokaet2t ech7OeKa
Aingeew8 zub1ohSo koTae2ek dohn1Ahk Ceim8Foo cee9eeTh UGho4nah Cho4aiTh
shiwee8I faecie0S aKaa8uen iezei6Qu EeHiiha7 Eexiech6 muWea6du ReeYi2he
vei7aiCe aiDohj0o iuSaum3f ca2queeL quaek1Ca ai5Iu3aC ieWe5We6 Cohk3ei9
mo1SeiG8 XeeN7aej GooTh0fa tie5TaeJ bah9ooSh nah2Dai7 aiCe0oeW Bah8Zuye
yohv5Eet aegie5Uz iZie6ca6 iw4Jaib4 oGhee9ie taexoe5A eeY6iehu ibaew6Vu
xie2Ieh8 eihe6eTa ooMe0oga ahli6eB7 ba2eaRah om7eiT2i Ie8shiWe Uiya3eew
Kai9ni2d Shoh2ePh EiZ4fe9Z ieSeipo0 ahxoi5Ee uNochae9 JooXo5uu BareiV0x
aa4Ishi2 jae9ohXa AeFo7Tha Zohthoo1 Ua4eeTho zo9Oa0Ph caiN7zeb bueZ2the
eelui6Ue joo8Baat phee8Tae ieQue4th eiya7eiJ ahGo7tho usoh7AhK mee9Fiec
au7Oow6u ohn8ohJu phij8Toh aigi1EiZ oZahmah0 quooGae3 Quaej7tu Ceexu7da
Quae4huz hoPhei6s Ahp3oopu aeGh7heg sah7ahMa ahCh0iit eiquae2A eixae7Uc
ingahCh5 Yai7ohve ohC3quee joth3Bay voyai8Bo shuNgoo3 wai5Kaiv ieJah3Ei

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

Управление группами

Отметим, что при создании нашего пользователя admin мы выбрали для него лишь одну дополнительную группу --- wheel. Было бы полезным, однако, добавить его и в другие группы. Зачем это может понадобиться? Дело в том, что при работе, например, с пользовательским десктопом, полезно выдавать первому "вошедшему" доступ к таким ресурсам, как съемные диски, аудиоустройства и пр. Такие действия обычно производятся специальным модулем PAM, меняющим права к соответствующему набору файлов из каталога /dev. В нашем случае таких файлов оказалось довольно много (более двух десятков): 

$ ls -l /dev/ | grep user
crw-rw---- 1 user  audio   14,   12 Jul 31  2008 adsp
crw-rw---- 1 user  audio   14,    4 Jul 31  2008 audio
crw------- 1 user  root     5,    1 Jul 31 14:07 console
crw-rw---- 1 user  audio   14,   25 Jul 31  2008 dmmidi1
crw-rw---- 1 user  audio   14,    3 Jul 31  2008 dsp
crw------- 1 user  root    29,    0 Jul 31  2008 fb0
brw-rw---- 1 user  floppy   2,    0 Jul 31  2008 fd0
brw-rw---- 1 user  floppy   2,   84 Jul 31  2008 fd0u1040
brw-rw---- 1 user  floppy   2,   88 Jul 31  2008 fd0u1120
brw-rw---- 1 user  floppy   2,   28 Jul 31  2008 fd0u1440
brw-rw---- 1 user  floppy   2,  124 Jul 31  2008 fd0u1600
brw-rw---- 1 user  floppy   2,   44 Jul 31  2008 fd0u1680
brw-rw---- 1 user  floppy   2,   60 Jul 31  2008 fd0u1722
brw-rw---- 1 user  floppy   2,   76 Jul 31  2008 fd0u1743
brw-rw---- 1 user  floppy   2,   96 Jul 31  2008 fd0u1760
brw-rw---- 1 user  floppy   2,  116 Jul 31  2008 fd0u1840
brw-rw---- 1 user  floppy   2,  100 Jul 31  2008 fd0u1920
brw-rw---- 1 user  floppy   2,   12 Jul 31  2008 fd0u360
brw-rw---- 1 user  floppy   2,   16 Jul 31  2008 fd0u720
brw-rw---- 1 user  floppy   2,  120 Jul 31  2008 fd0u800
brw-rw---- 1 user  floppy   2,   52 Jul 31  2008 fd0u820
brw-rw---- 1 user  floppy   2,   68 Jul 31  2008 fd0u830
srwx------ 1 user  root           0 Jul 31 14:07 gpmctl
brw-r----- 1 user  cdrom   22,    0 Jul 31  2008 hdc
crw-rw---- 1 user  audio   14,   18 Jul 31  2008 midi1
crw-rw---- 1 user  audio   14,    0 Jul 31  2008 mixer
crw-rw---- 1 user  audio   14,   16 Jul 31  2008 mixer1
crw-rw---- 1 user  audio   14,    1 Jul 31  2008 sequencer
crw-rw---- 1 user  audio   14,    8 Jul 31  2008 sequencer2

Какое отношение это имеет к группам? Оказывается, смена UID файлам устройств удобна далеко не всегда. Во многих случаях разумнее передавать права на такие файлы не одному пользователю, а целой группе, что дает возможность настроить права доступа "заранее". В том же /dev, как несложно заметить, есть большое количество файлов, принадлежащим не группе root или wheel, а группе audio, floppy и пр. Для того, чтобы пользователи имели доступ к этим файлам, и нужно включать их в соответствующие группы: 

$ id user
uid=500(user) gid=500(user) groups=500(user),10(wheel),14(uucp),19(proc),22(cdrom),71(floppy),80(cdwriter),81(audio),83(radio),119(xgrp),422(camera),423(scanner)

Как же добавить пользователя в ту или иную группу? В стандарте POSIX добавление пользователя в группу (равно как и удаление его оттуда) не реализовывалось какой-либо конкретной утилитой. Предполагалось, что соответствующие действия будут производиться системным администратором путем непосредственного редактирования файла /etc/group. Была (и, разумеется, никуда не исчезла) также возможность использования утилиты usermod с ключом -G, который требует явного указания полного списка групп, в которых должен состоять пользователь. Понятно, однако, что если пользователь уже являлся членом десяти групп, то для добавления его в одиннадцатую вначале нужно было получить список первых десяти и только потом добавить к ним одиннадцатую. Такая операция, очевидно, не атомарна, а потому в дистрибутивах ALT Linux предусмотрена команда gpasswd: 

# gpasswd -a admin proc
Adding user admin to group proc

Как видим, ее использование позволяет избежать описанных проблем. Проверим результат: 

$ id admin
uid=501(admin) gid=501(admin) groups=501(admin),10(wheel),19(proc)

Include: Nothing found for "^== Использвание su и sudo ==$"!

Использвание su и sudo

Использование su и sudo

Иногда системному администратору необходимо совершать действия от лица суперпользователя. Заходить под учётной записью root в программе login не рекомендуется, обычно этот метод используется в крайних случаях, когда другие варианты невозможны. Предпочтительней получать привилегии суперпользователя во время сеанса работы из под учётной записи обычного пользователя. На системном уровне подобная схема реализуется с помощью механизма setuid. Команд, способных предоставить обычному пользователю права суперпользователя, две --- su и sudo.

su

Команда su (switch user) позволяет получить права любого пользователя, при условии, что вам известен пароль этого пользователя.

Существует 4 режима работы su:

  • restricted --- выполнять su имеет право только root;

  • wheel --- выполнять su имеют право только пользователи, входящие в группу wheel;

  • wheelonly --- использовать su могут все, но лишь пользователи, входящие в группу wheel, могут получать с её помощью права суперпользователя;

  • public --- ограничения отсутствуют, любой пользователь может с использованием su получить права любого другого пользователя.

В ALTLinux команда su, выполненная без параметров, дает права суперпользователя, не меняя при этом окружения. Чтобы изменить окружение, то есть запустить login shell, необходимо использовать su -.

Login shell

Когда пользователь начинает сеанс работы с системой, в первую очередь запускается командный интерпетатор, указанный в /etc/passwd. Если для входа в систему и работы используется графический интерфейс в качестве основного, то кроме запуска самого командного интерпретатора, в нем выполняются скрипты инициализации графической сессии. Процесс этого командного интерпретатора отличается от процессов других шеллов, запущенных пользователем. Этот процесс называют login shell. В списке процессов к его имени в начале приписывается -. Login shell выполняет определённые дополнительные действия, например, устанавливает переменные окружения UID и GID.

sudo

Команда sudo обладает более широкими возможностями, чем su. Она позволяет уточнять, какие категории пользователей могут пользоваться учётными записями каких пользователей, а также ограничивать список команд, которые могут исполняться таким образом. Например, можно использовать sudo для разрешения монтирования cdrom некоторому пользователю.

По умолчанию sudo сохраняет окружение пользователя, но это поведение можно изменить (таким образом можно реализовать запуск X-приложений от учётной записи root).

/etc/sudoers

/etc/sudoers --- конфигурационный файл для sudo. Редактируется этот файл командой visudo. Будучи запущенной без каких-либо предварительных действий, эта команда откроет /etc/sudoers в редакторе vi. Для изменения используемого редактора необходимо указать желаемый редактор в переменной окружения EDITOR.

В этом файле задаются пользователи, группы пользователей, команды, которые они могут выполнять, и прочие ограничения. Синтаксис /etc/sudoers подробно описан при помощи EBNF в man sudoers.

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

%admin ALL=(ALL) ALL

Символ % означает, что admin --- название группы, а не имя пользователя.

Настройка X-сервера

Структура X-сервера

Архитектура

Графическая подсистема ПСПО базируется на комплекте программных продуктов Xorg. Поверх Xorg запускается несколько приложений, необходимых для организации "рабочего стола". Взаимодействие между всеми программами Xorg описывается протоколом x.11, поэтому эту подсистему принято также называть X11 или, в разговоре, "иксами".

Xorg имеет клиент-серверную архитектуру. X-Сервер -- это программа, которая имеет доступ к устройствам графического ввода (клавиатура, мышь) и вывода (графическая карта). По протоколу X11 сервер передаёт сообщения об активности мыши и клавиатуры другим программам -- X-клиентам, а также принимает от них запросы, как правило, что-либо нарисовать, вывести текст и т .п.

X-сервер и X-клиент вполне могут находиться на разных машинах: X-сервер -- на машине пользователя, а X-клиент -- где угодно. Принимать X-запросы от любых машин в сети небезопасно, поэтому это свойство в ПСПО отключено: сервер запускается с ключом -nolisten tcp (задаётся в файле /etc/sysconfig/xserver). На рабочей станции такое подключение смысла всё равно не имеет. Есть исключение: "Линукс Терминал", целиком построенный на том, что пользовательские машины запускают только X-серверы, а вся работа ведётся на центральном компьютере посредством X11.

Интерфейс

Окно. Понятие "окно", на самом деле, сильно сужает варианты использования графического интерфейса, однако осмысленных альтернатив "оконному" подходу пока не придумано. Каждое приложение регистрирует у X-сервера один или несколько прямоугольников -- окон. Внутри этого прямоугольника приложение имеет возможность рисовать фигуры, выводить текст и т. п. События -- нажатие клавиш на клавиатуре, перемещение мыши и нажатие кнопок на ней -- также считаются происходящими "на территории" окна. Для того, чтобы выяснить, какому именно окну предназначалось событие, используется синтетическое понятие -- фокус. Каждый раз не более одного окна может быть "в фокусе", именно этому окну направляются события. По умолчанию X-сервер передаёт фокус окну, над которым находится графический указатель мыши, но этот порядок может изменить некоторый X-клиент, принимая все события на себя и "раздавая" их по своему усмотрению. Прямоугольники могут накладываться друг на друга, образуя "стопку". Тем самым вводится понятие глубины окна: полностью видимо окно с наименьшей глубиной, окна под ним загораживаются вышележащими. Глубина окна учитывается и при передаче ему фокуса.

Диспетчер окон. X-клиент, в обязанности которого входит передавать другим X-клиентам фокус по своему усмотрению, называется диспетчером окон (окноводом). Диспетчер выполняет всю работу по управлению окнами: передаёт фокус, позволяет перемещать окна, изменять их размер и глубину, скрывать, превращать в иконки и многое другое. Все эти действия производит, разумеется, X-сервер, а диспетчер подаёт ему соответствующие команды. Для удобства управления диспетчер обычно пририсовывает к окнам декораторы: красивую рамочку, заголовок, кнопки и т. п. Сами приложения также могут посылать серверу соответствующие команды, однако заставлять каждый X-клиент заниматься управлением собственным окном было бы неразумно. С другой стороны, неправильно заставлять X-сервер заниматься управлением окнами самостоятельно: это привело бы к потере свободы выбора. На сегодня существуют десятки различных окноводов, каждый из них реализует свою собственную концепцию управления окнами и их оформления в соответствии с требованиями "рабочего стола".

В "Лёгком Линуксе" используется графическая среда XFCE, в состав которой входит диспетчер xfwm, а в "Юниоре", "Мастере" и "Терминале" -- KDE и диспетчер kwin.

Рабочий стол

Для реализации метафоры "рабочего стола" недостаточно управлять одними только окнами. Удобного интерфейса требует управление виртуальными экранами, быстрый запуск приложений, доступ к документам, отображение меняющейся информации и многое другое. Всевозможные интерфейсные примитивы: меню, панели, лотки и прочее диспетчер окон может на себя и не брать, этим в "больших" окружениях, вроде KDE, занимается целый комплект программ, дополняемый службой передачи сообщений, более сложных, чем X11, собственной интерфейсной библиотекой и многим другим. Настройка рабочего стола обсуждается в другом месте, здесь важно понять, что "настройка X-сервера" -- это другое, достаточно низкоуровневое действие, требующее некоторой квалификации.

Настройка графической среды

Использование Alterator

Запустим Центр Управления системой (он же Alterator)

../acc.png

Сам Alterator -- это некий графический интерфейс к набору утилит, диагностирующих и настраивающих ту или иную часть системы. В частности, пункт "Графический интерфейс -> Дисплей" отвечает за определение параметров видеокарты и монитора, и за внесение изменений в настройки Xorg.

../acc_display.png

Надпись "Монитор 1024х768" -- это не планируемое разрешение, а некий тип монитора по умолчанию. Такой тип который используется, если нет конкретных данных о мониторе, кроме того, что он, очевидно, поддерживает разрешение 1024 на 768 точек. Есть мониторы, о которых такие данные есть; кроме того, такие данные содержатся в т. н. "драйвере монитора", который представляет собою просто текстовый файл. Данные из этого файла можно использовать для ручной настройки Xorg.

Другие настройки достаточно очевидны. "Драйвер" -- это драйвер видеокарты; он определяется автоматически, и изменять это значение стоит только если что-то не работает (в этом случае стоит попробовать стандартный драйвер "vesa"), либо при ывборе между свободной и несвбодной реализацией драйверов AMD/ATI и nVidia. Можно также изменить планируемую глубину цветности (bits per pixel) и разрешение экрана в точках.

Файл xorg.conf

Рассмотрим содержание файла xorg.conf, расположенного в /etc/X11. Он состоит из секций, каждая секция описывает параметры какого-либо устройства, комплектацию или структуру сервера, пользующегося этими устройствами. В секции может встречаться поле "Identifier", на которое могут ссылаться другие секции.

  • Головная секция -- ServerLayout, она задаёт "рабочее место": мышь и клавиатуру, которыми пользователь пользуется и экран (Screen), на который он смотрит: 

    Section "ServerLayout"
        Identifier     "Minimal layout"
        Screen         "Screen0" 0 0
        InputDevice    "Keyboard0" "CoreKeyboard"
        InputDevice    "ImPS/2 Logitech Wheel Mouse|0" "CorePointer"
EndSection
  • Секция загрузки модулей Module определяет, какие расширения X11 необходимо дополнительно загрузить: 
    Section "Module"
        Load  "type1"
        Load  "freetype"
        Load  "glx"
        Load  "dri"
        Load  "dbe"
        SubSection "extmod"
                Option      "omit xfree86-dga"
        EndSubSection
EndSection
    Здесь type1 -- поддержка шрифтов "Type 1", freetype -- поддержка шрифтов "Truetype", glx -- трехмерная графика, dri -- графическое ускорение, dbe -- работа с памятью. Подсекция "extmod" отвечает за загрузку модуля с целым спектром расширений X11 и их настройку.

  • Секция ServerFlags: 

    Section "ServerFlags"
        Option      "AllowMouseOpenFail" "true"
EndSection

    Опция AllowMouseOpenFail позволяет серверу грузиться, даже если мышь не работает. Графическим указателем можно управлять с клавиатуры (нажать сочетание shift+numlock, а потом использовать клавиши на цифровой клавиатуре для перемещения мыши).

  • Секции InputDevice: 

    Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "kbd"
EndSection

    Эта часть отвечает за драйвер клавиатуры -- kbd. В настоящее время эта секция используется не столь активно, как раньше, так есть возможность изменять настройки клавиатуры из командной строки, с помощью setxkbmap. Например, если в Центре управления ("Графический интерфейс -> Настройка клавиатуры") выбрать тип "клавиатура acpi", начнут распознаваться три стандартные кнопки ACPI (Power, Sleep. Wake). Результат запишется не в xorg.conf, а в файл /etc/X11/xinit/Xkbmap, используемый при старте сеанса работы с X-сервером. 

    Section "InputDevice"
        Identifier  "ImPS/2 Logitech Wheel Mouse|0"
        Driver      "mouse"
        Option      "Device" "/dev/input/mice"
        Option      "Protocol" "IMPS/2"
        Option      "ZAxisMapping" "4 5"
EndSection

    Это параметры мыши. Стоит отметить, последнюю опцию -- !ZAxisMapping. Мало кто помнит, что поворот колеса мыши -- это "перемещение по оси Z". Это перемещение почти никто не использует, поэтому поворот колеса принято преобразовывать в нажатия кнопок 4 и 5. Также обстоит дело и с другими частями мыши. В результате может оказаться, что помимо первых трёх (стандартных кнопок) на вашей мыши имеется ещё четыре, причём номерам 4 и 5 соответствует не колесо, а две кнопки сбоку. Тогда необходимо запустить xev и выяснить, какая кнопка какой номер имеет, а затем использовать нечто похожее на xmodmap -e "pointer = 1 2 3 6 7 4 5".

  • Секция Monitor -- параметры монитора: 
    Section "Monitor"
        Identifier   "Monitor 1024x768|0"
        HorizSync    31.5 - 57.0
        VertRefresh  50.0 - 70.0
EndSection
    В таком виде формирует эту секцию модуль Центра управления. Первая строчка -- это название, вторая и третья -- допустимые диапазоны частоты строк и частоты кадров. Частота кадров больше 60 считается безопасной для зрения, а больше 85 -- достаточно удобной (эргономичной). Такие параметры соответствуют довольно старому монитору (что видно из названия), зато будут стопроцентно работать практически везде. Для более современных мониторов имеются стандарты DDC и EDID, позволяющие X-серверу получать более полную информацию непосредственно при запуске, поэтому в этой секции можно оставить один только Identifier. Однако дешёвые модели мониторов могут работать с DDC/EDID плоховато.
  • Секция Device -- параметры устройства: 
    Section "Device"
        Identifier  "Card0|0"
        Driver      "intel"
EndSection
    • Этот раздел отвечает за видеокарты. Здесь может быть много разных настроек, которые описаны в соответствующей странице руководства. Например, существуют реализации аппаратного трехмерного ускорения, хорошо работающие на одних картах, и плохо -- на других, по умолчанию они выключены, но можно и включить. Здесь же можно управлять режимом работы "двухголовой" карточки. Эта секция заполняется пунктом "Драйвер" в соответствующем модуле Центра управления.
  • Секция Screen -- режим работы видеокарты: 
    Section "Screen"
        Identifier "Screen0"
        Device     "Card0|0"
        Monitor    "Monitor 1024x768|0"
        DefaultDepth     16
        SubSection "Display"
                Depth     8
    Modes "1024x788" "800x600"
        EndSubSection
        SubSection "Display"
                Depth     15
        EndSubSection
        SubSection "Display"
                Depth     16
        EndSubSection
        SubSection "Display"
                Depth     24
        EndSubSection
        SubSection "Display"
                Depth     32
        EndSubSection
EndSection

    • Секция описывает режимы работы видеокарты для различных вариантов глубины цветности. В ней связывается конкретный монитор с конкретным графическим устройством. Поскольку параметры того и другого Xorg умеет неплохо определять и сам, никаких особенных настроек, кроме цветности по умолчанию, здесь нет. В подсекции "Display" может встречаться поле "Modes", задающее список режимов работы видеокарты. Строчки "1024x788" и "800x600" -- это именно названия режимов, а не строгое указание поддерживаемого разрешения. Автоматически определяемые режимы работы карточки обычно имеют такие значащие имена.

    Следует отличать виртуальный размер экрана (может быть вписан как значение поля Virtual) и физическое разрешение монитора. Они необязательно совпадают. Если видеокарта позволяет, то виртуальный размер экрана можно поставить намного больше реального. Тогда будет видна только часть экрана, которую можно перемещать, подводя мышь к краю экрана. В большинстве случаев переключаться между разными режимами (если их много) можно с использованием ctrl alt +, ctrl alt -, при этом виртуальный размер экрана остаётся прежним, а разрешение меняется.

  • Секция DRI -- прямой доступ к видеопамяти: 
    Section "DRI"
        Group        "xgrp"
        Mode         0660
EndSection

    Указывает права доступа к устройству, посредством которого X-сервер получает доступ к видеопамяти (обычно /dev/dri/card0).

ModeLine

Режимы работы монитора задаются в секции Monitor параметром Mode (полная форма) или ModeLine (краткая форма записи, в одну строку), которого по умолчанию в xorg.conf нет. Добыть ModeLine, используемые X-сервером, можно в журнале запуска X-сервера: 

$ grep -i modeline /var/log/Xorg.0.log
(II) NV(0): Printing DDC gathered Modelines:
. . .
(II) NV(0): Modeline "1024x768"  75.00  1024 1048 1184 1328  768 771 777 806 -hsync -vsync (56.5 kHz)
(II) NV(0): Modeline "1024x768"  65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
(II) NV(0): Modeline "1024x768"  78.75  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.0 kHz)
(II) NV(0): Modeline "832x624"   57.28  832 864 928 1152  624 625 628 667 -hsync -vsync (49.7 kHz)
(II) NV(0): Modeline "800x600"   50.00  800 856 976 1040  600 637 643 666 +hsync +vsync (48.1 kHz)
(II) NV(0): Modeline "800x600"   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
(II) NV(0): Modeline "800x600"   36.00  800 824 896 1024  600 601 603 625 +hsync +vsync (35.2 kHz)
. . .

Различные драйверы видеокарт (например, nvidia) могут создавать журнал по различным правилам, не всегда достаточно простого поиска слова "Modeline". Некоторые найденные режимы драйвер не использует, так как данный графический адаптер на данном мониторе их воспроизвести не в состоянии.

Для того, чтобы понять, что это за числа, необходимо в первом приближении понять, как работает электронно-лучевая трубка. В ЭЛТ имеется т. н. "пушка", которая может стрелять электронами. Место экрана, в которое попал электрон, недолго светится. Электрон в полёте отклоняется по вертикали и горизонтали. Итак пушка стреляет электронами с некоторой частотой, и они отклоняются таким образом, что первый "выстрел" попадает, допустим, в левый верхний угол экрана, второй -- в соседний справа пиксель, третий -- справа от второго и т. д. Дойдя до края экрана, "прицел луча" возвращается к началу и смещается на один пиксель вниз. Дойдя таким образом до правой нижней точки экрана, луч идёт обратно в левый верхний угол. Всё время обратного хода нарисованный кадр медленно гаснет. Затем процесс повторяется: рисуется следующий кадр.

../CRT.flat.png

Начальная и конечная часть "строки", по которой пробегает луч, -- невидимые. Невидимы могут быть также несколько первых и последних строк, Кроме того, какое-то время затрачивается на "обратных ход луча" по строкам и по кадру. В действительности всё намного сложнее, да и электронно-лучевых мониторов сегодня почти не выпускают, однако приведённая метафора вполне годится для толкования настроек Xorg.

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

Первый параметр -- т. н. "pixel clock" (количество миллионов пикселей в секунду, которое может выдавать видеокарта и отображать монитор). Минимальное и максимальное значение этого параметра для различных карт и мониторов различны; к тому же некоторые карты и мониторы имеют только фиксированный список допустимых частот.

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

../CRT.Cylinder.png

Если всё мерить в пикселях, экран следует представлять себе в виде тора, в котором по замкнутой спирали бегает луч. Часть этой спирали соответствует картинке, часть -- невидимой составляющей и часть -- обратному ходу луча. Для простоты разрежем этот тор, превраитв его в цилиндр. Отсчёт начинается с первого видимого пикселя. Второй параметр Modeline -- ширина видимой части строки. Третий -- конец завершающей невидимой части (время начала "синхронизации", то есть обратного хода луча), четвёртый -- конец обратного хода луча и начало стартовой невидимой части новой строки, пятый -- общий диаметр одного витка спирали (то есть время на показ одной строки целиком). Параметры с шестого по девятый описывают те же характеристики для строк в кадре.

Последний параметр -- особенности настройки режима. Более полную информациюрежимах можно найти, например, в руководстве XF86vidmodemodmodeline(3). Учебник по Modeline можно найти здесь: http://easymamecab.mameworld.net/html/monitor1.htm .

В Xorg есть утилита xvidtune, позволяющая настроить видеорежим и сконструировать соответствующий Modeline:

../xvidtune.png

При нажатии кнопки "Show" выведется самый настоящий Modeline: 

$ xvidtune          
Vendor: (null), Model: (null)
Num hsync: 1, Num vsync: 1
hsync range 0:  31.00 -  81.00
vsync range 0:  56.00 -  75.00
"1024x768"     75.00 1024 1048 1184 1328    768 771 777 806    +hsync +vsync

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

Переключать графические режимы можно также с помощью команды xrandr: 

$ xrandr 
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 1024 x 768
VGA connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1024x768       70.1*    60.0  
   832x624        74.6  
   800x600        72.2     75.0     60.3     56.2  
   640x480        75.0     72.8     75.0     63.1  
$ xrandr -s 832x624

Эта команда изменит разрешение на 832 на 624 точки.

Обработка X-событий

Для того, чтобы понять, какие именно события посылает устройство графического ввода (например, мышь при нажатии на светящуюся кнопку сбоку или клавиатура при нажатии на кнопку с нарисованной луной), можно запустить специальную программу-монитор xev:

../xev.png

Если нажать какую-то клавишу, то результатом будут сообщения о нажатии и отпускании кнопки такого вида (нажимаем кнопку с луной): 

$ xev
. . .
KeyPress event, serial 30, synthetic NO, window 0x1800001,
    root 0x1a6, subw 0x1800002, time 17925583, (28,48), root:(159,206),
    state 0x0, keycode 223 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 30, synthetic NO, window 0x1800001,
    root 0x1a6, subw 0x1800002, time 17925695, (28,48), root:(159,206),
    state 0x0, keycode 223 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False
. . .

Если подвигать мышью, то получим: 

MotionNotify event, serial 31, synthetic NO, window 0x2a00001,
    root 0x59, subw 0x0, time 2034286347, (52,96), root:(475,382),
    state 0x0, is_hint 0, same_screen YES

MotionNotify event, serial 31, synthetic NO, window 0x2a00001,
    root 0x59, subw 0x0, time 2034286355, (54,95), root:(477,381),
    state 0x0, is_hint 0, same_screen YES

MotionNotify event, serial 31, synthetic NO, window 0x2a00001,
    root 0x59, subw 0x0, time 2034286390, (55,94), root:(478,380),
    state 0x0, is_hint 0, same_screen YES
. . .

Есть программа xbindkeys, которая позволяет привязать произвольное действие к нажатию произвольной клавиши или кнопки мыши: 

$ xbindkeys
Error : /home/user/.xbindkeysrc not found or reading not allowed.
please, create one with 'xbindkeys --defaults > /home/user/.xbindkeysrc'
$ xbindkeys --defaults > ~/.xbindkeysrc
$ xbindkeys -s   
"xbindkeys_show"
    Control+Shift + q
"xterm"
    m:0x4 + c:41
    Control + f
"xterm"
    m:0x4 + b:2   (mouse)

Такие значения по умолчанию нас не устраивают, попробуем перенастроить запуск xterm на кнопку с луной: 

$ xbindkeys -k
Press combination of keys or/and click under the window.
You can use one of the two lines after "NoCommand"
in $HOME/.xbindkeysrc to bind a key.
"(Scheme function)"
    m:0x0 + c:223
    NoSymbol
$ echo '       
"xterm"
  m:0x0 + c:223
' > .xbindkeysrc
$ xbindkeys

Использование chroot

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

В качестве примера рассмотрим DNS-сервер --- BIND. Уязвимости в BIND встречаются не очень часто, но получить информацию о них вовремя (заранее) и бесплатно невозможно. Таким образом, BIND потенциально опасен. В документации обычно предполагается, что конфигурационные файлы BIND размещены в /etc и /var. В ALTLinux часть конфигурационных файлов расположена в других каталогах. Естественно, все необходимые для работы каталоги включаются в изолированное окружение, в котором запускается приложение. Корневым каталогом для BIND в ALTLinux является /var/lib/bind. Все файлы, необходимые для полноценной работы DNS сервера, находятся в /var/lib/bind. Так как BIND запускается из обычного окружения, и сначала загружает динамические библиотеки, а затем самостоятельно вызывает chroot, необходимость помещать библиотеки в изолированное окружение отсутствует.

Настройка DNS

Как рассказывалось ранее, DNS служит для преобразования символьных имен в IP-адреса и обратно. DNS имеет иерархическую структуру. У каждой зоны есть свой DNS-сервер, кроме того, в каждой сети должна быть зарегистрирована служба, преобразующаяся IP-адрес в доменное имя (обратный DNS). Существует два способа использования доменных имён:

  • Домен, зарегистрированный за провайдером. В этом случае пользователь получает поддомены, которые будут связаны с соответствующими IP-адресами. При необходимости изменить доменное имя какой-либо машины, придется обращаться к провайдеру.
  • Собственный домен. В этом случае провайдер организует лишь обратный DNS. Способов получить собственный домен несколько:
    • Выбрать незанятое доменное имя и оплатить его аренду у специальной компании-регистратора, после чего информация об этом появится в базе whois. Арендатор становится администратором домена. В этом случае надо обеспечить существование определенного количества "живых" адресов в арендованном домене. Общая стоимость подобного решения составляет около 20 у.е. в год.
    • Получить на непонятных правах поддомен у владельца домена. В большинстве случаев это не требует дополнительных затрат. Часто такой подход используется при регистрации поддоменов для структурных подразделений организаций, например --- po.cs.msu.su. Администратором поддомена можете быть и не вы.

При использовании доменного имени желательно (обязательно, в случае собственного домена) обеспечить наличие не менее двух доменных DNS-серверов с существенно различными IP-адресами.

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

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

pdnsd

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

Установим pdnsd: 

root@demo ~]# apt-get install pdnsd

Посмотрим его состав: 

[root@demo ~]# rpmquery -l pdnsd
/etc/pdnsd.conf
/etc/ppp/ip-up.d/0pdnsd
/etc/rc.d/init.d/pdnsd
/usr/sbin/pdnsd
/usr/sbin/pdnsd-ctl
/usr/share/doc/pdnsd-1.2.5
/usr/share/doc/pdnsd-1.2.5/AUTHORS
/usr/share/doc/pdnsd-1.2.5/COPYING.BSD
/usr/share/doc/pdnsd-1.2.5/ChangeLog
/usr/share/doc/pdnsd-1.2.5/ChangeLog.old
/usr/share/doc/pdnsd-1.2.5/NEWS
/usr/share/doc/pdnsd-1.2.5/README
/usr/share/doc/pdnsd-1.2.5/README.ALT
/usr/share/doc/pdnsd-1.2.5/README.par
/usr/share/doc/pdnsd-1.2.5/README.par.old
/usr/share/doc/pdnsd-1.2.5/THANKS
/usr/share/doc/pdnsd-1.2.5/TODO
/usr/share/doc/pdnsd-1.2.5/contrib
/usr/share/doc/pdnsd-1.2.5/contrib/README
/usr/share/doc/pdnsd-1.2.5/contrib/change_pdnsd_server_ip.pl
/usr/share/doc/pdnsd-1.2.5/contrib/dhcp2pdnsd
/usr/share/doc/pdnsd-1.2.5/contrib/pdnsd_dhcp.pl
/usr/share/doc/pdnsd-1.2.5/html
/usr/share/doc/pdnsd-1.2.5/html/dl.html
/usr/share/doc/pdnsd-1.2.5/html/doc.html
/usr/share/doc/pdnsd-1.2.5/html/faq.html
/usr/share/doc/pdnsd-1.2.5/html/index.html
/usr/share/doc/pdnsd-1.2.5/pdnsd.conf
/usr/share/doc/pdnsd-1.2.5/txt
/usr/share/doc/pdnsd-1.2.5/txt/faq.txt
/usr/share/doc/pdnsd-1.2.5/txt/intro.txt
/usr/share/doc/pdnsd-1.2.5/txt/manual.txt
/usr/share/man/man5/pdnsd.conf.5.bz2
/usr/share/man/man8/pdnsd-ctl.8.gz
/usr/share/man/man8/pdnsd.8.gz
/var/cache/pdnsd
/var/cache/pdnsd/pdnsd.cache
/var/run/pdnsd
/var/run/pdnsd/socket

Запустим (при необходимости можно отредактировать /etc/pdnsd.conf, например, чтобы указать отличный от /etc/hosts файл для списка соответствий адреса и имени): 

[root@demo ~]# service pdnsd start

Чтобы начать использовать DNS-сервер осталось лишь отредактировать настройки DHCP.

Для того, чтобы DNS-сервер использовал собственный DNS необходимо в качестве первого nameserver в /etc/resolv.conf указать 127.0.0.1.

BIND

BIND (Berkeley Internet Name Domain, ранее Berkeley Internet Name Daemon) --- одна из самых функциональных и популярных в мире реализаций DNS-сервера, разарабатываемая Internet Systems Consortium. Большинство RFC по данной тематике разработаны этой же организацией. bind --- имя пакета, соответствующая служба называется named. Запускается BIND из изолированного окружения /var/lib/bind. 

[root@demo ~]# cd /var/lib/bind/
[root@demo bind]# ls
dev  etc  var  zone

В подкаталоге /etc находятся конфигурационные файлы. В подкаталоге /zone размещена информация о зонах --- соответствиях между ip-адресами, доменами, почтовыми серверами, и т.п. Редактировать следует файл local.conf. При это стоит учитывать, что на момент использования этого файла BIND будет работать в изолированном окружении.

Пример настройки можно посмотреть в файле localdomain. 

[root@demo bind]# cat zone/localdomain
$TTL    1D
@       IN      SOA     localhost. root.localhost. (
                                2008070800      ; serial
                                12H             ; refresh
                                1H              ; retry
                                1W              ; expire
                                1H              ; ncache
                        )
        IN      NS      localhost.
        IN      A       127.0.0.0
localhost       IN      CNAME   localhost.

Запись типа SOA определяет различные параметры зоны, такие как время жизни, время обновления и т.п. serial --- число, которое должно увеличиваться каждый раз, когда изменяется содержимое зоны. Обычно в serial указывают дату редактирования.

Аналогично задаётся обратное преобразование: 

[root@demo bind]# cat zone/127.in-addr.arpa
$TTL    1D
@       IN      SOA     localhost. root.localhost. (
                                2008070800      ; serial
                                12H             ; refresh
                                1H              ; retry
                                1W              ; expire
                                1H              ; ncache
                                )
        IN      NS      localhost.
        0.0.0   IN      PTR     localdomain.
        1.0.0   IN      PTR     localhost.

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

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

Для удобства конфигурирования нескольких DNS-серверов существует возможность указать один из серверов в качестве основного (master), а все остальные в качестве вторичных, slave-серверов. Slave-серверам задается адрес основного сервера, и в дальнейшем все slave автоматически синхронизируют настройки с master. Таким образом, можно легко организовать несколько DNS-серверов, идентичных с точки зрения внешнего мира.

Так же имеет смысл запретить рекурсивные запросы для всех машин, кроме тех, для адресации которых предназначен данный DNS-сервер.

DNS предоставляет возможность преобразовывать символьное имя машины в её внутренний или внешний адрес в зависимости от того, откуда поступил запрос. Технология, обеспечивающая эту функциональность, называется split horizon. В BIND она реализована как BIND View Clause.

CategoryLectures CategoryPspo CategoryMpgu CategoryUneex