Свежее интервью о Samba 4

интересно, на базе чего он будет сделан...

> интересно, на базе чего он будет сделан...

OpenLDAP?

будут большие дураки, если опять изобретут лисапед.

Fedora DS надо развивать - единственный нормальный из свободных

>Fedora DS надо развивать - единственный нормальный из свободных

умник может заставить оффтопик в ходить в fds домен?

лехко - хавту по FDS описывает это и это РАБОТАЕТ. Делал

Речь о другом... о том чтобы не применять openLDAP а применять FDS - один хер LDAP - это только протокол. А прикручивать к LDAPу что-то еще поверх данного - неприятно. На FDS это делать проще и удобнее.
Он для этого и существует.

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

>лехко - хавту по FDS описывает это и это РАБОТАЕТ. Делал

ссылку в студию. А то я не нашел

Интересная мысль, даёшь в каждую софтину свой LDAP сервер!

Я вот чё не пойму: есть MSовский LDAP (AD), только к нему фиг чего неродное прицепишь, samba решила в том же направлении двигать?

!!!!!!!!!!!!!!

100% za

Народ, я над вами зверею. :) Называется - не английского незнаем, ни албанского...

> встроенный LDAP-сервер

"So at that point the LDAP server in Samba 4 will essentially have to act as a cache, as a proxy to the real LDAP server, the enterprise LDAP server that people are already running."

Встроенный LDAP будет кешем, для используемого пользователем LDAP-сервера.

"One of the things is, there are many many people who have - let's say - they've got a small office with 50 computers or whatever. They don't have an LDAP server, they don't want an LDAP server, they don't know what an LDAP server is, they just want something that will standardise all their accounts in a single file. So for that, a built-in Samba 4 LDAP server is great, is exactly what they want."

Основное назвачение встроенного LDAP-сервера - это маленькие конторы, где количесво компьютеров не превышает 50, где на фиг не упёрся полноценный LDAP-сервер, а все потребности в хранении данных - это список логинов/паролей, желательно, в одном файле. Для таких целей встроенный LDAP-сервер будет идеально подходить.

Намёк понятен, никто не собирается делать ещё один OpenLDAP.

>Интересная мысль, даёшь в каждую софтину свой LDAP сервер! > >Я вот чё не пойму: есть MSовский LDAP (AD), только к нему фиг чего неродное прицепишь, samba решила в том же направлении двигать?

таки вот и я про то же... как exim и cyrus прикручивать к этому всему...? очень удобно было OpenLDAP поднял потом samba к нему прикрутил, после cyrus-imap затем exim и единая авторизация везде... а как с этим горбатиться... ? таки пипец аднака

http://directory.fedora.redhat.com/wiki/Howto:Samba

читаем, делаем.

винда спокойно рабоатет с самбой3 как с PDC интегрированном в FDS.

FDS - ОБЫЧНЫЙ LDAP - просто доделаны удобства и полезные фичи.

будем дальше делать свой LDAP под самбу4 сам с собой несовместимым или использовать стрим?

блин - как достало, что в Лине досих пор все через ж. - правая рука не знает, что делает левая. А потом имей секс с уговариванием компонентов понимать друг друга. Плохо это все.

>а все потребности в хранении данных - это список логинов/паролей, желательно, в одном файле

маразм - на дворе 21 век. а мы все в плейн-файликах делаем бэкэнды.. ню ню

>винда спокойно рабоатет с самбой3 как с PDC интегрированном в FDS.

Без самбы пожалста. Чтобы оффтопик входил в fds как в родной домен.

>будем дальше делать свой LDAP под самбу4 сам с собой несовместимым или использовать стрим?

основная фишка samba4 - это способность работы как ADC а не лдап =) fds совместимостью с AD похвастаться не может

>Без самбы пожалста. Чтобы оффтопик входил в fds как в родной домен.
дядя задал вопрос по использованию FDS и самбы и сам же отверг потом самбу....
глупости пишете какие.
читайте лучше посты - поможет.
я говорю что против своего ЛДАПА в самбе4, что нужно использовать имеющиеся системы, а не городить свои лисапеды.
Учите русский язык

>дядя задал вопрос по использованию FDS и самбы и сам же отверг потом самбу....

