Школьный сервер LDAP + Kerberos + NFS

Краткое описание

Целью является создание школьного сервера со следующим функционалом.

1. Сервер является сервером авторизации для учащихся школы. Каждому учащемуся выдаётся логин и пароль, при помощи которого он может авторизоваться на любом компьютере, включённым в "школьный домен".
2. У каждого учащегося на сервере есть свой домашний каталог, который монтируется по сети по протоколу NFS при входе в систему. Тем самым файлы учащегося и его настройки будут идентичны на любом компьютере.

Предлагаемые технологии для этого:

1. LDAP для хранения базы пользователей.
2. Kerberos для хранения паролей и авторизации.
3. SSSD для подключения к LDAP и Kerberos.
4. NFS для доступа к домашним каталогам - /home на клиентах является сетевым разделом, монтируемым с сервера.
5. Autofs для автоматического монтирования домашнего каталога пользователя при обращении.

Для реализации будет использоваться платформа РОСА 13, как более современная. В настоящий момент для реализации такой конфигурации можно использовать:

1. Роса "Фреш" 13, версия Server для сервера.
2. МОС-13 (альфа-версия) для клиентских компьютеров (можно использовать Роса "Фреш" 13).

Скорее всего эти инструкции можно применить для дистрибутивов на базе РОСА-2021.1 (МОС-12) без больших изменений.

Установка дистрибутивов и общие идеи конфигурации

Дистрибутивы Роса "Фреш" 13 можно скачать по ссылке. Дистрибутивы Роса "Фреш" доступны для бесплатного использования без каких-либо ограничений (см. лицензионное соглашение при установке).

Поскольку будут настраиваться механизмы авторизации и монтирования /home по сети, необходимо при установке как сервера, так и клиентов разрешить вход пользователю root. Это упростит починку системы, если будет что-то сломано в механизмах авторизации или доступа к /home.

На клиентских компьютерах удобно помимо сетевых пользователей завести общий логин типа "user" или "student", функционирование которого не было бы привязано к работе сервера. Это позволит использовать компьютерные классы при проблемах с сетью или сервером. При этом домашний каталог такого пользователя НЕ ДОЛЖЕН находиться в /home, т.к. при проблемах с доступом /home по сети использование этого каталога будет невозможно. Предлагается разместить домашний каталог такого пользователя в /usr/local/home. Туда же следует перенести и домашний каталог локального администратора системы. Расположение домашнего каталога можно задать сразу при установке системы, нажав на кнопку "Дополнительно".

Можно перенести домашний каталог пользователя в другое место после установки. Пусть логин пользователя admin и мы хотим переместить домашний каталог пользователя из /home/admin в /usr/local/home/admin. Войдите в систему под пользователем root (не используйте sudo, не используйте su - в системе не должно быть открытых сеансов пользователя admin). Выполните команды.

mkdir /usr/local/home
mv /home/admin /usr/local/home/
usermod -d /usr/local/home/admin admin

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

Для пользователей необходимо квотировать размер дискового пространства. Желательный размер квоты на одного пользователя - 3-4 гигабайта, поэтому в масштабах одного школьного здания на хранение файлов пользователей следует выделять порядка 1 террабайта дискового пространства.

Если вам нужна графическая оболочка на сервере, установите lxqt - лёгкую и нетребовательную к ресурсам оболочку.

В дальнейшем все команды предполагается вводить от имени пользователя root или с использованием sudo.

dnf install -y task-lxqt

Для отключения всех ждущих-спящих режимов на компьютере выполните команду (от root).

systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

В МОС-13 может быть установлен пакет authselect-force, который управляет механизмом авторизации пользователей. Этот пакет не нужен, мы не будем использовать его. Удалите его и запретите последующую установку.

dnf remove -y authselect-force
dnf config-manager --setopt exclude="authselect-force" --save

Настройка доменных имён

Для работы Kerberos необходимо, чтобы все компьютеры имели имена (FQDN) и взаимодействовали друг с другом с использованием FQDN.

Предположим, что наша сеть имеет следующий вид. Локальный домен называется sch179.local. Понятие "домен" дальше будет возникать в разных смыслах - DNS-имён, домена LDAP, домена Kerberos. Некоторые из этих доменов должны совпадать, поэтому лучше выбрать один домен для своей школы (мы выбрали sch179.local) и везде используем именно его.

