Не секрет, что за использование нелицензионного ПО в организации администратор может всхлопотать от 2-ух до 5-ти лет. Сложнее становится администраторам, работающим в образовательных учреждениях, т.к. в ходе изучения, как правило, используется множество пакетов-гигантов, таких как photoshop, corel, flash и прочих. Если школы что-то могут еще получить худо-бедно от государства, то дополнительному образованию государством практически ничего не выделяется!

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

Выбор клиентской ОС был недолгим :) И, конечно, самым первым вопросом был вопрос о централизованном управлении и сетевых ресурсах. Домен под самбой и авторизация в самбе линукс-клиентов был отметен сразу, овчинка выделки не стоит из-за массы проблем с этой авторизацией. Сказать, что готовых систем управления для Unux очень мало - это ничего не сказать. Мне удалось найти 3: nowell, какой то дистр за 10 т.р. Linux Xp, и вроде как у дебиана что-то есть. Но хотелось реализации на Ubuntu, т.к. разбираться с новыми системами времени уже нет, сентябрь не загорами.

В качетсве серверной ОС планировалось взять любимую FreeBSD, но, даже настроив авторизацию клиентов linux в NIS домене FreeBSD, существовала еще куча проблем с оборудованием, в частности с поддержкой принтеров, и прочие мелкие недочеты по совместимости linux и FreebSD. Скрепя сердце и раскинув мозгами, была выбрана Ubuntu Server, все-таки совместимости с клиентами будет больше да и с оборудованием полегче.

В общем, выбор пал на Ubuntu 8.04 Server, Ubuntu 9.04 desktop и на связку NIS и NFS. Каких-то готовых how-to по этой связке очень мало, в основном все разбросано по малым кусочкам. Если NIS домен поднять сложностей не составляет, то вопросы, например, по автомонтированию шар для клиентов (да еще для каждого свои ресурсы), разобраны очень скудно. В процесе сборки выявлялось масса мелких недочетов, которые тормозили весь процесс.

Собственно перед вами HOW-TO: Централизованное управление в Linux сети на базе NIS и NFS.

• Централизованное управление пользовательскими учетными записями;
• Централизованное управление настройками клиентских Ос и приложений (частично);
• Централизованное управления общими и личными (для пользователя) ресурсами;
• Ограничение доступа к ресурсам с использованием прав ACL;
• Организация сервера печати;
• Дисковые квоты;

• Ubuntu Server 8.04 + все последние обновления
• Ubuntu Desktop 9.04 + все последние обновления
• NIS
• NFS
• WEBMIN, DHCPD3, BIND9, NTPD (опционально).
• Предполагается, что Вы знакомы с основными командами Unix, такие как копирование, смена прав, создание ссылок, редактирование файлов и др.

NIS, что является сокращением от Network Information Services (сетевые информационные службы), разработан компанией Sun Microsystems для централизованного администрирования систем UNIX® (изначально SunOS™). В настоящее время эти службы практически стали промышленным стандартом; все основные UNIX-подобные системы (Solaris™, HP-UX, AIX®, Linux, NetBSD, OpenBSD, FreeBSD и так далее) поддерживают NIS. NIS первоначально назывались Yellow Pages (или yp), но из-за проблем с торговым знаком Sun изменила это название. Старое название (и yp) всё ещё часто употребляется. Это система клиент/сервер на основе вызовов RPC, которая позволяет группе машин в одном домене NIS совместно использовать общий набор конфигурационных файлов. Системный администратор может настроить клиентскую систему NIS только с минимальной настроечной информацией, а затем добавлять, удалять и модифицировать настроечную информацию из одного места. Это похоже на систему доменов Windows NT®; хотя их внутренние реализации не так уж и похожи, основные функции сравнимы. ¹⁾

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

Для установки NIS потребуется пакет nis и portmap, ставим их:

sudo apt-get install portmap, nis

Далее, кто желает досканально ковыряться в конфиге, может проследовать в /var/yp/Makefile, кто экономит время, то идем в WEBMIN Сеть - Клиент и сервер NIS и выбираем раздел Сервер NIS. Для базовой настройки этого достаточно, а напильником обработать всегда можно позже.

Выставляем опции:

• Включить сервер NIS?: Да
• Тип сервера: Главный
• Обслуживаемый домен NIS: пишите свой домен.²⁾ Собственно мой домен UBUNTU
• Все остальные параметры рекомендуется пока оставить как есть.

После нажимаем кнопку «Сохранить и применить». Можно сказать что домен поднят. Проверьте, что демон ypserv и portmap стартанули:

root@sytserver:/etc/gdm# lsof -i -n -P | grep portmap
portmap   4388 daemon    3u  IPv4  12093       UDP *:111 
portmap   4388 daemon    4u  IPv4  12094       TCP *:111 (LISTEN)

root@sytserver:/etc/gdm# lsof -i -n -P | grep yp
ypserv    5119   root    4u  IPv4  13002       UDP *:631 
ypserv    5119   root    5u  IPv4  13007       TCP *:632 (LISTEN)

Если что-то не запустилось, для начала перезагрузитесь, попробуйте вручную запустить сервер /etc/init.d/nis start и смотрите логи. Чтобы сервер не тормозил при старте и рестарте, проверьте что параметр NISCLIENT=false в файле /etc/init.d/nis.

Теперь внимание: по nis могут авторизироваться пользователи только с UID более 1000 (это указано в настройках сервера NIS), более того, при добавлении, удалении, изменении параметров пользователей и групп необходимо заново перестраивать карты nis сервера. Это можно сделать написав команду make, предварительно зайдя в каталог /var/yp или нажав кнопку «Сохранить и применить» в WEBMIN «Сеть - Клиент и сервер NIS» - «Сервер NIS«.

В принципе сервер готов к использованию. Тонкую настройку можно будет произвести позже. ³⁾

На клиентской машине также установим пакеты portmap и nis:

 sudo apt-get install portmap, nis 

Если будете устанавливать через синаптик, то синаптик заботливо попросит сразу указать имя домена NIS. Укажите в этом случае имя своего домена (у меня UBUNTU). Если ничего не попросило, внесем имя домена вручную в файл /etc/defaultdomain, просто впишите туда имя своего домена. Далее отредактируйте файлы:

1. Добавить в конец файла /etc/passwd: +::::::
2. Добавить в конец файла /etc/group: +:::
3. Добавить в конец файла /etc/shadow: +

Приведите файл /etc/nsswitch.conf в такой вид:

passwd:         compat
group:          compat
shadow:         compat

passwd_compat: nis
group_compat:  nis
shadow_compat: nis

hosts:          files dns 
networks:       files nis

protocols:      db files nis
services:       db files nis 
ethers:         db files nis
rpc:            db files nis

netgroup:       nis

Этот файл заставляет Ubuntu искать ту или иную информацию в порядке приоритета указанном здесь. Например запись hosts: files dns (определение ИП адреса хоста), заставляет сначала обратиться в файл /etc/host, если запись там не найдена, то обратиться к DNS серверу.

А вот теперь интересный момент. Если вы используете DHCP сервер в своей сети, то можете столкнуться с проблемой тормозни при загрузке компьютера. Yapbind будет слишком долго подключаться к серверу. Чтобы этого не происходило уберите в файле /etc/default/nis у параметра YPBINDARGS ключ -no-dbus. Также можно немного отодвинуть запуск nis клиента. Для этого в /etc/rc5.d переименуйте ссылку @S18nis в @S80nis⁴⁾.

auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
gateway 192.168.1.1

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

Вот и всё, клиент настроен.

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

allex@allexwork:~$ sudo lsof -i -n -P | grep portmap
portmap   2127 daemon    4u  IPv4   5409       UDP *:111 
portmap   2127 daemon    5u  IPv4   5425       TCP *:111 (LISTEN)

allex@allexwork:~$ sudo lsof -i -n -P | grep ypbind
ypbind    3657   root    4u  IPv4   8988       UDP *:865 
ypbind    3657   root    5u  IPv4   8993       TCP *:866 (LISTEN)
ypbind    3657   root    8u  IPv4 148450       UDP *:866 

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

allex@allexwork:~$ sudo ypcat passwd.byname
child:x:1002:100::/home/srv/child:/bin/bash
test:x:1001:100::/home/srv/test:/bin/bash
allexserv:x:1000:0:allexserv,,,:/home/allexserv:/bin/bash

