а под линукс есть аналог Group Policy?

что? неужели таки нету?

Реестра в Линуксе тоже нет - тебя это удивляет?
Одно решение - раздавать /etc
Второе - если программа хранит настройки в LDAP или SQL BD - использовать их
Третье - скрипты и ssh/telnet/rsh
Это в том случае, если я правильно понял с твоих слов, что такое групповые политики ;)

Покопай в сторону Novell eDirectory и ZENworks.. - http://www.novell.com/products/zenworks/linuxmanagement/

Это конечно, не совсем то, что ты хотел, но, всё же..

> Реестра в Линуксе тоже нет - тебя это удивляет?

вообщето да. не забывайте, речь идёт не о "тонких клиентах" (использовать в качестве таковых нехилые офисные тачки типа celeron 2000 довольно таки расточительно). я понимаю там простейшие вещи - авторизация по PAM/LDAP, погружаемый профиль и всё такое.

но скажем есть аналог NTLM авторизации на проксике? или централизованное добавление/удаление пунктов меню (в кнопке Пуск)? или ярлыков на рабочем столе? или скажем запрет пользователям менять разрешение рабочего стола? в последнем случае можно конечно поправить xorg.conf, но вы представляете какой скриптище потребуется чтобы его отпарсить, и вписать нужные значения? к тому же без права на ошибку? (иначе придётся бегать по рабочим станциям и исправлять что там скрипт понаворотил).

да в конце концов совершенно банально - как можно централизованно прописать общесистемный прокси? (кстати по хорошему эту возможность следовало бы добавить в протокол DHCP до кучи). короче текстовые конфиги хороши пока ты сидишь над ними сам. как доходит до автоматизации... хрен пропарсишь. так что зря HIG на главной обсирают.

Дядя, я далек конечно от этих реалий, но очевидно - Ваши претензии надуманы, равно как и пожизненная вменяемость Балмера. Ибо эти "мегафичи" существовали тыщу лет назад, просто называются чуток иначе.

Все запреты ставятся как chattr +i, и кстати, что такое NTLM авторизация?

По поводу добавления менюшек и хотлинков на дектопе - `man cp`. Чего там еще? Моделайны, DHCP, прозрачный прокси, А по уму конечно - нормальный интегрированный дистр с поддержкой, а то поглядят на Федорино Горе или Генту - и сразу вопят мол: "того нет, сего нет!".

P.S. Чета вендузятнегов по жизни на запретах клинит, как ни посмотрю на наших админов - так диву каждый раз даюсь, особенно "секьюрити-оффицеры", те вообще с пулей в голове от рождения: как ворд осилили - одному Ктулху ведомо. Никак им не осознать, что и без этого все бай дефолт почикано, а за доступом в юниксовые сегменты все равно правильным людям в ноги кланяться приходится.

>>совершенно банально - как можно централизованно прописать общесистемный прокси? (кстати по хорошему эту возможность следовало бы добавить в протокол DHCP до кучи)
Можно через DHCP или через DNS.
http://blog.freyguy.com/archives/2006/03/01/proxy-auto-detect-ie-and-firefox/
>>есть аналог NTLM авторизации на проксике?
NTLM это устаревший и закрытый протокол. Можно использовать аутентификацию через SASL (поддерживаемый Squid-ом), например GSSAPI.
>>или централизованное добавление/удаление пунктов меню (в кнопке Пуск)? или ярлыков на рабочем столе? или скажем запрет пользователям менять разрешение рабочего стола?
Если необходимо всё это делать централизованно - то Gnome+gconf.

короче ясно. целостного механизма управления клиентскими настройками (а-ля домен) нет, зато есть зоопарк аутентификационных механизмов. разбираемся дальше.

пусть на клиентской тачке А есть NFS-шара. Предположим клиент с тачки В, вошедший в систему как Логин Пассвордович хочет подключится к шаре. информация о правах различных пользователей на эту шару лежат естественно не на А, а на PAM/LDAP сервере. Насколько я понимаю, А должна принять логин с B и свериться с сервером аутентификации. Так?

прошу прощения за много глупых вопросов, буду благодарен за информацию на эту тему (желательно на русском из разряда "для чайников")

>>есть NFS-шара

Какая NFS - 3 или 4? В старой NFS3 аутентификации как таковой нет. Пользователь получает/не получает доступ в зависимости от своих uid/gid и прав доступа к расшаренному каталогу. Как пользователь получит эти uid/gid - не важно. Можно через локальный /etc/passwd (но его идентификаторы должны совпадать с теми, что имеются на NFS-сервере, пусть даже имя пользователя на клиенте и сервере различно) или через любую информационную службу - LDAP, hesiod, NIS...