Сервер имеет IP-адрес 192.168.0.1 и имя server.sch179.local

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

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

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

На сервере выполните команду (от root).

hostnamectl set-hostname server.sch179.local

На клиенте выполните аналогичную команду (от root).

hostnamectl set-hostname ws01.sch179.local

В файл /etc/hosts на сервере добавьте адреса и имена всех клиентских компьютеров - строки вида

192.168.1.1 ws01.sch179.local ws01

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

На клиентском компьютере запишите в этот файл адрес и имя сервера - строку

192.168.0.1 server.sch179.local server

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

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

Установка и запуск

Установите на сервере пакеты (команда от root).

dnf install -y openldap-servers openldap-clients

Удалите файл /usr/share/openldap-servers/UPGRADE_INSTRUCTIONS

rm -f /usr/share/openldap-servers/UPGRADE_INSTRUCTIONS

Включите и запустите службу LDAP (команда от root).

systemctl enable --now slapd

Проверьте, что LDAP запущен и отвечает на запросы (команда от root).

systemctl status slapd.service
ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config dn

Создание базы и записи администратора LDAP

Сначала нужно создать хеш пароля администратора LDAP. Для этого запустите команду

slappasswd

и введите пароль два раза. Команда выведет хеш пароля. Например, при вводе "qwerty123" программа может выдать такой хеш:

{SSHA}51OzQC2m1HfQMEzuV8B7qY0TfSkNq+rX

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

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

Теперь создадим базу LDAP и запись администратора LDAP.

Создайте файл create-db.ldif и вставьте в него такой текст. Здесь dc=sch179,dc=local - суффикс имён всех объектов, которые будут храниться в LDAP. Замените здесь sch179 на своё название, делайте это везде в дальнейшем.

Замените хеш пароля в последней строке на тот, который вы получили.

dn: olcDatabase={2}mdb,cn=config
changetype: add
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {2}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=sch179,dc=local
olcRootDN: cn=admin,dc=sch179,dc=local
olcRootPW: {SSHA}51OzQC2m1HfQMEzuV8B7qY0TfSkNq+rX

Добавьте содержимое этого файла в базу LDAP.

ldapmodify -Y EXTERNAL -H ldapi:/// -f create-db.ldif

Проверка созданной базы командой.

ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=config" "(olcDatabase=*)"

Добавление схем

Далее в базу нужно добавить "схемы" - описание разных видов объектов (например, групп и учётных записей). Выполните команды:

ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/cosine.ldif
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/nis.ldif
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/inetorgperson.ldif

Для проверки введите команду:

ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=schema,cn=config" dn

Она должна вывести текст, в котором есть строки:

dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}nis,cn=schema,cn=config
dn: cn={3}inetorgperson,cn=schema,cn=config

Создание базовой структуры организации

Далее в базу LDAP нужно добавить разделы для хранения учетных записей и групп. Создайте файл base.ldif следующего содержания, заменив везде sch179 и параметр o: School No 179 на описание вашей школы.

dn: dc=sch179,dc=local
objectClass: top
objectClass: organization
objectClass: dcObject
o: School No 179
dc: sch179

dn: ou=people,dc=sch179,dc=local
objectClass: organizationalUnit
ou: people

dn: ou=groups,dc=sch179,dc=local
objectClass: organizationalUnit
ou: groups

dn: cn=admin,dc=sch179,dc=local
objectClass: organizationalRole
cn: admin
description: LDAP Administrator

Добавление в LDAP (не забудьте заменить sch179 на своё название):

ldapadd -x -D "cn=admin,dc=sch179,dc=local" -W -f base.ldif

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

Для проверки введите команду (не забудьте заменить sch179 на своё название):

ldapsearch -x -b "dc=sch179,dc=local"

Создание групп пользователей

Пусть мы ходим создать группы пользователей admins (администраторы), teachers (учителя), misc (другие сотрудники) и students (учащиеся).

Создайте файл groups.ldif. Замените в нём sch179 на своё название. Можете поменять названия и описания групп, их gidNumber.

dn: cn=admins,ou=groups,dc=sch179,dc=local
objectClass: top
objectClass: posixGroup
cn: admins
gidNumber: 2000
description: System administrators

