Централизованное управление в Linux сети (1,2,3,4,5,8 из 8) [уже в wiki]

[allexnew]

Внимание! Обновлённый оригинал статьи находится на вики по адресу:

https://help.ubuntu.ru/wiki/централизованное_управление_linux

Вступление

Не секрет, что за использование нелицензионного ПО в организации администратор может всхлопотать от 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.

ПРЕДПОЛАГАЕТСЯ ЧТО:

- Установлен сервер Ubuntu 8.04, выполнены последние обновления
- Установлен клиент Ubuntu 9.04, выполнены последние обновления
- Установлено и настроено на сервере: WEBMIN, DHCPD3, BIND9 (опционально), NTPD (опционально)
- Вы знакомы с основными командами Unix, такие как копирование, смена прав, создание ссылок, редактирование файлов и др.

Все остальное в процессе How-to.

Примечание к статье

Ув. читатели! Статья, в первую очередь, пишется для себя, чтобы через пол года не думать над конфигами "а зачем я делал вот это?". Во-вторую очередь, т.к. информации по этой теме достаточно мало, а интерес пользователей по-моему растет. Более того, в качестве серверной ОС я всегда использовал FreeBSD, она мне ближе, но здесь будет описана конфигурация Server Ubuntu. Кто пользует FreeBSD, знает, что часто синтаксис и конфигурация в этих системах имеет расхождения.  В связи с этим, убедительная просьба не высказывать свое "фи", если вдруг вы увидели, что тот или иной момент решен, так сказать, костылем. Вместо того чтобы писать свои любимые "man команда" лучше предложите более элегантный способ решения того или иного момента, описав по-шагово что и как. Одним словом если вам есть что конструктивно дополнить или изменить в статье, то я только За, если кроме своего "фи" у вас больше ничего нет, то просто промолчите, в конце-концов описанные здесь решения проверены и работают.

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

(Нажмите, чтобы показать/скрыть)

ЧАСТЬ 1: Установка и настройка домена NIS, клиента NIS

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

Установка сервера NIS

Потребуется пакет nis, ставим его:

Код: [Выделить]

sudo apt-get install portmap, nis
Неплохо бы почитать о принципах работы NIS, например здесь. Далее, кто желает досканально ковырятся в конфиге, может проследовать в /var/yp/Makefile, кто экономит время, то  идем в WEBMIN "Сеть - Клиент и сервер NIS" и выбираем раздел "Сервер NIS". Для  базовой настройки этого достаточно, а напильником обработать всегда можно позже.

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

- Включить сервер NIS?: Да
- Тип сервера: Главный
- Обслуживаемый домен NIS: пишите свой домен. Обратите внимание, что не рекомендуется, чтобы этот домен совпадал с вашим доменом в интернете. Также рекомендуется указывать домен заглавными символами, чтобы в будущем отличать его имя от пользователей и групп. Собственно мой домен UBUNTU
- Все остальные параметры рекомендуется пока оставить как есть.

Немного о т.н. картах NIS. Карты nis пердоставляются сервером для клиентов домена. Основные карты это passwd., group., shadow., netgroup.. Если одним словом, то у клиента NIS как бы подменяются (дополняются) эти файлы соответствующими файлами сервера. Таким образом, каждый клиент NIS будет знать о существовании, например, пользователей сервера NIS. Отдельно стоит отметить сетевые группы (карта netgroup), но о них чуть позже.

После нажимаем кнопку "Сохранить и применить". Можно сказать что домен поднят. Проверьте, что демон 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 могут авторизироваться пользователи только с уидом более 1000 (это указано в настройках сервера NIS), более того, при добавлении, удалении, изменении параметров пользователей и групп необходимо заново перестраивать карты nis сервера. Это можно сделать написав команду make, предварительно зайдя в каталог /var/yp или нажав кнопку "Сохранить и применить" в WEBMIN "Сеть - Клиент и сервер NIS" - "Сервер NIS".

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

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

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

Установим пакет 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 сервер в своей сети, то можете столкнуться с такой проблемой: клиент NIS будет пытаться подключиться к серверу NIS ДО того, как компьютер получит адресацию от DHCP сервера и активирует сетевой интерфейс. Отсюда замечены следующие баги: Ubunta при загрузке начинает дико тормозить, делая бесполезные попытки найти NIS cервер при неактивном сетевом интерфейсе. Чтобы этого не происходило необходимо:

1. Отредактировать файл /etc/network/interfaces добавив в начало строки:

Код: [Выделить]

auto eth0
iface eth0 inet dhcp
где eth0 это сетевой интерфейс компьютера

2. Чтобы интерфейс стартовал до того, как клиент NIS будет искать домен необходимо в /etc/rc0.d переименовать ссылку @S35networking в @S15networking (заметьте, что при переименовании символ «@» писать не нужно). Также стоит чуть "отодвинуть" старт самого клиента NIS переименовав в /etc/rc2.d ссылку @S18nis в @S80nis
Кстати, шаг 2 рекомендуется сделать даже если у вас статическая адресация в сети.

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

Вот и все, клиент настроен. Основной разбор полетов здесь был именно в последнем шаге, когда ubunta пыталась подключиться к серверу раньше, чем сетевая плата активировалась системой.
Для проверки что клиент 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.

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

Примечания

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

Код: [Выделить]

sudo polkit-gnome-authorization
PS кстати, кто подскажет где лежит конфиг этих полномочий, а то что-то я найти его не смог?

• Дополнения и изменения в ЧАСТЬ 1:
  
  18.06.09 (22.21) - Замечено, что нет-нет да клиент NIS иной раз все же раньше стартанет. В связи с этим "отодвинул" запуск NIS клиента на чуть позднее переименовав в /etc/rc2.d ссылку @S18nis в @S80nis. В тексте части добавлен этот момент.
  19.06.09 (14:42) - Добавлен блок отладки при настройки клиента NIS
  25.07.09 (11:18) - Добавлено несколько общих строк о безопастности NIS.

(Нажмите, чтобы показать/скрыть)

ЧАСТЬ 2: Конфигурация сервера и клиента NFS

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

                                                        

Настройка сервера 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
(!) Исторически каждый nfsd демоном поддерживает один запрос за раз, по этому запускается несколько копий.

Теперь необходимо экспортировать каталоги для дальнейшего пользования клиентами. В NFS термин экспортировать  означает представить в общее пользование. здесь и далее я буду использовать термин расшарить (от. лат. share). За список расшаренных ресурсов отвечает файл /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:

secure - Требует, чтобы запрос на удаленный доступ поступал из привилегированного порта;
rw - Экспорт для чтения и записи (по умолчанию);
ro - Экспорт только для чтения;
async - Асинхронная обработка всех запросов на запись (отложенная запись); при наличии этой опции повышается производительность операций записи, равно как повышается вероятность потери данных в случае краха сервера;
sync - Синхронная обработка (прямая запись); запись будет производится немедленно при операции записи, без буферизации. Медленнее, но зато надежнее.

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

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

Не менее важный момент это безопасность. Вообще очень хорошо написано про NFS здесь (включая статью о безопасности).

Все, с сервером покончено.

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

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

- rw - монтирование ФС для чтения-записи (серер также должен экспортировать в режиме rw);
- ro - монтирования ФС только для чтения;
- bg - если монтирование прошло неудачно, перевести операцию в фоновый режим и продолжить обрабатывать другие запросы монтирования;
- hard - если сервер отключился, операции, которые пытаются получить к нему доступ, повторяются до тех пор, пока сервер не ответит;
- soft - если сервер отключился,  операции, которые пытаются получить к нему доступ, завершаются, выдавая сообщения об ошибке; полезно устанавливать, чтобы предотвратить зависание процессов в случае неудачного монтирования не очень важных ФС;
- rsize=n - размер буфера чтения n байт;
- wsize=n - размер буфера записи n байт;

например:

Код: [Выделить]

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 частях.

• Дополнения и изменения в ЧАСТЬ 2:
  
  20.06.09 (00:55) - Опечатался. Пакет nfs-common обязателен для установки на клиенте.