В NFS4 (та которая все ещё experimental в ядрах 2.6.x) появилась настоящая аутентификация. Т.е. пользователю не верят на слово, что у него такие-то uid и gid, а предлагают доказать это, введя пароль. Если же для аутентификации используется Kerberos, то даже пароля вводить не требуется - там есть хитрый механизм, который позволяет подтвердить идетичность пользователя.

Про связку Kerberos + hesiod написано вот здесь:
http://linuxportal.ru/entry.php/1468_0_3_0_C/

Там же примерно рассказано почему нет "целостного механизма управления клиентскими настройками (а-ля домен)", и почему, то что есть на самом деле не является "зоопарком аутентификационных механизмов".

Ну, а для пользовательских/программных настроек пока остается только пользоваться расшаренным $HOME.

> Какая NFS - 3 или 4?

никакой, я гипотетически рассуждал.

> http://linuxportal.ru/entry.php/1468_0_3_0_C/

вроде бы, то что надо. спасибо, восстановили для меня целостную картину мира =)

Интересная статья, узнал новое, спасибо. Только осталось непонятность:

аутентификация через Цербер - т.е. на основании логина и пароля мы получаем "добро", и по логину получаем необходимую информацию о наших правах (авторизацию) через Hesiod. А точнее, эту информацию получает Цербер от Hesiod (параметр kdc=ns.myhome.domain).

Но не увидел (или проскочило мимо внимания?) как программы узнают, к какому Цербер-серверу обращаться? Где это прописывается ? В настройках самих программ? На примере с login.krb5 не совсем понятно (

>>А точнее, эту информацию получает Цербер от Hesiod

Нет не так. Церберу всё равно, как пользователь авторизовался. На самом деле эта информация крайне сильно зависит от сервиса. Взять какую-нибудь сетевую файловую систему с аутентификацией. Пользователь зашел, сообщил свое имя, Цербер подтвердил это имя. Сервис доверяет Церберу, так что он теперь уверен, что пользователь именно тот за кого себя выдает. Ну, а дальше? Сетевая файловая система должна каким-то образом определить к каким каталогам пользователь вот с таким именем имеет доступ. Те у нее где-то должен хранится список с каталогами с проставленными ACL для данного пользователя. Вот когда он найдет имя пользователя в этом списке и определит его ACL - тогда пользователь авторизован. В принципе, нормальная ситуация если пользователь аутентифицирован, но в авторизации ему отказано, поскольку сервис не может сопоставить ACL его имени (нет такого в списках)). Как сервис хранит эти списки - без разницы, лучше всего конечно, если в LDAP, но бывает, что и просто в конфигурационных файлах.

>>как программы узнают, к какому Цербер-серверу обращаться? Где это прописывается ?

Программа слинкована с библиотекой libkrb5.so, а эта библиотека знает, что сектор Цербера описан в файле /etc/krb5.conf или в том на который указывает переменная окружения $KRB5_CONFIG или из SRV record ближайшего DNS:
_kerberos TXT "MYREALM.RU"
kerberos CNAME kdc
_kerberos._udp SRV 0 0 88 kdc
_kerberos._tcp SRV 0 0 88 kdc
_kerberos-adm._tcp SRV 0 0 749 kdc
_kpasswd._udp SRV 0 0 464 kdc

Спасибо. Я правильно понимаю, что в статье рассмотрена авторизация с помощью Гесиода, и авторизация через Цербер, но не их связка? Т.е. чтобы работал, к примеру, фтп сервер, пользователь сообщает ему свое имя, фтп сервер проверяет его через Цербер, а затем каким либо спасобом (LDAP, Hesiod) авторизует его?

>>чтобы работал, к примеру, фтп сервер, пользователь сообщает ему свое имя, фтп сервер проверяет его через Цербер, а затем каким либо спасобом (LDAP, Hesiod) авторизует его?

Ага. Только на мой взгляд это и называется связкой - разве нет?

>> авторизация через Цербер

аутентификация через Цербер.

Да, точно, аутентификация. То что я описал - связка. Просто я не совсем понял приведенный пример из статьи, но щас вооде дошло.

Т.е. login.krb5 после аутентификации пользователя в Цербер, соответсвенно записям в nsswitch.conf - авторизует пользователя? В приведенном статье примере - через Гесиод?

Мне Гесиод как то не сильно понравился. Уж лучше LDAP. IMHO