dn: cn=teachers,ou=groups,dc=sch179,dc=local
objectClass: top
objectClass: posixGroup
cn: teachers
gidNumber: 3000
description: School teachers

dn: cn=misc,ou=groups,dc=sch179,dc=local
objectClass: top
objectClass: posixGroup
cn: misc
gidNumber: 4000
description: Miscellaneous people

dn: cn=students,ou=groups,dc=sch179,dc=local
objectClass: top
objectClass: posixGroup
cn: students
gidNumber: 5000
description: Students

Добавление этого файла в LDAP (команда от root):

ldapadd -x -D "cn=admin,dc=sch179,dc=local" -W -f groups.ldif

Проверка - запрос информации обо всех группах:

ldapsearch -x -b "ou=groups,dc=sch179,dc=local" "(objectClass=posixGroup)"

Создание пользователей

Попробуем добавить тестовых пользователей.

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

Создайте файл users.ldif следующего содержания. Не забудьте поменять sch179 на своё название, остальное - по мере необходимости.

dn: cn=teacher1,ou=groups,dc=sch179,dc=local
objectClass: posixGroup
cn: teacher1
gidNumber: 3001
description: Primary group for user teacher1

dn: uid=teacher1,ou=people,dc=sch179,dc=local
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: teacher1
sn: Иванов
givenName: Сергей
cn: Сергей Иванов
uidNumber: 3001
gidNumber: 3001
homeDirectory: /home/teacher1
loginShell: /bin/bash
description: User teacher1 (Сергей Иванов)

dn: cn=student1,ou=groups,dc=sch179,dc=local
objectClass: posixGroup
cn: student1
gidNumber: 5001
description: Primary group for user student1

dn: uid=student1,ou=people,dc=sch179,dc=local
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: student1
sn: Васильева
givenName: Мария
cn: Мария Васильева
uidNumber: 5001
gidNumber: 5001
homeDirectory: /home/student1
loginShell: /bin/bash
description: User student1 (Мария Васильева)

Добавление:

ldapadd -c -x -D "cn=admin,dc=sch179,dc=local" -W -f users.ldif

Проверка:

ldapsearch -x -b "ou=people,dc=sch179,dc=local" "(uid=teacher1)"
ldapsearch -x -b "ou=groups,dc=sch179,dc=local" "(cn=teacher1)"

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

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

Установка пакетов

dnf install -y krb5-server krb5-libs krb5-workstation

Настройка главного конфига Kerberos

Измените файл /etc/krb5.conf, записав в него следующий текст (нужно записать параметр default_realm и заполнить разделы [realms] и [domain_realm]).

Обратите внимание, на клиентах также будет необходимо настроить этот файл (см. ниже).

includedir /etc/krb5.conf.d/

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = SCH179.LOCAL
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true

[realms]
 SCH179.LOCAL = {
  kdc = server.sch179.local
  admin_server = server.sch179.local
 }

[domain_realm]
 .sch179.local = SCH179.LOCAL
 sch179.local = SCH179.LOCAL

Создание базы данных

Выполните команду. Нужно будет установить мастер-пароль для базы Kerberos,. Выполните команду от root.

kdb5_util create -s

Введите два раза KDC database master key (пароль администратора базы данных Kerberos), надёжно сохраните этот пароль.

Конфигурация базы данных Kerberos

Запишите в файл /var/kerberos/krb5kdc/kdc.conf следующий текст.

[realms]
 SCH179.LOCAL = {
  database_name = /var/kerberos/krb5kdc/principal
  admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
  acl_file = /var/kerberos/krb5kdc/kadm5.acl
  key_stash_file = /var/kerberos/krb5kdc/.k5.SCH179.LOCAL
  kdc_ports = 88
  kdc_tcp_ports = 88
  max_life = 24h
  max_renewable_life = 7d
  default_principal_flags = +forwardable
 }

Запишите в файл /var/kerberos/krb5kdc/kadm5.acl следующий текст.

*/admin@SCH179.LOCAL *

Включение и запуск служб

Выполните команды.

systemctl enable --now krb5kdc
systemctl enable --now kadmin

Создание принципала kadmin/admin

В базе Kerberos хранятся "принципалы" (principals) - идентификаторы пользователей, сервисов, хостов.

