Школьный сервер LDAP + Kerberos + NFS: различия между версиями

Материал из IT в школе
Перейти к навигацииПерейти к поиску

Школьный сервер LDAP + Kerberos + NFS (просмотреть исходный код)

Версия 15:14, 5 июля 2025

7444 байта добавлено ,  5 июль
нет описания правки
Строка 1: Строка 1:




<big>'''Это черновик статьи, он может содержать ошибки!'''</big>
<big>'''Это черновик статьи, он может содержать ошибки!'''</big>


==Функционал системы==
==Краткое описание==


Целью является создание школьного сервера со следующим функционалом:
Целью является создание школьного сервера со следующим функционалом:
Строка 29: Строка 28:
'''Важно! Поскольку будут настраиваться механизмы авторизации и доступа в домашние каталоги, необходимо при установке как сервера, так и клиентов разрешить вход пользователю root. Это упростит починку системы, если будет что-то сломано в механизмах авторизации или доступа к домашним каталогам /home.'''
'''Важно! Поскольку будут настраиваться механизмы авторизации и доступа в домашние каталоги, необходимо при установке как сервера, так и клиентов разрешить вход пользователю root. Это упростит починку системы, если будет что-то сломано в механизмах авторизации или доступа к домашним каталогам /home.'''


На клиентских компьютерах удобно помимо сетевых пользователей завести общий логин типа "user" или "student", функционирование которого не было бы привязано к работе сервера. Это позволит использовать компьютерные классы при проблемах с сетью или сервером. При этом домашний каталог такого пользователя '''НЕ ДОЛЖЕН''' находиться в /home, т.к. при проблемах использование этого каталога будет невозможно. Предлагается разместить домашний каталог такого пользователя в /usr/local/home. Туда же следует перенести и домашний каталог локального администратора системы. Пусть логин администратора системы - admin. Войдите под пользователем root (не используйте sudo, не используйте su - в системе не должно быть открытых сеансов пользователя admin). Выполните команды.<syntaxhighlight lang="bash">
На клиентских компьютерах удобно помимо сетевых пользователей завести общий логин типа "user" или "student", функционирование которого не было бы привязано к работе сервера. Это позволит использовать компьютерные классы при проблемах с сетью или сервером. При этом домашний каталог такого пользователя '''НЕ ДОЛЖЕН''' находиться в /home, т.к. при проблемах с доступом /home по сети использование этого каталога будет невозможно. Предлагается разместить домашний каталог такого пользователя в /usr/local/home. Туда же следует перенести и домашний каталог локального администратора системы. Расположение домашнего каталога можно задать сразу при установке системы.
 
Можно перенести домашний каталог пользователя в другое место после установки. Пусть логин пользователя - admin. Войдите под пользователем root (не используйте sudo, не используйте su - в системе не должно быть открытых сеансов пользователя admin). Выполните команды.<syntaxhighlight lang="bash">
mkdir /usr/local/home
mkdir /usr/local/home
mv /home/admin /usr/local/home/
mv /home/admin /usr/local/home/
usermod -d /usr/local/home/admin admin
usermod -d /usr/local/home/admin admin


</syntaxhighlight>Также расположение домашнего каталога администратора системы можно задать при установке системы.
</syntaxhighlight>На сервере необходимо вынести /home в отдельный раздел, чтобы при заполнении всего раздела на нём это не повлияло на работу сервера. Рекомендуется использование файловой системы XFS на этом разделе, она считается наиболее производительной. Наоборот, BTRFS не рекомендуется, т.к. нет смысла создавать снимки на этом разделе.


На сервере необходимо вынести /home в отдельный раздел, чтобы при отсутствии свободного места на нём это не повлияло на работу сервера. Рекомендуется использование файловой системы XFS на этом разделе, она считается наиболее быстрой. Наоборот, BTRFS не рекомендуется, т.к. нет смысла создавать снимки на этом разделе.
Для пользователей необходимо квотировать размер дискового пространства. Желательный размер квоты на одного пользователя - 2-3 гигабайта, поэтому в масштабах одного школьного здания на хранение файлов пользователей следует выделять порядка 1 террабайта дискового пространства.


