|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : Nick A. Leuta 2:5020/400 21 Jun 2000 13:46:29
To : All
Subject : Hа: Hа: Hа: Hа: Hа: Hа: Hа: uucpd and PAM
--------------------------------------------------------------------------------
"Valentin Nechayev" <netch@carrier.kiev.ua> сообщил/сообщила в новостях
следующее: news:8io6o2$9mt$1@solar.carrier.kiev.ua...
> Ага, как же, как же. И как Вы умудритесь в libc, которая в жизни не умела
LDAP,
> вдруг дать ей это умение одним приказом в nsswitch.conf? Рожденный ползать
> получил приказ летать?
Так, кажется, Вы так и не поняли суть... А она в том, кроме nss, другие
компоненты glibc не знают источника - ldap ли это, nis или что-то еще. В
этом-то и все фишка...
> >> И к паму оно как бы совеpшенно оpтогонально ;)
> NAL> Каждый по отдельности - действительно самостоятельны, и действительно
> NAL> неполноценны: PAM не может дать соответствия login<->UID, а NSS
далеко не
> NAL> всегда может вытащить пароль (далеко не всякая аутентификационная
система
> NAL> может его отдать, либо потому, что не может, либо даже может, вот
только
> NAL> кодирован он не так, так это ожидается от значения, возвращаемого
> NAL> getpwent() ). Hо вот вместе (систему не равна сумме компонентов
:-) ) они
> NAL> полностью справляются с задачей аутентификации, и даже больше:
> Как только доходит до реалий, в дело вступают грязные хаки.
> Мне пофиг, какой идиот придумал PAM - у него совершенно кривые и
извращенные
> отношения между AAA&S. Да, он решает задачу - частично - вынесением
> части этих операций в отдельные блоки. Hо точно так же это можно было
устроить
> и силами самого приложения - как оно часто и делается безо всякого пама.
Hу да, отсюда и все проблемы... В конце концов, можно прямо из приложения
парсить master.passwd, так даже быстрей будет. А потом для NIS/NIS+ собирать
одни бинарники, для локальных файлов другие, для еще какого-нить способа
аутентификации... Во, идея - сделать LdapBSD, NisBSD, KerberosBSD, NtpdcBSD
(далее по желанию трудящихся)...
> Я понимаю, почему в *BSD его (пама) мало: тошнит-с.
Hу, sunтехников не тошнит, линуксоидов не тошнит, а bsd значит самый
правильный unix... Hу-ну.
> >> Как бы засовывать тех же юзеpов в LDAP - ну совеpшенно неудобно.
> NAL> А рулить локальными юзерами на десятке машин удобнее?
> А при чем тут LDAP? Если бы был упомянут NIS+, я бы еще поверил.
Так не только ж UNIX'ы используются... Дабы сильней потошнило, пусть еще
NT(S,WS) будет.
> >> И надо патчить ту же libc (g- или нет - пофиг) на эту тему ну совсем
> >> не pадует...
> NAL> Патчить фрюшные библиотеки (или портировать glibc (где nss и живет,
> NAL> собственно) на FreeBSD)? Тут легким патчем не обойтись - задача
достаточно
> NAL> серьезная.
> /me rotfl. NSS именно как _N_SS во фряхе давно есть. man host.conf.
No manual entry for host.conf
К тому же это от DNS (Internet Domain Name System (c) man resolv.conf), а
DNS
даже в DOS'e работает :-)
> Остальное - то, что нужно и то, что реализуемо нормальными средствами -
тоже
> есть. Пусть и без уродского /etc/nsswitch.conf.
Да на nsswitch.conf в конце концов свет клином не сошелся... Предложите
_более_простой_
(менее трудозатратный в настоящее время; "более правильный", если нравится)
во FreeBSD (по сравнению с Linux'ом или Solaris'ом) способ аутентифицировать
юзеров на NT PDC. Причем, чтоб не только login, но и все остальное (ftpd
там, lock, etc) работало. И потом то же самое в NW NDS (W2K AD), причем в
этом случае
чтобы юзеров локально заводить не надо было. И я признаю, что ошибался, и
скорее всего не буду переходить с FreeBSD на Linux...
> А своими идеями про портирования glibc на фряху Вы мне кое-что напомнили.
> Про то, как Debian'овцы решили осчастливить светом Единственно Верного
Учения
> GNU несчастных моральных уродов из BSD world. Так оно и заглохло, потому
что
> не смогли решить - делать FreeBSD kernel + glibc или Linux kernel + BSD
libc...
Боюсь, что на самом деле было слишком мало денег и толкового руководителя.
К тому же я не призываю скрещивать ядра с *libc'ами, в конце концов это
разные ветви *nix'a. А вот пристроить несколько утвердившихся в других
ветках
идей стоит (как это уже на раз было, в конце концов, в истории разных ветвей
*nix'a), благо они затрагивают _функциональность_, а не рюшечки-погремушечки
для юзеров добавляют.
> NAL> К тому же просто прикручивать nss ради nss смысла мало, надо еще
> NAL> и pam, а значить и изрядное количество стандартных утилит тоже
править...
> NAL> Плюс еще о портах не забыть...
> Вот именно. А так как PAM по себе тоже никому толком не нужен, потому что
> убог и крив, то зачем вообще заниматься именно ими? Проблем и так хватает.
Точно. И главная из них заключается в том, что под Linux становится все
больше и больше коммерческих и не очень приложений, и как следствие растет
популярность, у *BSD наоборот... А поскольку "никому ничего не нужно", то
проблем становится все больше и больше...
===================
* Деньги - зло! Для получения подробной информации пришлите 10$
SkyNick
--- ifmail v.2.15dev5
* Origin: Lipetsk State Technical University (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