Утилита kdamin.local используется для управления базой Kerberos непосредственно на сервере Kerberos. Если запустить эту команду без параметров, то запустится оболочка, в которую можно вводить команды Kerberos. Например, команда "listprincs" выводит список всех принципалов. Команда "quit" завершает работу kdamin.local.

Другой способ использования kadmin.local - это указать команду непосредственно в виде параметров при запуске kdamin.local. Например, вывести список всех принципалов можно командой

kadmin.local listprincs

Специальным принципалом является принципал с именем kadmin/admin. Этот принципал необходимо создать, если вы будете управлять базой Kerberos с другого компьютера. Если все команды администрирования Kerberos будут вводиться через kadmin.local, то принципал kadmin/admin можно не создавать.

Для создания этого принципала запустите kadmin.local и в его консоли введите команду.

addprinc kadmin/admin

Задайте пароль для этого принципала. Завершите работу kadmin.local командой quit.

Если такой принципал уже существует в системе, создать его не получится. В этом случае нужно сначала удалить принципал kadmin/admin, затем создать его заново.

Создание принципалов для пользователей

Для каждого пользователя системы, необходимо создать принципал, например, принципалы teacher1, student1.

Это можно сделать разными способами. Можно запустить kadmin.local и ввести команду addprinc для создания принципала каждого пользователя, например,

addprinc teacher1
addprinc student1

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

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

kadmin.local addprinc -pw qwerty456 teacher1
kadmin.local addprinc -pw qwerty789 student1

Параметр -pw задаёт пароль принципала, то есть эти команды создадут принципал teacher1 с паролем qwerty456 и принципал student1 с паролем qwerty789.

Вывести список всех принципалов, хранящихся в Kerberos, можно командой.

kadmin.local -q list_principals

Доступ к LDAP и Kerberos через SSSD

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

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

Установка пакетов

dnf install -y sssd sssd-krb5 sssd-ldap openldap-clients krb5-workstation

Настройка sssd

Создайте файл /etc/sssd/sssd.conf и запишите в него следующий текст, внеся нужные правки.

[sssd]
domains = sch179.local
services = nss, pam

[domain/sch179.local]
id_provider = ldap
auth_provider = krb5

ldap_uri = ldap://server.sch179.local
ldap_search_base = dc=sch179,dc=local
ldap_id_use_start_tls = false
ldap_tls_reqcert = never

krb5_realm = SCH179.LOCAL
krb5_server = server.sch179.local

cache_credentials = true
enumerate = false

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

Установите на этот файл права.

chmod 600 /etc/sssd/sssd.conf
chown root:root /etc/sssd/sssd.conf

Настройка 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, заменив в нём три строки, начинающиеся с passwd:, shadow: и group: на следующие:

passwd:     files sss
shadow:     files sss
group:      files sss

Настройка PAM

PAM (Pluggable Authentication Module) - это библиотека, осуществляющая аутентификацию пользователей. Нужно настроить эту библиотеку так, чтобы сначала она сначала проверяла пароль по локальным файлам shadow, а затем обращалась к службе sssd.

Настройки PAM хранятся в каталоге /etc/pam.d/.

Измените файл /etc/pam.d/system-auth, добавив несколько строк.

Первое слово каждой строки (auth, account, password, session) - это интерфейс (тип взаимодействия): аутентификация, проверка учетной записи, управление паролями, управление сеансами. Добавляйте указанные строки после всех строк такого же интерфейса, но перед строкой pam_deny.so, если она есть для данного интерфейса (в интерфейсах auth и password).

auth        sufficient    pam_sss.so use_first_pass

account     [default=bad success=ok user_unknown=ignore] pam_sss.so

password    sufficient    pam_sss.so use_authtok

session     optional      pam_sss.so

Четыре строки с pam_sss.so получают информацию об учётной записи через модуль pam_sss.

Скорее всего у вас получится такой файл.

#%PAM-1.0
auth        required      pam_env.so
auth        sufficient    pam_unix.so try_first_pass likeauth nullok
auth        sufficient    pam_sss.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so
account     [default=bad success=ok user_unknown=ignore] pam_sss.so

password    sufficient    pam_unix.so try_first_pass nullok sha512 shadow
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     optional      pam_env.so
session     optional      pam_umask.so
session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so

Сделайте такие же правки в файле /etc/pam.d/pasword-auth

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

Запуск служб

systemctl enable --now sssd