Если информация о пользователях недоступна, то возможно их (пользователей) просто нет на сервре (напомню что NIS пользователями считаются пользователи у которых UID больше 1000 в нашем примере). Проверьте также, что вы не ошиблись при записи домена в файл /etc/domainname:

allex@allexwork:~$ /bin/domainname
UBUNTU

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

Сделать это можно либо через команду adduser, либо через WEBMIN: «Система - Пользователи и группы - Создать нового пользователя». Обратите внимание, что пароль в WEBMIN должен задаваться в поле Обычный пароль. В разделе «При создании..», можно везде поставить «нет». После добавления пользователей необходимо не забыть перестроить карты NIS. Это можно сделать написав команду make, предварительно зайдя в каталог /var/yp или нажав кнопку «Сохранить и применить» в WEBMIN «Сеть - Клиент и сервер NIS» - «Сервер NIS«.

К сожалению, судя по статьям, безопасность NIS находится на достаточно низком уровне. Чаcть огрехов можно исправить манипулируя ограничением обмена картами NIS. Если в Вашей сети безопасность должна быть на высоком уровне, вам придется посмотреть в сторону LDAP и отказаться от использования NIS. В общем-то любой пользователь, зная имя вашего домена, может выполнить запрос RPC к ypserv и получить содержимое ваших карт NIS. Для предотвращения такого неавторизованного обмена ypserv поддерживает так называемую систему securenets, которая может использоваться для ограничения доступа к некоторой группе хостов. Кроме того, для ограничения входа можно воспользоваться т.н. сетевыми группами NIS. Частично о модели безопасности описано здесь. Там же приведены очень хорошие примеры по использованию сетевых групп (netgroup).

Обратите внимание, что для клиентской машины с Ubuntu все пользователи домена NIS (в том числе и root) всего лишь обычные юзеры. Такие пользователи даже систему не могут перезагрузить. Часть этих привелегий можно отредактировать в полномочиях, запустив редактор командой:

sudo polkit-gnome-authorization

Возможно придется перед этим установить пакет policykit-gnome. Более тонко полиции можно настроить здесь /usr/share/polkit-1/actions/, отредактировав файлы. Там подробные комментарии, так что не запутаетесь.

Network File System (NFS) — сетевая файловая система, позволяющая пользователям обращаться к файлам и каталогам, расположенным на удалённых компьютерах, как если бы эти файлы и каталоги были локальными.⁵⁾ Собственно чем мы и займемся.

Как и настройка NIS, настройка NFS до безобразия проста.

Потребуется установить собственно сам демон сервера:

sudo apt-get install nfs-kernel-server, nfs-common

Собственно установка закончена. :) Файл конфигурации сервера по умолчанию используется /etc/default/nfs-kernel-server. Как и в случае с NIS сервером требуется демон portmap, так же должны запуститься демон rpc.mountd и процесс NFS операторских запросов для клиентских систем rpc.nfsd⁶⁾. Последние два запускаются сценарием:

/etc/init.d/nfs-kernel-server

root@sytserver:/etc/default# lsof | grep nfsd
nfsd4     6285       root  cwd       DIR        8,1    4096          2 /
nfsd4     6285       root  rtd       DIR        8,1    4096          2 /
nfsd4     6285       root  txt   unknown                               /proc/6285/exe
nfsd      6286       root  cwd       DIR        8,1    4096          2 /
nfsd      6286       root  rtd       DIR        8,1    4096          2 /
nfsd      6286       root  txt   unknown                               /proc/6286/exe
nfsd      6320       root  cwd       DIR        8,1    4096          2 /
nfsd      6320       root  rtd       DIR        8,1    4096          2 /
nfsd      6320       root  txt   unknown                               /proc/6320/exe
nfsd      6321       root  cwd       DIR        8,1    4096          2 /
nfsd      6321       root  rtd       DIR        8,1    4096          2 /
nfsd      6321       root  txt   unknown                               /proc/6321/exe
nfsd      6322       root  cwd       DIR        8,1    4096          2 /
nfsd      6322       root  rtd       DIR        8,1    4096          2 /
nfsd      6322       root  txt   unknown                               /proc/6322/exe
nfsd      6323       root  cwd       DIR        8,1    4096          2 /
nfsd      6323       root  rtd       DIR        8,1    4096          2 /
nfsd      6323       root  txt   unknown                               /proc/6323/exe
nfsd      6324       root  cwd       DIR        8,1    4096          2 /
nfsd      6324       root  rtd       DIR        8,1    4096          2 /
nfsd      6324       root  txt   unknown                               /proc/6324/exe
nfsd      6325       root  cwd       DIR        8,1    4096          2 /
nfsd      6325       root  rtd       DIR        8,1    4096          2 /
nfsd      6325       root  txt   unknown                               /proc/6325/exe
nfsd      6326       root  cwd       DIR        8,1    4096          2 /
nfsd      6326       root  rtd       DIR        8,1    4096          2 /
nfsd      6326       root  txt   unknown                               /proc/6326/exe
rpc.mount 6330       root    4u      REG        0,3       0 4026532089 /proc/net/rpc/nfsd.export/channel
rpc.mount 6330       root    6u      REG        0,3       0 4026532093 /proc/net/rpc/nfsd.fh/channel

Теперь необходимо экспортировать⁷⁾ каталоги для дальнейшего пользования клиентами. За список расшаренных ресурсов отвечает файл /etc/exports. При любых изменениях в этом файле, дабы активировать изменения, необходимо запускать команду sudo exportfs -a.

Немного о синтаксисе файла. Каждая строка подразумевает расшаривание одного ресурса. Указывается местоположение экспортируемого каталога и некоторые опции, например:

/media/Work/tmp 192.168.3.23(async,secure,ro) 192.168.3.20(async,ro)
/media/Work/testdir @test(sync,rw)
/media/Profil/home      *(rw)

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

• Первая строка: доступ только хосту 192.168.3.23 и 192.168.3.20. Каждый хост может иметь свои права доступа.
• Вторая строка: доступ только сетевой группе test.
• Третья строка: доступ разрешен всем на чтение и запись.

Часто используемые опции файла /etc/exports:

Остальные опции (их много) можно прочитать man exports, в документации они очень хорошо описаны.

Собственно, после базового знакомства структуры файла exports, можно большую часть шар предоставлять через WEBMIN: «Сеть - Каталоги NFS». Единственный момент: после создания шары не забудьте нажать кнопку «Применить изменения» или выполнить команду sudo exportfs -a.

C настройкой клиента ещё проще. Изначально ядро уже поддерживает NFS, поэтому дополнительных манипуляций и не требуется, кроме установки пакета nfs-common:

apt-get install nfs-common

Все. :) На всякий случай конфиг используется этот: /etc/default/nfs-common. Клиент готов монтировать ресурсы NFS. Монтирование шар NFS производится командой mount. Самый простейший способ смонтировать, такой:

sudo mount sytserver:/media/Work/tmp /mnt

где:

• sytserver - имя или адрес сервера;
• /media/Work/tmp - экспортируемый ресурс сервера;
• /mnt - точка монтирования на клиенте;

Более сложные способы используют дополнительные параметры nfs у команды mount, такие как размер буфера чтения и записи, тайм ауты запросов, способ подключения к серверу и пр. Вот некоторые из них:

Например:

sudo mount -t nfs -o users,hard,ro,rsize=1024 sytserver:/media/Work/tmp /mnt

Можно также включать монтирование в файл fstab в соответствии с его синтаксисом:

sytserver:/media/Profil/home /home/srv nfs auto,exec      0       0

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

Особых замечаний нет. О монтировании ресурсов более подробно остановимся в 3 и 4 частях настоящей статьи.

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

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

Для начала реализуем, скажем так, два типа домашних каталогов:

1. Личные домашние каталоги педагогов
2. Домашние каталоги детей