цитату в студию, где я про самбу спрашивал

>Учите русский язык

начни с себя. Может хоть читать научишься

Вам шашечки или ехать? Не стоит пускаться в крайности ради доказательства своей сомнительной правоты.

FDC+Samba это хорошее решение в стиле unixway ))

Ненавижу этот фигов linuxformat. Вечно для затравки ровно четверть интервью в Инет публикуют. Гады.

>Вам шашечки или ехать? Не стоит пускаться в крайности ради доказательства своей сомнительной правоты.

крайности? ну-ну

> Ненавижу этот фигов linuxformat. Вечно для затравки ровно четверть интервью в Инет публикуют.

Подписываться не пробовал? ;-)

>>очень удобно было OpenLDAP поднял потом samba к нему прикрутил, после cyrus-imap затем exim и единая авторизация везде...

Не с той стороны заходите. Через Цербер даже 3-я Самба легко интегрируется в единую систему регистрации не говоря уже о почтовиках. Фтоппку LDAP.
Насчет четвертой - судя по мэйл-листам heimdal и mit ребята из Самбы всерьёз замахнулись на реализацию AD, только фиг что у них выйдет, поскольку там все лазейки (ИМХО) прикрыты микрософтовскими лицензиями (в части авторизации, те там где LDAP какую-то роль играет). Есть вроде бы решение с заменой какой-то dll на прохаченную (искать на тему pGina), но я не знаю как оно работает. Вроде бы с помощью неё можно авторизоваться и проверять пароли на OpenLDAP сервере.

>Есть вроде бы решение с заменой какой-то dll на прохаченную (искать на тему pGina), но я не знаю как оно работает

замена msgina.dll - официальный путь. А вот создание временного _локального_ аккаунта после успешной авторизации - это,безусловно,грязный хак. По-хорошему, надо бы ещё netlogon.dll заимплементить...

>>>А вот создание временного _локального_ аккаунта после успешной авторизации - это,безусловно,грязный хак.

Вопрос спорный, что считать грязным хаком. MS сам всё это замутил, когда объеденил аутентификацию и авторизацию в один процесс. А теперь расхлебывай после них.

Чтоб не повторяться - http://www.linux.org.ru/profile/geekkoo/view-message.jsp?msgid=1205044

Чё плохого в локальных accounts? Если у вас в сети больше тысячи хостов, то локальные руты (или Administrators) неизбежное зло. Т.е. если хостов много, то делегировать полномочия - нормальное явление. К примеру, как вообще Керберос появился? Есть университет. У него куча общаг (кампусов). Контролировать каждый компьютер в общаге - вещь для сисадмина университета нереальная. Тогда уж пусть владелец компьютера в общежитии его и контролирует. Единственное, что доступ к сетевым (университетским) ресурсам должен контролироваться системным администратором. От всек пользователей компьютеров в кампусе требуется, чтобы они аутентифицировались при доступе к сетевым ресурсам. Т.е. со своей локальной файловой системой локальные руты пусть делают, что хотят, а вот при доступе к сетевой FS требуется допорлнительная регистрация в Кербкрос ( другое дело, что Керберос делает эту дополнительную проверку максимально незаметной для пользователя).
Если относится к Самбе как к урезанному аналогу OpenAFS или Coda, то такая возможность тоже имеет право на существование. К примеру, серверами самбы выступают только выделенные сервера, находящиеся в располряжении системного администратора. Никто другой в том же домене ( или realmе ) создать файловый сервер не может. Любой другой компьютер выступает только в качестве клиента. В таком случае полномочия пользователя не имеют никакого значения на серверах. При этом при соединении с сервером, полномочия этого юзера определяются авторизационной информацией, имеющийся на сервере и тем, насколько успешно пользователь прошел аутентификацию в Керберос. LDAP, netlogon и др. тут не очень-то и нужен.
Повотрюсь, это можно реализовать даже в третьей Самбе. Мне очень хотелось бы услышать аргументы, почему так уж необходимо иметь авторизационную информацию одинаковой по всей (гетерогенной) сети. Я пока таких аргументов не слышал. Поэтому, мне как-то не удалось проникнуться величием замыслов разработчиков Самба4. Может быть мне кто-то объяснит.