Проверка аутентификации

Проверка ldap. Эта команда должна вывести информацию о пользователе teacher1.

getent passwd teacher1

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

id teacher1

Получение билета Kerberos для пользователя. Выполните эту команду на клиенте (должен быть настроен файл /etc/krb5.conf). Нужно ввести пароль пользователя teacher1.

kinit teacher1

Выведите информацию о полученных билетах.

klist

Удалите полученный билет командой

kdestroy

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

su - teacher1

Затем попробуйте переключиться в пользователя teacher1 из другой учётной записи (не root), со вводом пароля.

Наконец. попробуйте войти в систему под пользователем teacher1 в текстовой консоли и в графической оболочке.

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

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

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

Установка пакетов

Установите нужные пакеты.

dnf install -y nfs-utils krb5-server krb5-workstation

Включение и запуск служб

Включите и запустите нужные службы.

systemctl enable --now nfs-server 
systemctl enable --now rpcbind
systemctl enable --now gssproxy

Настройка idmapd

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

[General]
Domain = sch179.local

Создание ключей Kerberos

На сервере необходимо создать ключи kerberos, которые будут использоваться в протоколе NFS. Эти ключи необходимо скопировать на компьютеры клиентов.

От имени пользователя root нужно запустить на сервере команду

kadmin.local

В консоли kadmin.local нужно ввести команды (не забудьте заменить server.sch179.local на имя своего сервера).

Первая команда создаёт на сервере принципал для службы nfs сервера server.sch179.local, без пароля, со случайным ключом. Вторая команда экспортирует ключ этого принципала в файл /etc/krb5.keytab.

addprinc -randkey nfs/server.sch179.local
ktadd -k /etc/krb5.keytab nfs/server.sch179.local
quit

Проверим, что ключи были созданы и экспортированы, для этого введите команду от root

klist -k /etc/krb5.keytab

Вывод будет таким.

Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   2 nfs/server.sch179.local@SCH179.LOCAL
   2 nfs/server.sch179.local@SCH179.LOCAL

Файл с ключами /etc/krb5.keytab необходимо будет скопировать на все клиенты для шифрования протокола nfs. Без этого ключа, подключение клиента к серверу будет невозможным.

Экспорт /home на сервере

Теперь настроим экспорт файловой системы /home сервера по сети. Для этого в файле /etc/exports напишем строку

/home 192.168.0.0/16(rw,sec=krb5p,async,no_subtree_check)

Здесь 192.168.0.0/16 - сеть, из которой разрешён доступ. Замените его на адрес своей локальной сети.

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

Вы можете указать сразу несколько возможных уровней безопасности Kerberos, которые будет поддерживать сервер, например: sec=krb5,sec=krb5i,sec=krb5p

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

Примените изменения командой

exportfs -ra

Проверьте, что система экспортируется, выполнив команду

exportfs -v

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

Установка пакетов

Установите нужные пакеты.

dnf install nfs-utils krb5-workstation

Копирование ключей Kerberos

Скопируйте файл с ключами /etc/krb5.keytab с сервера на клиентскую машину. Установите владельца root:root и права доступа 600 на этот файл.

Проверьте наличие ключей в этом файле командой

klist -k /etc/krb5.keytab

Включение и запуск служб

Запустите нужные службы.

systemctl enable --now nfs-client.target
systemctl enable --now gssproxy

Настройка idmapd

Откройте файл /etc/idmapd.conf и в секцию [General] добавьте параметр Domain.

[General]
Domain = sch179.local

Также нужно убедиться, что служба nfs-idmapd запущена и на сервере, и на клиенте. Для этого после перезагрузки выполните команду.

systemctl status nfs-idmapd

На сервере скорее всего вы увидите, что служба работает - в выводе будет строка "Active: active (running)". А на клиенте - не работает ("Active: inactive (dead)").

Это связано с тем, что на сервере запущена служба nfs-server, а на клиенте - только nfs-client, которая не включает по умолчанию nfs-ifmapd.

Нам нужно добавить автозапуск nfs-idmapd на клиенте при достижении цели nfs-client в настройках systemd. Но это нельзя сделать при помощи systemctl enable nfs-idmapd (попробуйте).

Для этого нужно создать на клиенте каталог /etc/systemd/system/nfs-client.target.d и записать в файл /etc/systemd/system/nfs-client.target.d/override.conf следующий текст.