Желательный размер квоты на одного пользователя - 2-3 гигабайта, поэтому в масштабах одного школьного здания на хранение файлов пользователей следует выделять порядка 1 террабайта дискового пространства.
Если вам нужна графическая оболочка на сервере, установите lxqt - лёгкую и нетребовательную к ресурсам оболочку.


Если вам нужна графическая оболочка на сервере, установите lxqt - лёгкую и нетребовательную к ресурсам оболочку (команда от root).
В дальнейшем все команды предполагается вводить от имени пользователя root или с использованием sudo.
  dnf install -y task-lxqt
  dnf install -y task-lxqt
Если вы тестируете установку в VirtualBox, установите гостевые расширения (команда от root).
Если вы тестируете установку в VirtualBox, установите гостевые расширения (команда от root).
  dnf install -y virtualbox-guest-additions
  dnf install -y virtualbox-guest-additions
Для отключения всех ждущих-спящих режимов на компьютере выполните команду.<syntaxhighlight lang="bash">
Для отключения всех ждущих-спящих режимов на компьютере выполните команду (от root).<syntaxhighlight lang="bash">
systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
</syntaxhighlight>
</syntaxhighlight>
Строка 51: Строка 52:
Для работы Kerberos необходимо, чтобы все компьютеры имели имена (FQDN) и взаимодействовали друг с другом с использованием FQDN.
Для работы Kerberos необходимо, чтобы все компьютеры имели имена (FQDN) и взаимодействовали друг с другом с использованием FQDN.


Мы предположим, что наша сеть имеет следующий вид.
Предположим, что наша сеть имеет следующий вид. Локальный домен называется sch179.local.


Локальный домен называется sch179.local. Далее в инструкциях измените название этого домена на своё.
Сервер имеет IP-адрес 192.168.0.1 и имя server.sch179.local


Сервер имеет IP-адрес 192.168.0.1 и имя server.sch179.local
Клиентский компьютер в дальнейших инструкциях имеет IP-адрес 192.168.1.1 и имя ws01.sch179.local.


Клиентский компьютер в дальнейших инструкциях имеет IP-адрес 192.168.1.1 и имя ws01.sch179.local
В дальнейших инструкциях везде замените sch179.local на свой домен, IP-адреса и доменные имена компьютеров - на свои адреса и имена.


Вы можете поднять DNS для разрешения имён ''[поможет ли в этом Avahi?]''. Но для надёжности и независимости от службы DNS можно создать статические записи для всех компьютеров - на каждом компьютере будут прописаны доменные имена других компьютеров. На клиенте достаточно прописать имя и адрес сервера, на сервере необходимо прописать имена всех подключённых к нему компьютеров в локальной сети.
Вы можете поднять DNS для разрешения имён ''[поможет ли в этом Avahi?]''. Но для надёжности и независимости от службы DNS можно создать статические записи для всех компьютеров - на каждом компьютере будут прописаны доменные имена других компьютеров. На клиенте достаточно прописать имя и адрес сервера, на сервере необходимо прописать имена всех подключённых к нему компьютеров в локальной сети.


На сервере выполните команду<syntaxhighlight lang="bash">
На сервере выполните команду (от root).<syntaxhighlight lang="bash">
hostnamectl set-hostname server.sch179.local
hostnamectl set-hostname server.sch179.local
</syntaxhighlight>На клиенте выполните аналогичную команду<syntaxhighlight lang="bash">
</syntaxhighlight>На клиенте выполните аналогичную команду (от root).<syntaxhighlight lang="bash">
hostnamectl set-hostname ws01.sch179.local
hostnamectl set-hostname ws01.sch179.local
</syntaxhighlight>В файл /etc/hosts на сервере добавьте адреса и имена всех клиентских компьютеров - строки вида<syntaxhighlight lang="ini">
</syntaxhighlight>В файл /etc/hosts на сервере добавьте адреса и имена всех клиентских компьютеров - строки вида<syntaxhighlight>
192.168.1.1 ws01.sch179.local ws01
192.168.1.1 ws01.sch179.local ws01


