LINUX.ORG.RU
ФорумAdmin

Автомонтирование сетевых ресурсов на многоюзерской рабочей станции

 , , , pam-mount


1

2

Привет, ЛОР.
Топик создаю, чтобы формализовать и более-менее серьезно обсудить вопрос из соседней темы, в которой по причине отсутствия читаемой формулировки вопроса закономерно образовался зоопарк, шапито и варьете с гопаком.

Итак. У нас есть сеть. В сети есть ряд (обязательно более одной!) файлопомоек, протокол, допустим, не имеет значения. Есть сервер каталога, авторизующий юзеров.

Юзеры в организации слоняются между рабочими местами туда-сюда совершенно непредсказуемым образом (допустим, это магазин с продавцами, которые постоянно друг друга подменяют, работают по гибкому графику и увольняются раз в неделю, плюс к ним иногда вламывается кто-то из менеджеров и сидит на первом попавшемся компе). Это суровая данность, и никуда от нее не деться.

В каталоге юзеры аккуратно рассованы по некоторому количеству групп.

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

Как бы вы организовали подобное, чтобы с минимумом действий и максимальной простотой внесения изменений? Очень прошу мало-мальски развернуть ответ, а не тупо скопипастить какой-нибудь из тегов, например.

ЗЫ. А что, теги с нижним подчеркиванием нельзя? Ну и будет теперь дурацкий pam-mount, раз такое дело.

★★★★★

Последнее исправление: thesis (всего исправлений: 2)

Домашний каталог пользователя должен монтироваться с сетевого ресурса?

sin_a ★★★★★
()

логин-скрипт, один на всех. каждому пользователю в .profile его, скажем. или в автозапуск корпоративного ДЕ

belkabelka
()

Я бы монтировал хомяк вместе с директорией, в которой хранились бы shadow, passwd, group (а в /etc — симлинки туда), по nfs. В ~/ каждого в ./bashrc прописан скрипт, монтирующий нужные ресурсы через fuse. А в ~/.bash_logout — размонтирующий.

Все. Пользователю надо только лишь набрать свой логин, ввести пароль, и все ОК.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от belkabelka

или в автозапуск корпоративного ДЕ

Ну в DE вряд ли, а вот в DM можно ли как-нибудь удобно впихнуть скрипт перед запуском DE?
Хотя скриптов, в общем, тоже не хочется, но все-таки тоже решение.

thesis ★★★★★
() автор топика
Ответ на: комментарий от thesis

Если профили на файловом сервере, то просто монтируешь с сервера не /home/user а /home, в котором и user/ и public/ (в котором смонтировано всё что нужно). А если ты на каждом рабочем месте заводишь пользователя с профилем, то разговор можно вообще заканчивать.

sin_a ★★★★★
()

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

Этим очень неудобно рулить. Кроме того, скрипт должен быть уникален для группы, а не для юзера. То есть, как вариант, скрипт монтирования должен вытаскиваться с сервера каталога пост-логин скриптом на основании принадлежности юзера к некоторой группе или нескольким группам.

thesis ★★★★★
() автор топика
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от sin_a

в котором и user/ и public/ (в котором смонтировано всё что нужно).

Кем смонтировано? Как смонтировано? Руками админа, каждому юзеру лично?

А если ты на каждом рабочем месте заводишь пользователя с профилем, то разговор можно вообще заканчивать.

А вот лицо надо носить как-то попроще.

thesis ★★★★★
() автор топика
Ответ на: комментарий от thesis

А что сложного накатать один скрипт для всех, который будет проверять участие юзверя в той или иной группы и запускать соответствующие скрипты?

Очень просто, прозрачно и красиво.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

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

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

Удивлен, кстати, что самбу такому до сих пор не научили. Впрочем, может и научили, а я проворонил - пусть кто-нибудь меня ткнет в это.

thesis ★★★★★
() автор топика
Ответ на: комментарий от thesis

У тебя есть возможность на сервере хранить каталог /mnt/share/home/, в котором уже user1/, user2/, user3/. И в котором-же можно держать все необходимые сетевые ФС с организованными как необходимо правами доступа. И, да, один раз на сервере это может сделать и админ. Тем более что доступ определяется группами, а не отдельными учётными записями.

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

sin_a ★★★★★
()
Ответ на: комментарий от thesis

В моей организации сделано так.
AD сделан на samba4, linux клиенты(debian stable) введены в домен.
Шары монтируются через pam_mount, строчки для монтирования в pam_mount.conf.xml выглядит так:

<volume fstype="cifs" server="fileserver1.domain" path="doc" mountpoint="/home/DOMAIN/%(USER)/Desktop/fileserver1_doc" options="user=DOMAIN\%(USER),iocharset=utf8,rw" />
<volume fstype="cifs" server="fileserver2.domain" path="doc" mountpoint="/home/DOMAIN/%(USER)/Desktop/fileserver2_doc" options="user=DOMAIN\%(USER),iocharset=utf8,rw" />
Пользователь может воспользоваться любой машиной, где будут только папки к которым он имеет доступ.

menzoberronzan
()
Ответ на: комментарий от sin_a

У тебя есть возможность на сервере хранить каталог /mnt/share/home/, в котором уже user1/, user2/, user3/.

Да, и монтировать, конечно, сам /mnt/share/home/, а не домашний каталог пользователя.

sin_a ★★★★★
()
Ответ на: комментарий от thesis

Ну, по-моему, такой велосипед — самое простое решение.

Вариант 2: монтировать вообще все, но четко распределить права доступа.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от sin_a

И, да, один раз на сервере это может сделать и админ. Тем более что доступ определяется группами, а не отдельными учётными записями.

Вотъ. Предполагается, что не «один раз». Берем самый хреновый сценарий. Группы - штука изменчивая. Шары - штука изменчивая. Юзеров миллиард человек. Негоже админу, изменив членство юзера в группе или добавив шару, лезть персонально в нему в хомяк и править руками скрипт. В идеале достаточным действием должна быть правка данных в каталоге.
Или я тебя недопонял?

О профилях пока неохота, я бы вообще предпочел перемещаемые профили вендового типа, честно говоря. Но об этом как-нибудь потом.

thesis ★★★★★
() автор топика
Ответ на: комментарий от Eddy_Em

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

thesis ★★★★★
() автор топика
Ответ на: комментарий от thesis

неохота скриптить - раз

Монтируй все.

в шарах бардак

Дай по шарам тем, кто бардак развел.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от thesis

я бы вообще предпочел перемещаемые профили вендового типа

Честно говоря, не знаю о чём. Но если пользователю на всех рабочих местах нужно один профиль то его нужно либо использовать по сети, либо копировать и затем синхронизировать. Мне кажется что по сети лучше.

Так вот, если у нас есть некая смонтированная ФС, на которой мы видим user1, user2, user3, ... workdir, и в последней каталоги sales, support, tech, buh, а пользователи при этом получают UID'ы и GID'ы при авторизации от ldap, то тебе достаочно определить пользователя в ту или иную группу и забыть о нём.

sin_a ★★★★★
()
Ответ на: комментарий от sin_a

копировать и затем синхронизировать

Вот это примерно и есть венда-way.

Ага, понял, для случая монтирования хомяка по сети - вполне рабочее решение, благодарю. Для моего любимого вендавея не покатит.

thesis ★★★★★
() автор топика
Ответ на: комментарий от thesis

копировать и затем синхронизировать

Вот это примерно и есть венда-way

Мне кажется что это переусложнено. Никогда не сломается та деталь, которой нет. Современная сеть в принципе позволяет работать со смонтированным домашним каталогом. Некоторые даже с тонкими клиентами работают. И в одном месте, ни о чём не думая, просто разобраться с группами.

sin_a ★★★★★
()

homedir, понятно, nfs (autofs) давно отработанная схема.

Остальные маунты тоже autofs, на каждом сетевом диске есть директории доступные юзеру (chown, chmod). У юзера на декстопе линки на нужные ему директории (при заходе autofs монтирует)

sdio ★★★★★
()
Ответ на: комментарий от belkabelka

а, забыл что монтировать-то рутом надо, прошу прощения

fuse

emulek
()
Ответ на: комментарий от sdio

C NFS разобрались, а вот если, например, с локальным профилем? Ну и с локальным монтированием ресурса напрямую к станции, а не сквозь сервер-посредник.

thesis ★★★★★
() автор топика
Последнее исправление: thesis (всего исправлений: 1)

Юзеры в организации слоняются между рабочими местами туда-сюда совершенно непредсказуемым образом (допустим, это магазин с продавцами, которые постоянно друг друга подменяют, работают по гибкому графику и увольняются раз в неделю, плюс к ним иногда вламывается кто-то из менеджеров и сидит на первом попавшемся компе). Это суровая данность, и никуда от нее не деться.

1. это бардак

2. можно разделить всех юзеров на группы. Скажем на 10 групп с разными правами. И сделать 10 учёток на каждом компе. Дальнейшее очевидно. Добавлять/обновлять учётки на всех компах сразу можно специальным скриптом. Авторизация по ssh.