Зачем? Объясняю: с педагогами все понятно - один пользователь - один каталог. С детьми несколько сложнее. Пусть дети состоят из т.н. групп по 12 человек. Для каждого ребенка завести свой аккаунт это тихий ужас для администратора, поэтому заводим аккаунт на всю группу, т.е. для каждой группы детей будет свой аккаунт. Это еще не все. Ввиду того, что дети - народ ушлый, добавим хитрость: все изменения производимые детьми в период текущей сессии при выходе не будут сохраняться на сервере. Одним словом домашний каталог детей никогда не будет изменен и всегда будет иметь первоначальный вид, в то время как дети могут делать на время своей сессии все что угодно, хоть на ушах стоять. По-моему очень занимательно. Но и это еще не все. Раз домашние каталоги детей изменяться не будут, очевидно, что нет смысла для каждого детского аккаунта заводить свою домашнюю папку. Сделаем хитрее и для всех детей у нас будет один домашний каталог. Это не только избавит администратора от лишних манипуляций по конфигурированию домашних каталогов, но и позволит за один присест менять параметры различных пользовательских приложений сразу для всех детей. Все это реализуемо и, как оказалось, совсем не сложно.

Для начала выполним ряд подготовительных операций:

Настройка на стороне клиента

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

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

Настройка на стороне сервера

3. Я пока не буду залезать в дебри групп (об этом поговорим в другой части), поставим эксперимент пока на двух пользователях: один педагог, второй ребенок. Выберем на сервере раздел и создадим папку home. В ней мы будем хранить профили пользователей. Мой каталог для профилей клиентов такой: /media/Profil/home. Назначим также ему права 777.

4. Теперь скопируем каталог default в папку /media/Profil/home/ и переименуем его в .child, еще раз скопируем default в /media/Profil/home/ и переименуем в pedagog. Домашние папки для наших двух пользователей почти готовы.⁸⁾

5. Создадим в домене этих двух пользователей, например через WEBMIN (см. ЧАСТЬ 1.), мои пользователи child и pedagog. При создании в поле «Домашний каталог» впишем /home/srv/.child и /home/srv/pedagog соответственно. Также нам понадобится, чтобы все пользователи-дети входили в одну общую группу. Пусть эта группа называется children, укажите ее принудительно при создании пользователя child. Не забываем перестроить карты nis!⁹⁾

6. Экспортируем всю домашнюю папку на сервере NFS. Для этого в файле /etc/export добавим запись: /media/Profil/home (rw). Вы, разумеется, добавляете свой путь (подробнее ЧАСТЬ 2.). Не забываем выполнить команду sudo exportfs -a или WEBMIN: «Сеть - Каталоги NFS» кнопка «Применить изменения».

7. Ограничим права на домашние профиля для наших двух пользователей. Очевидно что для каталога /media/Profil/home/pedagog мы назначим владельца pedagog и установим права 700. Для папки /media/Profil/home/.child, назначим владельца child и права 770.

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

Т.к. каталог с домашними папками должен монтироваться на всех машинах, я думать долго не стал. Возможно кому то это не понравится, но я реализовал у себя так, чтобы шара с домашними папками монтировалась автоматически при загрузке клиентской машины. Можно, конечно, сделать так, чтобы каждая домашняя папка монтировалась только при входе пользователя средствами pam_mount (об этом я упомяну ниже), но я в этом не вижу смысла, т.к. все домашние папки будут все равно защищены правами для каждого пользователя.

Сначала я запихнул команду монтирования в /etc/fstab, но погоняв рабочую станцию, заметил, что иногда монтирование не происходило. Возможно это потому, что монтирование иной раз стартовало до того как активировались сетевые интерфейсы (об этом я писал в ЧАСТЬ 1). Вобщем я не стал долго мучаться и добавил команду монтирования в файл /etc/rc.local:

/bin/mount -t nfs -o hard sytserver:/media/Profil/home /home/srv
/usr/sbin/ntpdate time.syt.local
exit 0

как видно, тут же еще и синхронизацию времени сделал. Все, после этого, рабочая станция монтировала все домашние папки в /home/srv на этапе загрузки. Кстати это еще удобно тем, что можно в этой папке размещать в будущем какие нибудь конфиги для программ. Можно считать, что для пользователя pedagog все готово. При входе в систему он будет использовать свою домашнюю папку, которая на самом деле хранится на сервере.

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

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

Для начала установим требуемый модуль на клиентской машине:

sudo apt-get install libpam-mount

Конфигурационный файл располагается в /etc/security/pam_mount.conf.xml. Синтаксис находится в XML формате. Именно с помощью него мы и будем конфигурировать кому какие шары при входе подключать (в 4 части). Первое о чем я задумался, это то, что не гоже вести этот файл на каждой рабочей станции, нужно сделать либо один общий файл, либо каждому пользователю по файлу-конфигу, либо оба варианта одновременно. В принципе задача решается и так и этак:

В первом случае файл /etc/security/pam_mount.conf.xml можно разместить на сервере в каталоге где хранятся домашние папки: /media/Profil/home/, а на клиентах сделать символическую ссылку на этот файл. Т.к. этот каталог монтируется при загрузке клиентской машины, то у компьютера не возникает ошибки об отсутствии настоящего файла pam_mount.conf.xml.

Во втором случае, в конфигурационном файле pam_mount.conf.xml есть опция

<luserconf name=".pam_mount.conf.xml" />

которая заставит искать файл конфигурации pam_mount.conf.xml в домашней папки пользователя. Но опять же придется прописывать эту опцию на всех клиентах.

Вобщем я буду использовать оба варианта:

1. сделаю один общий pam_mount.conf.xml, который буду хранить на сервере в папке /media/Profil/home/ (все равно она подключается автоматом при загрузке клиентской машины), на всех клиентских машинах удалю /etc/security/pam_mount.conf.xml, а вместо него сделаю символическую ссылку на общий pam_mount.conf.xml, который будет лежать на смонтированном каталоге /home/srv/pam_mount.conf.xml. Я не буду описывать как делать символические ссылки, думаю, что если вы читаете эту статью, то знаете как это делается.

2. Если мне потребуется, буду использовать опцию

<luserconf name=".pam_mount.conf.xml" />

Для решения нашей задачи также потребуется установить пакет aufs-tools¹⁰⁾ на клиентской машине. Инструмент aufs-tools поможет «объединить» временную файловую систему tmpfs и домашний каталог пользователя таким образом, что существующие в домашнем каталоге параметры будут учитываться системой, а вот все изменения производимые пользователем на время сессии будут записываться на временную файловую систему tmpfs. Когда пользователь завершит сеанс временная файловая система размонтируется, потеряв все изменения, а сам домашний каталог останется без изменений. Следует заметить, что tmpfs создаст виртуальный диск указанного размера в оперативной памяти компьютера, поэтому реализация такой схемы может плачевно сказаться на производительности клиентской машины в целом. ¹¹⁾ Ставим пакет aufs-tools¹²⁾:

sudo apt-get install aufs-tools

Собственно все почти готово, осталось сконфигурировать файл /media/Profil/home/pam_mount.conf.xml на стороне сервера. Вот примерное содержимое для нашей задачи (не забывайте, что комментарии в XML это <!– текст –>):

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd">

<pam_mount>

<!-- Volume definitions --><!-- pam_mount parameters: General tunables -->

<volume pgrp="children" fstype="tmpfs"  path="tmpfs" mountpoint="/tmp/%(USER)" 
options="size=50M,uid=%(USER),gid=children,mode=770" />

<volume pgrp="children" fstype="aufs" path="aufs" mountpoint="/tmp/%(USER)" 
options="dirs=/tmp/%(USER):/home/srv/.child=ro" />

<umount>sudo umount -l %(MNTPT)</umount>

<debug enable="1" />
<!--
<luserconf name=".pam_mount.conf.xml" />
-->

<!-- Note that commenting out mntoptions will give you the defaults.
     You will need to explicitly initialize it with the empty string
     to reset the defaults to nothing. 
<mntoptions allow="nosuid,nodev,loop,encryption,fsck,nonempty,allow_root,allow_other" />

<mntoptions deny="suid,dev" />
-->
<mntoptions allow="*" />
<!--
<mntoptions deny="*" />
-->
<mntoptions require="nosuid,nodev" />

<path>/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin</path>

<logout wait="0" hup="0" term="0" kill="0" />


		<!-- pam_mount parameters: Volume-related -->

<mkmountpoint enable="1" remove="true" />


</pam_mount>

Разберем подробнее записи. В частности следующие две строки и есть реализация нашей задачи. Вынесем их для удобства (остальные параметры /media/Profil/home/pam_mount.conf.xml разберем в четвертой части):