</syntaxhighlight>Одна строка соответствует одному компьютеру. Замените в этой строке IP-адрес компьютера, его полное и короткое имя.
</syntaxhighlight>Одна строка соответствует одному компьютеру. Замените в этой строке IP-адрес компьютера, его полное и короткое имя.


На клиентском компьютере запишите в этот файл адрес и имя сервера.<syntaxhighlight lang="ini">
На клиентском компьютере запишите в этот файл адрес и имя сервера - строку вида.<syntaxhighlight>
192.168.0.1 server.sch179.local server
192.168.0.1 server.sch179.local server


</syntaxhighlight>
</syntaxhighlight>
==Установка и настройка OpenLDAP на сервере==
==Настройка OpenLDAP на сервере==
LDAP (Lightweight Directory Access Protocol) - это сетевая база данных для хранения информации о пользователях, группах, может также использоваться для хранения сведений о компьютерах, сервисах и т.д. Мы будем хранить в LDAP учётные записи пользователей и групп пользователей. При этом на компьютере могут быть как локальные учётные записи (root, admin, student) - информация о них хранится в /etc/passwd, так и сетевые учётные записи, информация о которых будет загружаться из LDAP.


=== Установка и запуск ===
=== Установка и запуск ===
Строка 81: Строка 83:
</syntaxhighlight>
</syntaxhighlight>


