From: Evgeny Sinelnikov <sin@altlinux.org> To: ALT Linux Community general discussions <community@lists.altlinux.org> Cc: Andrey Cherepanov <cas@altlinux.org> Subject: Re: [Comm] Создание пользователей в Альтераторе Date: Tue, 19 Oct 2021 02:21:07 +0400 Message-ID: <CAK42-Goi9Zgx+0PQTy9QXCfuOi2TF5fNuRkUvtfwawOZaRREdw@mail.gmail.com> (raw) In-Reply-To: <246391634570731@mail.yandex.ru> Доброй ночи. пн, 18 окт. 2021 г. в 23:59, Максим Калинин <maxkalinin@yandex.ru>: > > + boyarsh@, community@ > > Да нет необходимости в "Контроллере Домена" в качестве отдельной сущности .. > Нужен единственный файловый сервер с авторизацией, на котором домашние каталоги. > И пользователей два десятка. > Просто с доменом это делается достаточно быстро и просто .. > > Можно это (автосоздание каталогов) где-то подкрутить ? > Или тянуть p7 ? Конечно, можно. Давайте разберемся в некоторых деталях. Модуль pam_mkhomedir используется для создания домашних каталогов для вновь созданных пользователей при их логине на конкретную машину. Он отрабатывает через цепочку модулей для заданных приложений в каталоге /etc/pam.d На текущий момент все механизмы аутентификации разделены на специфические для конкретной задачи модули. В частности system-auth отделён от system-policy: $ sudo control system-auth help krb5: authentication via Kerberos 5 krb5_ccreds: authentication via Kerberos 5 with local caching ldap: authentication via LDAP local: local authentication multi: use multi authentication method pkcs11: use pkcs11 authentication method pkcs11_strict: use pkcs11_strict authentication method sss: use sss authentication method winbind: authentication via Winbind $ sudo control system-policy help gpupdate: use gpupdate session policy local: local session policy remote: remote session policy with mkhomedir Кроме того, system-auth отрабатывает соответствующие модули сетевой аутентификации только для нелокальных пользователей (то есть таких пользователей, имена которых отсутствуют в /etc/passwd) по следующей схеме: MODULE [success=4 perm_denied=ignore default=die] pam_localuser.so MODULE [success=1 default=bad] pam_succeed_if.so uid >= 500 quiet MODULE [default=1] pam_permit.so MODULE substack system-auth-sss-only MODULE [default=1] pam_permit.so MODULE substack system-auth-local-only MODULE substack system-auth-common Список всех возможных вариантов можно посмотреть в соответствующих файлах настройки, которые управляются через control system-auth: $ ls -1 /etc/pam.d/system-auth-* | grep -v -e '.*-only$' -e '.*-use_first_pass.*' -e 'system-auth-common' /etc/pam.d/system-auth-krb5 /etc/pam.d/system-auth-krb5_ccreds /etc/pam.d/system-auth-ldap /etc/pam.d/system-auth-local /etc/pam.d/system-auth-multi /etc/pam.d/system-auth-pkcs11 /etc/pam.d/system-auth-pkcs11_strict /etc/pam.d/system-auth-sss /etc/pam.d/system-auth-winbind Модуль pam_mkhomedir перенесён в механизм, управляемый через соответствующий control system-policy (см. help выше). Этот механизм применяется только для приложений выполняющих вход в систему (common-login), что исключает сайд-эффекты "ложного" срабатывания для локальных подсистем. Например, для системных сервисов. # cat /etc/pam.d/common-login #%PAM-1.0 auth substack system-auth auth substack system-policy auth required pam_nologin.so account substack system-auth account substack system-policy account required pam_nologin.so password include system-auth password include system-policy session substack system-auth session required pam_loginuid.so -session optional pam_systemd.so session substack system-policy _____________________________ Насколько я понимаю, чтобы вернуть "оригинальное" поведение, которое ожидается для данного случая, достаточно вписать модуль pam_mkhomedir в файл system-auth-common: # cat /etc/pam.d/system-auth-common #%PAM-1.0 #account required pam_access.so session required pam_mktemp.so session required pam_limits.so Примерно так: #%PAM-1.0 #account required pam_access.so session required pam_mkhomedir.so silent session required pam_mktemp.so session required pam_limits.so Не думаю, что это правильный путь, но он должен решить вашу проблему. _____________________________ Правильно же было бы разобраться со схемой управления пользователями в ALT-домене и добавить в него соответствующий функционал по созданию каталогов. Честно говоря, я не очень понимаю сценарий работы всей этой схемы. Предполагаю, что домен, как бы всё-таки есть. Или нет? Есть там же и файловый сервер. И вот получается, что файловый сервер не пускает пользователей, поскольку домашние каталоги для них не создаются. Но кто бы сказал, что они должны создаваться? Наверное, для этого нужна соответствующая "ручка". Правильно ли я понимаю, что создавая учётную запись ALT-домене, предполагается, что на этом же сервере разворачивается файловый Samba-сервер и на этом же сервере у всех пользователей домена создаются домашние каталоги? Подозреваю, что оригинальный сценарий реализован в модуле alterator-ldap-users в функции ldap_user_new(), примерно следующим образом: 513 # trying to init user homedir 514 local init_user="$(su - $1 -s /bin/true > /dev/null 2>&1)" То есть это изначально, особенный вариант поведения под конкретную задачу. Вот именно "su - USERNAME" больше и не отрабатывает. Да и не должен. Тут нужно придумать что-то более надёжное и предсказуемое. Думаю, стоит добавить для этой задачи явную галочку - создавать домашний каталог пользователя. Но где его нужно создавать? На каком сервере? Ведь вовсе не обязательно, что файловый сервер и сервер ALT-домена будут на одном узле. По уму, данное поведение не имеет никакого отношения к созданию пользователей. Насколько я понимаю, требуется, чтобы при первой попытке захода на файловую шару создавался домашний каталог пользователя. Скорее всего, этот каталог даже не требуется инициализировать файлами из /etc/skel. Более того, даже не стоит, наверное, располагать домашние каталоги в /home. Надёжнее было бы перенести шару [homes] в отдельный каталог, например, /people или /srv/home. Для создания же пустых домашних каталогов стоит воспользоваться скриптами. Для этого существует специальная опция exec или preexec (см. man smb.conf): https://serverfault.com/questions/576136/how-to-force-samba-to-create-directory Предлагаю повесить по этому поводу багу на alterator-ldap-users с конкретным предложением по данному поведению. Хотя к alterator-ldap-users эта проблема не имеет никакого отношения. Тут нужно галочку в управлялке файловым сервером делать. _____________________________ Ещё раз. Вернуть оригинальное поведение просто (см. детали выше) - достаточно вписать модуль pam_mkhomedir в /etc/pam.d/system-auth-common. Но это стоит проверить. Буду благодарен, если кто-нибудь подтвердит, что всё так и есть. > > > Спасибо! > > 16.10.2021, 12:21, "Andrey Cherepanov" <cas@altlinux.org>: > > А какая разница, какой тип домена? Зачем на контроллере домена создавать домашние каталоги всех доменных пользователей? > > 15.10.2021 22:23, Максим Калинин пишет: > > Так ведь домен-то "ALT-Domain", а не ActiveDirectory ! > Для него не нужен отдельный контроллер и отдельный файловый сервер, достаточно одного ... > В таком варианте очень не удобно сначала в Альтераторе создавать юзера, затем вручную создавать ему каталог с соответствующими правами ...! > > Логично ? > > > > 15.10.2021, 21:20, "Andrey Cherepanov" <cas@altlinux.org>: > > 15.10.2021 17:06, Максим Калинин пишет: > > Здравствуйте! > С удивлением обнаружил, что на вновь поставленном Alt Server 9 ( при > созданном AT-домене ) > при создании пользователя в Альтераторе его домашний каталог не создается. > Создается только для локальных Unix-пользователей ... > Такая же ситуация с Alt Server 8.2.1 .. > В дистрибутивах на основе p7 подобного поведения не наблюдалось. > Или, может быть, я делаю что-то не так ? > > А с чего должны создаваться домашние каталоги доменных пользователей на > сервере? Обычно домашние каталоги пользователей создаются на вводимых в > домен ПК. Так что логично и оправдано. > > > -- > Andrey Cherepanov > cas@altlinux.org > > > > > -- > С уважением, > Калинин Максим > > > > > > -- > Andrey Cherepanov > cas@altlinux.org > > > > -- > С уважением, > Калинин Максим > > > _______________________________________________ > community mailing list > community@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/community -- Sin (Sinelnikov Evgeny)
next prev parent reply other threads:[~2021-10-18 22:21 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-10-18 8:39 ` Anton V. Boyarshinov 2021-10-18 22:21 ` Evgeny Sinelnikov [this message] 2021-10-19 7:49 ` Anton V. Boyarshinov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAK42-Goi9Zgx+0PQTy9QXCfuOi2TF5fNuRkUvtfwawOZaRREdw@mail.gmail.com \ --to=sin@altlinux.org \ --cc=cas@altlinux.org \ --cc=community@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Community general discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/community/0 community/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 community community/ http://lore.altlinux.org/community \ mandrake-russian@linuxteam.iplabs.ru community@lists.altlinux.org community@lists.altlinux.ru community@lists.altlinux.com public-inbox-index community Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.community AGPL code for this site: git clone https://public-inbox.org/public-inbox.git