PS Форум отказался принимать более 3000 символов   . Если у модераторов есть возможность убрать ограничение для статьи, то соеденю все в одну.
В третьей части: Домашние папки храним на сервере NFS
В четвертой части: Подключаем шары NFS при входе в систему
В пятой части: Настраиваем права (или ACL, группы и иже с ними)
В шестой части: Сервер печати
В седьмой части: Общий репозиторий для клиентских машин (не обещаю эту часть)
В восьмой части: Квоты (или делим место на винчестере)
Приложение 1: Стандартные права Unix, SUID, SGID, Sticky биты (к 5 части)
Приложение 2: Решение задачи (к 5 части)
Приложение 3: Замена программ Windows их аналогами для школ (список)
Приложение 4: Вопросы лицензирования (или как уберечься от неумных "Маски Шоу")

[allexnew]

Продолжение (3 и 4 часть из 8)

Цели и задачи: Цели и задачи
В первой части: Установка и настройка домена NIS, клиента NIS
Во второй части: Конфигурация сервера и клиента NFS

(Нажмите, чтобы показать/скрыть)

ЧАСТЬ 3: Домашнии папки пользователей храним на сервере 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 соответственно. Не забываем перестроить карты nis! Обратите внимание, здесь указывается местоположение домашней папки где она будет смонтирована  на клиенте. Т.е. мы также не должны забыть создать на клиентской машине каталог /home/srv и назначить ему аттрибут... ну я пока назначаю 777. Именно туда будут монтироваться все домашние папки. Владелец не критичен.

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 все готово. При входе в систему он будет использовать свою домашнюю папку, которая на самом деле хранится на сервере.


Монтирование домашней папки без сохранения изменений в ней

Побродив по интернету и почитав различную документацию, остановился на модуле 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 в домашней папки пользователя. Но опять же придется прописывать эту опцию на всех клиентах.

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

Код: [Выделить]

<luserconf name=".pam_mount.conf.xml" />
я не буду описывать как делать символические ссылки, думаю, что если вы читаете эту статью, то знаете как это делается.
Для решения нашей задачи также потребуется установить два пакета:

!!! ВАЖНОЕ ЗАМЕЧАНИЕ !!!

Инструменты  unionfs-tools заменены на aufs-tools. Это одна и та же "программа", только переписанная с нуля. Подробнее смотрите "Изменения и дополнения" в конце этой части. С unionfs-tools возникли некоторые осложнения при использовании.

- unionfs-source_2.2.3-2.6.24-1_all.deb
- unionfs-tools_0.2.1-1_i386.deb

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

Собственно все готово, осталось сконфигурировать файл /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 user="child" fstype="tmpfs"  path="tmpfs" mountpoint="/tmp/tmpfs" options="size=25M,uid=child,gid=child,mode=0700" />
<volume user="child" fstype="unionfs" path="unionfs" mountpoint="/home/srv/child" options="dirs=/tmp/tmpfs:/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>


Разберем подробнее записи. В частности следующие две строки и есть реализация нашей задачи. Создается временный том в RAM-FS, и "объединяются" каталоги /tmp/tmpfs и /home/srv/child. О RAM-FS некоторое обсуждение есть здесь.

Код: [Выделить]

<volume user="child" fstype="tmpfs"  path="tmpfs" mountpoint="/tmp/tmpfs" options="size=25M,uid=child,gid=child,mode=0700" />
<volume user="child" fstype="unionfs" path="unionfs" mountpoint="/home/srv/child" options="dirs=/tmp/tmpfs:/home/srv/child=ro" />

(скопирую обозначения из источника) где:
"volume" - ключевое слово, сигнализирующее об описании раздела;
user="child" - имя пользователя, для которого определены правила монтирования;
fstype="tmpfs" - тип файловой системы;
path="tmpfs" - путь;
mountpoint="/tmp/tmpfs" - точка монтирования;
options="size=25M,uid=child,gid=child,mode=0700" - параметры монтирования tmpfs:
          "size=25m," - размер;
          "uid=child,gid=child,"  - владелец;
          "mode=0700" - права доступа;
option="dirs=/tmp/tmpfs:/home/srv/child" - параметры монтирования unionfs: указывают отобразить изменения /home/srv/child в директории /tmp/tmpfs

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

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

Код: [Выделить]

ALL ALL=NOPASSWD: /bin/umount
Будьте внимательны с редактированием этого файла. Для редактирования используйте: sudo visudo. В конце файла должна быть одна пустая строка.

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

Код: [Выделить]

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

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

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

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

В четвертой части более подробно разберем концигурацию pam_mount.conf.xml.

• Дополнения и изменения в ЧАСТЬ 3:
  
  22.06.09 (22:45) - Поспешил с заявлением "Сделаем для всех групп детей один общий домашний каталог". К сожалению, трюк, который я планировал сделать, не увенчался успехом. Убунте обязательно надо, чтобы пользователь, входящий в систему, обязательно был владельцем своего домашнего каталога. Все же, похоже, придется для каждой группы детей создавать свой домашний каталог, что по большому счету не критично, просто добавляет лишние телодвижения. Текст в части подправил.
  
  10.08.09 (21:25) - При использовании профиля на файловой системе tmpfs наблюдаются неполадки с работой FireFox. Возможно, после очередного обновления.
  
  03.09.09 (23:45) - Ввиду эксплуатации unionfs возникли некоторые сложности. При разборе полетов выяснилось, что unionfs заменен пакетом aufs, который является тем же самым, но полностью переписан с нуля в целях обеспечения устойчивости работы. В связи с этим, логично, что использовать стоит aufs. Синтаксис ее остался прежним, поэтому в статье, по тексту, следует установить пакет aufs-tools из репозиториев вместо unionfs-tolls, а в файле pam_mount.conf.xml строку:
  <volume user="child" fstype="unionfs" path="unionfs" mountpoint="/home/srv/child" options="dirs=/tmp/tmpfs:/home/srv/child=ro" />
  следует заменить строкой:
  <volume user="child" fstype="aufs" path="aufs" mountpoint="/home/srv/child" options="dirs=/tmp/tmpfs:/home/srv/child=ro" />
  остальное все по тексту.
  Оба варианта работоспособны, но какой из них более стабильнее покажет время.
  
  

(Нажмите, чтобы показать/скрыть)

ЧАСТЬ 4: Подключаем шары NFS при входе в систему

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

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

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

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

Основные параметры pam_mount.conf.xml

Полный 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 user="child" fstype="tmpfs"  path="tmpfs" mountpoint="/tmp/tmpfs" options="size=25M,uid=child,gid=child,mode=0700" />
<volume user="child" fstype="unionfs" path="unionfs" mountpoint="/home/srv/child" options="dirs=/tmp/tmpfs:/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 -->

Начнем с общих параметров.

• <debug enable="1" /> - включает отладку при экспериментах с авторизацией. Может принимать значения 0 (выключено), 1 и 2. Удобно отлаживать прямо в консоли используя "su имя_пользователя", результаты работы pam_mount будут выводиться прямо на в консоль.
• <luserconf name=".pam_mount.conf.xml" /> - Дополнительный файл конфигурации для конкретного пользователя. Этот файл с синтаксисом таким же как  и основной файл, размещается в домашнем каталоге пользователя и имеет имя указанное здесь, в данном случае .pam_mount.conf.xml. Может использоваться для подключения личных ресурсов пользователя, причем самим пользователем. Если этот параметр задан, то нужно указать в параметре <mntoptions> какие опции может пользователь использовать. Заметьте, что присоединение томов с помощью этого конфига будут делаться от имени пользователя входящего в систему и имеющий домашний каталог с этим конфигом, а не от пользователя root. (прим. Думаю, что если назначить права только на чтение этого файла и сделать владельцем рута, то администратор может оперировать этим файлом как дополнительным инструментом по своему усмотрению.)
• <mntoptions allow="options,..." /> - Сообщает какие опции разрешается использовать в параметре options тега <volume>. Распространяется только на личный файл конфигурации пользователя. Не распространяется на главнй файл конфигурации. Может быть несколько таких тегов, все последующие разрешения добавятся к предыдущим.
• <mntoptions deny="options,..." /> - Тоже самое только на запрет использования опций пользователем. Не распространяется на главнй файл конфигурации.
• <mntoptions require="options,..." /> - Какие опции должны обязательно присутствовать в файле конфигурации пользователя. По умолчанию nosuid,nodev. Не распространяется на главный файл конфигурации.
• <path>directories...</path> - собственно переменные окружения системы.

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

• <lclmount>mount -p0 -t %(FSTYPE) ...</lclmount> - путь к mount и ее параметры монтирования. Для специфичных или конкретных программ монтирования см. дополнительные опции в оригинальной документации pam_mount.
• <umount>umount %(MNTPT)</umount> - путь и параметры команды umount.

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