emulek
()
Ответ на: комментарий от emulek

Разумеется, бардак. Как будто бардак - это что-то невообразимо редкое.

И сделать 10 учёток на каждом компе.

Уже плохо. Группы должны храниться в каталоге, принадлежность к группе лучше бы проверять на каталоге и неплохо бы чтобы с помощью чего-нибудь несамописного. А админить каждую тачку по отдельности - неумный мазохизм.

thesis ★★★★★
() автор топика
Ответ на: комментарий от thesis

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

да. Такой велосипед есть и в Win, и в RHEL. Но мне кажется, что в 95% практических случаях их возможности используются на 5%, а остальные 95% функционала является дырами. Которые надо изучить и закрыть. ИМХО проще сделать скрипт, который реализует 5% нужного тебе функционала.

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

Решать конечно тебе.

emulek
()
Ответ на: комментарий от sin_a

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

плюсую.

emulek
()
Ответ на: комментарий от emulek

Такой велосипед есть и в Win, и в RHEL
в RHEL

Как звать?

Решать конечно тебе.

А как же. Я - Заведующий Всем.

thesis ★★★★★
() автор топика
Ответ на: комментарий от thesis

Вотъ. Предполагается, что не «один раз». Берем самый хреновый сценарий. Группы - штука изменчивая. Шары - штука изменчивая. Юзеров миллиард человек. Негоже админу, изменив членство юзера в группе или добавив шару, лезть персонально в нему в хомяк и править руками скрипт.

админ может сделать симлинк в каталог юзера на сервере. Юзер увидит у себя новый каталог. Зачем править скрипт?

emulek
()
Ответ на: комментарий от sdio

PC (user) --> куча_шар_неважно_где,_но_управляемая_одним_админом.
Говорю же: не надо лишний раз писать про бардак. Да, бардак. Интересует выживание в условиях бардака.

thesis ★★★★★
() автор топика
Ответ на: комментарий от emulek

«Каталог юзера на сервере» - это что? Хомяк? Вопрос с сетевыми хомяками уже достаточно обсосан. Теперь интересуют локально хранимые хомяки.

thesis ★★★★★
() автор топика
Ответ на: комментарий от thesis

Уже плохо. Группы должны храниться в каталоге, принадлежность к группе лучше бы проверять на каталоге и неплохо бы чтобы с помощью чего-нибудь несамописного. А админить каждую тачку по отдельности - неумный мазохизм.

«группы» это UID'ы на сервере.

«принадлежность к группе» проверяет ОС сервера, при обращении к каждому файлу. Т.к. если дворник входит на сервер с UID'ом «дворник», то FS отдаёт и показывает ему только те файлы, которые можно дворникам.

А админить каждую тачку по отдельности - неумный мазохизм.

не нужно. На каждой тачке нужно только добавить учётку «дворник», и засунуть туда(в локальных хомяк) ssh ключ дворника. Ну и автомонтирование по fuse. А само администрирование будет на сервере, в каталоге /home/дворник/. Ну и/или в любых других каталогах.

emulek
()
Ответ на: комментарий от emulek

Опять большое спасибо. Пройдите в толксы.

thesis ★★★★★
() автор топика
Ответ на: комментарий от thesis

дык у тебя по любому тоже самое получится. Только

1. NIH

2. всё это будет _поверх_ ОС, а значит — костыли.

Так и скажи: «дайте готовый костыль». Дадут. Но сам понимаешь, не бесплатно.

emulek
()
Ответ на: комментарий от emulek

На каждой тачке нужно только добавить учётку «дворник»

Но зачем? Разве нельзя авторизоваться по ldap, при отсутствии любых локальных учётных записей? ?

sin_a ★★★★★
()
Ответ на: комментарий от sin_a

Но зачем? Разве нельзя авторизоваться по ldap

можно, но это костыль. ИМХО конечно. Без него будет железобетонный UID на сервере, который не обойти.

ЗЫЖ thesis ты спрашивал, как RHDS называется. Так и называется. Вот то, что в федоре сейчас: http://directory.fedoraproject.org/wiki/Main_Page Я не пробовал, но работает вроде... На Over9000 юзеров. IRL.

emulek
()
Ответ на: комментарий от emulek

Про сервер-то я знаю, конечно, хоть и не юзал в бою. Я про клиентов, умеющих монтировать шары, не знаю.

thesis ★★★★★
() автор топика
Ответ на: комментарий от emulek