Можно ссылки на linux format давать в читабельном виде? В данном случае это http://www.linuxformat.co.uk/print.php?sid=217 t10x

>Чё плохого в локальных accounts? Если у вас в сети больше тысячи хостов, то локальные руты (или Administrators) неизбежное зло

плохо то что SID в таком случае - тоже локальные. Или я ошибаюсь? Сейчас на файлопомойке можно выставить что к такой-то директории такие-то юзвери/группы имеют такие-то права. самба мапит SID в uid/gid и выставляет пермишны на файло соответствующим образом. Как быть в случае локальных аккаунтов - я плохо представляю. Сейчас вот пытаюсь осознать, как убрать из сетей w2k3...дело движется, но медленно....

Не в SID дело. Тут цепочка другая. Имя локального пользователя маппится в глобольного принципала (в Цербере). Если принципал аутентифицирован на сервере, то принципал ремаппится по имени в локального (но уже для сервера) пользователя. Права локального пользователя сервера определяются теми правами, что выданы ему на сервере. Т.е. роль играют только ACL выставленные для этого пользователя на сервере. SID, вообще, нафиг не нужен.

>Имя локального пользователя маппится в глобольного принципала (в Цербере). Если принципал аутентифицирован на сервере, то принципал ремаппится по имени в локального (но уже для сервера) пользователя. Права локального пользователя сервера определяются теми правами, что выданы ему на сервере. Т.е. роль играют только ACL выставленные для этого пользователя на сервере. SID, вообще, нафиг не нужен.

на воркстейшнах-то цербер-сервера нету. соответственно и авторизацию на доступ к локальным ресурсам _рабочей станции_ не организовать. А так да, pGina позволяет реализовать схему аутентификации [openldap+pam->pam-server->pGina] (т.е. без цербера)

надо попробовать...

>>> воркстейшнах-то цербер-сервера нету. соответственно и авторизацию на доступ к локальным ресурсам _рабочей станции_ не организовать.

Бли-и-ин :)
Цербер - глобальная система. Т.е., грубо говоря, пароли все храняться на одном компьютере (но не информация о правах пользователей). Вы можете получить Керберос-тикет сразу же при входе на свою рабочую станцию (не важно под линуксом, *BSD, виндовз, макос). Единственно, что у вас должна быть локальная информация о том, какой принципал соответствует какому имени локального пользователя. К сожалению эта информация может быть только локальна ( я AD не рассматриваю). На самом деле, даже эту информацию можно сделать глобальной, при условии, что у вас везде Линукс и вы используете NS-Switch. Но мелкомягкие станции понимают только либо локальную авторизацию, либо через AD, про NS-Switch они ничего не знают.
Главное тут как раз тикет. С его помощью можно получать доступ к любому сетевому ресурсу, зарегестрированному в том же контроллере Керберос. Доступ локального пользователя к локальному ресурсу, конечно же определяется через SID (uid/gid). Но я не могу придумать пример, когда бы это было бы действительно важно и возникла бы необходимость контрольровать этот доступ через глобальные настройки.

> маразм - на дворе 21 век. а мы все в плейн-файликах делаем бэкэнды.. ню ню

Про маразм в своей медицинской карточки почитай.
backend: openldap
access: via ldapfs (fuse file system for ldap servers)

>Единственно, что у вас должна быть локальная информация о том, какой принципал соответствует какому имени локального пользователя. К сожалению эта информация может быть только локальна ( я AD не рассматриваю)

я, собсно, говорил об этом же.

>На самом деле, даже эту информацию можно сделать глобальной, при условии, что у вас везде Линукс и вы используете NS-Switch

>Но мелкомягкие станции понимают только либо локальную авторизацию, либо через AD, про NS-Switch они ничего не знают.

мелкомягкие станции можно научить сетевой авторизации _не_ через AD. Через жопу правда, но я бы удивился, если б это можно было сделать прямо ;)

> маразм - на дворе 21 век. а мы все в плейн-файликах делаем бэкэнды.. ню ню

Нет, блин. Ради 3-х пользователей и четырёх компов, заведём ha-кластер с iSCSI!