<volume pgrp="children" fstype="tmpfs"  path="tmpfs" mountpoint="/tmp/%(USER)" 
options="size=50M,uid=%(USER),gid=children,mode=770" />
<volume pgrp="children" fstype="aufs" path="aufs" mountpoint="/tmp/%(USER)" 
options="dirs=/tmp/%(USER):/home/srv/.child=ro" />

где:

• «volume» - ключевое слово, сигнализирующее об описании раздела.
• pgrp=«children» - основная группа пользователя, для которого определены правила монтирования. Т.е. если пользователь входит в эту группу эта строка выполнится;
• fstype=«tmpfs» - тип файловой системы;
• path=«tmpfs» - путь к утилите tmpfs;
• mountpoint=»/tmp/%(USER)« - точка монтирования на клиентской стороне. Обратите внимание на переменную %(USER) - вместо нее подставляется имя пользователя при входе;
• options=«size=50M,uid=%(USER),gid=children,mode=770» - параметры монтирования tmpfs:
  • «size=50m,» - размер создаваемого виртуального тома. В зависимости от выполняемых пользователем задач, возможно потребуется увеличить размер тома;
  • «uid=%(USER),gid=children,» - владелец (будет выставлен всем объектам при монтировании);
  • «mode=0770» - права доступа;
• options=«dirs=/tmp/%(USER):/home/srv/.child=ro» - параметры монтирования aufs: указывают отобразить изменения /home/srv/.child в директории /tmp/%(USER).

Особое внимание хочу уделить размонтированию шары при выходе. Вобще у меня с этим возникли некоторые проблемы. В частности при настройках по умолчанию этого конфига, шары не размонтировались, включив отладку (<debug enable=«1» />), pam_mount упрямо сообщал при выходе пользователя, что запись о монтированном сетевом ресурсе не находится в fstab и мол вы не root. Скорее всего проблему решил костылем, если кто-то может предложить более лучший способ - предложите. Собственно решил ее так:

1. Разрешаем всем пользователям на клиентских машинах использовать команду /bin/umount без ввода пароля через sudo. Для этого добавим в самый конец файла /etc/sudoers строку:

ALL ALL=NOPASSWD: /bin/umount

2. На сервере в файле /media/Profil/home/pam_mount.conf.xml включим опцию:

<umount>sudo umount -l %(MNTPT)</umount>

Эта опция заставит pam_mount использовать команду umount c указанными параметрами. Ключ -l («л»), т.н. «ленивое» размонтирование, добавлен т.к. без него, tmpfs не размонтировалась сообщая о занятости девайса.

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

root@sytserver:/media/Profil/home/.child# ls -l -a
total 72
drwxrwxr-x 18 root children 4096 2009-09-23 18:54 .
drwxr-xr-x  9 root root     4096 2009-09-21 20:50 ..
drwxrwxr-x  6 root children 4096 2009-09-08 21:31 .config
drwxrwxr-x  2 root children 4096 2009-06-19 20:30 default
drwxrwxr-x  2 root children 4096 2009-06-19 20:30 .fonts
drwxrwxr-x  5 root children 4096 2009-09-08 20:50 .gconf
drwxrwxr-x  5 root children 4096 2009-09-08 20:50 .gvfs
drwxrwxr-x  9 root children 4096 2009-09-08 20:50 .gnome2
drwxrwxr-x  3 root children 4096 2009-09-18 23:36 .kde
drwxrwxr-x  4 root children 4096 2009-06-19 20:30 .mozilla
drwxrwxr-x  3 root children 4096 2009-06-19 20:30 .openoffice.org
drwxrwxr-x  9 root children 4096 2009-08-10 21:15 .opera
drwxrwxr-x  2 root children 4096 2009-06-19 20:30 Видео
drwxrwxr-x  2 root children 4096 2009-06-19 20:30 Документы
drwxrwxr-x  2 root children 4096 2009-06-19 20:30 Картинки
drwxrwxr-x  2 root children 4096 2009-06-19 20:30 Музыка
drwxrwxr-x  2 root children 4096 2009-06-19 20:30 Общедоступная
drwxrwxr-x  2 root children 4096 2009-06-19 20:30 Рабочий стол
drwxrwxr-x  2 root children 4096 2009-06-19 20:30 Шаблоны
root@sytserver:/media/Profil/home/.child#

Обратите внимание на права. Заметьте, что нет критичных файлов .dmrc, .ICEauthority, которые препятствуют многопользовательскому доступу. Они будут созданы в процессе входа пользователя на временной файловой системе и в связи с этим для каждого пользователя будут свои. Также важно отсутствие некоторых каталогов, каких уже не вспомню. Приведенная структура каталогов, сохранила в себе настройки окружения пользователя, а также настройки некоторых программ. Также можно добавлять конфигурационные каталоги других необходимых (но не системных) программ. Вообще, замечу, все чего не будет хватать системе она автоматически при входе пользователя будет это создавать, причем на временной ФС.¹³⁾. Замечу, что некоторые программы не загружаются при такой схеме. Например, опытным путем было выяснено, что для загрузки FireFox необходимо чтобы пользователь в обязательном порядке имел права на запись у каталога с профилем Firefox'a. А чтобы запустилась Opera, необходимо удалить файл lock*.* в профиле Oper'ы.

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

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

• Домен NIS, и машину-клиент присоединенную к домену NIS;
• Сервер NFS и машину-клиент настроенную на использование ресурсов NFS;
• Двух пользователей: pedagog и child;
• Домашние папки этих пользователей хранимые на сервере NFS;

Также мы уже познакомились со способом монтирования ресурсов при входе в систему (см. ЧАСТЬ 3), а именно с модулем pam_mount. Собственно об этом модуле и пойдет речь в этой части. Здесь мы разберем более подробно нужные нам параметры pam_mount.conf.xml и рассмотрим подключения общих сетевых ресурсов для пользователей. Как и в 3 части я пока не буду сильно оптимизировать права на шары. По этой теме стоит отдельно поговорить, используя ACL, группы пользователей и т.д.

Помимо имеющегося перечисленного выше, стоит добавить, что конфигурационный файл pam_mount.conf.xml у нас общий для всех клиентов и хранится на сервере с правами 744. На клиентских машинах у нас символическая ссылка на этот файл (см. ЧАСТЬ 3).

Полный MAN по использованию pam_mount.conf.xml можно найти здесь. Напомню что синтаксис этого файла в XML, поэтому будьте внимательны. Почти для всех параметров есть как открывающийся тег, так и закрывающийся.

Рассмотрим типичный конфиг:

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd">

<pam_mount>

<!-- Volume definitions-->
<volume pgrp="children" fstype="tmpfs"  path="tmpfs" mountpoint="/tmp/%(USER)" 
options="size=50M,uid=%(USER),gid=children,mode=770" />
<volume pgrp="children" fstype="aufs" path="aufs" mountpoint="/tmp/%(USER)" 
options="dirs=/tmp/%(USER):/home/srv/.child=ro" />

<!-- pam_mount parameters: General tunables -->

<umount>sudo umount -l %(MNTPT)</umount>
<debug enable="1" />
<luserconf name=".pam_mount.conf.xml" />

<!--  
<mntoptions allow="nosuid,nodev,loop,encryption,fsck,nonempty,allow_root,allow_other" />
<mntoptions deny="suid,dev" />
-->

<mntoptions allow="*" />

<!--
<mntoptions deny="*" />
-->

<mntoptions require="nosuid,nodev" />
<path>/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin</path>
<logout wait="0" hup="0" term="0" kill="0" />

<!-- pam_mount parameters: Volume-related -->

<mkmountpoint enable="1" remove="true" />

</pam_mount>

Как видно, конфигурационный файл разделен комментариями на 2 части:

• Параметры подключаемых ресурсов - <!— Volume definitions —>
• Общие главные параметры монтирования - <!— pam_mount parameters: General tunables —>

Здесь можно задать где конкретно искать файлы mount и umount (по умолчанию ищется через PATH$), а также можно задать дополнительные параметры (как в нашем примере в ЧАСТЬ 3):

<lclmount>mount -p0 -t %(FSTYPE) ...</lclmount>

<umount>umount %(MNTPT)</umount>

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

%(USER)

%(USERUID),%(USERGID)

%(FSTYPE)

%(SERVER)

%(VOLUME)

