Согласно строки
 [ $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