При этом в скриптах пакета openldap-servers (версии openldap-servers-2.6.9-1) есть [https://forum.rosa.ru/viewtopic.php?p=121370 ошибка], поэтому если вы видите такие ошибки при установке пакета, выполните команды.<syntaxhighlight lang="bash">
При этом в скриптах пакета openldap-servers (версии openldap-servers-2.6.9-1) есть [https://forum.rosa.ru/viewtopic.php?p=121370 ошибка], поэтому если вы видите такие ошибки при установке пакета, выполните после установки команды.<syntaxhighlight lang="bash">
chown -R ldap:ldap /etc/openldap/slapd.d
chown -R ldap:ldap /etc/openldap/slapd.d
chown -R ldap:ldap /var/lib/ldap
chown -R ldap:ldap /var/lib/ldap
Строка 110: Строка 112:
Теперь создадим базу LDAP и запись администратора LDAP.
Теперь создадим базу LDAP и запись администратора LDAP.


Создайте файл create-db.ldif и вставим в него такой текст. Замените хеш пароля в последней строке на тот, который вы получили.
Создайте файл create-db.ldif и вставьте в него такой текст. Здесь dc=sch179,dc=local - суффикс имён всех объектов, которые будут храниться в LDAP. Замените здесь sch179 на своё название, делайте это везде в дальнейшем.
 
Замените хеш пароля в последней строке на тот, который вы получили.
<syntaxhighlight>
<syntaxhighlight>
dn: olcDatabase={2}mdb,cn=config
dn: olcDatabase={2}mdb,cn=config
Строка 127: Строка 131:
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
ldapmodify -Y EXTERNAL -H ldapi:/// -f create-db.ldif
ldapmodify -Y EXTERNAL -H ldapi:/// -f create-db.ldif
</syntaxhighlight>Проверка созданной базы запросом.<syntaxhighlight lang="bash">
</syntaxhighlight>Проверка созданной базы командой.<syntaxhighlight lang="bash">
ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=config" "(olcDatabase=*)"
ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=config" "(olcDatabase=*)"
</syntaxhighlight>
</syntaxhighlight>
Строка 219: Строка 223:
</syntaxhighlight>
</syntaxhighlight>


Добавление:
Добавление этого файла в LDAP (команда от root):  
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
ldapadd -x -D "cn=admin,dc=sch179,dc=local" -W -f groups.ldif
ldapadd -x -D "cn=admin,dc=sch179,dc=local" -W -f groups.ldif
</syntaxhighlight>
</syntaxhighlight>


Проверка:
Проверка - запрос информации обо всех группах:
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
ldapsearch -x -b "ou=groups,dc=sch179,dc=local" "(objectClass=posixGroup)"
ldapsearch -x -b "ou=groups,dc=sch179,dc=local" "(objectClass=posixGroup)"
Строка 230: Строка 234:


===Создание пользователей===
===Создание пользователей===
Попробуем добавить тестовых пользователей.
Пусть мы ходим создать пользователя teacher1 c uid=2001 и пользователя student1 с uid=4001. При этом для каждого пользователя будет создана группа с таким же именем.
Пусть мы ходим создать пользователя teacher1 c uid=2001 и пользователя student1 с uid=4001. При этом для каждого пользователя будет создана группа с таким же именем.


Строка 286: Строка 292:
</syntaxhighlight>
</syntaxhighlight>


==Настройка Kerberos==
==Настройка Kerberos на сервере==
Kerberos - протокол аутентификации (проверки пароля). Хотя пароли пользователей могут храниться в LDAP, Kerberos является более защищённым протоколом. А для доступа к NFS с авторизацией использование Kerberos является обязательным. Поэтому мы будем хранить пароли пользователей только в Kerberos.


===Установка пакетов===
===Установка пакетов===
Строка 294: Строка 301:


===Настройка главного конфига Kerberos ===
===Настройка главного конфига Kerberos ===
Измените файл /etc/krb5.conf, записав в него следующий текст (нужно записать параметр default_realm и заполнить разделы [realms] и [domain_realm]). <syntaxhighlight lang="ini">
Измените файл /etc/krb5.conf, записав в него следующий текст (нужно записать параметр default_realm и заполнить разделы [realms] и [domain_realm]).
 
Обратите внимание, на клиентах также будет необходимо настроить этот файл (см. ниже). <syntaxhighlight lang="ini">
includedir /etc/krb5.conf.d/
includedir /etc/krb5.conf.d/


Строка 323: Строка 332:


===Создание базы данных===
===Создание базы данных===
Выполните команду. Нужно будет установить мастер-пароль для базы Kerberos, сохраните этот пароль.<syntaxhighlight lang="bash">
Выполните команду. Нужно будет установить мастер-пароль для базы Kerberos,. Выполните команду от root.<syntaxhighlight lang="bash">
kdb5_util create -s
kdb5_util create -s
</syntaxhighlight>Введите два раза KDC database master key (пароль администратора базы данных Kerberos), надёжно сохраните этот пароль.
</syntaxhighlight>Введите два раза KDC database master key (пароль администратора базы данных Kerberos), надёжно сохраните этот пароль.
Строка 388: Строка 397:
</syntaxhighlight>
</syntaxhighlight>


==Интеграция LDAP и Kerberos через SSSD==
==Доступ к LDAP и Kerberos через SSSD==
Эти шаги нужно сделать и на сервере, и на клиенте.
sssd (System Security Services Daemon) - это служба, которая запускается на компьютере для аутентификации пользователей. Она будет взаимодействовать с удалёнными серверами LDAP и Kerberos. Когда пользователей входит в систему, система обращается к sssd для проверки информации о пользователе и пароля, а она в свою очередь обращается к LDAP и Kerberos.


'''На клиенте также нужно настроить файл /etc/krb5.conf так же, как и на сервере (пример выше).'''
Эту настройку нужно сделать как на клиенте, так и на сервере, т.к. на сервере также должна быть информация об имеющихся пользователях для хранения их домашних каталогов /home.


===Установка пакетов===
===Установка пакетов===
Строка 398: Строка 407:
</syntaxhighlight>
</syntaxhighlight>


===Конфигурация SSSD===
===Настройка sssd===
Служба sssd получает информацию о пользователях и их паролях через ldap и kerberos.
Создайте файл /etc/sssd/sssd.conf и запишите в него следующий текст, внеся нужные правки.<syntaxhighlight lang="ini">
 
Создайте файл /etc/sssd/sssd.conf и запишите в него следующий текст, внеся нужные правки.
<syntaxhighlight lang="ini">
[sssd]
[sssd]
domains = sch179.local
domains = sch179.local
Строка 429: Строка 435:
</syntaxhighlight>
</syntaxhighlight>


===Настройка NSS===
=== Настройка Kerberos ===
На клиенте также нужно настроить файл /etc/krb5.conf так же, как и на сервере (пример выше).
 
Вероятно, этого можно и не делать, если обращаться к Kerberos будет только служба sssd, а параметры доступа к Kerberos в sssd.conf указаны. Но если вы захотите на клиенте получить билет Kerberos напрямую (без sssd), например, если для проверки вы попробуете смонтировать каталог /home по nfs, то для этого нужно будет использовать консольную утилиту kinit, а ей для информации о сервере kerberos нужен файл /etc/krb5.conf. Поэтому создайте на клиенте этот файл, аналогичный приведённому выше примеру для сервера.
 
===Настройка Name Service Switch (nss)===
В файле /etc/nsswitch.conf хранится информация о том, как система получает информацию о пользователях. Нам нужно сделать так, чтобы информация о пользователях бралась из локальных файлов (/etc/passwd, /etc/group), а затем из sssd.


Измените `/etc/nsswitch.conf, заменив в нём три строки на следующие:
Измените /etc/nsswitch.conf, заменив в нём три строки на следующие:
<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
passwd:    files sss
passwd:    files sss
Строка 439: Строка 451:


=== Настройка PAM ===
=== Настройка PAM ===
PAM (Pluggable Authentication Module) - это библиотека, осуществляющая аутентификацию пользователей. Нужно настроить эту библиотеку так, чтобы сначала она сначала проверяла пароль по локальным файлам shadow, а затем обращалась к службе sssd.
Настройки PAM хранятся в каталоге /etc/pam.d/.
Измените файл /etc/pam.d/system-auth, добавив несколько строк.
Измените файл /etc/pam.d/system-auth, добавив несколько строк.


Строка 444: Строка 460:
<syntaxhighlight>
<syntaxhighlight>
auth        sufficient    pam_sss.so use_first_pass
auth        sufficient    pam_sss.so use_first_pass
account    [default=bad success=ok user_unknown=ignore] pam_sss.so
account    [default=bad success=ok user_unknown=ignore] pam_sss.so
password    sufficient    pam_sss.so use_authtok
password    sufficient    pam_sss.so use_authtok
session    optional      pam_sss.so
session    optional      pam_sss.so
session    required      pam_mkhomedir.so skel=/etc/skel umask=0077
session    required      pam_mkhomedir.so skel=/etc/skel umask=0077
Строка 477: Строка 496:
</syntaxhighlight>'''Сделайте такие же правки в файле /etc/pam.d/pasword-auth'''
</syntaxhighlight>'''Сделайте такие же правки в файле /etc/pam.d/pasword-auth'''


Возможно, вы не хотите, чтобы пользователи входили в систему на сервере - вряд ли вы хотите давать пользователям такую возможность, в том числе и по ssh. Тогда на сервере правки в конфиги pam вносить не нужно - и у пользователей не будет возможности использовать LDAP + Kerberos для авторизации. Но поскольку пользователи должны быть в системе (пусть и без возможности входа), иные настройки (sssd, nsswitch.conf) необходимо сделать. ''(проверить информацию).''
Возможно, вы не хотите, чтобы пользователи входили в систему на сервере, в том числе и по ssh. Тогда на сервере правки в конфиги pam вносить не нужно - и у пользователей не будет возможности авторизоваться непосредственно на сервере. Но поскольку пользователи должны быть в системе (пусть и без возможности входа), иные настройки (sssd, nsswitch.conf) необходимо сделать. ''(проверить информацию).''


===Запуск служб===
===Запуск служб===
Строка 485: Строка 504:
</syntaxhighlight>
</syntaxhighlight>


===Проверка===
===Проверка аутентификации===
Проверка ldap. Эта команда должна вывести информацию о пользователе teacher1.<syntaxhighlight lang="bash">
Проверка ldap. Эта команда должна вывести информацию о пользователе teacher1.<syntaxhighlight lang="bash">
getent passwd teacher1
getent passwd teacher1


</syntaxhighlight>Получение билета Kerberos для пользователя. Выполните эту команду на клиенте. Нужно ввести пароль пользователя teacher1.<syntaxhighlight lang="bash">
</syntaxhighlight>Следующая команда должна вывести информацию о пользователе, включая группы, в состав которых он входит.<syntaxhighlight lang="bash">
id teacher1
 
</syntaxhighlight>Получение билета Kerberos для пользователя. Выполните эту команду на клиенте (должен быть настроен файл /etc/krb5.conf). Нужно ввести пароль пользователя teacher1.<syntaxhighlight lang="bash">
kinit teacher1
kinit teacher1


</syntaxhighlight>После этого введите команду вывода информации о полученном тикете.<syntaxhighlight lang="bash">
</syntaxhighlight>Выведите информацию о полученных билетах.<syntaxhighlight lang="bash">
klist
klist
</syntaxhighlight>Удалите полученный тикет командой<syntaxhighlight lang="bash">
</syntaxhighlight>Удалите полученный билет командой<syntaxhighlight lang="bash">
kdestroy
kdestroy
</syntaxhighlight>Попробуйте переключиться в пользователя.<syntaxhighlight lang="bash">
</syntaxhighlight>Попробуйте переключиться в пользователя teacher1, находясь под пользователем root на клиенте.<syntaxhighlight lang="bash">
su - teacher1
su - teacher1


</syntaxhighlight>Наконец. попробуйте войти в систему в консоли и в десктоп-менеджере.
</syntaxhighlight>Затем попробуйте переключиться в пользователя teacher1 из другой учётной записи (не root).
 
Наконец. попробуйте войти в систему под пользователем teacher1 в текстовой консоли и в десктоп-менеджере.
 
Если это получилось, переходите к настройке хранения домашних каталогов в сети.


== Настройка NFS на сервере ==
== Настройка NFS на сервере ==
Каталог /home на сервере, где будут лежать домашние каталоги всех доменных пользователей, будет доступен по сети. Для этого будем использовать сетевой протокол NFS.


=== Установка пакетов ===
=== Установка пакетов ===
Строка 519: Строка 546:


=== Настройка idmapd ===
=== Настройка idmapd ===
Откройте файл /etc/idmapd.conf и в секцию [General] добавьте параметр Domain.
Откройте файл /etc/idmapd.conf и в секцию [General] добавьте параметр Domain, указав имя сетевого домена.


(нужно уточнить, возможно, нужно как-то запускать службу nfs-idmapd).<syntaxhighlight lang="ini">
''[нужно уточнить, возможно, нужно как-то запускать службу nfs-idmapd]''<syntaxhighlight>
[General]
[General]
Domain = sch179.local
Domain = sch179.local
Строка 530: Строка 557:
На сервере необходимо создать ключи kerberos, которые будет необходимо скопировать на клиентов.
На сервере необходимо создать ключи kerberos, которые будет необходимо скопировать на клиентов.


От имени пользователя root нужно запустить на сервере команду<syntaxhighlight lang="bash">
От имени пользователя root нужно запустить на сервере команду <syntaxhighlight lang="bash">
kadmin.local
kadmin.local


</syntaxhighlight>В консоли kadmin.local нужно ввести команды (не забудьте заменить server.sch179.local на имя своего сервера).<syntaxhighlight lang="bash">
</syntaxhighlight>В консоли kadmin.local нужно ввести команды (не забудьте заменить server.sch179.local на имя своего сервера).
 
Первая команда создаёт на сервере принципал для службы nfs сервера server.sch179.local, без пароля, со случайным ключом. Вторая команда экспортирует ключ этого принципала в файл /etc/krb5.keytab.
 
'''Этот ключ необходимо будет скопировать на все клиенты для шифрования протокола nfs. Без этого ключа, подключение клиента к серверу будет невозможным.'''<syntaxhighlight lang="bash">
addprinc -randkey nfs/server.sch179.local
addprinc -randkey nfs/server.sch179.local
ktadd -k /etc/krb5.keytab nfs/server.sch179.local
ktadd -k /etc/krb5.keytab nfs/server.sch179.local
quit
quit


</syntaxhighlight>Проверим, что ключи были созданы, для этого введите команду от root<syntaxhighlight lang="bash">
</syntaxhighlight>Проверим, что ключи были созданы и экспортированы, для этого введите команду от root<syntaxhighlight lang="bash">
klist -k /etc/krb5.keytab
klist -k /etc/krb5.keytab


Строка 548: Строка 579:
   2 nfs/server.sch179.local@SCH179.LOCAL
   2 nfs/server.sch179.local@SCH179.LOCAL


</syntaxhighlight>'''Созданный в результате файл /etc/krb5.keytab необходимо будет скопировать на каждый клиентский компьютер - иначе kerberos будет отказываться устанавливать соединение с этим компьютером.'''
</syntaxhighlight>
 
=== Экспорт /home на сервере ===
=== Экспорт /home на сервере ===
Теперь настроим экспорт файловой системы /home сервера по сети. Для этого в файле /etc/exports напишем строку<syntaxhighlight>
Теперь настроим экспорт файловой системы /home сервера по сети. Для этого в файле /etc/exports напишем строку<syntaxhighlight>
/home 192.168.0.0/16(rw,sec=krb5p,sync,no_subtree_check)
/home 192.168.0.0/16(rw,sec=krb5p,sync,no_subtree_check)


</syntaxhighlight>192.168.0.0/16 - сеть, из которой разрешён доступ (можете поменять)
</syntaxhighlight>192.168.0.0/16 - сеть, из которой разрешён доступ (поменяйте, как вам нужно)


krb5p - уровень безопасности Kerberos, означающий полное шифрование всех передаваемых данных. Это наиболее безопасно, но создаёт дополнительную нагрузку на процессор. Для уменьшения нагрузки можно использовать варианты без шифрования (но тогда возможен перехват данных): krb5 (только авторизация) или krb5i (проверка контрольных сумм данных для защиты от подмены).
krb5p - уровень безопасности Kerberos, означающий полное шифрование всех передаваемых данных. Это наиболее безопасно, но создаёт дополнительную нагрузку на процессор. Для уменьшения нагрузки можно использовать варианты без шифрования (но тогда возможен перехват данных): krb5 (только авторизация, без шифрования передаваемых данных) или krb5i (авторизация и проверка контрольных сумм данных для защиты от подмены).


Вы можете указать сразу несколько возможных уровней безопасности Kerberos, которые будет поддерживать сервер, например: sec=krb5,sec=krb5i,sec=krb5p
Вы можете указать сразу несколько возможных уровней безопасности Kerberos, которые будет поддерживать сервер, например: sec=krb5,sec=krb5i,sec=krb5p
Строка 579: Строка 609:
Откройте файл /etc/idmapd.conf и в секцию [General] добавьте параметр Domain. Отсутствие этой строки приводит к медленной работе сети (длительный вход в систему, длительное открытие домашнего каталога) при сохранении общей работоспособности.
Откройте файл /etc/idmapd.conf и в секцию [General] добавьте параметр Domain. Отсутствие этой строки приводит к медленной работе сети (длительный вход в систему, длительное открытие домашнего каталога) при сохранении общей работоспособности.


(нужно уточнить, возможно, нужно как-то запускать службу nfs-idmapd).<syntaxhighlight lang="ini">
''[нужно уточнить, возможно, нужно как-то отдельно запускать службу nfs-idmapd]''<syntaxhighlight lang="ini">
[General]
[General]
Domain = sch179.local
Domain = sch179.local
Строка 602: Строка 632:
Теперь попробуем подмонтировать каталог /home с сервера. Это тестовая процедура, чтобы убедиться в том, что связка NFS + Kerberos настроена правильно.
Теперь попробуем подмонтировать каталог /home с сервера. Это тестовая процедура, чтобы убедиться в том, что связка NFS + Kerberos настроена правильно.


Выполняйте все последующие действия под пользователем root.
Выполняйте все последующие действия под пользователем root на клиенте.


Монтирование разделов при помощи NFS+Kerberos требует, чтобы у пользователя был действующий билет Kerberos. Этот билет нужно получить командой (выполним её от root)<syntaxhighlight lang="bash">
Монтирование разделов при помощи NFS+Kerberos требует, чтобы у пользователя был действующий билет Kerberos. Поскольку мы вошли в систему как root, нам нужно получить сначала билет kerberos для какого-нибудь пользователя. Этот билет нужно получить командой (выполним её от root).<syntaxhighlight lang="bash">
kinit teacher1
kinit teacher1
</syntaxhighlight>Понадобится ввести пароль пользователя teacher1. Убедитесь, что билет получен, введя команду <syntaxhighlight lang="bash">
</syntaxhighlight>Понадобится ввести пароль пользователя teacher1. Убедитесь, что билет получен, введя команду <syntaxhighlight lang="bash">
Строка 612: Строка 642:
mount -t nfs -o sec=krb5p server.sch179.local:/home /root/home
mount -t nfs -o sec=krb5p server.sch179.local:/home /root/home


</syntaxhighlight>Эта команда подмонтирует раздел /home с сервера в каталог /root/home на клиенте.
</syntaxhighlight>Эта команда подмонтирует раздел /home с сервера в каталог /root/home на клиенте. При доступе к файлам в этом каталоге ваши права будут соответствовать тому билету, который у вас был, то есть у вас должен быть доступ к каталогу home/teacher1, но не должно быть доступа к каталогам других пользователей.


== Автомонтирование домашних каталогов при помощи autofs ==
== Автомонтирование домашних каталогов при помощи autofs ==
Поскольку монтирование раздела через NFS+Kerberos требует получение билета, а получение билета происходит при авторизации в системе, домашние каталоги пользователей могут монтироваться только после авторизации в системе. Настроим на клиенте autofs, чтобы домашний каталог пользователя монтировался автоматически после входа. Настройка выполняется на клиенте.
Поскольку монтирование раздела через NFS+Kerberos требует получение билета, а получение билета происходит при авторизации в системе, домашние каталоги пользователей могут монтироваться только после авторизации в системе. Настроим на клиенте autofs, чтобы домашний каталог пользователя монтировался автоматически после входа. Также это создаёт дополнительную безопасность, т.к. в результате входа пользователя (например, student1) в систему, будет монтироваться только его домашний каталог (/home/student1), но не домашние каталоги других пользователей.
 
Настройка выполняется на клиенте.


Установим нужные пакеты.<syntaxhighlight lang="bash">
Установим нужные пакеты.<syntaxhighlight lang="bash">
sudo dnf install autofs
sudo dnf install autofs


</syntaxhighlight>Создадим файл /etc/autofs/auto.master.d/home.autofs и запишем в него<syntaxhighlight>
</syntaxhighlight>Создадим файл /etc/autofs/auto.master.d/home.autofs и запишем в него строку<syntaxhighlight>
/home /etc/auto.home --timeout=60
/home /etc/auto.home --timeout=60


</syntaxhighlight>Создадим файл /etc/auto.home и запишем в него<syntaxhighlight>
</syntaxhighlight>Создадим файл /etc/auto.home и запишем в него строку.<syntaxhighlight>
* -sec=krb5p,rw server.sch179.local:/home/&
* -sec=krb5p,rw server.sch179.local:/home/&


Источник — https://it-help-school.ru/Служебная:Сравнение_версий/2237

Навигация