Локальные учётные записи это забота о том, чтобы на неопределённом количестве машин были нужные логины, с одинаковыми паролями и с одинаковыми, требуемыми UID'ами. И всё это тогда, когда можно просто получать и то и другое и третье из оного места, централизованно...

sin_a ★★★★★
()

монтируй общий корень nfs, а там куда юзер может сунуться а куда не - как раз определяется группами. pretty straightforward. линки по вкусу.

unix системы, и особенно их такие кондовые части как сетевые ФС в принципе не задумывались для расстановки на кучу воркстейшнов, где каждый такой ВС это сам себе сервер. все должны сидеть на одном терм. серваке, там все один раз маунтится и рулится правами. а так да, нужно городить что-то, чего возможно и нет.

у меня дома накрасноглажен automounter с картами в ldap. ну и сам маунт с опцией krb5p чисто для прикола. кое-как работает. да, никакой пер-юзерности, по вышеописанным догадкам. всё маунтится в /net/data/. automounter может сам смонтировать домашний каталог ломящегося юзера.

mos ★★☆☆☆
()
Ответ на: комментарий от thesis

когда-то я вбил себе в голову, что хочу сделать LDAP+Kerberos+services... I didn't quite understand what have I got myself into.)

В лдапе лежат т.н. карты - типа /etc/auto.{master,net,...} (само собой в соотв. виде). автомаунтер на раб. станции (напр. на моем десктопе и моем лаптопе) если его попросить смотрит эти карты, а не те что в /etc. ну и выдает команду типа automount[582]: lookup_mount: lookup(ldap): data -> -fstype=nfs4,sec=krb5p,soft,intr,retry=0 helios.home.lan:/data

kerberos отдельная тема.

дела я всё это по этой хаутушке - http://itdavid.blogspot.ca/2012/05/howto-centos-6.html
лучшее, что я встречал по теме LDAP+Kerberos+...
но рыть кроме этого пришлось много. проверять, перепроверять и т.д. чтобы что-то более-менее понять. да и клиентская часть у меня на sssd а не на классических pam_*

mos ★★☆☆☆
()
Ответ на: комментарий от thesis

я сделал ls /net/data
в логах (если их врубить) видим:

Jan 25 17:21:51 marathon automount[32608]: attempting to mount entry /net/data
Jan 25 17:21:51 marathon automount[32608]: lookup_mount: lookup(ldap): looking up data
Jan 25 17:21:51 marathon automount[32608]: do_bind: lookup(ldap): auth_required: 2, sasl_mech GSSAPI
Jan 25 17:21:51 marathon automount[32608]: sasl_bind_mech: Attempting sasl bind with mechanism GSSAPI
Jan 25 17:21:51 marathon automount[32608]: getuser_func: called with context (nil), id 16385.
Jan 25 17:21:51 marathon automount[32608]: getuser_func: called with context (nil), id 16385.
Jan 25 17:21:51 marathon automount[32608]: sasl_bind_mech: sasl bind with mechanism GSSAPI succeeded
Jan 25 17:21:51 marathon automount[32608]: do_bind: lookup(ldap): autofs_sasl_bind returned 0
Jan 25 17:21:51 marathon automount[32608]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(cn=data)(cn=/)(cn=\2A)))" under "ou=auto.net,ou=autofs,ou=services,dc=home,dc=lan"
Jan 25 17:21:51 marathon automount[32608]: lookup_one: lookup(ldap): getting first entry for cn="data"
Jan 25 17:21:51 marathon automount[32608]: lookup_one: lookup(ldap): examining first entry
Jan 25 17:21:51 marathon automount[32608]: lookup_mount: lookup(ldap): data -> -fstype=nfs4,sec=krb5p,soft,intr,retry=0 helios.home.lan:/data
Jan 25 17:21:51 marathon automount[32608]: parse_mount: parse(sun): expanded entry: -fstype=nfs4,sec=krb5p,soft,intr,retry=0 helios.home.lan:/data
Jan 25 17:21:51 marathon automount[32608]: parse_mount: parse(sun): gathered options: fstype=nfs4,sec=krb5p,soft,intr,retry=0
Jan 25 17:21:51 marathon automount[32608]: parse_mount: parse(sun): dequote("helios.home.lan:/data") -> helios.home.lan:/data
Jan 25 17:21:51 marathon automount[32608]: parse_mount: parse(sun): core of entry: options=fstype=nfs4,sec=krb5p,soft,intr,retry=0, loc=helios.home.lan:/data
Jan 25 17:21:51 marathon automount[32608]: sun_mount: parse(sun): mounting root /net, mountpoint data, what helios.home.lan:/data, fstype nfs4, options sec=krb5p,soft,intr,retry=0
Jan 25 17:21:51 marathon automount[32608]: mount_mount: mount(nfs): root=/net name=data what=helios.home.lan:/data, fstype=nfs4, options=sec=krb5p,soft,intr,retry=0
Jan 25 17:21:51 marathon automount[32608]: mount_mount: mount(nfs): nfs options="sec=krb5p,soft,intr,retry=0", nobind=0, nosymlink=0, ro=0
Jan 25 17:21:51 marathon automount[32608]: get_nfs_info: called with host helios.home.lan(192.168.1.2) proto tcp version 0x40
Jan 25 17:21:51 marathon automount[32608]: get_nfs_info: nfs v4 rpc ping time: 0.000484
Jan 25 17:21:51 marathon automount[32608]: get_nfs_info: host helios.home.lan cost 483 weight 0
Jan 25 17:21:51 marathon automount[32608]: prune_host_list: selected subset of hosts that support NFS4 over TCP
Jan 25 17:21:51 marathon automount[32608]: mount_mount: mount(nfs): calling mkdir_path /net/data
Jan 25 17:21:51 marathon automount[32608]: mount_mount: mount(nfs): calling mount -t nfs4 -s -o sec=krb5p,soft,intr,retry=0 helios.home.lan:/data /net/data
Jan 25 17:21:51 marathon automount[32608]: spawn_mount: mtab link detected, passing -n to mount
Jan 25 17:21:52 marathon rpc.gssd[1778]: ERROR: GSS-API: error in gss_free_lucid_sec_context(): GSS_S_NO_CONTEXT (No context has been established) - Unknown error
Jan 25 17:21:52 marathon rpc.gssd[1778]: WARN: failed to free lucid sec context
Jan 25 17:21:52 marathon rpc.gssd[1778]: ERROR: GSS-API: error in gss_free_lucid_sec_context(): GSS_S_NO_CONTEXT (No context has been established) - Unknown error
Jan 25 17:21:52 marathon rpc.gssd[1778]: WARN: failed to free lucid sec context
Jan 25 17:21:52 marathon automount[32608]: mount_mount: mount(nfs): mounted helios.home.lan:/data on /net/data
Jan 25 17:21:52 marathon automount[32608]: dev_ioctl_send_ready: token = 11
Jan 25 17:21:52 marathon automount[32608]: mounted /net/data
Jan 25 17:21:52 marathon rpc.gssd[1778]: ERROR: GSS-API: error in gss_free_lucid_sec_context(): GSS_S_NO_CONTEXT (No context has been established) - Unknown error
Jan 25 17:21:52 marathon rpc.gssd[1778]: WARN: failed to free lucid sec context
Jan 25 17:21:52 marathon nfsidmap[20828]: nss_getpwnam: name 'deluge' not found in domain 'home.lan'

mos ★★☆☆☆
()
Последнее исправление: mos (всего исправлений: 1)
Ответ на: комментарий от mos

это лучше пропустить, я немного не то скопипастил
vvvvvvvvvvvvvvv
ну и выдает команду типа automount[582]: lookup_mount: lookup(ldap): data -> -fstype=nfs4,sec=krb5p,soft,intr,retry=0 helios.home.lan:/data

в портянке всё, что нужно, в т.ч. и эта строчка.

mos ★★☆☆☆
()
Ответ на: комментарий от thesis

Да, бардак. Интересует выживание в условиях бардака.

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

autofs5-ldap - LDAP map support for autofs, version 5
libpam-mount - PAM module that can mount volumes for a user session
autodir - Automatically creates home and group directories for LDAP/NIS/SQL/local accounts
libpam-ccreds - Pam module to cache authentication credentials
libpam-ldap - Pluggable Authentication Module for LDAP
libpam-mklocaluser - Configure PAM to create a local user if it do not exist already
libpam-ldapd - PAM module for using LDAP as an authentication service
nslcd - Daemon for NSS and PAM lookups using LDAP
sudo-ldap - Provide limited super user privileges to specific users
libpam-pkcs11 - Fully featured PAM module for using for using PKCS#11 smart cards

и это только по запросу «pam and ldap»

sdio ★★★★★
()
Последнее исправление: sdio (всего исправлений: 2)
Ответ на: комментарий от sdio

Я давно не занимаюсь юзерами и их компами

Та же фигня. Этот тред - простое любопытство.

беглый взгляд

Не, ну я тоже так умею. А по сути дела (монтирования) там одна autofs.

thesis ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.