• %(USER) - имя пользователя. Экспортируется при входе пользователя в систему.
• %(USERUID), %(USERGID) - UID и GID залогинившегося пользователя. Удобно использовать в опциях монтирования, например:  <volume options="uid=%(USERUID)" />.
• %(FSTYPE) - Тип монтируемой файловой системы. Определяется из параметра <volume fstype="...">.
• %(SERVER) - Имя сервера с которого монтируются ресурсы. Определяется из параметра <volume server="...">.
• %(VOLUME) - Монтируемый ресурс на сервере. Определяется из параметра <volume path="...">.
• %(MNTPT) - Точка монтирования. Определяется из параметра <volume mountpoint="...">.

Расширенные теги пользовательского контроля для монтирования ресурсов. Иногда обычных параметров в теге <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> - UID  пользователя или диапазон UIDов.
• <gid>number</gid> or <gid>number-number</gid> - GID  пользователя или диапазон 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".

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

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

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

• fstype="type" - Тип файловой системы.
• server="name" - Имя или ИП адрес сервер для подключения (в случае сетевого монтирования).
• 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! Избавляет от кучи вопросов от пользователей, т.к. все что в нем смонтировано, будет отображено на рабочем столе ввиде диска, очень удобно.

[allexnew]

Продолжение (5 часть из 8)

Цели и задачи: Цели и задачи
В первой части: Установка и настройка домена NIS, клиента NIS
Во второй части: Конфигурация сервера и клиента NFS
В третьей части: Домашние папки храним на сервере NFS
В четвертой части: Подключаем шары NFS при входе в систему

(Нажмите, чтобы показать/скрыть)

ЧАСТЬ 5: Настраиваем права (или ACL, группы и иже с ними)

Итак, пришло время проговорить о безопастности вашей сети. В частности о назначении прав на каталоги и файлы для пользователей и групп. Вы уже должны быть знакомы со стандартными правами систем Unix. Они не так гибки, как хотелось бы. Очень рекомендую ознакомиться с ПРИЛОЖЕНИЕ 1 к статье - Стандартные права Unix, SUID, SGID, Sticky биты.

Ну чтож, вы освежили в памяти стандартные права Unix :). К сожалению они годятся для использования в простых схемах сети. Например, ситуацию когда к одному и тому же каталогу нужно чтобы несколько групп пользователей имели разные права доступа, не реализовать с использованием стандартных прав.

Для реализации сложных структур прав доступа используются расширенные права - ACL (access control list - cписки контроля доступа).


ACL права

Напомню:

• Каждый пользователь входит в минимум одну группу. Группа присваемая пользователю при его создании называется основной. Все остальные группы в которые будет включен пользователь, будут являться дополнительными.*
• Группа пользователей может содержать некоторое количество пользователей, но не может содержать или включаться в другие группы.
• Группа может быть пустой, т.е. не содержать в себе ни одного пользователя.

* - Наличие основной и дополнительных групп может также облегчить написание правил монтирования ресурсов при входе в систему (см. расширенные параметры модуля pam_mount в 4-ой части).

Чтобы добавить пользователя в ту, или иную группу, достаточно отредактировать файл /etc/group:

Код: [Выделить]

syslog:x:103:
klog:x:104:
scanner:x:105:hplip,allexserv
nvram:x:106:
fuse:x:107:allexserv

Видно, что в листинге выше в группу scanner входят пользователи  hplip и allexserv. Чтобы добавить в эту группу еще пользователей, просто перечислите их символьные имена через запятую. Синтаксис файла прост:

имя_группы:пароль:GID:список_пользователей

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

Часть информации взята с этого перевода. Также очень хорошо описан синтаксис ACL здесь. Надеюсь, авторы непротив, если часть текста я позаимствую из этих статей.

Списки контроля доступом (ACL) дают большую гибкость, чем стандартный набор полномочий "пользователь/группа/остальные". ACL доступны в коммерческих Unix-системах, таких как IRIX или Solaris (и в Windows NT) в течение нескольких лет. В настоящее время, благодаря проекту TrustedBSD, ACL доступны в FreeBSD 5.0 и выше, а также в Linux.

Включение ACL в системе

С какой-то там версии Ubuntu, поддержка ACL уже включена и поддерживается ядром. Но как бы то ни было, по умолчанию, в системе, ACL не активированы. Для того чтобы ОС начала учитывать списки контроля, необходимо ей об этом сказать. Для этого потребуется отредактировать файл /etc/fstab и указать в нем, на каких разделах HDD следует учитывать ACL права. Проверить, поддерживает ли тот или иной раздел винта ACL, можно попытавшись установить эти самые ACL, командой setfacl:

Код: [Выделить]

/root > setfacl -m u:allexserv:rw-,g:root:rw- qqq
setfacl: qqq: Operation not supported

Operation not supported - операция не поддерживается - бодро рапортует вам система! Это признак того, что ACL на этом разделе винчестера, где лежит файл qqq не активирована.  Чтож, давайте отредактируем /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

В тех разделах винчестера в которых указан дополнительный параметр -acl- команды mount  - grpquota,acl,suid - списки контроля будут поддерживаться в полном объеме. В моем случае поддержка ACL активирована на разделах /dev/sda5 и /dev/sda6.
После редактирования файла лучше не мучаться и перезагрузить сервер, хотя, как утверждается в некоторых статьях, достаточно отмонтировать раздел и примонтировать его вновь (такой номер у меня почему-то не прошел).

После вышеописанной операции, ACL на соответствующих разделах готовы к работе.

Работа с ACL

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

Существуют два типа ACL: ACL для доступа и ACL по умолчанию. ACL для доступа — это список управления доступом для заданного файла или каталога. ACL по умолчанию может быть связан только с каталогом, и если файл в этом каталоге не имеет ACL для доступа, он использует правила, определённые в ACL по умолчанию, связанном с каталогом. ACL по умолчанию являются необязательными. ACL по умолчанию также можно сравнить с наследованием прав в, простите, Windows.

Управления списками осуществляется всего лишь двумя командами:

setfacl - используется для назначения, модификации и удаления ACL прав.
getfacl - используется для просмотра установленных ACL.

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

Несколько слов обязательно нужно сказать о взаимодействии других команд (такие как копирование, перемещение, архивирование и т.п.) с правами ACL. Вот выдержка из статьи:

К сожалению, большинство Unix-утилит все еще не поддерживает ACL. Например, tar не архивирует и не восстанавливает ACL, в FreeBSD NFS также игнорирует их. Ни формат файлов в утилите tar, ни протокол NFS нет ни намека на возможность использования ACL. Тем не менее, архивы полного раздела UFS1, сделанные с помощью tar или dump, восстанавливают каталог .attribute, и утилита dump в FreeBSD модицицирована для для "понимания" UFS2 (включающую ACL). Каталог-скелет archivers/star поддерживает ACL. Вы даже можете работать с архивами, созданными в Linux и FreeBSD С помощью star и предохраняющей расширенные атрибуты (включающие и ACL).

Но не все так грустно! Перевод статьи был написан в 2006 году (к сожалению до оригинала я так и не добрался). В другой же статье сказано:

Ядро Red Hat Enterprise Linux 4 обеспечивает поддержку ACL для файловой системы ext3 и экспортируемых файловых систем NFS. Списки ACL также работают в файловых системах ext3, доступных через Samba.
...
Команды cp и mv копируют и перемещают все списки ACL, связанные с файлами и каталогами.


Хоть большиство стандартных команд, призванных производить операции над файлами уже поддерживают ACL то, например, команды архивирования tar и dump ACL не архивируют. Для архивации данных с установленными ACL используется программа star. В кратце ее рассмотрим позже.
Замечу, что для NFS ACL поддерживаются по умолчанию. Вобще успешное использование ACL зависит от поддержки ACL файловой системой и поддержки ACL операционной системой  на клиентской машине.

Возвращаемся к нашим баранам (у нас их два) - это утилитки setfacl и getfacl. Придется рассмотреть их синтаксис и параметры.

О getfacl сильно и говорить нечего. Она выводит листинг ACL прав для указанного файла или файлов. Примеры использования:

getfacl * - отобразит права ACL для всех объектов в текущем каталоге;
getfacl sobaka.txt - отобразить ACL для файла sobaka.txt;
getfacl kartosh* - отобразит ACL для всех файлов в текущем каталоге, которые начинаются на kartosh;
getfacl -R * - отобразит ACL для всех объектов (включая подкаталоги и их содержимое) текущего каталога.

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

Теперь об утилите setfacl. Списки ACL можно настроить:

• На уровне пользователей
• На уровне групп
• С помощью маски эффективных прав
• Для пользователй, не включённых в группу данного файла

Рассмотрим простой синтаксис setfacl:

setfacl <опции> <ключ> <список правил> <файл или каталог>

<опции> - задает дополнительные опции;
<ключ> - задает режим работы утилиты;
<список правил> - собственно правила доступа к объекту (кому че можно, а кому нельзя);
<файл или каталог> - объект к которому применяется ACL.

Частоиспользуемые ключи:

--set или --set file* - Устанавливает новые указанные права ACL, удаляя все существующие. Необходимо, чтобы наравне с задаваемыми правилами ACL были также указаны стандартные права Unix, в противном случае будет давать ошибку;
-m или -M file* - Модифицирует указанные ACL на объекте. Другие существующие ACL сохраняются.
-x или -X file* - Удаляет указанные ACL права с объекта. Стандартные права Unix не изменяются.

Частоиспользуемые опции:

-b - Удаляет все ACL права с объекта, сохраняя основные права;
-k - Удаляет с объекта ACL по умолчанию. Если таковых на объекте нет, предупреждение об этом выдаваться не будет;
-d - Устанавливает ACL по умолчанию на объект.
--restore=file - Восстанавливает ACL права на объекты из ранее созданного файла с правами. Полезно для отката разрешений. Разумеется, необходимо сначала сделать резервную копию разрешений в текстовый файл file. Сделать можно либо вручную, в формате вывода getfacl, либо использовать команду getfacl -R file > file_out. Где file это файл(ы) или каталоги с которых нужно снять ACL, а file_out - текстовый файл куда запишутся снятые ACL права.

-R - Рекурсивное назначение (удаление) прав, тобишь пройтись по всем подкаталогам.

* При использовании -M, --set, -X разрешения будуть браться из указанного файла file, который должен быть заранее подготовлен в формате вывода ACL разрешений командой getfacl. Подготовить файл можно либо вручную, в формате вывода getfacl, либо использовать команду getfacl -R file > file_out. Где file это файл(ы) или каталоги с которых нужно снять ACL, а file_out - текстовый файл куда запишутся снятые ACL права.

Формирование списка правил:

u:<uid>:<perms>* - Назначает ACL для доступа заданному пользователю. Здесь можно указать имя или код пользователя. Это может быть любой пользователь, допустимый в данной системе. Пример: setfacl -m u:allexserv:rw myfile.odt

g:<gid>:<perms>* - Назначает ACL для доступа заданной группе. Здесь можно указать имя или код группы. Это может быть любая группа, допустимая в данной системе. Пример: setfacl -m g:children:r myfile.odt

m:<perms>* - Назначает маску эффективных прав. Маска — это объединение всех разрешений группы-владельца и всех записей пользователй и групп. Маска задает максимальные права доступа для всех пользователей, за исключением хозяина и групп. Установка маски представляет собой самый быстрый путь изменить фактические (эффективные) права доступа всех пользователей и групп. Например, маска r-- показывает, что пользователи и группы не могут иметь больших прав, чем просто чтение, даже если им назначены права доступа на чтение и запись. Например, если на файл koshka назначили ACL пользователю allexserv c правами rwx, а эффективную маску выставили в rx, то пользователь лишается права w, не смотря на то, что по ACL он имеет это право. Пример:  setfacl -m m:rx myfile.odt

o:<perms>* - Назначает ACL для доступа пользователям, не включённым в группу файла. Это пользователь "все остальные", как в стандартных правах Unix. Пример: setfacl -m o: myfile.odt - убирает все права (отсутствие прав).

* <perms> - правила для пользователя или группы. Могут принимать значения r, x, w.

C теорией покончено, давайте уже будем пробовать как да что. Итак, попробуем слегонца назначить пользователю child права ACL на файл qwert:

Код: [Выделить]

root@sytserver:/media/Work/test# ls -l
итого 24
drwxrwxrwt 2 root root 4096 2009-07-24 21:20 allex
-rwxr----- 1 root root   19 2009-07-25 14:45 qwert

# Устанавливаю права ACL:

root@sytserver:/media/Work/test# setfacl -m u:child:rw qwert

# Символ "+" в конце списка стандартных прав сообщает о наличии установленных прав ACL:

root@sytserver:/media/Work/test# ls -l
итого 28
drwxrwxrwt  2 root root 4096 2009-07-24 21:20 allex
-rwxr-x---+ 1 root root   19 2009-07-25 14:45 qwert

# Посмотрим как отображаются права ACL c помощью getfacl:

root@sytserver:/media/Work/test# getfacl qwert
# file: qwert
# owner: root
# group: root
user::rwx
user:child:rw-
group::r--
mask::rw-
other::---

Из примера видно, что без использования ACL, пользователь child не получил бы права к файлу qwert, т.к. не входит в группу root и не является владельцем файла. Права ACL, в данном случае, предоставили ему права на чтение и запись этого файла. Давайте подробнее разберем листинг getfacl:  

# file: qwert     - Имя файла
# owner: root  - Владелец файла (основные права Unix)
# group: root   - Группа файла (основные права Unix)
user::rwx         - Права для владельца файла (основные права Unix)
user:child:rw-    - Права ACL для пользователя child
group::r--         - Права для группы файла (основные права Unix)
mask::rw-          - Эффективная маска
other::---          - Права для пользователя "все остальные"

Теперь давайте добавим к этому файлу еще пользователя allexserv:

Код: [Выделить]

root@sytserver:/media/Work/test# setfacl -m u:allexserv:rwx qwert
root@sytserver:/media/Work/test# getfacl qwert
# file: qwert
# owner: root
# group: root
user::rwx
user:allexserv:rwx
user:child:rw-
group::r--
mask::rwx
other::---

Обратите внимание как изменилась эффективная маска. Все ACL права сложились: у пользователя child rw- и у пользователя allexserv rwx. Но маска вовсе не разрешает пользователю child иметь права выполнение (x). Посмотрите, что произойдет если принудительно изменить эффективную маску:
 

Код: [Выделить]

root@sytserver:/media/Work/test# setfacl -m m:r qwert
root@sytserver:/media/Work/test# getfacl qwert
# file: qwert
# owner: root
# group: root
user::rwx
user:allexserv:rwx          #effective:r--
user:child:rw- #effective:r--
group::r--
mask::r--
other::---

Теоретически, как гласит описание, в данном случае пользователь child не может удалить файл (про allexserv ничего не говорю, т.к. он входит в группу root у меня). Но проведя тест, пользователь child все-таки удалил файл, правда перед удалением система спросила:

Код: [Выделить]

