При описании установки и настройки сервера под управлением FreeBSD 6.0 в качестве файлового сервера (читаем раз, читаем два, читаем три) я умолчал об одной из главнейших операций – собственно о настройке сетевого сервиса, известного под названием самба. Молчаливо предполагалось, что существует Интернет, в котором о самбе сказано больше, чем достаточно.
В самом деле, стоит в любой поисковой машине набрать запрос «Как настроить самба-сервер?», как тут же в ответ вы получите миллионы ссылок на миллионы документов, в которых разные люди описывали настройку этого самого самба-сервера. И у всех авторов – варианты абсолютно рабочие, по их же собственным утверждениям. И, тем не менее, постоянно возникают вопросы и проблемы. Постоянно кто-то не может заставить самбу работать так, как ему надо. взгляните на любой форум – вы обязательно обнаружите там подобные вопросы. Стало быть, где-то в руководствах из Интернета что-то не сходится.
По здравом размышлении я решил вооружиться наполеоновской треуголкой и написать-таки руководство, следуя коему каждый смог бы настроить свой самба-сервер без лишних вопросов и проблем.
Исходные данные
Имеем готовый сервер под управлением FreeBSD 6.0, находящийся в нашей локальной сети и доступный для администрирования. Этот сервер прекрасно видит интернет и не менее прекрасно пингует и видит локальную сеть. Имя сервера – bsd.mydomain.local.
В локальной сети поднят полноценный домен MYDOMAIN.LOCAL на базе AD. Разумеется, имеется контроллер домена с именем pdc.mydomain.local и IP-адресом 192.168.0.1. Этот же контроллер домена является одновременно и DNS-сервером.
Сервер bsd.mydomain.local прописан в DNS со статическим IP-адресом 192.168.0.252.
Администратором домена является уч?тная запись admin с паролем adminpass. Пароль для root на сервере bsd.mydomain.local равен rootpass.
Задачи
Установить на сервер bsd.mydomain.local пакет samba.
Настроить этот сервер в качестве члена существующего в локальной сети домена.
Создать на сервере общую папку в публичном доступе – чтобы все могли там читать и писать.
Создать на сервере папку для админа домена с доступом только для него.
Установка самбы
Прежде всего, что такое самба? Если мы не говорим о латиноамериканских танцах, то самба – по данным сайта http://www.samba.org/ – это ПО с открытыми исходными кодами для предоставления доступа к сетевым файлам и принтерам клиентам SMB и CIFS, включая все без исключения версии MS Windows.
Установка самбы на сервер FreeBSD производится до неприличия просто – напрямую из портов. Алгоритм не сложен:
подключитесь к серверу по SSH;
перейдите в режим суперпользователя командой su (потребуется пароль для root);
если надо, обновите дерево портов командой portsnap fetch && portsnap update;
выполните установку самбы командой portinstall samba3.
При этом установка самбы сопровождается простейшим псевдографическим меню, в котором предлагается выбрать опции для установки. Меню состоит из следующих пунктов:
LDAP With LDAP support
ADS With Active Directory support
CUPS With CUPS printing support
WINBIND With WinBIND support
ACL_SUPPORT With ACL support
AIO_SUPPORT With experimental AIO support
SYSLOG With Syslog support
QUOTAS With Quota support
UTMP With UTMP support
MSDFS With MSDFS support
SMBSH With SMBSH wrapper for UNIX commands
PAM_SMBPASS With PAM authentication against passdb backends
EXP_MODULES With experimental module(s)
POPT With system-wide POPT library
На вопрос, какие именно пункты следует выбрать, легко можно ответить, если ч?тко представлять себе предназначение нашего самба-сервера и стиль его жизни вместе с его окружением. В самом деле, коль скоро наш сервер будет членом домена с полноценной АД, то поддержка LDAP в нашей самбе даже обсуждению не подлежит. Равно как и поддержка ADS и WINBIND – ведь вокруг нашего сервера толпится куча клиентов под управлением Windows, и все они – члены домена. Далее следует понимать, что мы хотим разграничивать права доступа к сетевым ресурсам, а это значит, что нам потребуются ACL – access control list (списки контроля доступа). Кроме того, можно же запретить пользователям захламлять сервер тоннами информации. Для этого достаточно наладить квотирование, а это, в свою очередь, означает поддержку квот. Поддержку CUPS (common unix printing system – общая система печати unix) имеет смысл включать только в том случае, если на этом сервере будут располагаться сетевые принтеры. Подобные же рассуждения можно привести по каждому пункту меню. Заметим, что я устанавливал самбу с поддержкой выделенного жирным шрифтом в привед?нном списке.
Выбрав вс? нужное и исключив вс? лишнее из списка, нажимаем ОК и обнаруживаем, что самба начала скачиваться и компилироваться. На этом весь процесс установки (точнее, наше в н?м участие) заверш?н – оста?тся дождаться окончания сборки.
Включение сервера в домен
Предварительные настройки
Чтобы сервер под управлением FreeBSD стал полноценным членом домена, необходимо обеспечить выполнение на этом сервера самбы и корректные е? настройки. Вот с этих самых настроек и начн?м…
Прежде всего, выполняется ли самба на нашем сервере? Ответим в одесской манере вопросом на вопрос – а кто е?, простите, запускал? Стало быть, необходимо озаботиться автозапуском самбы при старте сервера. Для этого необходимо соответствующим образом поправить файл rc.conf, располагающийся в каталоге /etc. Собственно, вся правка сводится к дополнению этого файла всего двумя строками:
samba_enable=«YES»
winbindd_enable=«YES»
Молчаливо предполагается, что править файлы в консоли FreeBSD мы уже умеем.
Теперь, лишь только мы перезапустим сервер, самба стартует автоматом. Но торопиться не стоит – стартовать-то она стартует, а вот в каком виде?
Прежде всего, вспомним, что мы имеем дело с полноценной АД. А это значит авторизацию, авторизацию и ещ? раз авторизацию. А авторизация в АД вед?тся по протоколу Kerberos.
За этот протокол в FreeBSD отвечает пакет heimdal. Как правило, он ставится вместе с самбой, но может и не поставиться. К примеру, на мо?м сервере его нет, а на сервере коллеги, с коего и пишется эта статья, этот пакет установлен. Так или иначе, его можно просто установить из портов. Описывать установку не буду – слишком уж примитивно.
Пакет heimdal работает с конфигурационным файлом krb5.conf, располагающимся в каталоге /etc. Выглядит этот файл следующим образом:
[libdefaults]
default_realm = MYDOMAIN.LOCAL
clockskew = 300
v4_instance_resolve = false
v4_name_convert = {
host = {
rcmd = host
ftp = ftp
}
plain = {
something = something-else
}
}
[realms]
MYDOMAIN.LOCAL = {
kdc = 192.168.0.1
admin_server = 192.168.0.1
kpasswd_server=192.168.0.1
}
[domain_realm]
.mydomain.local = MYDOMAIN.LOCAL
По сути вс? конфигурирование этого файла сводится к вписыванию имени нашего домена и адреса нашего КД на положенные места. При этом – внимание! – сам файл уже содержит некие записи по умолчанию для некоего вымышленного домена, так что понять, куда именно вписывать наши параметры, сможет каждый, у кого есть глаза. Просто замените данные для этого мифического домена своими данными – и всего делов!
Отныне наш сервер сможет получать билеты от нашего КД, ибо знает, к кому обращаться. А правильный билет – это наш доступ в домен и доступ к нам из домена. Теперь дело за собственно самбой…
Конфигурирование самбы
Внимательное чтение надписей на экране можно без преувеличения считать главной добродетелью системного администратора. Надписи эти несут в себе разумное, доброе, вечное. Во всяком случае – однозначно полезное. Основной постулат моей веры – если компьютер решил-таки написать что-то на экране, то это не просто так и это следует прочитать.
В частности, при установке самбы в заключительных строках сообщений на экране написано, что в каталоге /usr/local/etc имеется отныне файл smb.conf.sample. Далее в этих же надписях говорится, что можно скопировать этот файл в новый файл с именем smb.conf и поправить по своим потребностям. Послушаемся же совета мудрого компьютера!
Открыв свеженький файл /usr/local/etc/smb.conf мы можем обнаружить, что он состоит из нескольких секций, одна из которых располагается в самом начале и открывается ключевым словом [global]. Эта секция отвечает за параметры сервера и его поведение в сети. Все остальные секции описывают различные сетевые ресурсы этого сервера и ими мы займ?мся позже.
При каждом параметре имеется весьма подробный и обстоятельный комментарий, который описывает этот параметр и да?т наводку, что именно нам с этим параметром следует сделать. Вдумчивое чтение этих комментариев позволит нам настроить наш самба-сервер практически без использования всякой прочей документации. Предлагаю вам пройтись по всем этим параметрам и разобраться, что они обозначают и за что отвечают.
Параметр workgroup. Зада?т имя рабочей группы, к которому будет принадлежать наш сервер, о ч?м совершенно однозначно заявлено в комментарии. В частности, в случае домена используется NetBIOS-имя домена. Для нас этот параметр будет выглядеть как workgroup = MYDOMAIN
Параметр server string – это всего лишь описание нашего сервера в сетевом окружении. его можно оставить пустым, а можно и нарисовать всякие умные вещи. К примеру, server string = My cool new server!
Параметр security определяет, с чем и как самба будет согласовывать вопросы доступа и безопасности. В комментарии предложены различные схемы. Нам здесь важно понять, что раз мы используем полноценную АД, то для нас самым подходящим будет значение ads (active directory security – вс? просто, не правда ли?). То есть, security = ads
Параметр hosts allow описывает адреса машин, которым можно будет обращаться к нашему самба-серверу. Это полезно, т.к. никто из подключившихся снаружи при верно заданном параметре просто не добь?тся взаимности от нашего сервера, что изрядно повышает безопасность. При этом, согласно комментарию, в этот параметр должны быть включены компьютеры локальной сети и сетевой интерфейс loopback с адресом 127.0.0.1, указывающий на собственно наш сервер. При этом вместо перечня хостов можно указать целую подсеть – к примеру, для всех хостов сети 192.168.0.0 с маской 255.255.255.0 можно просто указать 192.168.0. и параметр будет выглядеть так
hosts allow = 192.168.0. 127.
Хосты и подсети перечисляются через пробел в количестве, отвечающем нашим запросам.
Следующие четыре параметра отвечают за сетевые принтеры, что напрямую следует из их названия. В мо?м случае самба-сервер не мыслился в качестве сервера печати, а посему эти параметры нас совершенно не интересуют. Лично я их не настраивал и не менял, оставил по умолчанию.
Параметр guest account отвечает за гостевой доступ. Если самбе не удалось авторизовать подключающегося пользователя, она присваивает ему привилегии уч?тной записи, указанной в этом параметре. Соответственно, если этот параметр отсутствует, то неавторизованного пользователя просто не подпускают к системе, что меня вполне устраивает – в мо?м домене гостей не бывает. Я этот параметр закомментировал.
Следующие два параметра отвечают за журнал самбы – за е? логи. В первом из них указывается, где хранить этот журнал. Во втором – максимальный размер файла журнала. Я бы рекомендовал оставить эти значения по умолчанию, поскольку в этом случае свой лог будет вестись для каждой подключающейся машины, что вполне адекватно.
Следующие три параметра отвечают за обработку самбой уч?тных данных пользователей. Первый из них – password server – отсылается к серверу, который обрабатывает пароли и авторизует пользователя. В нашем случае таковым, вполне законно, является контроллер домена. Второй параметр содержит имя домена, к которому принадлежит наш сервер. Заметим, что в отличие от параметра workgroup, который в большей мере отвечает за отображение сервера в сетевом окружении, параметр realm напрямую связан с безопасностью и должен содержать полное имя домена. И, наконец, третий параметр – passdb backend – определяет, каким образом самба будет кэшировать и хранить информацию о пользователях. При этом в комментарии сказано, что в случае значения этого параметра, равного tdbsam, никакой дальнейшей настройки не требуется. Заманчиво, не правда ли? В итоге для нашей задачи эта тройка параметров выглядит следующим образом:
password server = pdc.mydomain.local
realm = MYDOMAIN.LOCAL
passdb backend = tdbsam
Заметим также, что если в сети имеется не только главный КД, но и запасные КД (к примеру, bdc.mydomain.local), то их тоже можно указать в параметре password server через пробел. В этом случае если первичный контроллер домена по какой-либо причине недоступен, самба вполне успешно авторизует пользователя с подачи резервного контроллера домена.
Параметр include позволяет модифицировать конфигурацию самбы в зависимости от того, какой именно клиентский компьютер к ней подключается. Честно говоря, практического применения этой возможности я так и не смог придумать, а потому сам параметр просто закомментировал, как лишний.
Параметр socket options отвечает за производительность самбы в сети. В принципе, значение по умолчанию нас должно вполне устроить.
Параметр interfaces перечисляет сетевые интерфейсы, на которых самба принимает подключения. Если в вашем сервере имеется несколько сетевых интерфейсов, то вы можете сконфигурировать самбу на работу на одном из них, а прочие службы – на другом. По некоторым данным это благотворно влияет на сетевую нагрузку. В мо?м случае мы имеем дело с одним лишь интерфейсом, носящим название bge0. Кстати, в этом параметре интерфейс можно задать и по названию, и по сетевому адресу. К примеру, у меня этот параметр выглядит так – interfaces = bge0
Следующие четыре параметра определяют поведение самба-сервера на выборах обозревателя сети. При этом следует помнить, что в сети есть контроллер домена, который, как правило, и становится обозревателем сети. Ему это к лицу, так что необходимо объяснить самбе, что она в этих выборах участвует наравне с прочими рядовыми серверами. Для этого параметры должны иметь следующие значения:
local master = no
os level = 33
domain master = no
preferred master = no
Следующие три параметра определяют, будут ли машины под упрапвлением Windows регистрироваться на самбе вместо КД и если будут, то как. Вопрос, строго говоря, странный – в сети есть полноценный контроллер домена, который и занимается регистрацией и авторизацией. Самбе в этой области делать нечего. Соответственно, первым параметром запрещаем ей регистрировать машины – domain logons = no – и комментируем остальные два параметра, как излишние.
Следующие три параметра описывают взаимодействие нашего самба-сервера со службой WINS.
Параметр wins support определяет, должна ли самба задействовать имеющийся у не? компонент сервера WINS. Проще говоря, должна ли самба стать WINS-сервером сети.
Параметр wins server должен либо содержать IP-адрес существующего в сети WINS-сервера, либо отсутствовать. При этом важно учесть, что самба одновременно может быть либо сервером WINS, либо клиентом WINS. Если первый параметр установлен, как wins support = yes, то параметр wins server должен отсутствовать (быть закомментированным). Если же функция WINS-сервера в самбе отключена, то этот второй параметр может содержать адрес WINS-сервера (и тогда самба будет им пользоваться для поиска компьютеров в сети), или же может отсутствовать (и тогда самба не будет использовать имеющуюся в сети службу WINS, а станет искать компьютеры через DNS-сервер).
Третий параметр – wins proxy – позволяет использовать самбу в качестве посредника между существующим в сети WINS-сервером и клиентами, которые не поддерживают WINS. В этом случае клиент, который не умеет получать ответы о машинах в сети от WINS-сервера, будет получать такие ответы от нашей самбы, которая, в свою очередь, будет просто пересылать его запросы существующему WINS-серверу и его ответы клиенту. Для этого, соответственно, надо, чтобы параметр wins server содержал IP-адрес существующего в сети WINS-сервера.
Для моей сетки, в которой WINS-сервер отсутствует, как явление природы, эта тройка параметров выглядит так:
wins support = no
;wins server = закомментировано
wins proxy = no
Параметр dns proxy велит самбе пытаться выяснить NetBIOS-имя компьютера в сети через DNS-сервер, как следует из комментария. Вообще-то, в сети есть мастер-браузер (он же – обозреватель сети), который хранит таблицу этих им?н и у которого вполне можно имя нужного компьютера выяснить, так что эту опцию, пожалуй, следовало бы отключить…
Далее следуют настройки кодировок.
Ни для кого не секрет, что Windows и *nix между собой дружить упорно не хотят. И в первую голову это проявляется в различных кодовых страницах, используемых системами. Между тем, нам бы приятно было созерцать в сети ресурсы с русскими именами, да и файлы чтобы русские были… Посему надо объяснить самбе, как хранить имена у себя, как показывать windows-системам, а как – никс-системам. Вариантов множество и далеко не факт, что мой вариант у вас сработает, но вс? же… У меня это выглядит так:
dos charset = CP866
unix charset = KOI8-R
display charset = KOI8-R
Секреты шеф-повара
Как ни странно, все остальные параметры после кодировок (до того места, где начинаются описания сетевых ресурсов) можно спокойно закомментировать – они для нас несущественны. В основном этот остаток касается ситуации, когда самба сама выступает в роли контроллера домена, что для нас по меньшей мере неактуально. Но!
Существует ещ? несколько параметров, которые не упомянуты в файле /usr/local/etc/smb.conf.sample, но которые оказываются существенными, если мы говорим о сервере, который будет предоставлять свои ресурсы Windows-клиентам в домене. Эти параметры напрямую привязаны к модулю WINBIND.
Во-первых, нам необходимо, чтобы самба принимала пользователей Windows-домена. Как известно, пользователь в никс-системах определяется не столько по имени, сколько по своим идентификаторам – по идентификатору пользователя UID и по идентификатору группы, к коей этот пользователь принадлежит – GID. Соответственно, для успешного доступа к ресурсам самба-сервера необходимо, чтобы пользователю были присвоены эти самые идентификаторы. Для этого и существует компонент WINBIND. В конфигурации же нам надо, во-первых, указать, чтобы WINBIND присваивал идентификаторы пользователям домена и группам домена:
winbind enum groups = yes
winbind enum users = yes
и дать ему диапазон идентификаторов, чтобы избежать возможных накладок:
winbind uid = 10000-20000
winbind gid = 10000-20000
Теперь каждый пользователь домена при подключении к самбе будет получать свой UID и GID, начиная с 10000. Как правило, локальные пользователи нашей FreeBSD идентификаторы из этого диапазона не получат – числом не дотягивают…
Во-вторых, права доступа определяются на уровне домена и содержатся в списках контроля доступа – access control list. Соответственно, нам оста?тся намекнуть самбе, что эти списки нехудо бы использовать. Параметр прост и выглядит вот так:
nt acl support = yes
Ну и напоследок – немножко эстетики. Как различить между собой пользователя с именем admin в домене, и локального на нашей FreeBSD пользователя с именем admin? Кто подключился-то? Доменный или от имени локального? Путаница? Отнюдь нет…
Во-первых, следует вспомнить, что в домене имя пользователя выглядит отнюдь не как admin. Полное имя пользователя – admin@mydomain.local. Этот адрес e-mail защищен от спам-ботов. Чтобы увидеть его, у Вас должен быть включен Java-Script В самбу же уходит имя пользователя, составленное из NetBIOS-имени домена и собственно имени доменного пользователя. И мы можем задать разделитель для этих двух составляющих. Параметр выглядит так:
winbind separator =
и обозначает, что при подключении доменного пользователя админ его имя самбе будет передаваться в виде MYDOMAINadmin. Соответственно, мы можем изменить косую черту на что-то более милое нашему сердцу. К примеру, зачастую е? меняют на плюс. Впрочем, если этот параметр не использовать, то по умолчанию подставляется именно косая черта. В мо?м случае этот параметр отсутствует.
Глобальные настройки самбы можно считать сделанными. Осталось выложить полный текст этой секции конфигурационного файла, чтобы окончательно подвести итог…
[global]
workgroup = MYDOMAIN
server string = Samba-server %v
security = ads
hosts allow = 192.168.0. 127.
load printers = yes
log file = /var/log/samba/log.%U
max log size = 50
password server = pdc.mydomain.local
realm = MYDOMAIN.LOCAL
passdb backend = tdbsam
socket options = TCP_NODELAY
interfaces = bge0
local master = no
os level = 33
domain master = no
preferred master = no
domain logons = no
wins support = no
dns proxy = no
dos charset = CP866
unix charset = KOI8-R
display charset = KOI8-R
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind enum groups = yes
winbind enum users = yes
nt acl support = yes
Завершение конфигурирования
Осталось совсем немного – объяснить собственно FreeBSD, где и как авторизовать пользователей. Для этого предусмотрен конфигурационный файл /etc/nsswitch.conf, показывающий, с какими источниками и в каком порядке системе необходимо сверяться при получении авторизационной информации от клиента и присвоении этому клиенту соответствующих прав. В мо?м случае этот файл выглядит следующим образом:
group: files winbind compat
group_compat: nis
hosts: files dns
networks: files
passwd: files winbind compat
passwd_compat: nis
shells: files
Легко заметить, что в этом файле для проверки паролей и групп предусмотрено обращение к WINBIND и серверам сети (ключ nis). Это означает, что для авторизации пользователя будут применяться не только локальные данные самого сервера bsd.mydomain.local, но и информация авторизационных центров нашего домена, каковым является контроллер домена.
От винта!
Вс?, настройка конфигурационных файлов произведена. Теперь самба стартует автоматом при запуске сервера (то есть, всегда включена) и знает, в каком она домене и как с этим доменом ей следует взаимодействовать. Но вот знает ли о нашей самбе домен? Есть все основания предполагать, что ни разу не знает. Потому что мы ему не рассказали о пополнении. Но теперь, видимо, самое время…
Во-первых, необходимо наконец-то запустить самбу, если она ещ? не запущена. А если запущена, то е? необходимо перезапустить. Команда перезапуска самбы проста:
/usr/local/etc/rc.d/samba.sh restart
После удачного рестарта нам необходимо получить от нашего КД билет безопасности. Делается это командой
kinint admin@MYDOMAIN.LOCAL Этот адрес e-mail защищен от спам-ботов. Чтобы увидеть его, у Вас должен быть включен Java-Script
в ответ на которую модуль heimdal должен спросить вас о пароле пользователя admin (вспомним – он является администратором домена)
admin@MYDOMAIN.LOCAL Этот адрес e-mail защищен от спам-ботов. Чтобы увидеть его, у Вас должен быть включен Java-Script \’s Password:
Далее следует ввести пароль администратора домена. Если все настройки верны и КД адекватно отреагировал на запрос нашего сервера, то в итоге мы получим сообщение
kinit: NOTICE: ticket renewable lifetime is 1 week
что означает, что КД допустил нас к себе и выдал нам правильный билет сроком на 1 неделю.
Если же попытка получить билет окончилась провалом, то самые основные причины ошибки кроются в том, что где-то мы ошиблись в конфигурационном файле Kerberos, или же наблюдается слишком уж большое расхождение во времени между нашим сервером и КД (оно не должно превышать 5 минут). Соответственно, проверяем конфигурационный файл /etc/krb5.conf, синхронизируем КД и наш сервер и пробуем снова.
После удачного получения билета от КД осталось, собственно, прописать наш сервер в домен. Для этого воспользуемся командой net из комплекта самбы:
net ads join -w MYDOMAIN.LOCAL -U admin
Нас спросят о пароле для пользователя admin
admin\’s password:
в ответ на введ?нный пароль, если вс? настроено и работает корректно, мы получим следующие сообщения
Using short domain name — MYDOMAIN
Joined \’BSD\’ to realm \’MYDOMAIN.LOCAL\’
что свидетельствует об успешной записи нашего сервера в наш домен. Для полноты картины нам оста?тся ещ? раз перезапустить нашу самбу, как описано выше.
Убедиться в том, что нужный нам эффект достигнут, можно тремя способами.
Во-первых, если наш сервер вписан в домен, то его можно увидеть в сетевом окружении на любом из компьютеров домена под именем Bsd. Проверьте, появилась ли там такая машина.
Во-вторых, на контроллере домена в оснастке Active Directory Users and Computers в списке компьютеров домена должна появиться запись для нашего сервера. Проверьте, есть ли оно там.
В-третьих, на самом сервере можно ввести команду wbinfo -u, в ответ на которую машина должна выдать список всех пользователей и компьютеров нашего домена, взятый из нашей АД. Если такой список (внимание на разделители winbind separator – они могут и ввести в заблуждение непривычного человека) получен, то это значит, что наш сервер вполне успешно контактирует с контроллером домена и призна?тся последним за полноценного коллегу и члена домена.
Подводные камни
Собственно, подводный камень здесь бывает, в основном, один – мнительность. В ходе настройки самба-сервера можно заметить, что в сетевом окружении появилась некая загадочная рабочая группа. Обычно мы в сетевом окружении (для нашего случая) видим группу MYDOMAIN, содержащую все компьютеры нашей сети (включ?нные, разумеется). Когда же мы возьм?мся за настройку самбы, то мы можем обнаружить в сетевом окружении ещ? одну группу – MYDOMAIN.LOCAL. Откуда же она взялась?
Вс? очень просто. Как правило (и в подавляющем большинстве случаев) список, видимый в сетевом окружении, предоставляется так называемым мастер-браузером. Мастер-браузер – это всего лишь один из компьютеров сети, победивший на выборах мастер-браузера среди прочих компьютеров сети. Как правило, в доменной сети таковым становится контроллер домена. Что же это за должность такая – мастер-браузер?
Вс? ещ? проще. Периодически мастер-браузер опрашивает все доступные хосты нашей сети на предмет получения их им?н и рабочих групп. Собранные данные он хранит у себя и предоставляет каждому компьютеру, которому возжелалось обратиться к сети и получить список имеющихся в сети хостов. Каждый компьютер нашей сети сообщает мастер-браузеру сво? имя и название своего домена в качестве рабочей группы. На каком-то этапе самба-сервер уже знает, каково его имя и к какому домену он должен принадлежать. Соответственно, эти данные он уже может сообщить мастер-браузеру. Но! Домен ещ? не знает о нашей самбе – мы ещ? не вписали е? в домен. Соответственно, приписать нашу самбу к той же рабочей группе, что и все компьютеры домена, права не имеет. А куда тогда? Ведь в качестве рабочей группы сообщено имя MYDOMAIN.LOCAL и других вариантов нет. В итоге мастер-браузер и созда?т у себя отдельную группу с этим именем для нашей самбы.
Далее мы вписываем нашу самбу в домен и теперь мастер-браузер может отображать е? в списке компьютеров домена – в рабочей группе MYDOMAIN. Соответственно, созданная ранее группа MYDOMAIN.LOCAL оказывается пустой и через некоторое время будет удалена мастер-браузером по этой причине. Соответственно, получается, что беспокоиться по поводу возникновения лишней непонятной рабочей группы смысла нет.
Сетевые ресурсы
Мы настроили самба-сервер, мы видим его в сетевом окружении и без проблем можем к нему подключиться, но… На н?м нет ни одного сетевого ресурса. Потому что мы так ни одного и не создали. Займ?мся же этим в высшей степени богоугодным делом…
Прежде всего, уясним себе, что все секции файла smb.conf, следующие после секции [global], описывают тот или иной сетевой ресурс. Соответственно, создание нового сетевого ресурса сводится к написанию его секции.
Название секции, описывающей сетевой ресурс, является одновременно именем этого ресурса в сети. То есть, если мы хотим создать общую папку с именем Share на нашем самба-сервере, то секция, в которой описывается эта папка, должна называться [Share]. В скобках заметим, что название секции мне лично удавалось задать и на русском языке и в этом случае сетевой ресурс получался с русским именем, но здесь возможны проблемы с кодировками и локализацией самой FreeBSD.
Далее нам необходимо указать нашему серверу, какой именно из своих локальных ресурсов ему следует сделать доступным по сети. Проще говоря, какую именно папку следует объявить в общий доступ. При этом следует понимать, что на нашем сервере существует несколько дисковых разделов. Разумеется, общие ресурсы логичнее было бы размещать на том из них, объ?м которого максимален. Если вы вспомните, то при установке FreeBSD мы специально отдали под папку /usr/home максимальный объ?м винчестера, дабы пользователи сервера не испытывали недостатка в дисковом пространстве. Логично, поэтому, создавать сетевые ресурсы именно на этом диске.
Итак, для начала в папке /usr/home создадим папку, которая и станет нашим сетевым ресурсом. Назов?м е?, к примеру, share1. Далее в секции нашего сетевого ресурса требуется написать
path = /usr/home/share1
и тогда самба будет понимать, что при обращении к сетевому ресурсу bsdShare (в стандартной нотации Windows) необходимо оперировать с папкой /usr/home/share1 на своих локальных дисках.
Если название сетевого ресурса Share вам не кажется информативным, то можно снабдить его комментарием, который также можно будет видеть в сетевом окружении рядом с именем сетевого ресурса. Для такого описательного комментария используется параметр comment. К примеру, вот так:
comment = Моя первая шара.
Далее следует определить тип сетевого ресурса. В самом начале мы говорили, что самба-сервер предоставляет в общее пользование как файлы, так и принтеры. Соответственно, нам необходимо задать, является ли описываемый нами сетевой ресурс принтером, или вс? же папкой с файлами. Для этого существует параметр printable. В нашем случае запись должна выглядеть, как
printable = no
что означает, что данный сетевой ресурс не является принтером. При этом если мы описываем именно папку, то этот параметр вообще можно опустить – по умолчанию он принимается равным именно no. С другой стороны, с ним при чтении конфига самбы сразу видно, о ч?м ид?т речь.
Далее осталось разобраться с правами доступа к сетевому ресурсу. И вот этот вопрос – самый ответственный.
Во-первых, давайте условимся, что для начала мы созда?м сетевой ресурс, куда будут иметь польный доступ все пользователи. Это – самый простой вариант.
Итак, права доступа. В случае самба-сервера права доступа определяются двумя составляющими – правами файловой системы и правами сервера.
Права файловой системы определяются по тр?м направлениям и для тр?х групп пользователей. К направлениям относятся – чтение, запись и исполнение. К группам – владелец, группа, все остальные. Ниже в таблицах дана более подробная расшифровка этих элементов.
Таблица 1. Файловые операции.
Операция
Для файла
Для каталога
Чтение
Чтение содержимого файла.
Просмотр содержимого каталога. Чтение списка файлов и подкаталогов.
Запись
Изменение содержимого файла или удаление файла.
Изменение списка файлов и подкаталогов. В том числе удаление файлов и подкаталогов.
Исполнение
Исполнение содержимого файла, как соответствующего набора команд.
Вход в каталог и вход в подкаталоги каталога.
Таблица 2. Группы пользователей.
Группа
Описание
Владелец
Создатель файла. Атрибуты владельца присваиваются при каждом создании нового файла в файловой системе. Не меняются при изменении другим пользователем и не меняются при копировании файла в пределах одного компьютера.
Группа
Группа пользователей, к которой принадлежит владелец файла.
Прочие
Все пользователи, в том числе и удал?нные, не являющиеся владельцем файла и не принадлежащие к той же группе, что и владелец файла.
Для нас важно понимать, что все удал?нные пользователи, подключающиеся к сетевому ресурсу, будут по умолчанию причислены к группе прочих. Далее, создавая файлы на сетевом ресурсе, эти пользователи будут становиться владельцами созданных ими файлов. Пусть, к примеру, имеем пользователей user1 и user2, зарегистрированных в домене. Предположим, пользователь user1 созда?т в нашей сетевой папке файл file1. Тогда в самой FreeBSD владельцем файла станет пользователь MYDOMAINuser1 и группа его будет (по непонятным мне обстоятельствам) wheel. Соответственно, если с этим файлом должен работать и второй пользователь, то минимальный набор атрибутов этого файла должен быть равным -rw-rw—-, т.е. доступ на запись должен иметь не только владелец этого файла, но и вся группа, к которой он принадлежит. При этом право исполнения файла для нас не важно, т.к. это право да?т нам возможность исполнять файл в среде нашей FreeBSD и не имеет никакого отношения к сетевым пользователям. Лучше, если исполнение будет запрещено – так над?жнее.
С другой стороны, для директорий атрибут исполнения должен быть выставлен, т.к. удал?нные пользователи должны не только видеть эту директорию, но и иметь возможность попасть в не? и дальше по дереву. То есть, атрибуты должны быть равными drwxrwx—.
Я, однако, использую другую схему. Я предпочитаю выставлять атрибуты файловой системы для сетевых ресурсов на максимум и ограничивать доступ на уровне сервера. То есть, в мо?м случае для каталога атрибуты равны drwxrwxrwx и для файла равны -rw-rw-rw-. Чтобы такие атрибуты устанавливались каждый раз при создании нового файла или каталога в сетевой папке, необходимо прописать их самбе в описании сетевого ресурса. Для этого существуют параметры create mask и directory mask. Выглядит это следующим образом:
create mask = 0666
directory mask = 0777
Имеет смысл обратить внимание, что использованы числовые значения атрибутов, подробнее с которыми можно ознакомиться, изучив man chmod.
Права доступа на уровне сервера состоят из двух элементов – права на доступ и права на запись. В нашем случае права на доступ должны быть у всех, равно как и права на запись (если помните, мы созда?м сетевую папку для всех с полным доступом).
Задать право на доступ мы можем двумя путями – либо определить, что этот сетевой ресурс является публичным (как раз то, что нам надо), либо перечислить пользователей, которые должны иметь к нему доступ. В нашем случае публичный ресурс зада?тся параметром
public = yes
Право записи в сетевой ресурс также присваивается либо одним параметром всем, либо пут?м перечисления пользователей, имеющих право на запись. В нашем случае нужен первый вариант и параметр выглядит так:
writable = yes
Отметим в скобках, что вместо этого параметра можно было бы использовать параметр
read only = no
который является синонимом – эффект один и тот же.
В итоге описание нашей сетевой папки должно в полном виде выглядеть так:
[Share]
comment = Моя первая шара.
path = /usr/home/share1
writable = yes
public = yes
create mask = 0777
directory mask = 0777
После добавления этой секции в файл smb.conf необходимо перезапустить самбу, как мы это делали выше. Как только самба перезапустится, можно заглянуть в сетевое окружение и обнаружить на нашем самба-сервере только что созданную нами сетевую папку. Для полноты ощущений попытайтесь что-нибудь туда закачать – если мы нигде не ошиблись, то это у вас получится и можно считать опыт по созданию публичного сетевого ресурса успешным. При этом стоит понимать, что для клиентов под управлением Windows этот сетевой ресурс ничем не отличается от прочих сетевых ресурсов – он может быть совершенно спокойно прицеплен к машине пользователя сетевым диском или, к примеру, включ?н в состав FDS. То есть, это совершенно полноценная сетевая папка.
Создание сетевой папки с ограниченным доступом
Для того, чтобы ограничить доступ к сетевому ресурсу самба-сервера, достаточно понять, чем ограниченный доступ отличается от публичного. По сути, разница лишь в том, что существует список пользователей, которые имеют право подключаться к ресурсу (у публичного ресурса такого списка нет – право дано всем), и список пользователей, которые имеют право изменять содержимое ресурса (попросту записывать в него).
Предположим, имеем в домене пользователей admin, user1 и user2. Предположим также, что мы хотим создать некий сетевой ресурс с именем Restrict, доступ к которому будет только у этих тр?х пользователей. Предположим также, что пользователя user2 необходимо лишить права записи в этом ресурсе, а остальным двоим такое право предоставить. Как это осуществить?
Для начала создадим в каталоге /usr/home подкаталог restrict, который и будет содержать наш сетевой ресурс. Присвоим ему права доступа drwxrwxrwx (как это сделать – man chmod).
Далее в файле smb.conf созда?м секцию под названием [Restrict], которая в точности повторяет созданную нами ранее секцию для публичного сетевого ресурса, отличаясь от не? только названием и пут?м к папке сетевого ресурса:
[Restrict]
comment = Моя закрытая шара.
path = /usr/home/restrict
writable = yes
public = yes
create mask = 0777
directory mask = 0777
Создав вс? это, приступим к внедрению ограничений.
Для начала необходимо из секции убрать параметр public = yes, поскольку этот сетевой ресурс уже не будет публичным. Вместо этого нам необходимо подставить список допущенных к ресурсу пользователей. Для этого служит параметр valid users, который для нашего случая выглядит так:
valid users = MYDOMAINadmin MYDOMAINuser1 MYDOMAINuser2
Обратите внимание, что все пользователи в списке указываются через пробел. Кроме того, пользователь указывается именно как доменный пользователь, о ч?м свидетельствует префикс MYDOMAIN. При этом особое внимание следует обращать на тот факт, что используется именно NetBIOS-имя домена, что пишется оно заглавными буквами и – что особенно важно – между ним и именем пользователя стоит тот самый символ, который указан в параметре winbind separator секции [global] файла smb.conf. В нашем случае это слэш, поскольку мы не задавали специально этот параметр, но если у вас указано, к примеру, winbind separator = +, то список пользователей будет выглядеть, как MYDOMAIN+admin MYDOMAIN+user1 MYDOMAIN+user2.
Далее следует задать список пользователей, имеющих право записи в этот сетевой ресурс. Для этого используется параметр write list, формат которого ничем не отличается от формата параметра valid users и выглядит этот список для нашего примера так:
write list = MYDOMAINadmin MYDOMAINuser1
Заметим в скобках, что пользователь user2 в этот список не включ?н, поелику именно его-то мы и решили лишить права записи в наш сетевой ресурс. Следует также учесть, что давать право записи пользователю, не перечисленному в списке valid users – по меньшей мере бессмысленно, ибо как может записывать в папку тот, кто в не? попросту не допущен.
В итоге секция для нашего сетевого ресурса приобретает следующий вид:
[Restrict]
comment = Моя закрытая шара.
path = /usr/home/restrict
writable = yes
valid users = MYDOMAINadmin MYDOMAINuser1 MYDOMAINuser2
write list = MYDOMAINadmin MYDOMAINuser1
create mask = 0777
directory mask = 0777
Внеся все эти изменения, сохраняем smb.conf и перезапускаем самбу. После успешного перезапуска открываем сетевое окружение и проверяем, какие пользователи могут попасть во вновь созданный сетевой ресурс и какие могут в него что-то записывать.
Дополнительные замечания
Если в консоли нашего сервера ввести команду wbinfo -g, то мы должны получить список групп пользователей для нашего домена. При этом каждая группа в н?м представлена точно в таком же виде, что и пользователи, выводимые по команде wbinfo -u. К примеру, доменная группа managers будет выглядеть, как MYDOMAINmanagers. Соответственно, возникает вопрос – кто нам мешает в списки valid users и write list вместо отдельных пользователей подставлять названия соответствующих групп? Имеет смысл поэкспериментировать с этим и мы вполне можем обнаружить, что доступом можно управлять не только на уровне пользователей домена, но и на уровне доменных групп безопасности.
Второе замечание сводится к отображения файлов и папок на сетевых ресурсах в самой FreeBSD. Для примера приведу кусок листинга одного из каталогов, объявленного в общий доступ через самбу:
drwxrwxrwx 2 **admin wheel 512 Jul 26 09:22 My Music
drwxrwxrwx 2 **admin wheel 512 Jul 26 09:23 My Pictures
drwxrwxrwx 2 **admin wheel 512 Jul 7 06:34 My eBooks
drwxrwxrwx 3 **admin wheel 512 Jul 31 14:09 RECYCLER
drwxrwxrwx 5 **admin wheel 512 Sep 8 10:47 Temp
drwxrwxrwx 2 **admin wheel 1024 Jun 14 14:04 netadm
drwxrwxrwx 2 root wheel 512 Aug 15 06:13 script
-rwxrw-rw- 1 **admin wheel 1043045 Aug 31 11:36 ???????????.ods
drwxrwxrwx 2 **admin wheel 512 Jun 20 13:29 ?????
drwxrwxrwx 5 **admin wheel 512 Apr 7 15:18 ????????????
drwxrwxrwx 2 **admin wheel 512 Sep 8 11:17 ??????????????
drwxrwxrwx 8 **admin wheel 512 Jul 7 06:47 ????????????? ?????
Между тем, вместо вопросительных знаков на клиентской машине я вижу вполне адекватные имена файлов и папок на русском языке. Более того, резервное копирование этого самба-сервера производится встроенными средствами самой FreeBSD, и ей тоже наличие вопросительных знаков вместо им?н файлов и папок не мешает успешно справляться с резервным копированием.
Данный эффект возникает наложением двух причин.
Во-первых, я не локализовал свой сервер под FreeBSD. Задавшись вполне резонным вопросом – а кому нужна локализация этого сервера – я приш?л к выводу, что ровным сч?том никому. Ведь локально в консоли сервера никто не работает, кроме меня. Вс? общение ид?т исключительно через клиентские станции, а вот они в свою очередь прекрасно локализованы. Итак, русских символов в именах файлов (и вообще где бы то ни было) мой сервер не понимает напрочь.
Во-вторых, в системах семейства unix имя файла далеко не служит идентификатором файла. Точнее, имя файла в системах семейства unix – далеко не единственный идентификатор файла и уж точно не главный его идентификатор. А посему FreeBSD, не отображая и не понимая русские символы, тем не менее прекрасно умеет отличить один файл от другого. Таким образом, наличие этого огромного количества вопросительных знаков может составить проблему только в одном случае – если вы планируете работать с файлами сетевых ресурсов самбы в консоли сервера. У меня до сих пор такой необходимости не возникало и, честно говоря, я не представляю себе, при каких условиях она могла бы возникнуть.
В заключение
По традиции мне следовало бы сказать, что по описанной здесь схеме построены уже два самба-сервера и что они прекрасно работают. В принципе, сие заявление не противоречит истине и я под ним подпишусь. Тем не менее, самба – инструмент гораздо более гибкий и, посему, гораздо более сложный в настройке, нежели может показаться из этой статьи. Как минимум потому, что работает не только с доменами и не только в виде файлового сервера. А это, в свою очередь, обозначает, что кто-то не сможет построить боевой самба-сервер, следуя моим инструкциям. Но я тв?рдо уверен, что если соблюдать первую и главную заповедь админа – вс?, что компьютер сч?л нужным вывести на экран, выведено не просто так и имеет глубочайший смысл – можно многого добиться и без всяческих инструкций и статей. Но забывать о второй, не менее главной заповеди, тоже не стоит – RTFM.
Статья скопипастина отсюда)