[Unit]
Wants=nfs-idmapd.service
After=nfs-idmapd.service

Перезагрузите клиентский компьютер и проверьте, что служба nfs-idmapd запустилась после перезагрузки.

Отсутствие работающей службы nfs-idmapd приводит к медленной работе сетевых дисков (длительный вход в систему, длительное открытие домашнего каталога) при сохранении общей работоспособности.

Проверка монтирования файловой системы

Теперь попробуем подмонтировать каталог /home с сервера. Это тестовая процедура, чтобы убедиться в том, что связка NFS + Kerberos настроена правильно.

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

Монтирование разделов при помощи NFS+Kerberos требует, чтобы у пользователя был действующий билет Kerberos. Поскольку мы вошли в систему как root, нам нужно получить сначала билет kerberos для какого-нибудь пользователя (например, teacher1). Этот билет нужно получить командой (выполним её от root).

kinit teacher1

Понадобится ввести пароль пользователя teacher1. Убедитесь, что билет получен, введя команду

klist

Имея билет, можно выполнить команду монтирования. Создайте на компьютере точку для монтирования, например, /root/home. Затем дайте команду.

mount -t nfs -o sec=krb5p server.sch179.local:/home /root/home

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

Автомонтирование домашних каталогов при помощи autofs

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

Настройка выполняется на клиенте.

Установим пакет autofs.

sudo dnf install autofs

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

/home /etc/auto.home --timeout=60

Создадим файл /etc/auto.home и запишем в него строку.

* -sec=krb5p,rsize=1048576,wsize=1048576,hard,noatime,nosuid,timeo=600,retrans=2 server.sch179.local:/home/&

Включим и запустим службу autofs

systemctl enable --now autofs

Включение дисковых квот

На сервере необходимо включить дисковые квоты для пользователей на разделе /home.

Пусть раздел, на котором хранится /home, находится на устройстве /dev/sda4. Измените это имя в дальнейших настройках.

Файловая система ext4

Установите пакет quota

dnf install quota

Добавьте в файл /etc/fstab опцию usrquota для монтирования нужного раздела. Должно получиться примерно так.

/dev/sda4 /home ext4 noatime,usrquota 0 2

В вашем файле /etc/fstab вместо /dev/... может быть указано UUID=... Отмонтируйте раздел.

umount /home

Современные ядра Linux поддерживают квоты на уровне файловой системы ext4. Нужно добавить эту возможность в вашу файловую систему. Если у вас старое ядро - квоты будут храниться в специальном файле в корне файловой системы.

tune2fs -O quota /dev/sda4

Подмонтируйте раздел

mount /home

Создайте записи для хранения квот (в файле или внутри файловой системы, в зависимости от ядра).

quotacheck -cum /home

Включите квоты на файловой системе.

quotaon /home

Файловая система xfs

В файловой системе xfs поддержка квот уже присутствует. Достаточно только указать опцию в /etc/fstab при монтировании файловой системы.

/dev/sda4 /home xfs noatime,usrquota 0 2

Массовое создание пользователей

Для создания пользователя нужно выполнить следующие шаги.

1. Добавить информацию о пользователе в LDAP.
2. Создать билет Kerberos.
3. Создать домашний каталог и скопировать туда содержимое /etc/skel или аналогичного каталога.
4. Установить квоты.

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

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

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

Каждому учащемуся назначается логин вида s29a_ivanov. Здесь s - первая буква слова student, 29 - год окончания школы, a - буква класса, ivanov - фамилия учащегося. То есть это логин пользователя ivanov из А-класса 2029 года выпуска. Если в классе сть однофамильцы, к фамилии можно добавлять имя или одну букву имени.

Всем пользователям назначаются уникальные идентификаторы. Например, для класса s29a можно выдавать идентификаторы, начинающиеся с 291: 29101, 29102, 29103 и т.д. То есть идентификаторы - пятизначные числа, где первые две цифры означают год выпуска, следующая цифры - буква класса (можно отвести и две цифры, если одной недостаточно), следующие две цифры - номер учащегося в класса. Учащимся класса s29b будут выдаваться идентификаторы 29201, 29202 и т.д.

Также каждому учащемуся нужно сделать пароль. Много случайных паролей можно сгенерировать утилитой pwgen.

