Автор Тема: samba fstab  (Прочитано 4646 раз)

Оффлайн sin

  • alt linux team
  • ***
  • Сообщений: 4
    • Email
samba fstab
« : 29.09.2019 00:46:55 »
В тему давнего обсуждения:
https://forum.altlinux.org/index.php?topic=36935.0

Сегодня не конференции (https://www.basealt.ru/about/news/archive/view/shestnadcataja-konferencija-razrabotchikov-svobodnykh-pro/) подняли вопрос о проблеме монтирования через fstab. На текущем Сизифе (очень близок к недавнему бранчу p9) проверен следующий сценарий монтирования через Kerberos с опцией multiuser (для прощения проблем с локальными правами доступа можно также использовать опцию noperm):

1) Добавляем точку монтирования в fstab (предполагается, что машина введена а домен под именем CLW0 и в /etc/krb5.keytab получены ключи - проверка командой klist -k от рута)
# grep domain /etc/fstab
//dc0.domain.alt/sysvol /mnt/sysvol cifs _netdev,multiuser,sec=krb5,user=CLW0$,users 0 0
2) Включаем цель монтирования удалённых файловых систем в systemd
# systemctl enable remote-fs.target3) Перезагружаемся
# reboot4) После перегагрузки видим смонтированный каталог с учётными данными машины (файлы доступны только от рута):
# mount | grep domain
//dc0.domain.alt/sysvol on /mnt/sysvol type cifs
(rw,nosuid,nodev,noexec,relatime,vers=default,sec=krb5,cache=strict,multiuser,uid=0,noforceuid,gid=0,noforcegid,addr=10.64.171.10,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,noperm,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1,_netdev,user=CLW0$)
5) Проверяем доступ от пользователя без учётных данных в кеше Kerberos
# su - administrator
$ kdestroy
$ ls /mnt/sysvol
ls: cannot access '/mnt/sysvol': Permission denied
$ klist
klist: No credentials cache found (filename: /tmp/krb5cc_1510800500)
6) Получаем учётные данные (при входе доменным пользователем получаются автоматически):
$ kinit
Password for administrator@DOMAIN.ALT:
$ klist
Ticket cache: FILE:/tmp/krb5cc_1510800500
Default principal: administrator@DOMAIN.ALT

Valid starting     Expires            Service principal
09/28/19 19:33:51  09/29/19 05:33:51  krbtgt/DOMAIN.ALT@DOMAIN.ALT
        renew until 10/05/19 19:33:47
7) При попытке доступа получаем автоматическое подключение под учётными данными пользователя:
$ ls /mnt/sysvol/
domain  domain.alt  dsfsdfds  stdin-13066  users.reg
$ klist
Ticket cache: FILE:/tmp/krb5cc_1510800500
Default principal: administrator@DOMAIN.ALT

Valid starting     Expires            Service principal
09/28/19 19:33:51  09/29/19 05:33:51  krbtgt/DOMAIN.ALT@DOMAIN.ALT
        renew until 10/05/19 19:33:47
09/28/19 19:34:15  09/29/19 05:33:51  cifs/dc0.domain.alt@
        renew until 10/05/19 19:33:47
09/28/19 19:34:15  09/29/19 05:33:51  cifs/dc0.domain.alt@DOMAIN.ALT
        renew until 10/05/19 19:33:47

Но это для варианта использования шары в домене. Для других сценарием нужно рассмотреть отдельно. Также нужно проверить на стандартной настройке кеша в ядра (опция default_ccache_name = KEYRING:persistent:%{uid} в /etc/krb5.conf), а также на бранче p8. В целом, результат такой, что можно использовать одну точку монтирования для разных пользователей. Важно учесть, что на стадии загрузки сеть должна быть доступна. Для вариант отложенного монтирования нужно использовать пакет autofs, вместо прямого прописывания шары в fstab.

Оффлайн klark973

  • Завсегдатай
  • *
  • Сообщений: 662
  • Неспящий саппорт
Re: samba fstab
« Ответ #1 : 29.09.2019 23:29:30 »
Важно учесть, что на стадии загрузки сеть должна быть доступна. Для вариант отложенного монтирования нужно использовать пакет autofs, вместо прямого прописывания шары в fstab.
Я бы тут добавил подробностей. Если сеть не окажется поднята вовремя, возникнет один из двух вариантов развития событий. Первый вариант: systemd будет ждать сети очень долго, пока она не появится, либо пока не отработает таймаут. Второй вариант, это и лучшие последствия первого, только тут проблема может иметь плавающий характер: в лучшем случае машина будет хорошо грузиться со смонтированной шарой (когда сеть была доступна), в худшем -- доступа к шаре не будет. Короче, ситуация гонок. Поэтому вариант такого статического монтирования через /etc/fstab в системах с systemd рассматривать не стоит совсем. autofs -- чудесно и удобно, но тоже надо учитывать, что это решение для стационарной рабочей машины. Если АРМ окажется там, где рабочей сети нет, а пользователь обратится к шаре (явно или не совсем), ему придётся долго ожидать "развисания".

Вот примеры сетевого авто-монтирования для систем с systemd, но здесь не учитывается доменная инфраструктура. Пример с "простым" авто-монтированием шары на сервере Samba:

//10.10.3.167/allfiles /home/user/samba-files cifs noauto,rw,x-systemd.automount,x-systemd.device-timeout=10,x-systemd.idle-timeout=1min,iocharset=utf8,uid=user,gid=user,dir_mode=0750,file_mode=0640,workgroup=WORKGROUP,user=pro-test,pass=12345678,_netdev 0 0На Samba-сервере должен быть заведён пользователь pro-test с паролем 12345678. У него должен быть полный доступ к ресурсу [allfiles]. На клиентах работает "из коробки" с дефолтными настройками. mount-файлы systemd в данном случае будет создавать сам, при необходимости. Это лишь пример для упрощения, обычно заданные явно credentials выносят в отдельный файл с правами 0600 и доступный только руту.

Пример с авто-монтированием шары на сервере NFS:

server:/space /mnt/space nfs4 noauto,ro,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,x-systemd.idle-timeout=1min,_netdev 0 0
To moan or to solve -- that is the question!