24494 2010-11-03 17:41:44 +0300 Невозможно добавить пользователя из LDAP в системные группы 2012-10-31 16:39:14 +0400 1 1 4 Development Sisyphus alterator-ldap-users unstable all Linux CLOSED FIXED distro-blocker P3 normal --- 23155 27685 1 glebfm cas Dmitriy.Kruglikov aen boyarsh cas dd fotonsalt george kharpost lav manowar sem qa-sisyphus oldest_to_newest 114809 0 glebfm 2010-11-03 17:41:44 +0300 В модуле не прописываются системные группы (wheel) и группы только что созданные в ldap. 115247 1 Dmitriy.Kruglikov 2010-11-13 21:13:24 +0300 Согласно строки [ $gid -lt 100 ] || write_enum_item "$name" "$name" все группы, ниже 100, в список не попадают. Кто, когда и из каких соображений принял такое решение - мне не ведомо. Но предыдущий автор модуля сделал именно так. Оторвать с руками? Без проблем. А если такое поведение обосновано, то подтвердите. Касаемо свежесозданных в LDAP групп, то весь модуль ldap-groups нужно переделывать в корне. 115249 2 cas 2010-11-13 21:16:46 +0300 (В ответ на комментарий №1) > Согласно строки > [ $gid -lt 100 ] || write_enum_item "$name" "$name" > все группы, ниже 100, в список не попадают. Это было сделано, чтобы не заблудится в куче групп, поэтому user-специфичные системные группы прибили явным списком. 115250 3 Dmitriy.Kruglikov 2010-11-13 21:36:10 +0300 (В ответ на комментарий №2) > Это было сделано, чтобы не заблудится в куче групп, поэтому user-специфичные > системные группы прибили явным списком. Тогда снимай баг... А по списку групп, могу локальные группы пометить как-нибудь... Например, дописать (l) ... Или еще как... Сделаете цветовыделение в списке, могу зеленую полосу... 115343 4 cas 2010-11-15 16:57:38 +0300 (В ответ на комментарий №3) > А по списку групп, могу локальные группы пометить как-нибудь... > Например, дописать (l) ... > Или еще как... > Сделаете цветовыделение в списке, могу зеленую полосу... Не надо делать разукрашку. Я вижу четыре типа групп: 1. именованные локальные системные (wheel, scanner, disk и т.п.) 2. прочие локальные системные (например, postfix) 3. персональная группа пользователя LDAP 4. отдельно заведённые группы в LDAP. По идее, в списке должны показываться группы 1 и 4. 2 для пользователя не нужна, 3 не имеет смысла отрывать от пользователя, пусть к нему всегда привязывается. 115922 5 dd 2010-12-02 14:09:23 +0300 Ещё бы хотелось иметь возможность управлять списком групп, в которые пользователь включается при создании. Чтобы добавлять туда группы, отдельно заведённые в LDAP. Сейчас этот список захардкоден как default_groups в /usr/lib/alterator/backend3/ldap-users Предлагаю использовать для этих целей, например, /etc/alterator/ldap-groups/group-init-list 115925 6 Dmitriy.Kruglikov 2010-12-02 15:25:45 +0300 (В ответ на комментарий №5) > Ещё бы хотелось иметь возможность управлять списком групп Согласен. Думаю над этим... Кроме того, есть еще список групп для домена и Samba (Domain Admins, Domain Users, etc...) Думаю, как вывести этот список в модуль и сделать его управляемым. В связи с крайней загруженностью по работе беру тайм-аут на недельку... 122210 7 aen 2011-06-18 18:06:32 +0400 Исправлено? 122229 8 Dmitriy.Kruglikov 2011-06-18 19:38:30 +0400 Скорее, нет. Сейчас не на чем, к сожалению. 123349 9 cas 2011-07-20 17:37:01 +0400 (В ответ на комментарий №7) > Исправлено? Нет. 123353 10 Dmitriy.Kruglikov 2011-07-20 18:54:03 +0400 (В ответ на комментарий №7) > Исправлено? Обзавелся полигоном. Могу привести модули к какому-то знаменателю. Тут вопрос упирается в политики нумерования системных пользователей и групп. На том я и остановился в свое время. Суть проблемы в том, что ели у нас уже есть хоть один пользователь/группа в LDAP, а потом устанавливается некоторый демон, у которого свой пользователь и группа, то UID|GID могут быть созданы автоматически в области выше 5000, "последний+1". А хотелось бы "видеть" всех системных < 499... У себя локально я каких-то костылей пробовал, но все оказалось малоприемлемо. 123844 11 aen 2011-08-10 20:50:20 +0400 Прошу предлагать возможные решения. Дмитрий описал проблему. 124279 12 cas 2011-08-19 16:08:08 +0400 Группы показываются в интерфейса с пометкой '(local)', их можно выбрать. Но есть две проблемы: а) нет назначенных системных групп при создании нового пользователя (/etc/alterator/ldap-groups/group-init-list есть, но группы оттуда не помечаются * как устанавливаемые по умолчанию); б) выбранная системная группа не сохраняется. Добавляю wheel, перезапускаю alteratord и группа исчезает. 124325 13 Dmitriy.Kruglikov 2011-08-21 11:25:35 +0400 Ну так как с политикой нумерации групп? Потому как я не знаю, что и как прибивать гвоздями в модуль... 124372 14 george 2011-08-22 18:06:46 +0400 (В ответ на комментарий №13) > Ну так как с политикой нумерации групп? > Потому как я не знаю, что и как прибивать гвоздями в модуль... По просьбе АЕН провожу экспертизу :P 1. При добавлении LDAP-ного пользователя он должен входить в несколько дополнительных групп по умолчанию, тех же, что и локальный (сейчас не входит ни в одну). 2. Добавление LDAP-ного пользователя в любую группу должно работать, т. е. после добавления пользователь при логине должен получать членство в этой группе. Суть блокера — в этом. По-видимому, необходимо при создании LDAP-ной базы групп набивать её этими группами по умолчанию, и позаботиться о включении пользователя в них. Вторая проблема — установка дополнительного софта, заводящего своих пользователей и группы, на сервер, и вообще всякое автозаведение ргупп. Для групп есть варианты: 1. Заранее прибить все возможные группы к LDAP-ной базе и надеяться, что пакет при установке не хакает /etc/group, а использует getent group и groupadd; предупредить админа, чтобы не выключал аутентификацию по LDAP при заходе на сервер (выключать логин можно, а вот getent должен работать) 2. Заранее прибить все возможные группы в /etc/group, а в LDAP организовать прямую синхронизацию Третья проблема — установка дополнительного софта на клиенте. В первом случае придётся предупредить, что установка пакетов должна производиться только при работоспособном LDAP-е, а второй случай вообще не спасает :( 124376 15 Dmitriy.Kruglikov 2011-08-22 19:33:02 +0400 (В ответ на комментарий №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, то про локальные группы забыть нужно. Как минимум, для рабочих станций. 130998 16 fotonsalt 2012-05-03 12:02:27 +0400 Думаю, что проще будет создать спецгруппу в LDAP, например "locgroups" и только к ней подключать локальные группы... 130999 17 fotonsalt 2012-05-03 12:33:16 +0400 Ну, можно ещё в модуле альтератора вывести отдельным списком локальные группы... P.S. На одном сайте уже решали проблему с локальным wheel и ldap: http://www.gentoo.ru/content/ldap-sudo 131000 18 Dmitriy.Kruglikov 2012-05-03 12:41:19 +0400 (В ответ на комментарий №17) > Ну, можно ещё в модуле альтератора вывести отдельным списком локальные > группы... > > P.S. На одном сайте уже решали проблему с локальным wheel и ldap: > http://www.gentoo.ru/content/ldap-sudo Перечитайте внимательнейшим образом всё обсуждение... Не проблема сделать костыль и прибить настройки локальной станции к локальному же LDAP... Но если вы хотите настроить произвольный сервер LDAP для ведения пользователей и групп для некоторого числа рабочих станций с произвольного компьютера, который в число тех рабочих станций не входит, тогда "ой"... Потому как мне, в моих локальных группах, пользователи из LDAP не нужны. А каким-либо образом править локальные группы на тех рабочих станциях возможности нет. 131007 19 cas 2012-05-03 18:50:51 +0400 Проблему рано закрывать. 131008 20 Dmitriy.Kruglikov 2012-05-03 19:45:06 +0400 (В ответ на комментарий №19) > Проблему рано закрывать. Пока нет четкого понимания сути процесса, делать что-либо не имеет смысла. Делать подпорки для частных случаев, которые потом будут вызывать больше проблем, чем отсутствие решения, мне не очень хочется... 131186 21 lav 2012-05-12 15:47:31 +0400 Возможно стоит посмотреть на libnss-role? Он позволяет задать на машине соответствие между ролями (т.е. группами из LDAP) и локальными группами. 134209 22 repository-robot 2012-10-26 10:52:02 +0400 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