Bug 24494 - Невозможно добавить пользователя из LDAP в системные группы
: Невозможно добавить пользователя из LDAP в системные группы
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/alterator-ldap-users)
: unstable
: all Linux
: P3 normal
Assigned To:
:
:
: distro-blocker
:
: 23155 27685
  Show dependency tree
 
Reported: 2010-11-03 17:41 by
Modified: 2012-10-31 16:39 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2010-11-03 17:41:44
В модуле не прописываются системные группы (wheel) и группы только что
созданные в ldap.
------- Comment #1 From 2010-11-13 21:13:24 -------
Согласно строки
 [ $gid -lt 100 ] || write_enum_item "$name" "$name"
все группы, ниже 100, в список не попадают.
Кто, когда и из каких соображений принял такое решение - мне не ведомо.
Но предыдущий автор модуля сделал именно так.

Оторвать с руками? Без проблем.
А если такое поведение обосновано, то подтвердите.

Касаемо свежесозданных в LDAP групп, то весь модуль 
ldap-groups нужно переделывать в корне.
------- Comment #2 From 2010-11-13 21:16:46 -------
(В ответ на комментарий №1)
> Согласно строки
>  [ $gid -lt 100 ] || write_enum_item "$name" "$name"
> все группы, ниже 100, в список не попадают.
Это было сделано, чтобы не заблудится в куче групп, поэтому user-специфичные
системные группы прибили явным списком.
------- Comment #3 From 2010-11-13 21:36:10 -------
(В ответ на комментарий №2)
> Это было сделано, чтобы не заблудится в куче групп, поэтому user-специфичные
> системные группы прибили явным списком.
Тогда снимай баг...

А по списку групп, могу локальные группы пометить как-нибудь...
Например, дописать (l) ...
Или еще как...
Сделаете цветовыделение в списке, могу зеленую полосу...
------- Comment #4 From 2010-11-15 16:57:38 -------
(В ответ на комментарий №3)
> А по списку групп, могу локальные группы пометить как-нибудь...
> Например, дописать (l) ...
> Или еще как...
> Сделаете цветовыделение в списке, могу зеленую полосу...
Не надо делать разукрашку. 
Я вижу четыре типа групп:
1. именованные локальные системные (wheel, scanner, disk и т.п.)
2. прочие локальные системные (например, postfix)
3. персональная группа пользователя LDAP
4. отдельно заведённые группы в LDAP.

По идее, в списке должны показываться группы 1 и 4. 2 для пользователя не
нужна, 3 не имеет смысла отрывать от пользователя, пусть к нему всегда
привязывается.
------- Comment #5 From 2010-12-02 14:09:23 -------
Ещё бы хотелось иметь возможность управлять списком групп, в которые
пользователь включается при создании. Чтобы добавлять туда группы, отдельно
заведённые в LDAP.

Сейчас этот список захардкоден как default_groups в
/usr/lib/alterator/backend3/ldap-users

Предлагаю использовать для этих целей, например,
/etc/alterator/ldap-groups/group-init-list
------- Comment #6 From 2010-12-02 15:25:45 -------
(В ответ на комментарий №5)
> Ещё бы хотелось иметь возможность управлять списком групп
Согласен. Думаю над этим...
Кроме того, есть еще список групп для домена и Samba (Domain Admins, Domain
Users, etc...)
Думаю, как вывести этот список в модуль и сделать его управляемым.

В связи с крайней загруженностью по работе беру тайм-аут на недельку...
------- Comment #7 From 2011-06-18 18:06:32 -------
Исправлено?
------- Comment #8 From 2011-06-18 19:38:30 -------
Скорее, нет.
Сейчас не на чем, к сожалению.
------- Comment #9 From 2011-07-20 17:37:01 -------
(В ответ на комментарий №7)
> Исправлено?
Нет.
------- Comment #10 From 2011-07-20 18:54:03 -------
(В ответ на комментарий №7)
> Исправлено?

Обзавелся полигоном.
Могу привести модули к какому-то знаменателю.
Тут вопрос упирается в политики нумерования системных пользователей и групп.
На том я и остановился в свое время.

Суть проблемы в том, что ели у нас уже есть хоть один пользователь/группа в
LDAP, а потом устанавливается некоторый демон, у которого свой пользователь и
группа, то UID|GID могут быть созданы автоматически в области выше 5000,
"последний+1".