%(MNTPT)

Иногда обычных параметров в теге <volume>, например «user=«, недостаточно. Хочется оптимизации, например, предоставление ресурса целой группе пользователей. Это можно реализовать используя теги расширенного контроля. Пример использования:

<volume path="/dev/shm" mountpoint="~"> <and> <user>students</user> <not> <sgrp>profs</sgrp> </not> </and> </volume>

- Что означает: смонтировать ресурс /dev/shm в домашнюю папку пользователя, если имя пользователя students, и который не входит в главную или дополнительную группу profs.

Вспомним логику:

<and><elements>*</and>

<or><elements>*</or>

<xor><elements>{2}</xor>

<not><element></not>

<user>username</user>

<uid>number</uid> или <uid>number-number</uid>

<gid>number</gid> или <gid>number-number</gid>

<pgrp>groupname</pgrp>

<sgrp>groupname</sgrp>

Ну и основной параметр конфига это параметр <volume>. С некоторыми параметрами подключаемых ресурсов мы уже знакомы. Заметьте, здесь, в нашем примере у тега <volume… нет закрывающего тега </volume>, т.к. мы не используем дополнительные опции. ¹⁶⁾ Собственно именно параметр volume отвечает за монтирование ресурсов (не только NFS но и многих других типов ФС).

По умолчанию ресурс монтируется всем пользователям, если не оговорено иное. Например:

<volume user="joe" fstype="nfs" server="fsbox" path="/home/%(USER)" mountpoint="/bigdisk/%(USER)" />

- указано, что этот ресурс будет подключен только пользователю «joe».

Простые параметры ограничивающие монтирование. Ресурс может быть доступен если сразу после <volume… указано и выполняется следующее:¹⁷⁾

• user=«username» - имя пользователя.
• uid=«number» или uid=«number-number» - UID или диапазон UIDов.
• pgrp=«groupname» - основная группа пользователя.
• gid=«number» или gid=«number-number» - GID или диапазон GIDов.
• sgrp=«groupname» - группа пользователя (основная или дополнительные).

Другие параметры <volume>:

• fstype=«type» - Тип файловой системы.
• server=«name» - Имя или IP адрес сервер для подключения (в случае сетевого монтирования).
• path=«path» - Путь до экспортируемого ресурса на сервере.
• mountpoint=«directory» - Точка монтирования на клиентской машине.
• options=«…« - дополнительные параметры для команды mount. Перечисляются через запятую.

В заключении: манипулируя этими параметрами можно создать воистину гибкое монтирование ресурсов для пользователя и групп пользователей.

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

1. Создаем на сервере NFS экспортируемый ресурс, предварительно создав сам каталог talk и выставив ему права 777. Мой каталог: /media/Work/talk. Для его экспорта добавляем запись в /etc/export: /media/Work/talk (rw). Незабываем обновить изменения: sudo exportfs -a.

2. Т.к. у нас pam_mount.conf.xml общий для всех клиентских машин, то редактирую его, добавив запись:

sudo nano /media/Profil/home/pam_mount.conf.xml

Добавляем:

<volume fstype="nfs" server="sytserver" path="/media/Work/talk" mountpoint="/media/Talk"
options="hard"><or><user>child</user><user>pedagog</user></or></volume> 

Из примера видно, что каталог talk будет смонтирован только пользователям child и pedagog. Остальным он смонтирован не будет. Если нужен чтобы каталог монтировался всем, достаточно записи:

<volume fstype="nfs" server="sytserver" path="/media/Work/talk" mountpoint="/media/Talk" options="hard,suid"/>

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

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

Решим следующую задачу:

Есть педагог. У педагога есть 5 групп детей. В каждой группе по 12 человек. Требуется:

• Подключать педагогу при входе сетевой каталог который бы содержал в себе папки всех 5-ти групп (допустим для проверки заданий);
• Педагог должен иметь доступ к детским папкам на запись;
• Каждой группе детей при входе подключается их сетевой диск, который содержит папки с фамилиями ребят. Дети не могут удалять папки с фамилиями из корневого каталога сетевого диска, но могут писать в своих папках. Также дети не могут создавать в корневом каталоге сетевого диска ни файлов, ни папок.
• Среди папок с фамилиями у каждой из групп есть папка Задания. Для детей доступ к этой папке только для чтения, для педагога на чтение-запись.
• Каждая группа детей не может получить доступ к папкам других групп.

Выполним ряд подготовительных действий:

1. Для начала организуем две группы в системе если их еще нет. Группу pedagog и группу children. Для этого либо редактируем файл /etc/group, либо создаем группы в WebMin:

children:x:1001:
mysql:x:130:
pedagog:x:1002:

2. Создадим пользователя-педагога. Пусть ее имя будет olga. Сделать это можно по разному, я сделаю через WebMin. При создании никаких экзотических опций не использую. Обратите только внимание на путь к домашней папке. Помним, что все домашние папки у нас подключаются при загрузке клиентских машин с сервера и монтируются в папку /home/srv. Так что путь к домашней папки у olga будет такой: /home/srv/olga. Основная группа будет pedagog.

3. Подготовим домашнюю папку для olga на сервере. Помним, что у нас уже есть т.н. папка с окружением рабочего стола по умолчанию, которая называется default (см. часть 3). Все мои папки с домашними каталогами находятся на сервере здесь: /media/Profil/home. Создам в ней папку olga, скопирую в нее содержимое из default. Назначу права 700, а также сделаю владельцем olga:

root@sytserver:/media/Profil/home#chown -R olga olga
root@sytserver:/media/Profil/home#chmod -R 700 olga  

Пользователь olga и ее домашняя папка готовы.

4. Теперь, т.к. у педагога 5 групп детей, создадим для них аккаунты. По одному аккаунту на группу. Пусть аккаунты именуются так: ol1, ol2, ol3, ol4, ol5. Создаем пользователей с такими именами в системе, домашняя папка у них будет числиться как /home/srv/.child. Основная группа - children.

5. Домашняя папка для всех групп у нас общая и лежит на сервере. Напомню, что при подключении пользователей-детей у нас используется временная файловая система (см. часть 3), что обеспечивает неизменность профиля для детей. Помним, что у нас уже есть т.н. папка с окружением рабочего стола по умолчанию, которая называется default (см. часть 3). Все мои папки с домашними каталогами находятся на сервере здесь: /media/Profil/home.

Итак, создам в папке /media/Profil/home папку .child, скопирую в нее содержимое из default. Теперь назначим папке .child необходимые права. Владельцем папки оставим пользователя root, а вот группу сделаем children, чтобы любой ребенок имел к ней доступ:

root@sytserver:/media/Profil/home# ls -l
итого 16
drwx--x--x  2 allexserv nogroup 4096 2009-06-24 12:35 allex
drwx------ 35 root      root    4096 2009-06-22 21:46 .child
drwx------ 34 olga      root    4096 2009-08-08 17:47 olga
-rwxrwxrwx  1 nobody    nogroup  945 2009-08-08 18:09 pam_mount.conf.xml

root@sytserver:/media/Profil/home# chown -R root:children .child
root@sytserver:/media/Profil/home# chmod -R 775 .child
root@sytserver:/media/Profil/home# ls -l

итого 16
drwx--x--x  2 allexserv nogroup 4096 2009-06-24 12:35 allex
drwxrwxr-x 35 root     children    4096 2009-06-22 21:46 .child
drwx------ 34 olga      root    4096 2009-08-08 17:47 olga
-rwxrwxrwx  1 nobody    nogroup  945 2009-08-08 18:09 pam_mount.conf.xml

6. С домашними папками покончено. Обновим карты NIS домена после добавления новых пользователей и групп. Это можно сделать написав команду make, предварительно зайдя в каталог /var/yp на сервере NIS или нажав кнопку «Сохранить и применить» в WEBMIN: «Сеть - Клиент и сервер NIS» - «Сервер NIS«.

7. Создадим структуру каталогов (см. рис.) для групп детей на сервере и назначим им права доступа. Эти каталоги будут подключаться детям при входе в систему соответственно и будут служить рабочими «дисками» для детей, где они будут складывать свои наработки во время занятий. Все пользовательские каталоги у меня размещаются здесь: /media/Work/Disk_child. Создадим каталог olga_ch, который будет содержать в себе все каталоги групп детей педагога. Этот каталог (olga_ch) будет подключаться педагогу olga. В нем создадим пять каталогов, для каждой из груп: ol1, ol2, ol3, ol4, ol5. Каждый из них будет подключаться той или иной группе соответственно. В каждом из этих пяти каталогов будут еще каталоги с фамилиями ребят. В данном примере фамилии заменят каталоги 01, 02, 03 и тп. Вот что получается:

root@sytserver:/media/Work/Disk_child/olga_ch# ls -l
итого 20
drwxr-xr-x 4 root root 4096 2009-08-08 18:55 ol1
drwxr-xr-x 2 root root 4096 2009-08-08 18:03 ol2
drwxr-xr-x 2 root root 4096 2009-08-10 17:59 ol3
drwxr-xr-x 2 root root 4096 2009-08-10 17:59 ol4
drwxr-xr-x 2 root root 4096 2009-08-10 17:59 ol5

Для всех пяти групп я не буду приводить примеры с разрешениями, приведу только для ol1. И вообще, в целях оптимизации можно все права выставить только для одной группы, а для остальных четырех групп просто скопировать структуры папок с уже назначенными правами и немного модифицировать их (права) о чем ниже. Так и сделаем. Начнем с педагога olga. При входе в систему, помимо личного диска, ей будет экспортироваться папка olga_ch, в которой будут содержаться все ее группы ребят. Очевидно, что права на запись в саму папку olga_ch педагогу ненужны ибо нефик! Владельца папки оставляем рута и назначаем права ACL:

root@sytserver:/media/Work/Disk_child# chown root:root olga_ch
root@sytserver:/media/Work/Disk_child# chmod 700 olga_ch
root@sytserver:/media/Work/Disk_child# setfacl -m u:olga:rx olga_ch
root@sytserver:/media/Work/Disk_child# getfacl ol*
# file: olga_ch
# owner: root
# group: root
user::rwx
user:olga:r-x
group::---
mask::r-x
other::---

Теперь разбираемся с правами на группы (папки ol1 - ol5). Здесь уже для педагога потребуются также права на запись, дабы он мог удалять лишние файлы, редактировать файлы ребят и добавлять новые. Поэтому для каталога группы (в нашем случае ol1), назначаем права rwx. Владельцем каталога также оставляем рута:

root@sytserver:/media/Work/Disk_child/olga_ch# chown root:root ol1
root@sytserver:/media/Work/Disk_child/olga_ch# chmod 700 ol1
root@sytserver:/media/Work/Disk_child/olga_ch# setfacl -m u:olga:rwx ol1
root@sytserver:/media/Work/Disk_child/olga_ch# getfacl ol1
# file: ol1
# owner: root
# group: root
user::rwx
user:olga:rwx
group::---
mask::rwx
other::---

Заметьте, что хоть olga и имеет права rwx на каталог ol1, она не сможет удалить САМ каталог ol1, который находится в папке olga_ch.

Теперь сразу добавим на этот же каталог права для пользователя ol1. Писать детям в сам каталог ol1 нужды нет, ибо опять нефик! Поэтому им даем права rx:

root@sytserver:/media/Work/Disk_child/olga_ch# setfacl -m u:ol1:rx ol1
root@sytserver:/media/Work/Disk_child/olga_ch# getfacl ol1
# file: ol1
# owner: root
# group: root
user::rwx
user:ol1:r-x
user:olga:rwx
group::---
mask::rwx
other::---

Теперь освободим себя еще от лишней работы. Пускай педагог сама создает каталоги с фамилиями ребят, которые ему (педагогу) нужны. Загвоздка в том, чтобы при создании каталогов руками педагога они еще должны быть доступны детям. Для этого воспользуемся ACL по умолчанию, т.н. сделаем «наследование» прав. Более того, сразу глядим в будущее… Попробую объяснить:

• В сеть будут отдаваться каталоги olga_ch и ol1, должен быть соответствующий доступ только для пользователей этих каталогов.
• С каталогом olga_ch все ясно, дополнительных манипуляций не надо, доступ только для olga.
• К каталогу ol1 должны уже иметь доступ olga и группа детей ol1, тоже сделано.
• Ну, а к каталогам-фамилиям уже можно чуть приспустить разрешения. Т.к. мы планируем потом раскопировать структуру и права для других групп, сделаем разрешения ACL не к пользователям, а к группам, да так, чтобы они наследовались на каталоги, которые будет создавать педагог в папке ol1:

root@sytserver:/media/Work/Disk_child/olga_ch# setfacl -d -m g:children:rwx,g:pedagog:rwx ol1
root@sytserver:/media/Work/Disk_child/olga_ch# getfacl ol1
# file: ol1
# owner: root
# group: root
user::rwx
user:ol1:r-x
user:olga:rwx
group::---
mask::rwx
other::---
default:user::rwx
default:group::---
default:group:children:rwx
default:group:pedagog:rwx
default:mask::rwx
default:other::---

Теперь все создаваемые каталоги и файлы внутри каталога ol1 будут принимать разрешения rwx для групп pedagog и children. Вместе с тем, ребята из группы ol1 не могут удалять каталоги-фамилии, потому как права для логина ol1 под которым будут входить ребята ограничиваются чтением и выполнением: user:ol1:r-x, а мы с вами знаем, что права на запрет имеют приоритет перед правами на разрешение.

Осталось решить вопрос с папкой «Задания». Создадим ее и назначим нужные права:

root@sytserver:/media/Work/Disk_child/olga_ch# cd ol1
root@sytserver:/media/Work/Disk_child/olga_ch/ol1# ls -l
root@sytserver:/media/Work/Disk_child/olga_ch/ol1# mkdir Zadaniya
root@sytserver:/media/Work/Disk_child/olga_ch/ol1# setfacl -d -m g:children:rx,g:pedagog:rwx Zad*
root@sytserver:/media/Work/Disk_child/olga_ch/ol1# setfacl -m g:children:rx,g:pedagog:rwx Zad*
root@sytserver:/media/Work/Disk_child/olga_ch/ol1# getfacl *
# file: Zadaniya
# owner: root
# group: root
user::rwx
group::---
group:children:r-x
group:pedagog:rwx
mask::rwx
other::---
default:user::rwx
default:group::---
default:group:children:r-x
default:group:pedagog:rwx
default:mask::rwx
default:other::---

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

8. Для начала нужно расшарить каталог на сервере NFS. Тут уж выбирать вам самим. Я к примеру, считаю, что в моем случае достаточно каталог olga_ch расшарить на доступ всем. Тем самым мы облегчим себе жизнь: не надо в этом случае экспортировать дополнительно каталоги ol1 - ol5, т.к. папка, содержащая их (olga_ch) уже будет расшарена. Т.к. функции ограничения будут осуществлять сами ACL, то нет ничего страшного в том, что папка olga_ch расшарена на доступ всем. Т.е. если какой то другой пользователь, отличный от olga или ol1 примонтирует себе каталог olga_ch, то доступ ко внутренностям он все равно не получит, ACL не дадут. Если у вас религиозные взляды отличаются от моих, то вам прямая дорога в сетевые группы (netgroup), забавная, кстати, вещь. С помощью них ограничите расшаривание так, как считаете нужным. Ну а для тех, у кого религиозные взгляды совпадают с моими, продолжаем разговор. Для расшаривания редактируем файл /etc/exports (см. последнюю строку):

# /etc/exports: the access control list for filesystems which may be exported
/media/Work/tmp @test(sync,rw)
/media/Work/deluge      (ro)
/media/Profil/home      (rw)
/media/Work/Disk_child/olga_ch      (rw)

Перестроим записи командой: exportfs -a.

9. Теперь осталось настроить pam_mount.conf.xlm, чтобы каталоги подключались пользователям при входе в систему. Помним, что файл pam_mount.conf.xlm лежит на сервере и все клиентские машины настройки считывают из него (см. часть 3). Его и редактируем. Лежит он у меня на сервере здесь: /media/Profil/home/pam_mount.conf.xml. Привожу полный конфиг с комментариями:

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd">
<pam_mount>


<debug enable="1" />
<mntoptions allow="nosuid,nodev,loop,encryption,fsck,nonempty,allow_root,allow_other" />
<mntoptions deny="suid,dev" />
<umount>sudo umount -l %(MNTPT)</umount>
<mntoptions require="nosuid,nodev" />
<path>/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin</path>
<logout wait="0" hup="0" term="0" kill="0" />
<mkmountpoint enable="1" remove="true" />

