Настройка файлового сервера на базе FreeBSD в домене Windows.
 

Знаю, тема избитая-переизбитая - связать BSD-Linux систему с доменной Windows-сетью. Но во всех инструкциях, по которым я действовал (в частности, вот этой и вот этой), не получается не только настроить так, как нужно мне, но даже и дойти вообще до каких-то осмысленных настроек. Просто расшарить папку у меня получалось, без аутентификации доменных пользователей. Но это не нужно.

А нужно вот что: есть доменная сеть, где всё на Windows. Подсеть одна - 192.168.0.*. PDC работает на Windows 2000 server, установлена AD. Для файлового сервера, члена домена, нужно только предоставление сетевых папок доменным пользователям, сидящим под Windows, и разграничение доступа (чаще всего по группам в AD, но и по отдельным пользователям тоже). Квоты тоже не нужны. Единственное, чего бы хотелось, это более простое управление разрешениями на доступ из-под какой-нибудь оболочки, неважно, где это будет находиться - на сервере Windows, локально на файловом сервере из-под иксов, или с Windows-машины администратора.

Почему выбор пал на FreeBSD? Да потому что ни один Линукс не смог распознать рэйд-массив (зеркало) на сервере. Убунту видит два диска отдельно, и из них можно легко построить программный рэйд, но зачем мне программный, если уже построен аппаратный? FreeBSD сразу предложила установку на ar0.
Пользуясь хэнд-буком, установил FreeBSD 7.0, Gnome и Samba3 (достаточно свежую, которая идёт в комплекте дисков FreeBSD 7.0), пользуясь sysinstall-ом. Настроил автозапуск Гнома, перезагрузился, зашёл под root-ом.

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

После установки, в вышеприведённых инструкциях написано, что надо установить heimdal для работы с kerberos5. Это меня удивило. А зачем? Поддержка пятого кербероса, согласно хэнд-буку, встроена в дистрибутив ещё со времён FreeBSD-5.1. Читаю хэнд-бук дальше - "Heimdal Kerberos доступен в виде порта (security/heimdal), его минимальный комплект включен в базовую установку FreeBSD." Понятно, возвращаюсь к инструкции. Чтобы настроить heimdal, надо отредактировать файл /etc/krb5.conf. Нету этого файла нигде! Ладно, установлю heimdal сам.
Появилось окошко, что ставить. Я выбрал LDAP (как по инструкциям), и на всякий случай, x11 utilies - подумал, что будет GUI какой-нибудь.
Heimdal скомпилировался и установился. А krb5.conf как не было, так и нет! Поискал - нашлись файлы krb5.conf.5 (справка какая-то), и два одинаковых файла krb5.conf.5.gz в разных местах. Вот тут я и застрял.

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

Спасибо.

