Вступление
Не секрет, что за использование нелицензионного ПО в организации администратор может всхлопотать от 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.
Уважаемые читатели! В качестве серверной ОС я всегда использовал FreeBSD под свои нужды, она мне ближе, но здесь будет описана конфигурация Server Ubuntu. Кто пользует FreeBSD знает, что часто синтаксис и конфигурация в этих системах имеют расхождения. В связи с этим, если вдруг вы увидели, что тот или иной момент решен, так сказать, костылем, просьба предложить лучший вариант.
Приведенная конфигурация администрирования вполне успешно внедрена в государственном учреждении дополнительного образования и не менее успешно функционирует в учебном процессе.
Т. к. статья предполагается большой, наполнятся она будет частями по мере свободного времени.
Дополнительные команды по работе с квотами
Существует ряд дополнительных утилит для работы с квотами.
quotacheck – утилита по проверке квот. рекомендуется регулярно проводить такую проверку, а также в случаях неправильного размонтирования разделов.
Пример использования:
quotacheck -avug
где:
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.
Монтирование домашней папки без сохранения изменений в ней
Если с домашней папкой пользователя pedagog все предельно ясно, педагог сам будет конфигурировать свое рабочее окружение, то с детскими домашними каталогами пришлось повозиться. Побродив по интернету и почитав различную документацию, остановился на модуле pam_mount. Изучая по нему документацию радости моей не было предела, в нем есть все, что нужно для монтирования ресурсов при входе в систему и даже больше. Именно этот модуль разрешает монтировать, и, что немаловажно, размонтировать удаленные ресурсы при входе/выходе пользователей. Подробнее о синтаксисе pam_mountздесь.
В этой части я не буду подробно рассказывать об опциях pam_mount (мы это затронем в четвертой части), здесь он нам нужен только для реализации нашей задачи.
Для начала установим требуемый модуль на клиентской машине:
sudo apt-get install libpam-mount
Конфигурационный файл располагается в /etc/security/pam_mount.conf.xml. Синтаксис находится в XML формате. Именно с помощью него мы и будем конфигурировать кому какие шары при входе подключать (в 4 части). Первое о чем я задумался, это то, что не гоже вести этот файл на каждой рабочей станции, нужно сделать либо один общий файл, либо каждому пользователю по файлу-конфигу, либо оба варианта одновременно. В принципе задача решается и так и этак:
В первом случае файл /etc/security/pam_mount.conf.xml можно разместить на сервере в каталоге где хранятся домашние папки: /media/Profil/home/, а на клиентах сделать символическую ссылку на этот файл. Т.к. этот каталог монтируется при загрузке клиентской машины, то у компьютера не возникает ошибки об отсутствии настоящего файла pam_mount.conf.xml.
Во втором случае, в конфигурационном файле pam_mount.conf.xml есть опция
<luserconf name=".pam_mount.conf.xml" />
которая заставит искать файл конфигурации pam_mount.conf.xml в домашней папки пользователя. Но опять же придется прописывать эту опцию на всех клиентах.
Вобщем я буду использовать оба варианта:
1. сделаю один общий pam_mount.conf.xml, который буду хранить на сервере в папке /media/Profil/home/ (все равно она подключается автоматом при загрузке клиентской машины), на всех клиентских машинах удалю /etc/security/pam_mount.conf.xml, а вместо него сделаю символическую ссылку на общий pam_mount.conf.xml, который будет лежать на смонтированном каталоге /home/srv/pam_mount.conf.xml.
Я не буду описывать как делать символические ссылки, думаю, что если вы читаете эту статью, то знаете как это делается.
2. Если мне потребуется, буду использовать опцию
<luserconf name=".pam_mount.conf.xml" />
Для решения нашей задачи также потребуется установить пакет aufs-tools10) на клиентской машине. Инструмент aufs-tools поможет «объединить» временную файловую систему tmpfs и домашний каталог пользователя таким образом, что существующие в домашнем каталоге параметры будут учитываться системой, а вот все изменения производимые пользователем на время сессии будут записываться на временную файловую систему tmpfs. Когда пользователь завершит сеанс временная файловая система размонтируется, потеряв все изменения, а сам домашний каталог останется без изменений. Следует заметить, что tmpfs создаст виртуальный диск указанного размера в оперативной памяти компьютера, поэтому реализация такой схемы может плачевно сказаться на производительности клиентской машины в целом. 11) Ставим пакет aufs-tools12):
sudo apt-get install aufs-tools
Собственно все почти готово, осталось сконфигурировать файл /media/Profil/home/pam_mount.conf.xml на стороне сервера. Вот примерное содержимое для нашей задачи (не забывайте, что комментарии в XML это <!– текст –>):
<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd"> <pam_mount> <!-- Volume definitions --><!-- pam_mount parameters: General tunables --> <volume pgrp="children" fstype="tmpfs" path="tmpfs" mountpoint="/tmp/%(USER)" options="size=50M,uid=%(USER),gid=children,mode=770" /> <volume pgrp="children" fstype="aufs" path="aufs" mountpoint="/tmp/%(USER)" options="dirs=/tmp/%(USER):/home/srv/.child=ro" /> <umount>sudo umount -l %(MNTPT)</umount> <debug enable="1" /> <!-- <luserconf name=".pam_mount.conf.xml" /> --> <!-- Note that commenting out mntoptions will give you the defaults. You will need to explicitly initialize it with the empty string to reset the defaults to nothing. <mntoptions allow="nosuid,nodev,loop,encryption,fsck,nonempty,allow_root,allow_other" /> <mntoptions deny="suid,dev" /> --> <mntoptions allow="*" /> <!-- <mntoptions deny="*" /> --> <mntoptions require="nosuid,nodev" /> <path>/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin</path> <logout wait="0" hup="0" term="0" kill="0" /> <!-- pam_mount parameters: Volume-related --> <mkmountpoint enable="1" remove="true" /> </pam_mount>
Разберем подробнее записи. В частности следующие две строки и есть реализация нашей задачи. Вынесем их для удобства (остальные параметры /media/Profil/home/pam_mount.conf.xml разберем в четвертой части):
<volume pgrp="children" fstype="tmpfs" path="tmpfs" mountpoint="/tmp/%(USER)" options="size=50M,uid=%(USER),gid=children,mode=770" /> <volume pgrp="children" fstype="aufs" path="aufs" mountpoint="/tmp/%(USER)" options="dirs=/tmp/%(USER):/home/srv/.child=ro" />
где:
«volume» – ключевое слово, сигнализирующее об описании раздела.
pgrp=«children» – основная группа пользователя, для которого определены правила монтирования. Т.е. если пользователь входит в эту группу эта строка выполнится;
fstype=«tmpfs» – тип файловой системы;
path=«tmpfs» – путь к утилите tmpfs;
mountpoint=»/tmp/%(USER)« – точка монтирования на клиентской стороне. Обратите внимание на переменную %(USER) – вместо нее подставляется имя пользователя при входе;
options=«size=50M,uid=%(USER),gid=children,mode=770» – параметры монтирования tmpfs:
options=«dirs=/tmp/%(USER):/home/srv/.child=ro» – параметры монтирования aufs: указывают отобразить изменения /home/srv/.child в директории /tmp/%(USER).
Особое внимание хочу уделить размонтированию шары при выходе. Вобще у меня с этим возникли некоторые проблемы. В частности при настройках по умолчанию этого конфига, шары не размонтировались, включив отладку (<debug enable=«1» />), pam_mount упрямо сообщал при выходе пользователя, что запись о монтированном сетевом ресурсе не находится в fstab и мол вы не root. Скорее всего проблему решил костылем, если кто-то может предложить более лучший способ – предложите. Собственно решил ее так:
1. Разрешаем всем пользователям на клиентских машинах использовать команду /bin/umount без ввода пароля через sudo. Для этого добавим в самый конец файла /etc/sudoers строку:
ALL ALL=NOPASSWD: /bin/umount
Будьте внимательны с редактированием этого файла. Для редактирования используйте команду: sudo visudo. В конце файла должна быть одна пустая строка.
2. На сервере в файле /media/Profil/home/pam_mount.conf.xml включим опцию:
<umount>sudo umount -l %(MNTPT)</umount>
Эта опция заставит pam_mount использовать команду umount c указанными параметрами. Ключ -l («л»), т.н. «ленивое» размонтирование, добавлен т.к. без него, tmpfs не размонтировалась сообщая о занятости девайса.
Очень важно сконфигурировать сам домашний каталог (его содержимое) детей, т.к. он будет использоваться сразу несколькими пользователями. Основная проблема заключается в том, что у некоторых файлов в домашнем каталоге владельцем должен обязательно быть сам пользователь, поэтому при попытке входа другого пользователя имеющего тот же самый домашний каталог, возникала коллизия. Система сообщала, что владельцем таких то файлов обязан быть сам пользователь и никак иначе. Поэтому такие файлы следует из многопользовательского домашнего каталога исключить.
Приведу листинг того, что должно быть в нем:
root@sytserver:/media/Profil/home/.child# ls -l -a total 72 drwxrwxr-x 18 root children 4096 2009-09-23 18:54 . drwxr-xr-x 9 root root 4096 2009-09-21 20:50 .. drwxrwxr-x 6 root children 4096 2009-09-08 21:31 .config drwxrwxr-x 2 root children 4096 2009-06-19 20:30 default drwxrwxr-x 2 root children 4096 2009-06-19 20:30 .fonts drwxrwxr-x 5 root children 4096 2009-09-08 20:50 .gconf drwxrwxr-x 5 root children 4096 2009-09-08 20:50 .gvfs drwxrwxr-x 9 root children 4096 2009-09-08 20:50 .gnome2 drwxrwxr-x 3 root children 4096 2009-09-18 23:36 .kde drwxrwxr-x 4 root children 4096 2009-06-19 20:30 .mozilla drwxrwxr-x 3 root children 4096 2009-06-19 20:30 .openoffice.org drwxrwxr-x 9 root children 4096 2009-08-10 21:15 .opera drwxrwxr-x 2 root children 4096 2009-06-19 20:30 Видео drwxrwxr-x 2 root children 4096 2009-06-19 20:30 Документы drwxrwxr-x 2 root children 4096 2009-06-19 20:30 Картинки drwxrwxr-x 2 root children 4096 2009-06-19 20:30 Музыка drwxrwxr-x 2 root children 4096 2009-06-19 20:30 Общедоступная drwxrwxr-x 2 root children 4096 2009-06-19 20:30 Рабочий стол drwxrwxr-x 2 root children 4096 2009-06-19 20:30 Шаблоны root@sytserver:/media/Profil/home/.child#
Обратите внимание на права. Заметьте, что нет критичных файлов .dmrc, .ICEauthority, которые препятствуют многопользовательскому доступу. Они будут созданы в процессе входа пользователя на временной файловой системе и в связи с этим для каждого пользователя будут свои. Также важно отсутствие некоторых каталогов, каких уже не вспомню. Приведенная структура каталогов, сохранила в себе настройки окружения пользователя, а также настройки некоторых программ. Также можно добавлять конфигурационные каталоги других необходимых (но не системных) программ. Вообще, замечу, все чего не будет хватать системе она автоматически при входе пользователя будет это создавать, причем на временной ФС.13). Замечу, что некоторые программы не загружаются при такой схеме. Например, опытным путем было выяснено, что для загрузки FireFox необходимо чтобы пользователь в обязательном порядке имел права на запись у каталога с профилем Firefox’a. А чтобы запустилась Opera, необходимо удалить файл lock*.* в профиле Oper’ы.
Собственно это все. Теперь при входе в систему пользователь child получит как бы «копию» своей домашней папки в /tmp/child, все изменения во время сессии будут сохраняться именно там, а настоящая его домашняя папка останентся не тронутой, чтобы он в ней не вытворял. При выходе временная шара просто размонтируется потеряв все изменения, а домашняя папка останется в своем первоначальном виде.
Необходимо чтобы все пользователи использующие общую домашнюю папку входили в определенную основную группу (в моем случае children), у всех пользователей домашний каталог должен быть выставлен один и тот-же (в моем случае) /home/srv/.child.
Настройка клиента nis
На клиентской машине также установим пакеты portmap и nis:
sudo apt-get install portmap, nis
Если будете устанавливать через синаптик, то синаптик заботливо попросит сразу указать имя домена NIS. Укажите в этом случае имя своего домена (у меня UBUNTU). Если ничего не попросило, внесем имя домена вручную в файл /etc/defaultdomain, просто впишите туда имя своего домена.
Далее отредактируйте файлы:
Добавить в конец файла /etc/passwd:
::::::
Добавить в конец файла /etc/group:
:::
Добавить в конец файла /etc/shadow:
Приведите файл /etc/nsswitch.conf в такой вид:
passwd: compat group: compat shadow: compat passwd_compat: nis group_compat: nis shadow_compat: nis hosts: files dns networks: files nis protocols: db files nis services: db files nis ethers: db files nis rpc: db files nis netgroup: nis
Этот файл заставляет Ubuntu искать ту или иную информацию в порядке приоритета указанном здесь. Например запись hosts: files dns (определение ИП адреса хоста), заставляет сначала обратиться в файл /etc/host, если запись там не найдена, то обратиться к DNS серверу.
А вот теперь интересный момент. Если вы используете DHCP сервер в своей сети, то можете столкнуться с проблемой тормозни при загрузке компьютера. Yapbind будет слишком долго подключаться к серверу. Чтобы этого не происходило уберите в файле /etc/default/nis у параметра YPBINDARGS ключ -no-dbus. Также можно немного отодвинуть запуск nis клиента. Для этого в /etc/rc5.d переименуйте ссылку @S18nis в @S80nis4).
После этих манипуляций вся загрузка будет происходить четко и быстро.
Вот и всё, клиент настроен.
Для проверки что клиент 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«.
Настройка сервера nfs
Потребуется установить собственно сам демон сервера:
sudo apt-get install nfs-kernel-server, nfs-common
Собственно установка закончена. 🙂 Файл конфигурации сервера по умолчанию используется /etc/default/nfs-kernel-server. Как и в случае с NIS сервером требуется демон portmap, так же должны запуститься демон rpc.mountd и процесс NFS операторских запросов для клиентских систем rpc.nfsd6). Последние два запускаются сценарием:
/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
Теперь необходимо экспортировать7) каталоги для дальнейшего пользования клиентами. За список расшаренных ресурсов отвечает файл /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)
Первая запись сообщает о реальном местоположении каталога на сервере, далее идут ограничения и опции.
Часто используемые опции файла /etc/exports:
Остальные опции (их много) можно прочитать man exports, в документации они очень хорошо описаны.
Собственно, после базового знакомства структуры файла exports, можно большую часть шар предоставлять через WEBMIN: «Сеть – Каталоги NFS». Единственный момент: после создания шары не забудьте нажать кнопку «Применить изменения» или выполнить команду sudo exportfs -a.
Подготовительные операции
Для начала выполним ряд подготовительных операций:
Настройка на стороне клиента
1. Возьмем чистую рабочую станцию и на каком-нибудь пользователе (неважно на каком, хоть на локальном) выполним оформление рабочего окружения так, как вы считаете нужным. Ну там шрифты изменить, оформление окон, обои, настройки приложений и прочее.
2. Когда домашний каталог будет готов, скопируем его на сервер. Это будет, так сказать, домашняя папка по-умолчанию, мы ее будем копировать всем вновь создаваемым пользователям. Пусть каталог с содержимым домашних настроек будет называться default.
Настройка на стороне сервера
3. Я пока не буду залезать в дебри групп (об этом поговорим в другой части), поставим эксперимент пока на двух пользователях: один педагог, второй ребенок. Выберем на сервере раздел и создадим папку home. В ней мы будем хранить профили пользователей. Мой каталог для профилей клиентов такой: /media/Profil/home. Назначим также ему права 777.
4. Теперь скопируем каталог default в папку /media/Profil/home/ и переименуем его в .child, еще раз скопируем default в /media/Profil/home/ и переименуем в pedagog. Домашние папки для наших двух пользователей почти готовы.8)
5. Создадим в домене этих двух пользователей, например через WEBMIN (см. ЧАСТЬ 1.), мои пользователи child и pedagog. При создании в поле «Домашний каталог» впишем /home/srv/.child и /home/srv/pedagog соответственно. Также нам понадобится, чтобы все пользователи-дети входили в одну общую группу. Пусть эта группа называется children, укажите ее принудительно при создании пользователя child. Не забываем перестроить карты nis!9)
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.
Решение задачи
Выполним ряд подготовительных действий:
1. Для начала организуем две группы в системе если их еще нет. Группу pedagog и группу children. Для этого либо редактируем файл /etc/group, либо создаем группы в WebMin:
children:x:1001: mysql:x:130: pedagog:x:1002:
2. Создадим пользователя-педагога. Пусть ее имя будет olga. Сделать это можно по разному, я сделаю через WebMin. При создании никаких экзотических опций не использую. Обратите только внимание на путь к домашней папке. Помним, что все домашние папки у нас подключаются при загрузке клиентских машин с сервера и монтируются в папку /home/srv. Так что путь к домашней папки у olga будет такой: /home/srv/olga. Основная группа будет pedagog.
3. Подготовим домашнюю папку для olga на сервере. Помним, что у нас уже есть т.н. папка с окружением рабочего стола по умолчанию, которая называется default (см. часть 3). Все мои папки с домашними каталогами находятся на сервере здесь: /media/Profil/home. Создам в ней папку olga, скопирую в нее содержимое из default. Назначу права 700, а также сделаю владельцем olga:
root@sytserver:/media/Profil/home#chown -R olga olga root@sytserver:/media/Profil/home#chmod -R 700 olga
Пользователь olga и ее домашняя папка готовы.
4. Теперь, т.к. у педагога 5 групп детей, создадим для них аккаунты. По одному аккаунту на группу. Пусть аккаунты именуются так: ol1, ol2, ol3, ol4, ol5. Создаем пользователей с такими именами в системе, домашняя папка у них будет числиться как /home/srv/.child. Основная группа – children.
5. Домашняя папка для всех групп у нас общая и лежит на сервере. Напомню, что при подключении пользователей-детей у нас используется временная файловая система (см. часть 3), что обеспечивает неизменность профиля для детей. Помним, что у нас уже есть т.н. папка с окружением рабочего стола по умолчанию, которая называется default (см. часть 3). Все мои папки с домашними каталогами находятся на сервере здесь: /media/Profil/home.
Итак, создам в папке /media/Profil/home папку .child, скопирую в нее содержимое из default. Теперь назначим папке .child необходимые права. Владельцем папки оставим пользователя root, а вот группу сделаем children, чтобы любой ребенок имел к ней доступ:
root@sytserver:/media/Profil/home# ls -l итого 16 drwx--x--x 2 allexserv nogroup 4096 2009-06-24 12:35 allex drwx------ 35 root root 4096 2009-06-22 21:46 .child drwx------ 34 olga root 4096 2009-08-08 17:47 olga -rwxrwxrwx 1 nobody nogroup 945 2009-08-08 18:09 pam_mount.conf.xml root@sytserver:/media/Profil/home# chown -R root:children .child root@sytserver:/media/Profil/home# chmod -R 775 .child root@sytserver:/media/Profil/home# ls -l итого 16 drwx--x--x 2 allexserv nogroup 4096 2009-06-24 12:35 allex drwxrwxr-x 35 root children 4096 2009-06-22 21:46 .child drwx------ 34 olga root 4096 2009-08-08 17:47 olga -rwxrwxrwx 1 nobody nogroup 945 2009-08-08 18:09 pam_mount.conf.xml
6. С домашними папками покончено. Обновим карты NIS домена после добавления новых пользователей и групп. Это можно сделать написав команду make, предварительно зайдя в каталог /var/yp на сервере NIS или нажав кнопку «Сохранить и применить» в WEBMIN: «Сеть – Клиент и сервер NIS» – «Сервер NIS«.
7. Создадим структуру каталогов (см. рис.) для групп детей на сервере и назначим им права доступа. Эти каталоги будут подключаться детям при входе в систему соответственно и будут служить рабочими «дисками» для детей, где они будут складывать свои наработки во время занятий. Все пользовательские каталоги у меня размещаются здесь: /media/Work/Disk_child. Создадим каталог olga_ch, который будет содержать в себе все каталоги групп детей педагога. Этот каталог (olga_ch) будет подключаться педагогу olga. В нем создадим пять каталогов, для каждой из груп: ol1, ol2, ol3, ol4, ol5. Каждый из них будет подключаться той или иной группе соответственно. В каждом из этих пяти каталогов будут еще каталоги с фамилиями ребят. В данном примере фамилии заменят каталоги 01, 02, 03 и тп. Вот что получается:
root@sytserver:/media/Work/Disk_child/olga_ch# ls -l итого 20 drwxr-xr-x 4 root root 4096 2009-08-08 18:55 ol1 drwxr-xr-x 2 root root 4096 2009-08-08 18:03 ol2 drwxr-xr-x 2 root root 4096 2009-08-10 17:59 ol3 drwxr-xr-x 2 root root 4096 2009-08-10 17:59 ol4 drwxr-xr-x 2 root root 4096 2009-08-10 17:59 ol5
Для всех пяти групп я не буду приводить примеры с разрешениями, приведу только для ol1. И вообще, в целях оптимизации можно все права выставить только для одной группы, а для остальных четырех групп просто скопировать структуры папок с уже назначенными правами и немного модифицировать их (права) о чем ниже. Так и сделаем.
Начнем с педагога olga. При входе в систему, помимо личного диска, ей будет экспортироваться папка olga_ch, в которой будут содержаться все ее группы ребят. Очевидно, что права на запись в саму папку olga_ch педагогу ненужны ибо нефик! Владельца папки оставляем рута и назначаем права ACL:
root@sytserver:/media/Work/Disk_child# chown root:root olga_ch root@sytserver:/media/Work/Disk_child# chmod 700 olga_ch root@sytserver:/media/Work/Disk_child# setfacl -m u:olga:rx olga_ch root@sytserver:/media/Work/Disk_child# getfacl ol* # file: olga_ch # owner: root # group: root user::rwx user:olga:r-x group::--- mask::r-x other::---
Теперь разбираемся с правами на группы (папки ol1 – ol5). Здесь уже для педагога потребуются также права на запись, дабы он мог удалять лишние файлы, редактировать файлы ребят и добавлять новые. Поэтому для каталога группы (в нашем случае ol1), назначаем права rwx. Владельцем каталога также оставляем рута:
root@sytserver:/media/Work/Disk_child/olga_ch# chown root:root ol1 root@sytserver:/media/Work/Disk_child/olga_ch# chmod 700 ol1 root@sytserver:/media/Work/Disk_child/olga_ch# setfacl -m u:olga:rwx ol1 root@sytserver:/media/Work/Disk_child/olga_ch# getfacl ol1 # file: ol1 # owner: root # group: root user::rwx user:olga:rwx group::--- mask::rwx other::---
Заметьте, что хоть olga и имеет права rwx на каталог ol1, она не сможет удалить САМ каталог ol1, который находится в папке olga_ch.
Теперь сразу добавим на этот же каталог права для пользователя ol1. Писать детям в сам каталог ol1 нужды нет, ибо опять нефик! Поэтому им даем права rx:
root@sytserver:/media/Work/Disk_child/olga_ch# setfacl -m u:ol1:rx ol1 root@sytserver:/media/Work/Disk_child/olga_ch# getfacl ol1 # file: ol1 # owner: root # group: root user::rwx user:ol1:r-x user:olga:rwx group::--- mask::rwx other::---
Теперь освободим себя еще от лишней работы. Пускай педагог сама создает каталоги с фамилиями ребят, которые ему (педагогу) нужны. Загвоздка в том, чтобы при создании каталогов руками педагога они еще должны быть доступны детям. Для этого воспользуемся ACL по умолчанию, т.н. сделаем «наследование» прав. Более того, сразу глядим в будущее… Попробую объяснить:
В сеть будут отдаваться каталоги olga_ch и ol1, должен быть соответствующий доступ только для пользователей этих каталогов.
С каталогом olga_ch все ясно, дополнительных манипуляций не надо, доступ только для olga.
К каталогу ol1 должны уже иметь доступ olga и группа детей ol1, тоже сделано.
root@sytserver:/media/Work/Disk_child/olga_ch# setfacl -d -m g:children:rwx,g:pedagog:rwx ol1 root@sytserver:/media/Work/Disk_child/olga_ch# getfacl ol1 # file: ol1 # owner: root # group: root user::rwx user:ol1:r-x user:olga:rwx group::--- mask::rwx other::--- default:user::rwx default:group::--- default:group:children:rwx default:group:pedagog:rwx default:mask::rwx default:other::---
Теперь все создаваемые каталоги и файлы внутри каталога ol1 будут принимать разрешения rwx для групп pedagog и children. Вместе с тем, ребята из группы ol1 не могут удалять каталоги-фамилии, потому как права для логина ol1 под которым будут входить ребята ограничиваются чтением и выполнением: user:ol1:r-x, а мы с вами знаем, что права на запрет имеют приоритет перед правами на разрешение.
Осталось решить вопрос с папкой «Задания». Создадим ее и назначим нужные права:
root@sytserver:/media/Work/Disk_child/olga_ch# cd ol1 root@sytserver:/media/Work/Disk_child/olga_ch/ol1# ls -l root@sytserver:/media/Work/Disk_child/olga_ch/ol1# mkdir Zadaniya root@sytserver:/media/Work/Disk_child/olga_ch/ol1# setfacl -d -m g:children:rx,g:pedagog:rwx Zad* root@sytserver:/media/Work/Disk_child/olga_ch/ol1# setfacl -m g:children:rx,g:pedagog:rwx Zad* root@sytserver:/media/Work/Disk_child/olga_ch/ol1# getfacl * # file: Zadaniya # owner: root # group: root user::rwx group::--- group:children:r-x group:pedagog:rwx mask::rwx other::--- default:user::rwx default:group::--- default:group:children:r-x default:group:pedagog:rwx default:mask::rwx default:other::---
Теперь дети из папки Задания могут только читать, а педагог может и писать туда. В принципе все готово к монтированию.
8. Для начала нужно расшарить каталог на сервере NFS. Тут уж выбирать вам самим. Я к примеру, считаю, что в моем случае достаточно каталог olga_ch расшарить на доступ всем. Тем самым мы облегчим себе жизнь: не надо в этом случае экспортировать дополнительно каталоги ol1 – ol5, т.к. папка, содержащая их (olga_ch) уже будет расшарена. Т.к. функции ограничения будут осуществлять сами ACL, то нет ничего страшного в том, что папка olga_ch расшарена на доступ всем. Т.е. если какой то другой пользователь, отличный от olga или ol1 примонтирует себе каталог olga_ch, то доступ ко внутренностям он все равно не получит, ACL не дадут. Если у вас религиозные взляды отличаются от моих, то вам прямая дорога в сетевые группы (netgroup), забавная, кстати, вещь. С помощью них ограничите расшаривание так, как считаете нужным.
Ну а для тех, у кого религиозные взгляды совпадают с моими, продолжаем разговор. Для расшаривания редактируем файл /etc/exports (см. последнюю строку):
# /etc/exports: the access control list for filesystems which may be exported /media/Work/tmp @test(sync,rw) /media/Work/deluge (ro) /media/Profil/home (rw) /media/Work/Disk_child/olga_ch (rw)
Перестроим записи командой: exportfs -a.
9. Теперь осталось настроить pam_mount.conf.xlm, чтобы каталоги подключались пользователям при входе в систему. Помним, что файл pam_mount.conf.xlm лежит на сервере и все клиентские машины настройки считывают из него (см. часть 3). Его и редактируем. Лежит он у меня на сервере здесь: /media/Profil/home/pam_mount.conf.xml. Привожу полный конфиг с комментариями:
<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd"> <pam_mount> <debug enable="1" /> <mntoptions allow="nosuid,nodev,loop,encryption,fsck,nonempty,allow_root,allow_other" /> <mntoptions deny="suid,dev" /> <umount>sudo umount -l %(MNTPT)</umount> <mntoptions require="nosuid,nodev" /> <path>/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin</path> <logout wait="0" hup="0" term="0" kill="0" /> <mkmountpoint enable="1" remove="true" /> <!-- user options --> <!-- Две последующие строки для организации временной файловой системы. Подключаются все пользователям, у которых основная группа children. (см. ЧАСТЬ 3) --> <volume pgrp="children" fstype="tmpfs" path="tmpfs" mountpoint="/tmp/%(USER)" options="size=50M,uid=%(USER),gid=children,mode=770" /> <volume pgrp="children" fstype="aufs" path="aufs" mountpoint="/tmp/%(USER)" options="dirs=/tmp/%(USER):/home/srv/.child=ro" /> <!-- Монтирование ресурса ol1 только для пользователя ol1 --> <volume user="ol1" fstype="nfs" server="sytserver" path="/media/Work/Disk_child/olga_ch/ol1" mountpoint="/media/Disk_ol1" options="hard,suid" /> <!-- Монтирование ресурса olga_ch только для пользователя olga --> <volume user="olga" fstype="nfs" server="sytserver" path="/media/Work/Disk_child/olga_ch" mountpoint="/media/Disk_group" options="hard,suid" /> </pam_mount>
Сохраняемся! И собственно все, можно проверять.
10. Теперь раскопируем структуру каталогов группы детей ol1 на остальные группы ol2…ol5. Имеем:
/media/Work/Disk_child/olga_ch > ls -l итого 24 drwxrwx--- 4 root root 4096 2009-08-10 19:57 ol1
Размножаем (обратите внимание на ключ -p, который позволяет также копировать атрибуты):
root@sytserver:/media/Work/Disk_child/olga_ch# cp -R -p ./ol1 ol2 root@sytserver:/media/Work/Disk_child/olga_ch# cp -R -p ./ol1 ol3 root@sytserver:/media/Work/Disk_child/olga_ch# cp -R -p ./ol1 ol4 root@sytserver:/media/Work/Disk_child/olga_ch# cp -R -p ./ol1 ol5 root@sytserver:/media/Work/Disk_child/olga_ch# ls -l итого 40 drwxrwx--- 4 root root 4096 2009-08-10 19:57 ol1 drwxrwx--- 4 root root 4096 2009-08-10 19:57 ol2 drwxrwx--- 4 root root 4096 2009-08-10 19:57 ol3 drwxrwx--- 4 root root 4096 2009-08-10 19:57 ol4 drwxrwx--- 4 root root 4096 2009-08-10 19:57 ol5
Теперь осталось всего-то просто несколько модифицировать у каталогов ol2…ol5 права для пользователей, соответственно на ol2…ol5, потому как сейчас у этих каталогов доступ для пользователя ol1. Смотрим, например, для группы каталога ol2:
root@sytserver:/media/Work/Disk_child/olga_ch# getfacl ol2 # file: ol2 # owner: root # group: root user::rwx user:ol1:r-x user:olga:rwx group::--- mask::rwx other::--- default:user::rwx default:group::--- default:group:children:rwx default:group:pedagog:rwx default:mask::rwx default:other::---
Видно, что нужно заменить здесь только пользователя ol1 на ol2. Удаляем ACL для ol1 и меняем на ol2:
root@sytserver:/media/Work/Disk_child/olga_ch# setfacl -x u:ol1 ol2 root@sytserver:/media/Work/Disk_child/olga_ch# setfacl -m u:ol2:rx ol2 root@sytserver:/media/Work/Disk_child/olga_ch# getfacl ol2 # file: ol2 # owner: root # group: root user::rwx user:ol2:r-x user:olga:rwx group::--- mask::rwx other::--- default:user::rwx default:group::--- default:group:children:rwx default:group:pedagog:rwx default:mask::rwx default:other::---
Тоже самое нужно проделать для папок ol3..ol5.
Вот собственно и все. Внутри менять права не надо т.к. там права назначены у нас для групп pedagog и children.
Установка и настройка nfs-сервера в linux centos
По умолчанию nfs уже установлен в CentOS 8 с пакетом Standard. Если вы удалили компоненты NFS, или ставили сервер в режиме Minimal Install, можно установить пакет NFS с помощью пакетного менеджера yum (dnf):
Для CentOS 7
# yum install nfs-utils -y
Для CentOS 8
# dnf install nfs-utils -y
У меня пакет уже был установлен:
После установки нужных пакетов, нужно запустить службы nfs-server и rpcbind, добавьте их в автозагрузку:
# systemctl enable rpcbind
# systemctl enable nfs-server
# systemctl start rpcbind
# systemctl start nfs-server
Если вам нужен только NFSv4.1/4.2, служба rpcbind не нужна.
Если у вас в системе установлен firewalld откройте необходимые порты:
# firewall-cmd –permanent –add-port=111/tcp# firewall-cmd –permanent –add-port=20048/tcp# firewall-cmd –permanent –zone=public –add-service=nfs# firewall-cmd –permanent –zone=public –add-service=mountd# firewall-cmd –permanent –zone=public –add-service=rpc-bind# firewall-cmd –reload
Теперь создадим директорию, которая будет раздаваться вашим NFS сервером:
# mkdir -p /backup/nfs# chmod -R 777 /backup/nfs
Теперь в конфигурационном файле с настройками NFS сервера (/etc/exports) нужно опубликовать данный каталог и назначить права доступа.
# nano /etc/exports
Добавьте в файл следующую строку для предоставления доступа к NFS всем хостам в указанной IP подсети:
/backup/nfs 192.168.1.0/24 (rw,sync,no_root_squash,no_all_squash)
Или можно ограничить доступ для конкретного IP:
/backup/nfs 192.168.2.24 (rw,sync,no_root_squash,no_all_squash, anonuid=1000,anongid=1000) 192.168.3.100 (ro,async,no_subtree_check)
Рассмотрим более подробно формат предоставления прав к NFS каталогу:
- rw – права на запись в каталоге, ro – доступ только на чтение;
- sync – синхронный режим доступа. async – подразумевает, что не нужно ожидать подтверждения записи на диск (повышает производительность NFS, но уменьшает надежность);
- no_root_squash – разрешает root пользователю с клиента получать доступ к NFS каталогу (обычно не рекомендуется);
- no_all_squash — включение авторизации пользователя. all_squash – доступ к ресурсам от анонимного пользователя;
- no_subtree_check – отключить проверку, что пользователь обращается в файлу в определенном каталоге (subtree_check – используется по умолчанию);
- anonuid, anongid – сопоставить NFS пользователю/группу указанному локальному пользователю/группе(UID и GID).
Чтобы применить новые настройки NFS каталогов, выполните:
# exportfs -a
И перезапустите nfs-сервер:
# systemctl restart nfs-server
На этом установка и настройка nfs-сервера закончена и можно приступить к настройке клиента.
Установка параметров квот для пользователя 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 килобайту.19) Грубо говоря, здесь, пользователь olga уже потратила на разделе /dev/sda5 173252*1024=177 410 048 байт, ну, или, опять же, грубо 173 252 килобайт.
Столбец soft задает мягкое ограничение пользователю на количество блоков.
Столбец hard задает жесткое ограничение пользователю на количество блоков. Обратите внимание, что если значения soft или hard равны нулю, то квоты для пользователя считаются отключенными.
Столбец inodes отражает, грубо говоря, количество используемых файлов.20)
И последние два столбца 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.
Итак, отредактировав необходимые параметры, записываем файл квот. Обратите внимание, что запись будет происходить в темповый (временный) файл, а затем, после проверки системой выставленных параметров, параметры квот запишутся куда надо.