Подготовьте текстовый файл с новыми пользователями. Удобно создавать отдельный файл на каждый класс. Файл будет выглядеть таким образом:

29101 students s29a_bezukhov Безухов Пётр t8Fi5A77
29102 students s29a_rostova Ростова Наталья LRhevK2O

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

Для работы утилиты useradmin.py необходим конфигурационный файл .useradmin.conf, который должен находиться в домашнем каталоге (например, /root/.useradmin.conf). Запуск утилиты создаст этот файл, если он не существует. Отредактируйте этот файл, задав актуальный адрес вашего сервера, суффикс ваших записей в LDAP, пароли доступа к LDAP и Kerberos (для доступа к Kerberos можно использовать kadmin.local). Установите значения дисковой квоты и путь к каталогу skel, где хранятся файлы, которые будут копироваться в домашний каталог по умолчанию.

Скрипт запускается так

python useradmin.py add-file users.txt

python useradmin.py add-file users.txt

Или если сделать файл useradmin.py исполняемым, то ./useradmin.py add-file users.txt

./useradmin.py add-file users.txt

Примеры параметров, которые можно передавать скрипту

Параметры скрипта	Выполняемое действие
list-users	Вывести список пользователей
list-users --detailed	Вывести список пользователей с подробной информацией (наличие принципала Kerberos, дисковая квота)
add-file users.txt	Создать пользователей используя файл users.txt. Создаются записи в LDAP, Kerberos, создаётся домашний каталог и устанавливается квота
add-file users.txt --ldap	Только создать записи ldap
add-file users.txt --kerberos	Только создать принципалы Kerberos
add-file users.txt --home	Только создать домашние каталоги (и скопировать туда skel)
add-file users.txt --quota	Только установить квоту
add-file users.txt --steps ldap kerberos home	Выполнить только указанные шаги (ldap, kerberos, home), то есть создать пользователя с домашним каталогом, но без квоты
delete-user user_login	Удалить пользователя с логином user_login (в том числе удаляется и домашний каталог)

Подключение ноутбуков к WiFi до входа в систему

На компьютере должна быть поднята сеть до входа в систему. Если используются ноутбуки с WiFi, то подключение к WiFi сети должно быть осуществлено до входа пользователя в систему, то есть без участия пользователя. Это возможно сделать, если для подключения к WiFi-сети достаточно указать только SSID и ключ подключения к сети.

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

nmcli dev wifi list

Добавьте новую сеть командой, заменив YOUR_SSID на SSID вашей сети и YOUR_PASSWORD - на ключ подключения к вашей сети. school-wifi - это имя соединения, его также можно изменить.

nmcli dev wifi connect YOUR_SSID password YOUR_PASSWORD name school-wifi

Установите автоподключение для этого соединения.

nmcli connection modify school-wifi connection.autoconnect yes

В каталоге /etc/NetworkManager/system-connections/ появится файл school-wifi.nmconnection примерно такого содержания

[connection]
id=school-wifi
uuid=***какой-то uuid***
type=wifi
interface-name=wlp0s20f3
timestamp=1753189862

[wifi]
mode=infrastructure
ssid=***SSID вашей сети***

[wifi-security]
auth-alg=open
key-mgmt=wpa-psk
psk=***ключ вашей сети***

[ipv4]
method=auto

[ipv6]
addr-gen-mode=default
method=auto

[proxy]

Обслуживание системы

Обновление ldap

В состав пакета openldap-servers входит файл /usr/share/openldap-servers/UPGRADE_INSTRUCTIONS с инструкциями по обновлению базы данных при обновлении сервера ldap. Если этот файл присутствует в системе, то сервер ldap не запустится (посмотрите команду systemctl status slapd). Чтобы сервер стартовал, необходимо удалить этот файл. Предполагается, что администратор системы выполняет действия по обновлению базы ldap, затем удаляет этот файл. Однако, при минорных обновлениях версии ldap эти действия не нужны, но файл восстанавливается при любом обновлении пакета openldap-servers. Поэтому как правило, если был обновлён пакет openldap-servers, например, при выполнении команды dnf update, необходимо удалить этот файл и перезапустить сервис ldap.

rm -f /usr/share/openldap-servers/UPGRADE_INSTRUCTIONS
systemctl restart slapd