child@sytserver:/media/Work/test$ rm qwert
rm: удалить защищенный от записи обычный файл `qwert'?
В тоже время попробовал отредактировать qwert под пользователем child и попытался записать изменения. Здесь система в записи отказала. Вобщем странный момент. Недоверяю я этой маске. Нужно будет еще подумать.

Теперь давайте удалим с файла qwert права ACL для пользователя allexserv:

Код: [Выделить]

root@sytserver:/media/Work/test# setfacl -x u:allexserv qwert
root@sytserver:/media/Work/test# getfacl qwert
# file: qwert
# owner: root
# group: root
user::rwx
user:child:rw- #effective:r--
group::r--
mask::r--
other::---

Чтобы удалить все ACL права с файла можно воспользоваться командой: setfacl -b qwert

Очевидно, что таким макаром можно назначать и удалять ACL права для пользователей и групп на файлы и каталоги.
Давайте еще рассмотрим т.н. наследованность прав. Если не задано иное, то все объекты создаваемые в каталоге у которого есть ACL, не наследуют права ACL c каталога в котором они создаются. Но иногда возникают ситуации, когда необходимо, чтобы все объекты создаваемые внутри каталога наследовали его ACL права. Это называются ACL по умолчанию.

Задача: создадим каталог Proverka  и назначим ему владельца child и группу children. Установим ACL права для пользователя allexserv и пользователя mysql. Установим ACL по умолчанию так, чтобы создаваемым объектам также назначались ACL c каталога Proverka.

Код: [Выделить]

# Создаем каталог, устанавливаем права и владельца:

root@sytserver:/media/Work/test# mkdir Proverka
root@sytserver:/media/Work/test# chmod 700 Proverka
root@sytserver:/media/Work/test# chown child:children Proverka
root@sytserver:/media/Work/test# ls -l
итого 24
drwxrwxrwt 2 root  root     4096 2009-07-24 21:20 allex
drwx------ 2 child children 4096 2009-07-25 23:36 Proverka

# Назначаем ACL права сразу для двух пользователей, перечислив их через запятую:

root@sytserver:/media/Work/test# setfacl -m u:allexserv:rwx,u:mysql:rwx Proverka
root@sytserver:/media/Work/test# getfacl Proverka
# file: Proverka
# owner: child
# group: children
user::rwx
user:mysql:rwx
user:allexserv:rwx
group::---
mask::rwx
other::---

# Теперь назначим ACL по умолчанию. При назначении ACL по умолчанию, также требуется в обязательном порядке указывать
# и основные права в виде u::rwx,g::-,o::- где u - user - владелец, g - group - группа, o - other - все остальные:

root@sytserver:/media/Work/test# setfacl -d -m u::rwx,g::-,o::-,u:allexserv:rwx,u:mysql:rwx Proverka
root@sytserver:/media/Work/test# getfacl Proverka
# file: Proverka
# owner: child
# group: children
user::rwx
user:mysql:rwx
user:allexserv:rwx
group::---
mask::rwx
other::---
default:user::rwx
default:user:mysql:rwx
default:user:allexserv:rwx
default:group::---
default:mask::rwx
default:other::---


# Видно, что появились строки начинающиеся с default - это и есть права по умолчанию, которые будут принимать все
# создаваемые внутри объекты. Проверим, создав пустой файл myfile.txt и подкаталог MyKatalog в каталоге Proverka:

root@sytserver:/media/Work/test/Proverka# touch myfile.txt
root@sytserver:/media/Work/test/Proverka# mkdir MyKatalog
root@sytserver:/media/Work/test/Proverka# getfacl *
# file: myfile.txt
# owner: root
# group: root
user::rw-
user:mysql:rwx #effective:rw-
user:allexserv:rwx #effective:rw-
group::---
mask::rw-
other::---

# file: MyKatalog
# owner: root
# group: root
user::rwx
user:mysql:rwx
user:allexserv:rwx
group::---
mask::rwx
other::---
default:user::rwx
default:user:mysql:rwx
default:user:allexserv:rwx
default:group::---
default:mask::rwx
default:other::---

Вот блин, эффективная маска создаваемых файлов почему-то rw :(. Интересно почему... Хотя сценарии выполняются... Вобщем мозг взрывает будь здоров! Ладно, оставим на потом.

Удалить права по умолчанию можно: setfacl -k Proverka. Если нужно также удалить права по умолчанию и в подкаталогах, то добавьте ключ -R: setfacl -R -k Proverka.

Вобщем затея с правами ACL очень интересная! Здесь мы оперировали двумя пользователями. Но ничто не мешает вам оперировать также группами пользователей.

Множественные автоматические операции.

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

Копирование ACL прав с одного файла на другой. Принцип прост:

- Снять ACL c одного объекта
- Записать их на другой

В документации приведен следующий пример:

getfacl file1 | setfacl --set-file=- file2

Где, file1 - объект с которого снимаем ACL командой getfacl, а далее устанавливаем ACL командой setfacl на объект file2. Обратите внимание на запись --set-file=- в конце указан символ "-", видимо, который берет информацию от команды getfacl (со стандартного вывода). Справедлива будет также такая запись:
  
getfacl file1 | setfacl -M- file2

В этом случае права на file2 не заменяются как при использовании --set, а добавляются к уже существующим правам ACL.

Другой пример: копирование прав ACL каталога в права по умолчанию этого же каталога:

getfacl --access dir | setfacl -d -M- dir

В этом примере getfacl получает все права которые вы установили на каталог dir и устанавливат их на этот же каталог dir делая их правами по умолчанию. Очень удобно. Обратите внимание на ключ --access у команды getfacl. При вызове getfacl без параметров, она отображает все права ACL, включая права по умолчанию. Здесь же, ключ --access заставляет getfacl показать только права ACL на каталог, а права по умолчанию (если таковые имеются у каталога) - скрыть. Обратный ключ - это ключ -d :

getfacl -d Proverka

заставит getfacl показать только права по умолчанию, а права ACL на сам каталог - скрыть. Кстати, в нашем примере, с каталогом Proverka, на который мы назначали права по умолчанию, чтобы не писать строку:

setfacl -d -m u::rwx,g::-,o::-,u:allexserv:rwx,u:mysql:rwx Proverka  

можно было бы воспользоваться именно этой фишечкой, как то так:

getfacl --access Proverka | setfacl -d -M- Proverka

Результат был бы тот же. Вот и все, а вобще, не поленитесь почитать man getfacl.

Операции над объектами у которых имеются ACL права.

В заключении хочу еще раз обратить внимание на операции с обектами у которых установлены ACL, такие как копирование, перемещение, архивирование. Выше мы уже упоминали о них. Некоторые замечания:

- При перемещении (mv) никаких дополнительных параметров ненужно;
- При копировании (cp), необходимо использовать ключ -p, в противном случае ACL права будут потеряны;
- При архивировании или распаковке вместо tar используем утилиту star.

Утилиту star нужно будет установить из репозиториев: apt-get install star
Вот некоторые частоиспользуемые опции star:

-c   Создаёт файл архива
-n   Отключает извлечение файлов, используется в сочетании с -x для просмотра списка извлекаемых файлов.
-r   Заменяет файлы в архиве. Файлы записываются в конец архива, заменяя любые файлы с тем же путём и именем.
-t   Выводит содержимое файла архива.
-u   Обновляет файл архива. Файлы записываются в конец архива, если их ещё не было в архиве или если они новее, чем файлы с тем же именем в архиве. Этот параметр работает только если архив представляет собой файл или незаблокированную ленту, которую можно стирать.
-x   Извлекает файлы из архива. Если используется с ключом -U и файл в архиве старее, чем соответствующий файл в файловой системе, такой файл не извлекается.
-help   Выводит наиболее важные параметры.
-xhelp   Выводит менее важные параметры.
-/   Оставляет ведущую косую черту в имени файла при извлечении файлов из архива. По умолчанию она убирается.
-acl   При создании архива или извлечении файлов, архивирирует или восстанавливает все ACL, связанные с файлами или каталогами.

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


PS Чуть позже попробуем решить более сложную задачу с использованием ACL:

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

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

Во как! Задачу сделаю в виде приложения, а то форум опять будет ругаться, что я превысил 30000 знаков в сообщении.

• Дополнения и изменения в ЧАСТЬ 5:
  
  26.07.09 (02:56) - Не совсем ясно получилось с эффективными масками. В частности, в середине статьи, где пользователь child все-таки может удалить файл qwert несмотря на то, что эффективная маска - r--, плюс пользователь не является владельцем файла и не принадлежит группе root. Вобщем либо баг, либо я чего-то до конца не догоняю. Воздержусь пока от применения эффективных масок на практике.
  
  31.08.09 (02:04) - Наконец-то дошли руки опубликовать решение задачи, которая описывается в конце части. Решение задачи в ПРИЛОЖЕНИЕ 2.
  
  

В шестой части: Сервер печати
В седьмой части: Общий репозиторий для клиентских машин (не обещаю эту часть)
В восьмой части: Квоты (или делим место на винчестере)
Приложение 1: Стандартные права Unix, SUID, SGID, Sticky биты (к 5 части)
Приложение 2: Решение задачи (к 5 части)
Приложение 3: Замена программ Windows их аналогами для школ (список)
Приложение 4: Вопросы лицензирования (или как уберечься от неумных "Маски Шоу")

[allexnew]

Приложение 1

Цели и задачи: Цели и задачи
В первой части: Установка и настройка домена NIS, клиента NIS
Во второй части: Конфигурация сервера и клиента NFS
В третьей части: Домашние папки храним на сервере NFS
В четвертой части: Подключаем шары NFS при входе в систему
В пятой части: Настраиваем права (или ACL, группы и иже с ними)
В шестой части: Сервер печати
В седьмой части: Общий репозиторий для клиентских машин (не обещаю эту часть)
В восьмой части: Квоты (или делим место на винчестере)

(Нажмите, чтобы показать/скрыть)

Приложение 1 - Стандартные права Unix, SUID, SGID, Sticky биты

Стандартные права Unix
Приложение к 5 части статьи.

Прежде чем мы займемся ACL правами, считаю необходимым освежить в памяти как работают стандартные права Unix. Выведем для примера листинг содержимого каталога:

Код: [Выделить]

/media/Work/applicat > ls -l
итого 1308
-rwx------  1 allexserv nogroup 638116 2009-06-25 20:42 autumnscolor.zip
drwxr-xr-x 13 allexserv nogroup   4096 2009-05-31 14:58 phpBB3
drwx------ 10 allexserv nogroup   4096 2009-06-25 14:29 phpMyAdmin-3.2.0-all-languages
-rwx------  1 allexserv nogroup 677334 2009-06-25 20:42 pro_ubuntu.zip
drwxr-xr-x  2 allexserv nogroup   4096 2009-06-25 14:29 безымянная папка

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

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

Код: [Выделить]

OCT        BIN          Mask
------------------------------------
  0        000          --- отсутствие прав  
  1        001          --x права на выполнение
  2        010          -w- права на запись
  3        011          -wx права на запись и выполнение
  4        100          r-- права на чтение
  5        101          r-x права на чтение и выполнение
  6        110          rw- права на чтение и запись
  7        111          rwx полные права

Для назначения обычных прав используются три восмеричные цифры (9 битов). Первая цифра определяет права для владельца файла, вторая - права для основной группы пользователя, третья - для всех остальных пользователей. Так, например, чтобы задать права на файл всем и вся, нужно установить права 777 (rwxrwxrwx). Существуют также специальные биты, такие как SUID, SGID и Sticky-бит. Они влияют на запуск файла. При их применении необходимо использовать не три восмеричных цифры, а 4. Зачастую, в различной технической литературе права обозначаются именно 4-мя цифрами, например 0744. Почему-то многие стараются не использовать специальные биты, сетуя на безопастность, но, по-моему, их использование в некоторых ситуациях очень оправдано. Поговорим о них несколько позже.

Не буду далеко залазить в дебри, давайте будем рассматривать жизненные примеры, итак:

Код: [Выделить]

-rwx------  1 allexserv nogroup 677334 2009-06-25 20:42 pro_ubuntu.zip
drwxr-xr-x  2 allexserv nogroup   4096 2009-06-25 14:29 безымянная папка
Для первой строки первый символ пустой: "-" для файлов. Следующие три символа обозначают права для владельца файла, в данном случае полные права для пользователя allexserv (по умолчанию, при создании файла устанавливаются полные права для владельца). Следующие три - определяют права для группы nogroup, в нашем примере для всех пользователей группы nogroup доступ запрещен. Ну и последние три символа определяют права для всех остальных пользователей,  в нашем случае доступ запрещен. Восмеричное обозначение прав для файла pro_ubuntu.zip: 0700.

Для второй строки (это каталог, о чем свидетельствует первый символ "d"), по аналогии: для владельца каталога allexserv - полные права, для группы nogroup и всех остальных - права только на листинг каталога. Восмеричное обозначение в этом примере: 0755. Напомню, что для того, чтобы пользователи могли просматривать каталог, необходимы права на чтение и выполнение каталога, т.е. минимальные права на каталог 0555 (r-xr-xr-x), прав 0444 (r--r--r--) будет недостаточно для входа в каталог.

Права устанавливаются командой chmod. По умолчанию пользовать ее может только root.

chmod 744 koshka.txt - установит права для файла koshka.txt - (rwx-r--r--);
chmod -R 775 sobaki - установит права на каталог sobaki и на все, что внутри этого каталога, включая содержимое подкаталогов (ключ -R - реверсивный режим установки прав) (rwxrwxr-x);
chmod 700 ap* - установит права только для владельца на все файлы и каталоги в текущем каталоге, имя которых начинается на символы ap (rwx------).

Биты SUID, SGID и Sticky

Unix отслеживает не символьные имена владельцев и групп, а их идентификаторы (UID - для пользователей и GID для групп). Эти идентификаторы хранятся в файлах /etc/passwd и /etc/group соответственно. Символьные эквиваленты идентификаторов используются только для удобства, например, при использовании команды ls, идентификаторы заменяются соответствующими символьными обозначениями.

vipw
allexserv:x:1000:0:allexserv,,,:/home/allexserv:/bin/bash

1000 - идентификатор (UID) пользователя allexserv
0 - идентификатор (GID) основной группы (root) для пользователя allexserv

/etc/group
allexserv:x:1000:

1000 - идентификатор (GID) дополнительной группы allexserv пользователя allexserv  (!!!)

Обратите внимание, в этом примере основная группа при создании пользователя allexserv - это группа root (идентификатор 0), а группа allexserv (1000) - считалась бы дополнительной. В данном примере пользователь allexserv не входит больше в группу allexserv (видимо я, при создании себя сначала напарил с группами, а потом исправил), так что группа allexserv на данный момент пуста.
Зачастую, при создании пользователя, если не указано иное, идентификатор пользователя равен идентификатору его группы. Например:

vipw
backup:x:34:34:backup:/var/backups:/bin/sh

/etc/group
backup:x:34:

Что касается процессов, то с ними связано не два идентификатора, а 4-е: реальный и эффективный пользовательский (UID), а также реальный и эффективный групповой (GID). Реальные номера применяются для учета использования системных ресурсов, а эффективные для определения прав доступа к процессам. Как правило, реальные и эффективные идентификаторы совпадают. Владелец процесса может посылать ему сигналы, а также изменять приоритет.
Процесс не может явно изменить ни одного из своих четырех идентификаторов, но есть ситуации когда происходит косвенная установка новых эффективных идентификаторов  процесса. Дело в том, что существуют два специальных бита: SUID (Set User ID - бит смены идентификатора пользователя) и SGID (Set Group ID - бит смены идентификатора группы). Когда пользователь или процесс запускает исполняемый файл с установленным одним из этих битов, файлу временно назначаются права его (файла) владельца или группы (в зависимости от того, какой бит задан). Таким образом, пользователь может даже запускать файлы от имени суперпользователя.

Восмеричные значения для SUID и SGID - 4000 и 2000.
Буквенные: u+s и g+s.

Вобщем одним словом установка битов SUID или SGID позволит пользователям запускать исполняемые файлы от имени владельца (или группы) запускаемого файла. Например, как говорилось выше, команду chmod по умолчанию может запускать только root. Если мы установим SUID на исполняемый файл /bin/chmod, то обычный пользователь сможет использовать эту команду без использования sudo, так, что она будет выполнятся от имени пользователя root. В некоторых случаях очень удобное решение. Кстати по такому принципу работает команда passwd, c помощью которой пользователь может изменить свой пароль.

Возьмите на заметку: если установить SGID для каталога, то все файлы созданные  в нем при запуске будут принимать идентификатор группы каталога, а не группы владельца, который создал файл в этом каталоге. Аналогично SUID. Одним словом, если пользователь поместил исполняемый файл в такой каталог, запустив его, процесс запустится от имени владельца (группы) каталога, в котором лежит этот файл.

Установить SUID и SGID можно командой chmod:

chmod 4755 koshka.pl - устанавливает на файл koshka.pl бит SUID и заменяет обычные права на 755 (rwxr-xr-x).
chmod u+s koshka.pl - тоже самое, только обычные права не перезаписываются.

chmod 2755 koshka.pl - устанавливает на файл koshka.pl бит SGID и заменяет обычные права на 755 (rwxr-xr-x).
chmod g+s koshka.pl - тоже самое, только обычные права не перезаписываются.

Догадайтесь, что произойдет если выполнить такую команду :

chmod 6755 koshka.pl

Чтобы снять установленные биты:

chmod g-s koshka.pl
chmod u-s koshka.pl

Код: [Выделить]

/media/Work/test > ls -l
итого 20
drwxr-xr-x 2 root root 4096 2009-06-15 16:18 allex
drwx------ 2 root root 4096 2009-06-15 14:20 qqq
-rwxrwsrwx 1 root root    0 2009-07-24 19:42 qwert


Видно, что для файла qwert установлен SGID, о чем свидетельствует символ "s" (-rwxrwsrwx). Символ "s" может быть как строчная буква (s), так и прописная (S). Регистр символа только лишь дает дополнительную информацию об исходных установках.

Еще одно важное усовершенствование касается использования sticky-бита в каталогах. Каталог с установленным sticky-битом означает, что удалить файл из этого каталога может только владелец файла или суперпользователь. Другие пользователи лишаются права удалять файлы (даже если имеют права 7, хотя писать (создавать) файлы в таких каталогах они могут, при условии что имеют права 7). Установить sticky-бит в каталоге может только суперпользователь. Sticky-бит каталога, в отличие от sticky-бита файла, остается в каталоге до тех пор, пока владелец каталога или суперпользователь не удалит каталог явно или не применит к нему chmod. Заметьте, что владелец может удалить sticky-бит, но не может его установить.

В отличии установки sticky на каталог, на файл такой бит устанавливать уже не имеет смысла. Многие современные ядра попросту игнорируют sticky на файле. На файлах он использовался на старых системах с малой ОЗУ и был очень важен в те времена. Он запрещал выгрузку программ из памяти.  

Восмеричное значение stiky-бита: 1000
Символьное: +t
 
Установить sticky-бит на каталог можно:

chmod 1755 allex - с заменой прав
chmod +t allex

Убрать:

chmod -t allex

Код: [Выделить]

/media/Work/test > ls -l
итого 20
drwxr-xr-t 2 root root 4096 2009-06-15 16:18 allex
drwx------ 2 root root 4096 2009-06-15 14:20 qqq
-rwxr--r-T 1 root root    0 2009-07-24 19:42 qwert
-rw-r--r-- 1 root root 4099 2009-06-11 14:14 sources.list

Видно, что sticky-бит установлен на каталоге allex, а также на файле qwert, о чем свидетельствует символ (t).
Символ "t" может быть как строчная буква (t), так и прописная (T). Строчная буква отображается в том случае, если перед установкой “sticky bit” произвольный пользователь уже имел право на выполнение (х), а прописная (Т) — если такого права у него не было. Конечный результат один и тот же, но регистр символа дает дополнительную информацию об исходных установках.

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

Пример с каталогом на котором установлен sticky:

Код: [Выделить]

/media/Work/test > ls -l
итого 20
drwxrwxrwx 2 root root 4096 2009-07-24 20:54 allex
drwx------ 2 root root 4096 2009-06-15 14:20 qqq

# Устанавливаю sticky-бит:

/media/Work/test > chmod +t allex
/media/Work/test > ls -l
итого 20
drwxrwxrwt 2 root root 4096 2009-07-24 20:54 allex
drwx------ 2 root root 4096 2009-06-15 14:20 qqq

/media/Work/test > cd allex
/media/Work/test/allex > ls -l
итого 4
-rw-r----- 1 root fuse 215 2009-06-10 19:54 fuse.conf

# Создаю файл с разрешением 777 (полные права для всех):

/media/Work/test/allex > touch proverka
root@sytserver:/media/Work/test/allex# ls -l
итого 4
-rw-r----- 1 root fuse 215 2009-06-10 19:54 fuse.conf
-rw-r--r-- 1 root root   0 2009-07-24 21:20 proverka

root@sytserver:/media/Work/test/allex# chmod 777 *
root@sytserver:/media/Work/test/allex# ls -l
итого 4
-rwxrwxrwx 1 root fuse 215 2009-06-10 19:54 fuse.conf
-rwxrwxrwx 1 root root   0 2009-07-24 21:20 proverka

# Захожу под обычным пользователем child и пытаюсь удалить файл proverka:

root@sytserver:/media/Work/test/allex# su child
child@sytserver:/media/Work/test/allex$ cd /media/Work/test/allex
child@sytserver:/media/Work/test/allex$ ls -l
итого 4
-rwxrwxrwx 1 root fuse 215 2009-06-10 19:54 fuse.conf
-rwxrwxrwx 1 root root   0 2009-07-24 21:20 proverka

child@sytserver:/media/Work/test/allex$ rm proverka
rm: невозможно удалить `proverka': Operation not permitted
child@sytserver:/media/Work/test/allex$