<!-- user options -->
<!-- Две последующие строки для организации временной файловой системы. Подключаются 
все пользователям, у которых основная группа children. (см. ЧАСТЬ 3) -->

<volume pgrp="children" fstype="tmpfs"  path="tmpfs" mountpoint="/tmp/%(USER)" 
options="size=50M,uid=%(USER),gid=children,mode=770" />

<volume pgrp="children" fstype="aufs" path="aufs" mountpoint="/tmp/%(USER)" 
options="dirs=/tmp/%(USER):/home/srv/.child=ro" />

<!-- Монтирование ресурса ol1 только для пользователя ol1 -->

<volume user="ol1" fstype="nfs"  server="sytserver" path="/media/Work/Disk_child/olga_ch/ol1" 
mountpoint="/media/Disk_ol1" options="hard,suid" />

<!-- Монтирование ресурса olga_ch только для пользователя olga -->

<volume user="olga" fstype="nfs"  server="sytserver" path="/media/Work/Disk_child/olga_ch" 
mountpoint="/media/Disk_group" options="hard,suid" />

</pam_mount>

Сохраняемся! И собственно все, можно проверять.

10. Теперь раскопируем структуру каталогов группы детей ol1 на остальные группы ol2…ol5. Имеем:

/media/Work/Disk_child/olga_ch > ls -l
итого 24
drwxrwx---+ 4 root root 4096 2009-08-10 19:57 ol1

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

root@sytserver:/media/Work/Disk_child/olga_ch# cp -R -p ./ol1 ol2
root@sytserver:/media/Work/Disk_child/olga_ch# cp -R -p ./ol1 ol3
root@sytserver:/media/Work/Disk_child/olga_ch# cp -R -p ./ol1 ol4
root@sytserver:/media/Work/Disk_child/olga_ch# cp -R -p ./ol1 ol5
root@sytserver:/media/Work/Disk_child/olga_ch# ls -l
итого 40
drwxrwx---+ 4 root root 4096 2009-08-10 19:57 ol1
drwxrwx---+ 4 root root 4096 2009-08-10 19:57 ol2
drwxrwx---+ 4 root root 4096 2009-08-10 19:57 ol3
drwxrwx---+ 4 root root 4096 2009-08-10 19:57 ol4
drwxrwx---+ 4 root root 4096 2009-08-10 19:57 ol5

Теперь осталось всего-то просто несколько модифицировать у каталогов ol2…ol5 права для пользователей, соответственно на ol2…ol5, потому как сейчас у этих каталогов доступ для пользователя ol1. Смотрим, например, для группы каталога ol2:

root@sytserver:/media/Work/Disk_child/olga_ch# getfacl ol2
# file: ol2
# owner: root
# group: root
user::rwx
user:ol1:r-x
user:olga:rwx
group::---
mask::rwx
other::---
default:user::rwx
default:group::---
default:group:children:rwx
default:group:pedagog:rwx
default:mask::rwx
default:other::---

Видно, что нужно заменить здесь только пользователя ol1 на ol2. Удаляем ACL для ol1 и меняем на ol2:

root@sytserver:/media/Work/Disk_child/olga_ch# setfacl -x u:ol1 ol2
root@sytserver:/media/Work/Disk_child/olga_ch# setfacl -m u:ol2:rx ol2
root@sytserver:/media/Work/Disk_child/olga_ch# getfacl ol2
# file: ol2
# owner: root
# group: root
user::rwx
user:ol2:r-x
user:olga:rwx
group::---
mask::rwx
other::---
default:user::rwx
default:group::---
default:group:children:rwx
default:group:pedagog:rwx
default:mask::rwx
default:other::---

Тоже самое нужно проделать для папок ol3..ol5.

Вот собственно и все. Внутри менять права не надо т.к. там права назначены у нас для групп pedagog и children.

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

Если объемы сервера большие, сильно на это не обращаешь внимания. Ну хранят и ладно. А вот ругаться начинаешь, когда предстоят какие-то работы, например, переезд на новый сервер или новую платформу, или винчестер надо заменить и т.п. Встает вопрос о резервации пользовательских файлов «куда-то», с последующим возвратом их на место. Ну бывают такие ситуации. Во тут и начинаешь ворчать, мол стока хлама всякого, куда девать?

Кто работает с пользователями, меня поймут. Объяснять (уговаривать) о необходимости порядка в своих ресурсах пользователей - бесполезно, особенно если эти пользователи - дети. Когда подходишь к педагогу и сообщаешь, что по рейтингу в черном списке «хламавщиков» она занимает второе место после администратора, глаза педагога округляются и произносится заветная фраза типа »Это не я, оно само!».

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

Квота - (от лат. quota - часть, приходящаяся на каждого) - Доля, часть, пай, норма ч.-л.

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

Частично использовалась информация из статей этой и этой. А также очень хорошо описано использование квот здесь.

Ubuntu (по крайней мере 8.04) поддерживает квотирование практически «из кароПки», для этого достаточно установить пакет quota:

sudo apt-get install quota

Собственно все! Вторым шагом будет активирование квот на тех разделах винчестера, где это необходимо. Для этого внесем необходимые изменения в файл /etc/fstab:

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# /dev/sda1
UUID=1b09f304-1772-4a87-bc1c-ee8c6170ef1e /               ext3    relatime,errors=remount-ro 0       1
# /dev/sda5
UUID=95b26917-535e-46ac-8d72-443d46184bb5  /media/Profil  ext3  grpquota,acl,suid,dev,usrquota,relatime,exec  0  2
# /dev/sda6
UUID=759a8adb-ed01-4d4f-b173-9005ad165368  /media/Work  ext3  grpquota,acl,suid,dev,usrquota,relatime,exec  0  2
# /dev/sda7
UUID=f90b3fb0-e515-4b4e-8a1b-dfe7ed269a10 none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto,exec,utf8 0       0
/dev/fd0        /media/floppy0  auto    rw,user,noauto,exec,utf8 0       0
/media/Work/test  /export/test  bind  bind  0

Из листинга fstab видно, что у разделов /dev/sda5 и /dev/sda6 в дополнительных параметрах монтирования указаны опции grpquota и usrquota. Из названий этих опций можно догадаться, что первая активирует поддержку квот для групп, вторая для пользователей. Указывать можно как обе опции для разделов винчестера, так и какую-нибудь из них. Логично, что убрав эти опции, поддержка квот отключится.

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

Итак, после перезагрузки компьютера, система готова для работы с квотами. На тех разделах НЖМД, где активированы квоты появятся файлы:

root@sytserver:/media/Work# ls -l
total 84
-rw-------   1 root root  8192 2009-09-04 20:17 aquota.group
-rwxr--r--   1 root root  8192 2009-07-29 18:21 aquota.group.new
-rw-------   1 root root  7168 2009-09-04 20:17 aquota.user
-rwxr--r--   1 root root  7168 2009-07-29 18:21 aquota.user.new

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

Для начала разберемся с некоторыми понятиями, а именно:

• Мягкий лимит (soft limits)
• Жесткий лимит (hard limits)
• Период отсрочки (grace period)

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

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

Период отсрочки - это период времени, после которого мягкий лимит принудительно ограничивает доступное пространство файловой системы для пользователя, после чего доступ на запись невозможен. Интервал времени можно указывает в секундах, минутах, часах и днях [seconds, minutes, hours, days].

Собственно, работа с квотами в основном заключается в использовании утилиты edquota.¹⁸⁾ Разберем ее синтаксис и часто используемые опции:

edquota [опции] [имя или группа пользователей]

Опции:

А собственно все. Это и есть основные опции. Теперь будем разбирать примеры их использования. Давеча мы заводили уже пользователя olga и группу pedagog, на ней и будем ставить эксперименты.

Выполним команду:

sudo edquota olga или sudo edquota -u olga

При выполнении этой команды откроется редактор по умолчанию со следующим содержанием:

Disk quotas for user olga (uid 1007):
  Filesystem                   blocks       soft       hard     inodes     soft     hard
  /dev/sda5                    173252          0          0       1790        0        0
  /dev/sda6                     19176          0          0         29        0        0

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