А хотелось бы "видеть" всех системных < 499...

У себя локально я каких-то костылей  пробовал, но все оказалось малоприемлемо.
------- Comment #11 From 2011-08-10 20:50:20 -------
Прошу предлагать возможные решения. Дмитрий описал проблему.
------- Comment #12 From 2011-08-19 16:08:08 -------
Группы показываются в интерфейса с пометкой '(local)', их можно выбрать. Но
есть две проблемы:
а) нет назначенных системных групп при создании нового пользователя
(/etc/alterator/ldap-groups/group-init-list есть, но группы оттуда не
помечаются * как устанавливаемые по умолчанию);
б) выбранная системная группа не сохраняется. Добавляю wheel, перезапускаю
alteratord и группа исчезает.
------- Comment #13 From 2011-08-21 11:25:35 -------
Ну так как с политикой нумерации групп?
Потому как я не знаю, что и как прибивать гвоздями в модуль...
------- Comment #14 From 2011-08-22 18:06:46 -------
(В ответ на комментарий №13)
> Ну так как с политикой нумерации групп?
> Потому как я не знаю, что и как прибивать гвоздями в модуль...
По просьбе АЕН провожу экспертизу :P

1. При добавлении LDAP-ного пользователя он должен входить в несколько
дополнительных групп по умолчанию, тех же, что и локальный (сейчас не входит ни
в одну).
2. Добавление LDAP-ного пользователя в любую группу должно работать, т. е.
после добавления пользователь при логине должен получать членство в этой
группе.

Суть блокера — в этом. По-видимому, необходимо при создании LDAP-ной базы групп
набивать её этими группами по умолчанию, и позаботиться о включении
пользователя в них.

Вторая проблема — установка дополнительного софта, заводящего своих
пользователей и группы, на сервер, и вообще всякое автозаведение ргупп. Для
групп есть варианты:
1. Заранее прибить все возможные группы к LDAP-ной базе и надеяться, что пакет
при установке не хакает /etc/group, а использует getent group и groupadd;
предупредить админа, чтобы не выключал аутентификацию по LDAP при заходе на
сервер (выключать логин можно, а вот getent должен работать)
2. Заранее прибить все возможные группы в /etc/group, а в LDAP организовать
прямую синхронизацию

Третья проблема — установка дополнительного софта на клиенте. В первом случае
придётся предупредить, что установка пакетов должна производиться только при
работоспособном LDAP-е, а второй случай вообще не спасает :(
------- Comment #15 From 2011-08-22 19:33:02 -------
(В ответ на комментарий №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, то про локальные группы
забыть нужно.
Как минимум, для рабочих станций.
------- Comment #16 From 2012-05-03 12:02:27 -------
Думаю, что проще будет создать спецгруппу в LDAP, например "locgroups" и только
к ней подключать локальные группы...
------- Comment #17 From 2012-05-03 12:33:16 -------
Ну, можно ещё в модуле альтератора вывести отдельным списком локальные
группы...

P.S. На одном сайте уже решали проблему с локальным wheel и ldap:
http://www.gentoo.ru/content/ldap-sudo
------- Comment #18 From 2012-05-03 12:41:19 -------
(В ответ на комментарий №17)
> Ну, можно ещё в модуле альтератора вывести отдельным списком локальные
> группы...
> 
> P.S. На одном сайте уже решали проблему с локальным wheel и ldap:
> http://www.gentoo.ru/content/ldap-sudo

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

Потому как мне, в моих локальных группах, пользователи из LDAP не нужны.
А каким-либо образом править локальные группы на тех рабочих станциях
возможности нет.
------- Comment #19 From 2012-05-03 18:50:51 -------
Проблему рано закрывать.
------- Comment #20 From 2012-05-03 19:45:06 -------
(В ответ на комментарий №19)
> Проблему рано закрывать.

Пока нет четкого понимания сути процесса, делать что-либо не имеет смысла.
Делать подпорки для частных случаев, которые потом будут вызывать больше
проблем, чем отсутствие решения, мне не очень хочется...
------- Comment #21 From 2012-05-12 15:47:31 -------
Возможно стоит посмотреть на libnss-role?
Он позволяет задать на машине соответствие между ролями (т.е. группами из LDAP)
и локальными группами.
------- Comment #22 From 2012-10-26 10:52:02 -------
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