• Дополнения и изменения в ПРИЛОЖЕНИЕ 1:
  
  06.09.2009 (04:00) - Исправил несколько досадных опечаток (не критичных).
  

Приложение 2: Решение задачи (к 5 части)
Приложение 3: Замена программ Windows их аналогами для школ (список)
Приложение 4: Вопросы лицензирования (или как уберечься от неумных "Маски Шоу")

[allexnew]

Приложение 2

Цели и задачи: Цели и задачи
В первой части: Установка и настройка домена NIS, клиента NIS
Во второй части: Конфигурация сервера и клиента NFS
В третьей части: Домашние папки храним на сервере NFS
В четвертой части: Подключаем шары NFS при входе в систему
В пятой части: Настраиваем права (или ACL, группы и иже с ними)
В шестой части: Сервер печати
В седьмой части: Общий репозиторий для клиентских машин (не обещаю эту часть)
В восьмой части: Квоты (или делим место на винчестере)
Приложение 1: Стандартные права Unix, SUID, SGID, Sticky биты (к 5 части)

(Нажмите, чтобы показать/скрыть)

Приложение 2 - Решение задачи из ЧАСТЬ 5
Приложение к 5 части статьи.

Задача:

Есть педагог. У педагога есть 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/ol(цифра). Основная группа - children.

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