Столбец blocks - отражает количество используемых блоков пользователем на каждом разделе. А чему собственно равен 1 блок? Судя по документации 1 блок равен 1 килобайту.¹⁹⁾ Грубо говоря, здесь, пользователь olga уже потратила на разделе /dev/sda5 173252*1024=177 410 048 байт, ну, или, опять же, грубо 173 252 килобайт.

Столбец soft задает мягкое ограничение пользователю на количество блоков.

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

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

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

Очевидно, что манипулируя значениями soft и hard можно выставить ограничения на использование пространства жесткого диска. Обратите внимание, что столбцы blocks и inodes не подлежат изменению. При попытке записи файла с параметрами квот с измененными blocks или inodes, будет выдана ошибка примерно следующего содержания:

root@sytserver:/media/Profil/home# edquota olga
edquota: WARNING - /dev/sda5: cannot change current block allocation

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

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

Выполним команду:

sudo edquota -g pedagog

При выполнении этой команды откроется редактор по умолчанию со следующим содержанием:

Disk quotas for group pedagog (gid 1002):
  Filesystem                   blocks       soft       hard     inodes     soft     hard
  /dev/sda5                    596048          0          0       9912        0        0
  /dev/sda6                    278516          0          0       6337        0        0

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

• sudo edquota -t - Единый период времени для всех пользователей системы
• sudo edquota -t -g - Единый период времени для всех групп пользователей системы.

При выполнении первой команды откроется редактор по умолчанию со следующим содержанием (для пользователей):

Grace period before enforcing soft limits for users:
Time units may be: days, hours, minutes, or seconds
  Filesystem             Block grace period     Inode grace period
  /dev/sda5                     7days                  7days
  /dev/sda6                     7days                  7days

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

Период указывается в секундах, минутах, часах и днях (seconds, minutes, hours, days, ).

Аналогично для всех групп пользователей.

sudo edquota -T olga - Единый период времени для указанного пользователя системы
sudo edquota -T -g pedagog - Единый период времени для указанной группы пользователей системы.

При выполнении первой команды откроется редактор по умолчанию со следующим содержанием:

Times to enforce softlimit for user olga (uid 1007):
Time units may be: days, hours, minutes, or seconds
  Filesystem                         block grace               inode grace
  /dev/sda5                                 unset                  unset
  /dev/sda6                                 unset                  unset

Параметры block grace и inode grace могут принимать такие же значения как и в предыдущем случае с использование ключа -t, а также значение unset, которое отключает период для конкретного пользователя или группы. Логично, что приоритет будет у параметров конкретного пользователя (если ему задан отдельный от остальных период отсрочки).

Аналогично и для указанной группы пользователей.

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

sudo edquota -p исходный_пользователь конечный_пользователь….

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

Например:

sudo edquota -p ol1 ol2 ol3 ol4

Будут скопированы значения квот с пользователя ol1 на пользователей ol2, ol3, ol4.

root@sytserver:~# quota ol1
Disk quotas for user ol1 (uid 1001):
     Filesystem       blocks   quota     limit     grace     files     quota   limit   grace
      /dev/sda5       74208*   70000     80000     7days      1908       0       0    

Существует ряд дополнительных утилит для работы с квотами.

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

Пример использования:

quotacheck -avug

где:

• a — Проверяет все локально смонтированные файловые системы, в которых включены квоты
• v — Выводит подробную информацию о процессе проверке квот
• u — Проверяет информацию о дисковых квотах пользователей
• g — Проверяет информацию о дисковых квотах групп

quotaoff -vaug - Отключение всех квот не сбрасывая их значения в нуль. Если не один из параметров -u и -g не указан, отключаются только квоты пользователей. Если указан только параметр -g, отключаются только квоты групп. Чтобы снова включить квоты, выполните с теми же параметрами команду quotaon:

quotaon -vaug

Чтобы включить квоты в определённой файловой системе, например, /media/Profil, выполните следующую команду:

quotaon -vug /media/Profil

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

Для создания отчёта об использовании диска необходимо запустить утилиту repquota. Например, при выполнении команды repquota /media/Profil вы получите следующее:

root@sytserver:~# repquota /media/Profil
*** Report for user quotas on device /dev/sda5
Block grace time: 7days; Inode grace time: 7days
                        Block limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
root      -- 4451100       0       0          17568     0     0       
nobody    --       4       0       0              1     0     0       
allexserv --       4       0       0              1     0     0       
ol1       --   52948       0       0            956     0     0       
olga      --  257228       0       0           3022     0     0       
natasha   --  452048       0       0           6126     0     0       
tanya     --  123112       0       0           3136     0     0       
roma      --   49140       0       0           1831     0     0       
lmn       --   21840       0       0            989     0     0       
#502      --       8       0       0              1     0     0       

Чтобы просмотреть отчёт об использовании диска по всем (параметр -a) файловым системам, в которых включены квоты, выполните команду:

repquota -a

root@sytserver:~# repquota -a
*** Report for user quotas on device /dev/sda5
Block grace time: 7days; Inode grace time: 7days
                        Block limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
root      -- 4451100       0       0          17568     0     0       
nobody    --       4       0       0              1     0     0       
allexserv --       4       0       0              1     0     0       
ol1       --   52948       0       0            956     0     0       
olga      --  257228       0       0           3022     0     0       
natasha   --  452048       0       0           6126     0     0       
tanya     --  123112       0       0           3136     0     0       
roma      --   49140       0       0           1831     0     0       
lmn       --   21840       0       0            989     0     0       
#502      --       8       0       0              1     0     0       


*** Report for user quotas on device /dev/sda6
Block grace time: 7days; Inode grace time: 7days
                        Block limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
root      -- 21580372       0       0            164     0     0       
allexserv --   26352       0       0           1756     0     0       
ol1       --   23048       0       0            417     0     0       
ol2       --    5580       0       0            274     0     0       
ol3       --    4972       0       0            154     0     0       
ol4       --   77652       0       0            183     0     0       
ol5       --   14524       0       0            105     0     0       
olga      --  896304       0       0            907     0     0       
natasha   --   16400       0       0             97     0     0       
tanya     --  114680       0       0             31     0     0       
ol6       -- 1260348       0       0           6077     0     0       
ol7       --   22148       0       0            626     0     0       
ta1       --     240       0       0             12     0     0       
nm1       --       8       0       0              1     0     0       
nm2       --  395104       0       0            809     0     0       
artfsoft  --       4       0       0              1     0     0       
ta1x1     --      40       0       0              5     0     0       
ta1x4     --      40       0       0              5     0     0       
lmn       --   17716       0       0             44     0     0       
lmn1      --   14588       0       0             36     0     0   

Символы «- -», выводимые после имени пользователя, позволяют быстро определить, какой предел был превышен (блоков или inode). Если мягкий предел превышен, вместо тире появляется соответствующий + (плюс); при этом первый символ - (тире) представляет предел блоков, а второй — предел inode.

Раздел на стадии редактирования

Раздел в разработке

Думаю, каждый администратор устанавливая программу так или иначе, пусть, возможно, мимолетом, задумывался о правовых аспектах закона об авторский и смежных правах. Если в несвободном программном обеспечении вопрос о законности его использования более-менее закрывается покупкой соответствующего количества подходящих лицензий (!), то в СПО до сих пор царит хаос. Нет однозначного нормативного документа, где бы указывалось, что использование СПО на территории России является правомерным, равно как нет никаких документов прямо говорящих об обратном.

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

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

Итак, начнем.

(Раздел на стадии редактирования)

Обсуждение на форуме forum.ubuntu.ru

http://www.freebsd.org/doc/ru_RU.KOI8-R/books/handbook/network-nis.html
http://www.freebsd.org/doc/ru_RU.KOI8-R/books/handbook/network-nfs.html
http://www.linuxshare.ru/docs/HOWTO/NFS-HOWTO-6.html
http://web.iesrodeira.com/cgi-bin/man/man2html?pam_mount.conf+5
http://www.opennet.ru/openforum/vsluhforumID3/40938.html
http://www.opennet.ru/base/sys/linux_disk_quota2.txt.html
http://www.opennet.ru/base/sys/quota_mini_howto.txt.html
http://www.rhd.ru/docs/manuals/enterprise/RHEL-4-Manual/sysadmin-guide/ch-disk-quotas.html