В модуле не прописываются системные группы (wheel) и группы только что созданные в ldap.
Согласно строки [ $gid -lt 100 ] || write_enum_item "$name" "$name" все группы, ниже 100, в список не попадают. Кто, когда и из каких соображений принял такое решение - мне не ведомо. Но предыдущий автор модуля сделал именно так. Оторвать с руками? Без проблем. А если такое поведение обосновано, то подтвердите. Касаемо свежесозданных в LDAP групп, то весь модуль ldap-groups нужно переделывать в корне.
(В ответ на комментарий №1) > Согласно строки > [ $gid -lt 100 ] || write_enum_item "$name" "$name" > все группы, ниже 100, в список не попадают. Это было сделано, чтобы не заблудится в куче групп, поэтому user-специфичные системные группы прибили явным списком.
(В ответ на комментарий №2) > Это было сделано, чтобы не заблудится в куче групп, поэтому user-специфичные > системные группы прибили явным списком. Тогда снимай баг... А по списку групп, могу локальные группы пометить как-нибудь... Например, дописать (l) ... Или еще как... Сделаете цветовыделение в списке, могу зеленую полосу...
(В ответ на комментарий №3) > А по списку групп, могу локальные группы пометить как-нибудь... > Например, дописать (l) ... > Или еще как... > Сделаете цветовыделение в списке, могу зеленую полосу... Не надо делать разукрашку. Я вижу четыре типа групп: 1. именованные локальные системные (wheel, scanner, disk и т.п.) 2. прочие локальные системные (например, postfix) 3. персональная группа пользователя LDAP 4. отдельно заведённые группы в LDAP. По идее, в списке должны показываться группы 1 и 4. 2 для пользователя не нужна, 3 не имеет смысла отрывать от пользователя, пусть к нему всегда привязывается.
Ещё бы хотелось иметь возможность управлять списком групп, в которые пользователь включается при создании. Чтобы добавлять туда группы, отдельно заведённые в LDAP. Сейчас этот список захардкоден как default_groups в /usr/lib/alterator/backend3/ldap-users Предлагаю использовать для этих целей, например, /etc/alterator/ldap-groups/group-init-list
(В ответ на комментарий №5) > Ещё бы хотелось иметь возможность управлять списком групп Согласен. Думаю над этим... Кроме того, есть еще список групп для домена и Samba (Domain Admins, Domain Users, etc...) Думаю, как вывести этот список в модуль и сделать его управляемым. В связи с крайней загруженностью по работе беру тайм-аут на недельку...
Исправлено?
Скорее, нет. Сейчас не на чем, к сожалению.
(В ответ на комментарий №7) > Исправлено? Нет.
(В ответ на комментарий №7) > Исправлено? Обзавелся полигоном. Могу привести модули к какому-то знаменателю. Тут вопрос упирается в политики нумерования системных пользователей и групп. На том я и остановился в свое время. Суть проблемы в том, что ели у нас уже есть хоть один пользователь/группа в LDAP, а потом устанавливается некоторый демон, у которого свой пользователь и группа, то UID|GID могут быть созданы автоматически в области выше 5000, "последний+1". А хотелось бы "видеть" всех системных < 499... У себя локально я каких-то костылей пробовал, но все оказалось малоприемлемо.
Прошу предлагать возможные решения. Дмитрий описал проблему.
Группы показываются в интерфейса с пометкой '(local)', их можно выбрать. Но есть две проблемы: а) нет назначенных системных групп при создании нового пользователя (/etc/alterator/ldap-groups/group-init-list есть, но группы оттуда не помечаются * как устанавливаемые по умолчанию); б) выбранная системная группа не сохраняется. Добавляю wheel, перезапускаю alteratord и группа исчезает.
Ну так как с политикой нумерации групп? Потому как я не знаю, что и как прибивать гвоздями в модуль...
(В ответ на комментарий №13) > Ну так как с политикой нумерации групп? > Потому как я не знаю, что и как прибивать гвоздями в модуль... По просьбе АЕН провожу экспертизу :P 1. При добавлении LDAP-ного пользователя он должен входить в несколько дополнительных групп по умолчанию, тех же, что и локальный (сейчас не входит ни в одну). 2. Добавление LDAP-ного пользователя в любую группу должно работать, т. е. после добавления пользователь при логине должен получать членство в этой группе. Суть блокера — в этом. По-видимому, необходимо при создании LDAP-ной базы групп набивать её этими группами по умолчанию, и позаботиться о включении пользователя в них. Вторая проблема — установка дополнительного софта, заводящего своих пользователей и группы, на сервер, и вообще всякое автозаведение ргупп. Для групп есть варианты: 1. Заранее прибить все возможные группы к LDAP-ной базе и надеяться, что пакет при установке не хакает /etc/group, а использует getent group и groupadd; предупредить админа, чтобы не выключал аутентификацию по LDAP при заходе на сервер (выключать логин можно, а вот getent должен работать) 2. Заранее прибить все возможные группы в /etc/group, а в LDAP организовать прямую синхронизацию Третья проблема — установка дополнительного софта на клиенте. В первом случае придётся предупредить, что установка пакетов должна производиться только при работоспособном LDAP-е, а второй случай вообще не спасает :(
(В ответ на комментарий №14) > 1. При добавлении LDAP-ного пользователя он должен входить в несколько > дополнительных групп по умолчанию, тех же, что и локальный (сейчас не входит ни > в одну). На том и застрял... Предположим, что в списке групп есть N локальных (на сервере) групп и M сетевых (в LDAP) групп. И что с ними делать в этом случае? * Нет гарантии, что GID не пересекаются. * На сервере (на котором крутится alteratord) тех локальных пользователей и быть-то не должно... * Сервер (на котором LDAP) может быть и не смотрит в него. Там все локально, или LDAP в контейнере OpenVZ. Типичная ситуация, когда пользователь из LDAP должен входит в админскую группу на локальной рабочей станции. Но ни alteratord, ни LDAP про эту локальную машинку и ее группы не знают. > Суть блокера — в этом. По-видимому, необходимо при создании LDAP-ной базы групп > набивать её этими группами по умолчанию, и позаботиться о включении > пользователя в них. Базу набить группами можно. И пользователей в эти группы включить. Но тогда участник группы "Админы" будет админом на всех рабочих станциях. > Вторая проблема — установка дополнительного софта, заводящего своих > пользователей и группы, на сервер, и вообще всякое автозаведение ргупп. Тут просится полиси и жесткое распределение GID по сервисам. Тогда эти группы и в LDAP заводить можно/нужно. Иначе получим перекрытие GID в локальном /etc/group и в LDAP. > Третья проблема — установка дополнительного софта на клиенте. Ветвистость дерева вариантов не позволила мне единолично прибить гвоздями какое-либо решение для данного модуля. А посему, нужно четко выработать политику, отразить ее в ТЗ, а потом что-то писать в код. P.S. И таки повынимать все "гвозди" из кода и вынести настройки политик в конфиги. P.P.S. Все больше склоняюсь к варианту, что если домен и LDAP, то про локальные группы забыть нужно. Как минимум, для рабочих станций.
Думаю, что проще будет создать спецгруппу в LDAP, например "locgroups" и только к ней подключать локальные группы...
Ну, можно ещё в модуле альтератора вывести отдельным списком локальные группы... P.S. На одном сайте уже решали проблему с локальным wheel и ldap: http://www.gentoo.ru/content/ldap-sudo
(В ответ на комментарий №17) > Ну, можно ещё в модуле альтератора вывести отдельным списком локальные > группы... > > P.S. На одном сайте уже решали проблему с локальным wheel и ldap: > http://www.gentoo.ru/content/ldap-sudo Перечитайте внимательнейшим образом всё обсуждение... Не проблема сделать костыль и прибить настройки локальной станции к локальному же LDAP... Но если вы хотите настроить произвольный сервер LDAP для ведения пользователей и групп для некоторого числа рабочих станций с произвольного компьютера, который в число тех рабочих станций не входит, тогда "ой"... Потому как мне, в моих локальных группах, пользователи из LDAP не нужны. А каким-либо образом править локальные группы на тех рабочих станциях возможности нет.
Проблему рано закрывать.
(В ответ на комментарий №19) > Проблему рано закрывать. Пока нет четкого понимания сути процесса, делать что-либо не имеет смысла. Делать подпорки для частных случаев, которые потом будут вызывать больше проблем, чем отсутствие решения, мне не очень хочется...
Возможно стоит посмотреть на libnss-role? Он позволяет задать на машине соответствие между ролями (т.е. группами из LDAP) и локальными группами.
alterator-ldap-groups-0.6.1-alt1 -> sisyphus: * Thu Oct 25 2012 Andrey Cherepanov <cas@altlinux> 0.6.1-alt1 - Move init script from firsttime.d to hostname.d hooks directory. Please, run /etc/hooks/hostname.d/91-ldap-groups manually to create initial groups for existing domain (ALT #24494) - Obsoletes alterator-ldap-groups-school-server package - Hide registered workstations groups (with trailing $) - Support School Server specific default groups. If they are unnecessary, just remove it manually