!!! ДОПОЛНИТЕЛЬНОЕ ЗАМЕЧАНИЕ !!!

После некоторых опытов, удалось воплотить в жизнь первоначальную идею "Для всех пользователей-детей, которые имеют временную домашнюю папку сделать ОДИН домашний каталог". Замечания смотрите в "Дополнения и изменения ЧАСТЬ 3 (продолжение)".

Итак, создам в папке  /media/Profil/home папки ol1...ol5, скопирую в них содержимое из default. Теперь каждой из папок нужно назначить соответствующего владельца (пользователи ol1..ol5) и задать права 700. Я покажу пример на папке ol1:

Код: [Выделить]

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 ol1
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 ol1:children ol1
root@sytserver:/media/Profil/home# chmod -R 700 ol1
root@sytserver:/media/Profil/home# ls -l

итого 16
drwx--x--x  2 allexserv nogroup 4096 2009-06-24 12:35 allex
drwx------ 35 ol1     children    4096 2009-06-22 21:46 ol1
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. В нем создадим пять каталогов, для каждой из груп: 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), назначаем права 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. Вместе с тем, ребята не могу удалять каталоги-фамилии.
Осталась решить вопрос с папкой "Задания". Создадим ее и назначим нужные права:

Код: [Выделить]

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 расшарить на доступ всем. Да-да, именно всем, т.к. функции ограничения будут осуществлять сами ACL. Т.е. если какой то другой пользователь, отличный от olga или ol1 примонтирует себе каталог olga_ch или ol1, то доступ ко внутренностям он все равно не получит, 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/ol1      (rw)
/media/Work/Disk_child/olga_ch      (rw)

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

9. Теперь осталось настроить pam_mount.conf.xlm, чтобы каталоги подключались пользователям при входе в систему. Помним что файл pam_mount.conf.xlm лежит на сервере и все клиентские машины настройки считывают из него (см. ЧАСТЬ 3). Его и редактируем. Лежит он у меня здесь: /home/srv/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/tmpfs" options="size=25M,uid=%(USER),gid=children,mode=0700" />
<volume pgrp="children" fstype="unionfs" path="unionfs" mountpoint="/home/srv/%(USER)" options="dirs=/tmp/tmpfs:/home/srv/%(USER)=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>

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

Теперь раскопируем структуру каталогов  группы детей 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.

• Дополнения и изменения в ПРИЛОЖЕНИЕ 2:
  
  Пока нет.
  

Приложение 3: Замена программ Windows их аналогами для школ (список)
Приложение 4: Вопросы лицензирования (или как уберечься от неумных "Маски Шоу")

[allexnew]

• Дополнения и изменения в ЧАСТЬ 4:
  
  пока нет
  