Это файлы man`a в котором описано как создавать krb.conf
krb5.conf.5 (вызываются man krb5.conf)

Две статьи, по которым можно реализовать вашу задачу:
http://www.lissyara.su/?id=1180
http://www.lissyara.su/?id=1460
Если осилить не удастся - могу скинуть старые конфиги.
ЗЫ: керберос в версиях выше 6.0 трогать вообще не нужно ;)

DJ Mogarych, да тут вроде, написано всё :cool:
ЗЫ. Инструкция - это хорошо, главное - доступно, для чайников типа меня (тоже пытался настроить, вроде, работало, но потом почему-то перестала проходить авторизация. Плюнул)

Вот, сделал как у Лисяры в инструкции, билетики керберосовские получаю, к домену присоединился, списки пользователей и групп от домена получаю.

Только был нюанс был при присоединении к домену - сначала не хотело присоединяться, писало can not join as standalone machine. Решение нашёл на форуме Ubuntu - в smb.conf заменил security = ADS на security = domain, и закомментировал сточку realm = имя_домена. Тогда присоединился. Подозреваю, что так как ставил Самбу не из портов, а из собранных пакетов с диска, поддержки AD в пакете нет, поэтому параметр ADS Самбе неизвестен. Надо собирать из исходников; хоть это и долгий процесс, зато настроить модули можно. Кстати, вопрос знатокам: можно ли добавлять и удалять эти опции после установки Самбы?

Теперь новая проблема: Самбу запустил, настроил по инструкции. В сетевом окружении FreeBSD видна, и расшаренная папка имеется. В настройках папки стоит read only = no, но записать туда я ничего не могу. Пишет: "Нет доступа, или файл такой-то уже используется". Как это победить?

Для фряшки:

# cd /usr/ports/japanese/samba3
# make config
# make install clean
# rehash

smb.conf только сохрани куда-ньть

Например так:
# chmod 777 /some/way/shara

Сомневаюсь, что я пойму что-нибудь по-японски. :)
Но в общем понял, спасибо. Сейчас попробую.

да и я вобщем-то не японец :)

Действительно chmod помог.
Теперь только разрешения раздать не могу (пытаюсь раздать из клиентской Windows под учёткой доменного админа). Пишет: не удалось сохранить изменения разрешений, отказано в доступе.
А выглядят свойства папки вот так:
http://forum.oszone.net/attachment.p...1&d=1215775493
У всех записей разрешения пустые, нет ни одной галочки.

Да, ещё все русские названия на сервере выглядят как @@@@@@. На клиентских машинах с Windows всё нормально. Можно это как-то вылечить? Локаль переделывать в cp-1251 надо?

Это на консоли картина такая или по ssh?

DJ Mogarych, у лисяры есть описание переделки, я сделал - в консоли всё нормально видно, по-русски (однако, это все-таки дурной тон - называть файлы локализовано :drug: )

Для консоли вроде так:
# pw usermod root -L russian

И добавляем в rc.conf:
font8x14="cp866-8x14"
font8x16="cp866b-8x16"
font8x8="cp866-8x8"
scrnmap="koi8-r2cp866"
mousechar_start="3"
keymap="ru.koi8-r"

А если админим сервак через putty - не забываем править кодировку в ее настройках.

Аlchemist, ну и будут кракозябры в консоли, да и в puTTY-сессии тоже, проверено

Лучше настроить ср1252, как в статье

Очень спорное утверждение
Для никсов koi8-r намного ближе, чем виндовая cp1251

Этого я тоже не понимаю, равно как и установку heimdal-a на систему, в которой уже давно встроен пятый керберос (хеймдаловский же). Когда я ставил систему, я настраивал всякие шрифты, кеймапы, скринмапы... Всё настроил в sysinstall-e правильно, поставил koi8-r, и прочее. Так что же это, зря? В rc.conf все эти строчки есть.

Кстати, ничего криминального не вижу, чтобы настроить консоль в cp-1251. Если будет видно русские названия, то почему бы и нет? Конечно, для юниксов koi-8 ближе. А мне-то ближе отсутствие проблем и несовместимостей... А почему речь зашла о cp-1252?

Сейчас меня больше волнует раздача разрешений...

А, забыл сказать: крякозябры - в Гноме. В консоли что-то не догадался посмотреть. Гном меня ещё радует тем, что, заходя по рутом, я, пытаясь открыть в меню какие-то параметры системы, получаю сообщение, что у меня не хватает прав. Наверное, права есть только у разработчиков FreeBSD и Гнома.

Нет, не зря. Если какие-то строчки, из тех что я приводил выше, у тебя есть - второй раз их писать не стоит :)Просто шрифт в некоторых программах, например мс, будет отображаться некорректно.
насмешил =)

Бог с ним, с МС. Переживу. Есть ведь что-нибудь другое?
Так что делать с разрешениями? Хочется ведь рулить ими так, чтобы было удобно, а не в консоли. XXI век на дворе, такие элементарные вещи хочется делать быстро и удобно, без мантр в командной строке...

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

По идее, в конце должна получиться статья, которая охватывает все аспекты и всех авторов. :)

а попробуйте клиентов под windows писАть в кои8...
да, есть такое.. Но мне оно не мешает (ну, почти не мешает, можно не все консоли делать типа 25r, оставить парочку "как есть")

А ведь 21 век на дворе, надо осваивать связку FreeBSD 7 + Windows 2003. Вот и получится актуальная и нужная статья.

Не совсем понял, ты хочешь расставлять разрешения никсовым шарам из винды через вкладку безопасность?
Если да, то я уже давал ссылку: http://www.lissyara.su/?id=1460

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

DJ Mogarych, а с юзерами разобрались? Настройкой шары может заниматься юзер с админскими правами (т.е. надо шару на БСД присвоить юзеру из АД, администратору или администраторам). Сегодня-завтра попробую проверить, отпишусь

Да, вспомнил, там был нюанс с которым я долго ковырялся: нужно на фряхе хозяином шары сделать админа из АД, тогда и доступ будет, но менять эти права может только этот админ.

А можно ли заходить локально на файл-сервер под доменным админом, дав ему права рута? То есть, заменить рута доменным админом, и, соответственно, все действия делать от его имени, чтобы не париться с правами?

Чтобы из винды выставлять разрешения (ака "ACL" - access control lists) на *nix-сервере в файловой системе *nix-сервера должна быть включена поддержка ACL - man tune2fs.

Вернее, для freebsd - tunefs

... и при сборке самбы её тоже надо включить

dmitryst,

Верно, но, если моя память мне ни с кем не изменяет, оно по дефолту включено. Равно как и параметр "nt acl support" в конфиге. Но для надежности лучше указать ручками. :)

Dimon, да, при сбоке пакета достаточно один раз указать, и всё. Меня сейчас больше волнует "... time skew is too great.." . Пока застрял на поднятии time-сервиса или на win или BSD, и их синхронизации

dmitryst,

У меня такое было по следующим причинам:
А синхронизить время можно с помощью той же самбы: net time set ... - чтобы NTP не поднимать.

не, лучше наоборот, чтобы эталонное время было на контроллере домена, а клиенты пусть синхронизируются с ним

dmitryst,

net time - на самбе выполнять :)

Dimon, а зачем? Пусть уж контроллер домена всем выдает эталон времени, а на файловом сервере я буду синхронизироваться, всего-то делов..
Кстати, билетик Kerberos получить не удалось, пароль, видите ли, неправильный, но к домену подсоединился, клиенты шары видят, читать/писать могут. Пробую включить ACL на отдельном диске..

Не получается-
tunefs -a enable /shares
tunefs: ACLs set
tunefs: /dev/ad0s1a: failed to write superblock

Галочек не будет? :(

Дык я о том же: файл-сервер с помощью утилитки net из пакета самбы будет синхронизить свое время с контроллером домена. Просто предложил как одно из решений - даже ntp не нужно ставить, а эффект тот же. :)
klist что говорит? Как вариант: удали все билеты командой kdestroy и kinit'ом получи заново.

да, но так проще - одну строку в конфиг, и одну в rc.conf :)

говорит, что неправильный пароль. А нужен этот билет вообще? В домен-то я зашел, доступ есть.

Я так понимаю, что получение билета - это чтобы проверить работу кербероса, и ничего более.

У вас вообще winbind отрабатывает?
# wbinfo -p
# wbinfo -t
# wbinfo -g
# wbinfo -u

да, всё есть, и группы и юзеры. Не поленился, поставил еще одну FreeBSD, настроил, керберовский билет опять получить не смог, пароль, типа, не совпадает. А и пёс с ним, в домен вошел, юзеры файлы видят, всё хорошо

Важно! В конфиг самбы обязательно добавить "nt acl support = yes", а то галочек не будет..

Интересно, а зачем давать права доменному админу два раза: один раз на файловую систему, а другой - на расшаренные папки? Может быть, сначала дать права на файловую систему, а потом создавать расшаренные папки, уже имея на них права администратора домена? Так получится?
Хочется сделать всё проще и прозрачнее.
У меня wbinfo отрабатывает отлично, списки получаются, и билеты тоже. Вот почему Гном, собака, пишет под рутом, что нет прав, тоже вопрос...

Я так и сделал - присвоил папку /shares/data админу, а затем по сети создал внутри неё ещё папки для других пользователей (но окончательно запутался в правах доступа, это вам не 755 выставлять :biggrin:. Кстати, где можно найти толковое разъяснение этих прав доступа под win?)

А что там непонятного может быть? Это же венда =) В чем конкретно запутались?

Если нужно прятать папки/файлы на шаре от юзеров, которые их не имеют права читать/писать - параметры smb.conf hide unreadable, hide unwriteable в помощь

Dimon, это вырез гланд ректально, не наш метод :biggrin: Нужно всё-таки добраться до этих "unreadable"...

Dimon, вы собирали Самбу из пакета. В вашей инструкции написано:
Хотелось бы узнать всё с начала...
1) tar -zxvf samba-.3.0.23d.tar.gz - это после какой команды? Что-то там fetch?
2) И дальше: cd samba-3.0.23/source. Папка samba-3.0.23 - это что, в корне?
3) И, наверное, самое важное: если ставить Самбу через команду
, то ставится она без поддержки ADS. А она-то как раз и нужна. В связи с этим вопрос: можно ли поставить Самбу с диска, указав приведённые вами опции? Она ведь довольно свежая на диске с FreeBSD 7.0.

А зачем такие сложности????
cd /usr/ports/net/samba3
make ( качаем свеженькую версию, 3,0,28,1 - около 4Мб)
(после закачки выбираем то, что нужно)
make install
Всё :)

Сложности в том, что почему-то сборка из портов вылетает с ошибкой, и, к тому же, зачем качать из интернета ту же самую версию, которая есть на диске?

# cd /usr/ports/net/samba3
# make clean
# make config
# make install clean

Хотябы потому, что от того что есть на диске мало толку :)

DJ Mogarych,

Имеется ввиду установка из _исходников_ - не из портов или бинарных пакетов. Небольшая путаница в терминах, миль пардон :)
Насчет бинарных пакетов: как-то практически никогда не пользовался ими во freebsd, всегда хватало портов, в крайнем случае - исходники, так что тут не подскажу ничего толкового...

Да, действительно, запутался. Ладно, шут с ним, развели портов, пакетов каких-то... :)
Самба собралась, когда я выкинул CUPS из конфигуратора сборки.

Теперь хочется обойтись без ненужных настроек. Итак, что я выяснил:
1) Что Керберос устанавливать и настраивать не надо. Сразу после установки системы, если был сконфигурирован сетевой интерфейс, команда с последующим указанием его пароля без проблем даёт билетик.
2) Что в smb.conf не нужна строка:
потому что стоит security = ADS, а не security = domain. А также можно обойтись без обозначения размеров лог-файлов и прочего, оставить всё по умолчанию, и ладно.

Без чего ещё можно обойтись?
Я подумал - да бог с ними, с галками этими под Windows. В принципе, достаточно создать папку, и дать разрешения группам или отдельным пользователям домена, и всё. И пусть бы эти пользователи создавали дальше папки сами, какие им нужно. А если что - можно и зайти на сервер раз в полгода, и создать ещё один ресурс с разрешениями.

Просто хочется минимального размера конфигурационного файла.

Ещё несколько вопросов:
1) Обязательно ли править nsswitch.conf?
2) Какие минимально возможные настройки сборки Самбы из портов, чтобы получить функциональность файлового сервера-члена AD?
3) Нужны ли всякие там ACL, если галки из-под Windows отпадают, и достаточно обычного разграничения доступа по доменным пользователям?

1) Да
2) ADS, Winbind
3) нужна ли лопата, если копать не будем? :)

у меня из портов собралась нормально
нууу..... Лишать себя такого удовольствия? Я против :)

1) да, иначе оно работать не будет
2) ADS (чтоб в домен войти), winbind (получить список пользователей и групп) точно нужны, можно до кучи выключить поддержку syslog
3) нет, в них не будет тогда смысла

ЗЫ. В соавторы статейки возьмёте? ;)

1. Без правки nsswitch система не будет знать в каких локальных базах искать юзеров/группы/хосты и прочее относящееся к домену. Если не добавлять строку "winbind" то не будет происходить "отображение" (map) юзеров домена на локальную машину. Иначе говоря, если есть строка winbind в nsswitch то фря будет обрабатывать доменных юзеров точно так же (точно такими же системными вызовами, например gethostbyname() ), как и своих локальных из /etc/passwd, /etc/group например. man nsswitch.conf более подробно расскажет зачем это нужно.
2. Членом домена можно быть в режиме совместимости - NT-style и в "родном" режиме. В первом случае нужна аутентификация NTLM(2), winbind и все. Во втором случае - kerberos, winbind, ads.
3. Параметры к acl нужны если нужна функциональная вкладка "Безопасность" в свойствах папки с вин-машины.

Копать будем, только хочется копать там, где помягче, а ещё лучше - воспользоваться экскаватором. :)

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

Так, ADS, winbind и ACL. LDAP не нужен?

Вычитал в журнале "Системный администратор" за февраль 2007-го, что из файла nsswitch.conf надо удалить всё, и оставить такие строчки:
Достаточно компактно, во всех остальных инструкциях nsswitch.conf более многословен. Достаточно ли этих трёх параметров?

Достаточно. Строка "files winbind" говорит о том, что вначале будет произведен поиск юзеров, паролей, групп и хостов в локальных базах типа /etc/group, при ненахождении будет запрос к winbindd, который произведет поиск всего этого через самбу в домене.
При сборке самбы с поддержкой ADS необходимо также включать и поддержку LDAP (хотя, возможно при включении ADS оно автоматом само подхватывает и ЛДАП - уж не помню щас - если же нет - должна быть ошибка сборки).

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

Простейшая настройка файлового сервера на FreeBSD 7.0 с интеграцией в Active Directory на контроллере домена Windows.

Дано: Небольшая Windows-сеть с контроллером домена Windows 2000 server. На контроллере домена, естественно, стоит Active Directory. Домен, для простоты, назовём DOMAIN, а администратора домена - Administrator.

Задача: сделать файловый сервер под управлением бесплатной операционной системы, с контролем доступа пользователей, записанных в Active Directory на контроллере домена Windows 2000-2003. Сервера печати, квот и прочих чудес не будет. Просто папочки с доступом определённых пользователей или групп.


Почему FreeBSD? Потому что эта система воспринимает большее число серверных устройств, к примеру, RAID-контроллеров, без установки дополнительных драйверов (которые просто так зачастую не устанавливаются, или их просто не существует под UNIX-системы), и потому что нет такой путаницы с дистрибутивами, как у Linux.

Описывать установку FreeBSD не буду, скажу лишь, что желательно при установке включить доступ по SSH. Данная настройка файлового сервера не подразумевает управление разрешениями с клиентских машин с Windows, и для удалённого доступа к файловому серверу можно использовать программу Putty. А можно и вообще удалённого доступа не делать, это уже хозяин-барин.

Почему не сделать управление доступом к разрешениям на папки галочками из Windows? Да потому что полезность этого стремится к нулю - разрешения на папки меняются не каждый день; чаще всего создаётся папка, даются права какому-то пользователю или группе, а потом всё это не меняется годами. В конце концов, можно дать пользователю или группе полные права в этой папке - пусть делает там что ему заблагорассудится. И с настройкой есть проблемы: у меня, например, никак не хотели изменяться права на файловую систему; не хотела она отмонтироваться, чтобы поменять права, и всё тут! Ни в монопольном режиме, никак. В общем, лишняя головная боль. Оставим эту возможность.

Графических оболочек для создания файлового сервера не нужно: всё ограничится несколькими командами в консоли, да небольшими правками конфигурационных файлов. Можно установить Midnight Commander, по вкусу.

Также при установке FreeBSD не нужно создавать пользователей. Они тоже ни к чему. Настроив сервер, выйдем из сеанса суперпользователя, и сервер будет работать себе дальше. Надо что-то поправить - опять зайдём под суперпользователем, и настроим что нужно. В конце концов, пользователя можно элементарно завести из консоли когда угодно.

Обновлять порты и пересобирать ядро не будем. И так сойдёт.

И, наконец, пакет, необходимый для взаимодействия с Windows-окружением - Samba3 - ставить из пакетов, идущих в дистрибутиве FreeBSD 7.0, не будем, потому что в этом пакете нет поддержки Active directory, которая нам как раз и нужна.


Итак, FreeBSD 7.0 установлена, сетевая карта настроена, сервер имеет доступ в интернет, и в систему зашли под root-ом. Теперь надо ставить Samba3. В дереве портов она находится по адресу
Забавно, но поиск нужного порта по команде
выдаёт ссылку на японский порт:
Его-то я и ставил. :-) Но японский ставить или нет, совершенно неважно.

Для установки пишем:
Всплывает окно конфигурации. Я убрал CUPS (сервер печати), поставил крестик на ADS (поддержке Active directory) и, на всякий случай, на ACL_SUPPORT. Больше ничего не менял. Нажимаем OK и не спеша идём пить чай - скачиваться и устанавливаться будет небыстро.

Во многих подобных инструкциях дальше указывается ставить и настраивать kerberos5. Так вот - не надо ничего ни ставить, ни настраивать. Kerberos5 входит в состав FreeBSD начиная ещё с версии 5.1, и дополнительной настройки требует в случаях сложной организации сети. Пропускаем этот пункт.

Дальше нужно отредактировать файл nsswitch.conf. Это конфигурационный файл диспетчера службы имён, и в нём задаётся порядок просмотра тех или иных источников информации по спискам пользователей, паролям, сетевым протоколам и другим вещам.
Во FreeBSD есть простенький консольный текстовый редактор, он называется "ee".
Итак, редактируем:
Перечисленные ниже параметры надо привести к такому виду:

Чтобы выйти из редактора, нажмите кнопку Esc и выберите пункт "leave editor". Далее выберите "save changes", чтобы сохранить изменения.


Теперь надо заняться конфигурированием непосредственно файл-сервера. Сначала создадим саму папку, которая будет общей. В данном случае папка называется share, и находится она в корне файловой системы.
Настраиваем Самбу. Её конфигурационным файлом является smb.conf.
Набираем:
Потом стираем всё, что есть в конфигурации (нажимаем и держим Ctrl+k), и пишем следующее:
Можно и исходный файл отредактировать, но лучше написать только то, что нужно, убрав весь мусор (и комментарии тоже). Так как файл smb.conf часто перечитывается, лучше, чтобы он был наименьшего размера. Выходим из "ee", сохранив результат.

Дальше получаем билетик kerberos от имени администратора домена:
Теперь можно присоединить наш сервер к домену:
Отлично. Теперь редактируем файл rc.conf. Это конфигурационный файл с некоторыми системными параметрами и список служб, загружаемых вместе со стартом системы.
Ничего не трогаем, только в конец файла записываем:
Выходим из "ee", сохранив результат.

Перезагружаем наш сервер командой reboot.

Всё!

P. S. Я не знаю, достаточно ли обычного указания кодировок в Самбе для нормального отображения русских названий файлов в консоли. Я думал, что дело в кодировке консоли, и переделал её сначала под cp1251. Но это не помогло (только Midnight commander стал русским - приятный сюрприз). Только после этого я добавил строки с указанием кодировок в smb.conf. После этого всё стало на свои места. И я не знаю, надо переделывать консоль в cp1251, или нет. Может быть, можно обойтись и без этого.
А может быть, не трогать консоль, а установить Midnight commander, и выставить кодировку там. В Коммандэре всё ж удобнее файлы-то просматривать.

Я переделал, доволен :)
Кстати, удалось ли решить проблему с наследованием свойств, как на обычной ntfs системе?

А в чём эта проблема заключается?

:nnn: Спасибо всем! Из всего что читал, это оказалось самым конкретным!