Bug 24494 - Невозможно добавить пользователя из LDAP в системные группы
Summary: Невозможно добавить пользователя из LDAP в системные группы
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: alterator-ldap-users (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: Andrey Cherepanov
QA Contact: qa-sisyphus
URL:
Keywords: distro-blocker
Depends on:
Blocks: 23155 27685
  Show dependency tree
 
Reported: 2010-11-03 17:41 MSK by Gleb F-Malinovskiy
Modified: 2012-10-31 16:39 MSK (History)
11 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gleb F-Malinovskiy 2010-11-03 17:41:44 MSK
В модуле не прописываются системные группы (wheel) и группы только что созданные в ldap.
Comment 1 Dmitriy Kruglikov 2010-11-13 21:13:24 MSK
Согласно строки
 [ $gid -lt 100 ] || write_enum_item "$name" "$name"
все группы, ниже 100, в список не попадают.
Кто, когда и из каких соображений принял такое решение - мне не ведомо.
Но предыдущий автор модуля сделал именно так.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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