• Дополнения и изменения в ЧАСТЬ 3 (продолжение):
  
  28.09.09 (13.00) Первоначальной идей было создание единственного домашнего каталога для всех пользователей-детей, изменения в котором происходили только на время сессии, а при завершении сессии домашний каталог оставался в первоначальном виде, таким, каким его настроил администратор (см. Дополнения и замечания в ЧАСТЬ 3 от 22.06.09 (22.45)).
  Сразу воплотить идею полностью не удалось. В частности попытка с созданием единственного домашнего каталога для нескольких пользователей провалилась сразу и требовала разбора и анализа. После того, как мне надоело копировать туеву хучу детских каталогов, сел за оптимизацию и собственно добился желаемого результата.
  
  Основная проблема заключалась в том, что у некоторых файлов в домашнем каталоге владельцем должен обязательно быть сам пользователь, поэтому при попытке входа другого пользователя имеющего тот же самый домашний каталог, возникала коллизия. Система сообщала, что владельцем таких то файлов обязан быть сам пользователь и никак иначе.  
  
  Как видно из статьи для пользователей, имеющих общую домашнюю папку, использовалась т.н. темповая файловая система на основе unionfs. Я не буду объяснять ее принцип действия, он прост, если разобраться. Сразу расскажу как реализовать ОДНУ домашнюю папку для нескольких пользователей.
  
  Весь фокус заключается в правильном формировании строки для монтирования unionfs (теперь aufs) в файле  pam_mount.conf.xml.
  
  Итак, старая запись выглядела так:
  
  

  <volume user="child" fstype="tmpfs"  path="tmpfs" mountpoint="/tmp/tmpfs" options="size=25M,uid=child,gid=child,mode=0700" />
  <volume user="child" fstype="aufs" path="aufs" mountpoint="/home/srv/child" options="dirs=/tmp/tmpfs:/home/srv/child=ro" />
  

  
  Новая запись выглядит так:
  
  

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

  
  Рассмотрим изменения:
  
  1. pgrp="children" (в обоих строках) - означает, что монтирование будет происходить для всех пользователей, входящих в основную группу children.
  
  2. mountpoint="/tmp/%(USER)" (в обоих строках) - Сообщает о точке монтирования на клиенте. В старом методе было статически указана точка: mountpoint="/tmp/tmpfs", здесь же монтирование будет происходить в каталог с предварительным созданием этого каталога в /tmp, который будет называться именем пользователя. Такой подход обеспечит универсальность не только для обычного входа пользователя, но и в том случае, если пользователи работают по "терминалу" (XDMCP), подключаясь к одному терминальному серверу. (!)
  
  3. options="dirs=/tmp/%(USER):/home/srv/.child=ro" - Несколько изменился путь к домашнему каталогу. Теперь он указывает на скрытый каталог. Путь соответствует пути на клиенте (помним что все домашние папки подключаются при загрузке клиентской машины).
  
  Теперь касаемо изменений в параметра пользователей. Необходимо чтобы все пользователи использующие общую домашнюю папку входили в определенную основную группу (в моем случае children), у всех пользователей домашний каталог должен быть выставлен один и тот-же (в моем случае) /home/srv/.child.
  
  Очень важно сконфигурировать сам домашний каталог (его содержимое). Приведу листинг того, что должно быть в нем:
  
  

  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  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, которые препятствуют многопользовательскому доступу. Они будут созданы в процессе входа пользователя на временной файловой системе, в связи с этим для каждого пользователя будут свои. Также важно отсутствие некоторых каталогов, каких уже не вспомню. Приведенная структура каталогов, сохранила в себе настройки окружения пользователя, а также настройки программ. Также можно добавлять конфигурационные каталоги других необходимых (но не системных) программ.
  
  Вот собственно и все. Теперь у кучи детей один общеиспользуемый домашний каталог.
  
  ЗЫ Если система будет ругаться на то, что кроме владельца доступ имеет еще и группа, следует разрешить использование системы в этом случае. Для этого сделайте: Система - Администрирование - Окно входа в систему - Безопасность - уберите галку с "Разрешать вход только если пользователь..."
  
  
  31.10.2009 (17:39) 25 мегабайт для пользовательских нужд на временном разделе, пожалуй, недостаточно. Этот параметр следует увеличить, в моем случае увеличил до 50 мб:
  
  

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

  [/size]

[/list]



В пятой части: Настраиваем права (или ACL, группы и иже с ними)
В шестой части: Сервер печати
В седьмой части: Общий репозиторий для клиентских машин (не обещаю эту часть)
В восьмой части: Квоты (или делим место на винчестере)
Приложение 1: Стандартные права Unix, SUID, SGID, Sticky биты (к 5 части)
Приложение 2: Решение задачи (к 5 части)
Приложение 3: Замена программ Windows их аналогами для школ (список)
Приложение 4: Вопросы лицензирования (или как уберечься от неумных "Маски Шоу")

[Malamut]

Несколько сообщений были выделены в отдельную тему:
https://forum.ubuntu.ru/index.php?topic=66827.0

[allexnew]

Окончание (8 часть из 8)

Цели и задачи: Цели и задачи
В первой части: Установка и настройка домена NIS, клиента NIS
Во второй части: Конфигурация сервера и клиента NFS
В третьей части: Домашние папки храним на сервере NFS
В четвертой части: Подключаем шары NFS при входе в систему
В пятой части: Настраиваем права (или ACL, группы и иже с ними)
В шестой части: Сервер печати
В седьмой части: Общий репозиторий для клиентских машин (не обещаю эту часть)

(Нажмите, чтобы показать/скрыть)

ЧАСТЬ 8: Квоты (или делим место на винчестере)

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

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

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

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

Квота - (от лат. quota - часть, приходящаяся на каждого) - Доля, часть, пай, норма  ч.-л.
Нас интересуют дисковые квоты. Собственно, в операционных системах, как правило, под этим подразумевается выделение некоторого объема hdd для пользователей или группы.

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

Включение квот в Ubuntu

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. Из названий этих опций можно догадаться, что первая активирует поддержку квот для групп, вторая для пользователей. Указывать можно как обе опции для разделов винчестера, так и какую-нибудь из них. Логично, что убрав эти опции, поддержка квот отключится.

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

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

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

Код: [Выделить]

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 [опции] [имя или группа пользователей]

Опции:

• -u - Редактирование квот на файловых системах для указанного пользователя. Используется по умолчанию, может быть опущен.
• -g - Редактирование квот для указанной группы пользователей.
• -t - Устанавливает период времени действия мягкого лимита на всех файловых системах для всех пользователей. При добавлении в конце ключа -g - будет устанавливаться период времени для всех групп.
• -T - Устанавливает период времени действия мягкого лимита на всех файловых системах для указанного пользователя. При добавлении в конце ключа -g - будет устанавливаться период времени для указанной группы.
• -p - Распространить значения квот указанного пользователя на нескольких других пользователей (множественная операция).

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

Установка параметров квот для пользователя olga:

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.

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

* Примечание: Есть один момент. Сколько я ни считал, реально потраченное место пользователем на разделе несколько меньше, чем потрачено блоков. Здесь видимо нужно учитывать момент записи на файловую систему. Я так понимаю, не каждый блок может быть полностью использован файлом. Если размер файла менее размера блока, то считается занятым весь блок. Поправьте меня если я ошибаюсь, кто там спец по файловым системам. Более того, не совсем ясно какую единицу используют при подсчете квот, ведь многим известно (а многим, кстати, и нет), что один килобайт, по международному стандарту, равен 1000 байт, а 1 кибибайт равен 1024 байтам. Ради справедливости стоит сказать, что подавляющее большинство, в том числе и я, стандарт "не принимают" и считают, что в килобайте все также 1024 байта и ни байтом меньше.

** Примечание: Inodes - индексный дескриптор. В индексном дескрипторе хранится вся информация о файле, кроме его имени. Имя файла хранится в блоке каталога, вместе с номером дескриптора. Ввиду этого, по моему мнению, можно сказать, что inodes отражает здесь количество используемых файлов.


Установка параметров квот для группы pedagog:

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.

На заметку: Посмотреть состояние квот у пользователя или группы можно командами:

quota -u пользователь
quota -g группа

Если произошло превышение квоты у какого-нибудь пользователя, в столбце blocks будет стоять звездочка, как, например, в этом случае:

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.

• Дополнения и изменения в ЧАСТЬ 8:
  
  Пока нет.
  
  

Приложение 1: Стандартные права Unix, SUID, SGID, Sticky биты (к 5 части)
Приложение 2: Решение задачи (к 5 части)
Приложение 3: Замена программ Windows их аналогами для школ (список)
Приложение 4: Вопросы лицензирования (или как уберечься от неумных "Маски Шоу")