Создаём интегрированный в Active Directory файл-сервер на базе Samba во FreeBSD::Журнал СА 2.2007
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
20.12.2019г.
Просмотров: 5101
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 6343
Комментарии: 0
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 7599
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 7922
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 6979
Комментарии: 0
Django 2 в примерах

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Создаём интегрированный в Active Directory файл-сервер на базе Samba во FreeBSD

Архив номеров / 2007 / Выпуск №2 (51) / Создаём интегрированный в Active Directory файл-сервер на базе Samba во FreeBSD

Рубрика: Администрирование /  Продукты и решения

Алексей Бережной

Создаём интегрированный в Active Directory файл-сервер на базе Samba во FreeBSD

«Как поступить со старой серверной техникой?» – такой вопрос возникает во многих организациях. На базе сервера, давно устаревшего по критериям Microsoft, вы можете сделать вполне приличный файл-сервер и сервер печати, используя пакет Samba3.x и операционную систему FreeBSD 6.x.

Лежал без дела в серверной старый сервер с двухпроцессорной материнской платой, двумя процессорами Pentium III 450 МГц «на борту» и SCSI-адаптером (80 Мб/с, но все же «скайзи»!), правда, без поддержки функций RAID-контроллера. К моей радости, к материнской плате подошли обычные Non-ECC (то есть без контроля четности) SDRAM-модули памяти: 4 слота по 256 Мб – всего 1 Гб ОЗУ. А это уже не так плохо. К тому же после апгрейда других серверов у меня скопилось некоторое количество SCSI-винчестеров: шесть дисков (три пары по два одинаковых) размером 18 Гб и два диска размером по 9 Гб.

А тут на основном файловом сервере стало заканчиваться свободное место. Возникло решение: не так часто используемые файлы, такие как юридическая справочная база данных, коллекцию драйверов и другие подобные «пожиратели пространства», перенести на отдельный файл-сервер.

Другая проблема возникла с необходимостью использования старинных программ, написанных для DOS-совместимых операционных систем. Как известно, многие из них не работают с сетевыми печатающими устройствами. В лучшем случае от них можно добиться корректного вывода на LPT-порт из Windows 2000/XP. А посему просто необходим сервер печати, позволяющий подключать сетевые принтеры на порт LPT командой «net use».

Готовим к инсталляции Samba

Выбор операционной системы и планирование конфигурации сервера.

В качестве операционной системы я выбрал FreeBSD. Подкупила низкая требовательность к ресурсам вкупе с высокой стабильностью и хорошо продуманной системой инсталляции ПО через коллекцию портов. К тому же она бесплатна, а покупку дополнительной лицензии, скажем, Microsoft Windows 2003 Server для «файлопомойки» вряд ли кто-то одобрит. Версия OS также определилась сразу – 6.1, как самая свежая на тот момент. Ну а раз решено ставить UNIX-систему в качестве файлового сервера для клиентов сети Microsoft Windows, да еще интегрированного в структуру каталога Active Directory, то ясно, что без пакета программ Samba не обойтись.

Поскольку винчестеры, которые предполагалось использовать, были, что называется, «видавшие виды», нужно было задуматься о структуре дискового массива. Приняв во внимание тот факт, что купить аналогичные 18 Гб SCSI-винчестеры на замену вышедшим из строя не представляется возможным, я решил организовать три небольших массива RAID1 (прямое зеркалирование) по 18 Гб каждый для хранения данных. В случае выхода одного из зеркальных дисков из строя это позволит сделать резервную копию данных. А заменять в этом случае лучше сразу оба зеркальных диска, не дожидаясь выхода из строя второго накопителя. Поскольку встроенной аппаратной поддержки RAID в данной материнской плате не наблюдалось, требовалось сделать программный RAID средствами, доступными в ОС FreeBSD 6.1

Также, несмотря на отсутствие на данный момент необходимости, решил зарезервировать возможность применения дисковых квот на будущее.

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

Таким образом, была запланирована следующая организация дискового пространства (см. таблицу).

Организация дискового пространства

Объем

Обозначение устройства

во FreeBSD

Примечание

9 Гб

da0

Диск с установленной системой

9 Гб

da1

Файл подкачки + место для хранения

резервной копии конфигурационных файлов

18 Гб

da2

Первый дисковый массив RAID1

18 Гб

da3

 

18 Гб

da4

Второй дисковый массив RAID1

18 Гб

da5

 

18 Гб

da6

Третий дисковый массив RAID1

18 Гб

da7

 

Начало установки

Наверное, не имеет смысла подробно рассказывать, как устанавливать саму операционную систему и как размечать первые два диска. Со всем этим прекрасно справляется программа /usr/sbin/sysinstall. Отмечу только, что, так как мы будем строить на базе оставшихся дисков RAID-массивы, нет смысла выполнять их разметку на этапе установки системы.

После установки операционной системы необходимо сконфигурировать сетевые интерфейсы. Этот процесс настройки был описан в моей статье: «Настраиваем шлюз в Интернет на базе FreeBSD», вышедшей в №12 за 2006 г. Кроме того, с этой задачей прекрасно справится все та же программа sysinstall. После всех настроек наш сервер имеет имя fs, сетевой адрес 192.168.1.3, маску подсети 255.255.255.0. Имя домена: mydomain.ru.

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

Сборка ядра с поддержкой двухпроцессорной конфигурации и дисковых квот

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

Переходим в каталог с конфигурационными файлами для процессоров с архитектурой i386:

fs# cd /sys/i386/conf

Делаем копию файла GENERIC:

fs# cp GENERIC   fs

открываем файл на редактирование и добавляем следующие строки:

fs# vi fs

Опцию поддержки двухпроцессорной архитектуры:

options          SMP

Опцию поддержки дисковых квот:

options          QUOTA

Изменяем параметр ident (это поможет в дальнейшем использовать команду «uname -i» для в качестве «шпаргалки» при определение наличия мультипроцессорной поддержки в ядре):

ident                   SMP-GENERIC

Создаем компиляционный каталог:

fs# config fs

Эта команда создаст директорию /usr/src/sys/compile/fs и поместит туда файлы, необходимые для компиляции ядра.

Сохраняем изменения, закрываем файл, переходим в нужный каталог:

fs# cd ../compile/fs

и запускаем компиляцию ядра:

fs# make depend && make && make install

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

Вернувшись, перезагружаем систему и смотрим, нормально ли работает только что собранное ядро:

fs# reboot

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

fs# portsnap fetch && portsnap extract && portsnap update

Создание дисковых массивов

В современных версиях FreeBSD есть три способа создания RAID1-массивов:

  • Старый добрый ccd, издавна присутствовавший во FreeBSD, но показавшийся, на мой взгляд, довольно сложным для решения простейших задач.
  • Неплохо отработавший во FreeBSD 4-й ветки vinum. Современная интерпретация vinum носит название gvinum, чтобы подчеркнуть, что работа современного vinum строится на базе другого продукта: GEOM. Кроме того, сам vinum имеет непрозрачный для понимания конфигурационный файл.
  • И наконец, сам GEOM – новый программный продукт, имеющий хорошую репутацию и прекрасно работающий в 5-й и 6-й ветках FreeBSD.

Я выбрал GEOM за его простоту и стабильность. Мы будем использовать утилиту gmirror из пакета GEOM для создания зеркальных массивов. У нас самый простой случай, так как мы объединяем свободные от данных, идентичные винчестеры в простой RAID1:

fs# gmirror label -v gm0 da2 da3

fs# gmirror label -v gm1 da4 da5

fs# gmirror label -v gm2 da6 da7

Итак, у нас созданы на дисках da2, da3, da4, da5, da6, da7 соответствующие метки, указывающие на их принадлежность к тому или иному дисковому массиву.

Необходимо включить поддержку gmirror. Добавляем в /boot/loader.conf функцию geom_mirror_load=YES и перезагружаемся.

fs# echo geom_mirror_load="YES" >> /boot/loader.conf

После перезагрузки проверяем наличие вновь созданных псевдоустройств, представляющих собой дисковые массивы:

fs# ls /dev/mirror

gm0     gm1     gm2

Теперь можно создать файловые системы на этих разделах:

fs# newfs /dev/mirror/gm0

fs# newfs /dev/mirror/gm1

fs# newfs /dev/mirror/gm2

Поддержка ACL

Теперь еще одна интересная деталь. FreeBSD, как и все стандартные UNIX-системы, имеет стандартную структуру атрибутов. Что это означает? Это значит, что для одного файла, каталога или другого ресурса можно задать следующие права: права для владельца, права для группы (причем владелец файла необязательно должен принадлежать этой группе) и права для всех остальных. Но представьте себе ситуацию, когда над одним файлом работают сразу несколько пользователей, к тому же совершенно из разных групп. Как поступить в этом случае? Выход есть – создать еще одну дополнительную группу, в которую бы входили все данные пользователи, и разрешить этой группе доступ к ресурсу. Вроде бы все ничего, только в стандартных случаях в UNIX существует еще одно ограничение: пользователь может входить не более чем в 16 групп (включая группу по умолчанию). А если пользователю необходимо периодически работать над 17 аналогичными ресурсами? Вот тут на помощь приходит поддержка Access Control Lists (сокращенно ACL), проще говоря, – списков доступа. Это позволяет разрешить доступ пользователям из различных групп к одному ресурсу, не включая этих пользователей в дополнительную группу, так, как это реализовано в операционных системах Microsoft Windows и Novell Netware.

Помимо указанной проблемы, существует и другая причина применения ACL. Это делегирование полномочий. В нашем случае сотрудник, ответственный за поддержание системы в отсутствие системного администратора, даже не обладая знаниями по операционным системам семейства UNIX, сможет сам назначать права, используя обычный инструментарий (в данном случае – Проводник Microsoft Windows).

Поддержка ACL по умолчанию включена в ядро GENERIC FreeBSD 6.1. Поскольку при построении нашего ядра мы ориентировались на ядро GENERIC, нам нужно только включить поддержку ACL для выбранных файловых систем. У нас самый простой случай, потому что мы включаем поддержку ACL для несмонтированных файловых систем, на которых нет данных. Итак, приступим.

Вводим команду:

fs# /sbin/tunefs -a enable /dev/mirror/gm0

На что система нам выдаст ответ:

tunefs: ACLs set

Аналогично:

fs# /sbin/tunefs -a enable /dev/mirror/gm1

tunefs: ACLs set

fs# /sbin/tunefs -a enable /dev/mirror/gm2

tunefs: ACLs set

Все, теперь можно смело монтировать наши созданные файловые системы.

Монтирование и проверка созданных разделов

Создаем каталоги для монтирования новых файловых систем (в моем случае это были каталоги: /vol0, /vol1, /vol2):

fs# mkdir /vol0

fs# mkdir /vol1

fs# mkdir /vol2

И монтируем файловые системы наших RAID-массивов:

fs# mount /dev/mirror/gm0 /vol0

fs# mount /dev/mirror/gm1 /vol1

fs# mount /dev/mirror/gm2 /vol2

Проверяем:

fs# mount

/dev/da0s1a on / (ufs, local, soft-updates)

devfs on /dev (devfs, local)

/dev/da1s1d on /add (ufs, local, soft-updates)

/dev/mirror/gm1 on /vol1 (ufs, local, acls)

/dev/mirror/gm0 on /vol0 (ufs, local, acls)

/dev/mirror/gm2 on /vol2 (ufs, local, acls)

Запись «acls» показывает, что для указанных файловых систем включена поддержка ACL.

Добавляем нужные записи в /etc/fstab:

fs# vi /etc/fstab

# Device      Mountpoint    FStype  Options   Dump  Pass#

/dev/da1s1b      none       swap    sw         0     0

/dev/da0s1a      /          ufs     rw         1     1

/dev/da1s1d      /add       ufs     rw         2     2

/dev/acd0        /cdrom     cd9660  ro,noauto  0     0

# GMIRROR volume

/dev/mirror/gm0  /vol0      ufs     rw         1     2

/dev/mirror/gm1  /vol1      ufs     rw         1     2

/dev/mirror/gm2  /vol2      ufs     rw         1     2

Установка Kerberos, интеграция с Active Directory

В Active Directory для обеспечения единой системы безопасности используется протокол Kerberos. Во FreeBSD для его поддержки нужно установить программу heimdal:

fs# cd /usr/ports/security/heimdal

fs# make install clean

Создаем файл /etc/krb5.conf:

fs# vi /etc/krb5.conf

И вносим туда следующие строки:

[libdefaults]

        default_realm = MYDOMAIN.RU

        clockskew = 300

        v4_instance_resolve = false

        v4_name_convert = {

                host = {

                        rcmd = host

                        ftp = ftp

                }

                plain = {

                        something = something-else

                }

        }

[realms]

        MYDOMAIN.RU = {

                kdc = pdc.mydomain.ru

                admin_server = pdc.mydomain.ru

                default_domain = mydomain.ru

        }

        OTHER.REALM = {

                v4_instance_convert = {

                        kerberos = kerberos

                        computer = pdc.mydomain.ru

                }

        }

[domain_realm]

        .mydomain.ru = MYDOMAIN.RU

Стоит обратить особое внимание на строки: default_realm = MYDOMAIN.RU и default_domain = mydomain.ru. Они необходимы для описания домена, который подразумевается по умолчанию, когда пользователь не указывает его имя в явном виде. Синхронизируем время с контроллером домена:

fs# ntpdate 192.168.1.6

Я предпочитаю, чтобы время синхронизировалось при каждом старте системы (мало ли из-за чего мог перезагрузиться сервер, например, из-за длительного отключения питания), для этого добавляем в файл /etc/rc.local строку с командой синхронизации. Следующая команда добавляет команду ntpdate в стартовый файл запуска /etc/rc.local:

fs# echo ntpdate 192.168.1.6 >> /etc/rc.local

Пробуем получить билетик от Kerberos:

fs# kinit -p Administrator

Ответ системы в положительном случае:

Administrator@MYDOMAIN.RU's password:

После ввода правильного пароля система выдаст ответ:

kinit: NOTICE: ticket renewable lifetime is 1 week

Если введен неверный пароль, система выдаст сообщение:

kinit: krb5_get_init_creds: Preauthentication failed

Если возникли какие-либо дополнительные проблемы, нужно более тщательно проверить конфигурационный файл /etc/krb5.conf. С приведенными здесь настройками у меня в сети данная схема работает. Если возникли дополнительные трудности, рекомендую книгу «Active Directory для Windows Server 2003. Справочник администратора», авторы Стен Реймер и Майк Малкер, СП ЭКОМ. Москва, 2004 г.

Проверим состояние соединения;

fs# klist

Credentials cache: FILE:/tmp/krb5cc_0

 Principal: berezhnoy_a@MYDOMAIN.RU

 

 Issued Expires Principal

Jan 11 17:03:04 Jan 12 03:03:04 krbtgt/MYDOMAIN.RU@MYDOMAIN.RU

Все. Поддержка Kerberos включена.

Настройка файла переключения служб /etc/nsswitch.conf

Я не буду подробно описывать для чего нужен файл nsswitch.conf и какие опции он содержит. Обо всем этом подробнейшим образом можно узнать посредством man nsswitch.conf. Из файла /etc/nsswitch.conf удаляем все, оставим только следующие строки:

passwd: files winbind

group: files winbind

hosts: files dns

Теперь, когда выполнены все необходимые подготовительные этапы, можно приступать к установке и настройке Samba-сервера.

Установка Samba

И теперь нам осталось последнее и самое важное: установить пакет программ Samba (вместе с системой печати CUPS) и настроить его. Так как необходима интеграция с Active Directory, мы используем Samba версии 3x (в нашем случае 3.0.23d).

Устанавливаем Samba из портов:

fs# cd /usr/ports/net/samba3

fs# make install clean

Появится окно с предложением выбрать нужные опции, которые будет поддерживать наш Samba-сервер.

Я отметил следующие опции (некоторые модули, приведенные без комментариев, включены с расчетом «на будущее», чтобы не пересобирать каждый раз Samba):

[X] LDAP With LDAP support       # Включаем поддержку LDAP

[X] ADS With Active Directory support     # Необходимо для интеграции с Active Directory

[X] CUPS With CUPS printing support     # Система печати

[X] WINBIND With WinBIND support      # Необходимо для интеграции с Active Directory

[X] ACL_SUPPORT With ACL support      # Поддержка ACL

[X] FAM_SUPPORT With File Alteration Monitor

[X] SYSLOG With Syslog support           # Поддержка Syslog

[X] QUOTAS With Disk quota support      # Поддержка квот

[X] UTMP With UTMP accounting support

[X] MSDFS With MSDFS support            # Поддержка Microsoft Distributed File Systems

[X] PAM_SMBPASS With PAM authentication vs passdb backends

[ ] CLUSTER With experimental cluster support

[ ] EXP_MODULES With experimental modules

[X] POPT With system-wide POPT library

[ ] MAX_DEBUG With maximum debuging

После некоторого этапа компиляции появится окно с выбором опций для сборки CUPS. Опять же с тем же расчетом «на будущее» я отметил все опции.

После сборки необходимо отредактировать файл /etc/rc.conf на предмет запуска необходимых «демонов» – резидентных программ.

Открываем файл /etc/rc.conf:

fs# vi /etc/rc.conf

И вносим туда необходимые строки:

cupsd_enable="YES"  # Unix Pint System

inetd_enable="YES"  # Super Daemon for call some services

nmbd_enable="YES"   # SMB client for Unix (need for WINS)

smbd_enable="YES"   # SMB server for Unix

winbindd_enable="YES"  # WinBIND for Windows autorization

После чего перезагружаемся и проверяем запущенные сервисы:

fs# ps aux | grep inetd

root    533  0.0  0.1  1428   952  ??  Is   Fri04PM   0:00.06 /usr/sbin/inetd -wW -C 60

fs# ps aux | grep cupsd

root    418  0.0  0.2  4184  2168  ??  Is   Fri04PM   0:04.75 /usr/local/sbin/cupsd

fs# ps aux | grep nmbd

root    437  0.0  0.2  5544  2128  ??  Ss   Fri04PM   0:30.16 /usr/local/sbin/nmbd -D -s /usr/local/etc/smb.conf

fs# ps aux | grep smbd

root    441  0.0  0.4  9588  4120  ??  Is   Fri04PM   0:01.19 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf

fs# ps aux | grep winbindd

root    446  0.0  0.3  7036  2788  ??  Ss   Fri04PM   0:11.49 /usr/local/sbin/winbindd -s /usr/local/etc/smb.conf

Настройка системы печати CUPS

Весь этап настройки CUPS сводится к редактированию файла /usr/local/etc/cupsd.conf:

fs# vi /usr/local/etc/cupsd.conf

Привожу пример своего файла cupsd.conf. Красным цветом выделены необходимые изменения:

#

# "$Id: cupsd.conf.in 5454 2006-04-23 21:46:38Z mike $"

#

#   Sample configuration file for the Common UNIX Printing

#   System (CUPS) scheduler. See "man cupsd.conf" for

#   a complete description of this file.

#

# Log general information in error_log - change "info"

# to "debug" for troubleshooting...

LogLevel info

# Administrator user group...

SystemGroup wheel

# Only listen for connections from the local machine.

Listen localhost:631

Listen 192.168.1.3:631

Listen /var/run/cups.sock

# Show shared printers on the local network.

Browsing On

BrowseOrder allow,deny

BrowseAllow @LOCAL

# Default authentication type, when authentication

# is required...

DefaultAuthType Basic

# Restrict access to the server...

<Location />

  Order deny,allow

  Deny From All

  Allow localhost

  Allow 192.168.1.*

</Location>

# Restrict access to the admin pages...

<Location /admin>

    AuthType Basic

    AuthClass System

  Encryption Required

  Order deny,allow

  Deny From All

  Allow localhost

  Allow 192.168.1.*

</Location>

# Restrict access to configuration files...

<Location /admin/conf>

  AuthType Basic

  Require user @SYSTEM

  Order deny,allow

  Deny From All

  Allow localhost

  Allow 192.168.1.*

</Location>

# Set the default printer/job policies...

<Policy default>

  # Job-related operations must be done by the owner or

  # an adminstrator...

  <Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription Cancel-Subscription

Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job CUPS-Move-Job>

    Require user @OWNER @SYSTEM

    Order deny,allow

  </Limit>

  # All administration operations require an adminstrator

  # to authenticate...

  <Limit Pause-Printer Resume-Printer Set-Printer-Attributes Enable-Printer Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Job

s Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer Startup-Printer Promote-Job Schedule-Job-After CUPS-Add-Printer CUPS-Delete-Printer CUP

S-Add-Class CUPS-Delete-Class CUPS-Accept-Jobs CUPS-Reject-Jobs CUPS-Set-Default>

    AuthType Basic

    Require user @SYSTEM

    Order deny,allow

  </Limit>

  # Only the owner or an administrator can cancel

  # or authenticate a job...

  <Limit Cancel-Job CUPS-Authenticate-Job>

    Require user @OWNER @SYSTEM

    Order deny,allow

  </Limit>

  <Limit All>

    Order deny,allow

  </Limit>

</Policy>

#

# End of "$Id: cupsd.conf.in 5454 2006-04-23 21:46:38Z

# mike $".

#

Коротко прокомментируем:

Строка:

Listen 192.168.1.3:631

указывает, на каком интерфейсе и порту сервер CUPS будет ожидать соединения с интернет-браузером для настройки параметров.

Строки:

  Order deny,allow

  Deny From All

  Allow localhost

  Allow 192.168.1.*

разрешают доступ к серверу для настройки только с внутренней подсети 192.168.1.*.

Строка:

Encryption Required

указывает, что для доступа к веб-интерфейсу управления CUPS будет использоваться шифрованный протокол https.

Перезапускаем CUPS:

fs# /usr/local/etc/rc.d/cupsd restart

Для того чтобы CUPS стартовал автоматически при каждом запуске системы, мы уже добавили строку «inetd_enable=”YES”» в файл /etc/rc.conf.

Далее посредством интернет-браузера подключаемся к адресу: https://192.168.1.3:631. Система предложит принять сертификат. Соглашаемся.

В разделе «Администрирование» сервер будет запрашивать пароль. Вводим логин root и соответствующий пароль. Все, можно подключать и настраивать принтеры (см. рис. 1,  2).

Рисунок 1. Так выглядит раздел «Администрирование» в веб-консоли для настройки сервера CUPS

Рисунок 1. Так выглядит раздел «Администрирование» в веб-консоли для настройки сервера CUPS

Рисунок 2. Консоль управления подключенным принтером

Рисунок 2. Консоль управления подключенным принтером

Возможные проблемы и пути их разрешения:

  1. На файерволе (если вы все же решите использовать файервол на этом серврере и/или на рабочей станции) закрыт TCP-порт 631. Соответственно нужно или открыть этот порт или использовать другой.
  2. Используется прокси-сервер, который не позволяет интернет-браузеру нормально работать c веб-интерфейсом CUPS. Нужно или отключать прокси или указать в настройках интернет-браузера – не использовать прокси-сервер для соединения с данным сервером.
  3. Не запущен «демон» cupsd. Проверить это можно командой:

fs# ps aux | grep cupsd

В ответ вы увидите сообщение:

root    418  0.0  0.3  4120  2616  ??  Ss   Fri01AM   0:06.13

/usr/local/sbin/cupsd

Если «демон» не запущен, сообщение выведено не будет. Запустить cupsd можно следующим образом:

fs# /usr/local/etc/rc.d/cupsd start

после чего нужно проверить наличие строчки «cupsd_enable= ”YES”» в файле /etc/rc.conf.

Настройка файлового сервера

Итак, наступил решающий момент. Мы настраиваем наш конфигурационный файл Samba – smb.conf.

«Классический» метод настройки данного сервиса заключается в копировании файла /usr/local/etc/smb.conf.sample в /usr/local/etc/smb.conf с последующим редактированием smb.conf в текстовом редакторе:

fs# cp  usr/local/etc/smb.conf.sample  usr/local/etc/smb.conf

fs# vi usr/local/etc/smb.conf

Но поскольку мы решили идти по пути делегирования полномочий, то все настройки будем выполнять через веб-консоль настройки Samba – SWAT. Дополнительный бонус, который мы получаем в этом случае, – наличие прекрасной системы помощи при конфигурировании Samba-сервера.

Программа SWAT вызывается посредством супердемона inetd. Мы уже добавили строку «inetd_enable=”YES”» в файл /etc/rc.conf для его автоматического запуска.

Поэтому всего лишь остается открыть для редактирования конфигурационный файл /etc/inetd.conf:

fs# vi /etc/inetd.conf

и раскомментировать в нем следующую строку:

swat    stream  tcp     nowait/400    root   /usr/local/sbin/swat     swat

после чего перезапустить «демон» inetd:

fs# killall -1 inetd

Проверяем доступность веб-консоли по 901 порту:

fs# sockstat | grep 901

root    inetd    533   5  tcp4   *:901    *:*

После чего вводим в строке интернет-браузера адрес http://192.168.1.3:901, в ответ на запрос пароля вводим логин и пароль root. Все, мы подключились к серверу Samba через веб-консоль программы SWAT.

Нас интересуют в первую очередь вкладки «GLOBALS» и «WIZARD». Управляя параметрами, приведенными в них, необходимо создать соответствующий конфигурационный файл. Изменения сохраняются при нажатии кнопки «Commit». Проконтролировать его содержание можно во вкладке «VIEW» (см. рис. 3, 4, 5).

Рисунок 3. Так выглядит вкладка «GLOBALS» для задания общих параметров

Рисунок 3. Так выглядит вкладка «GLOBALS» для задания общих параметров

Рисунок 4. Так выглядит вкладка «SHARES», служащая для конфигурации общих папок

Рисунок 4. Так выглядит вкладка «SHARES», служащая для конфигурации общих папок

Приведу пример основной части моего конфигурационного файла:

# Samba config file created using SWAT

# from 192.168.1.32 (192.168.1.32)

# Date: 2007/01/12 15:19:15

[global]

    dos charset = cp866

    unix charset = koi8-r

    display charset = cp866

    workgroup = ARS

    realm = MYDOMAIN.RU

    server string = Samba Server

    security = DOMAIN

    auth methods = winbind

    map to guest = Bad User

    client NTLMv2 auth = Yes

    client lanman auth = No

    client plaintext auth = No

    log file = /var/log/samba/log.%m

    max log size = 50

    client signing = Yes

    preferred master = No

    local master = No

    domain master = No

    dns proxy = No

    wins server = 192.168.1.1

    ldap ssl = no

    usershare allow guests = Yes

    idmap uid = 10000-20000

    idmap gid = 10000-20000

    winbind use default domain = Yes

    printer admin = root

    acl group control = Yes

    hosts allow = 192.168.1., 127.

    map acl inherit = Yes

    case sensitive = No

Процесс создания конфигурационного файла при помощи SWAT несколько необычен, но несложен.

В случае возникновения проблем с подключением к SWAT, как и в случае с CUPS, нужно проверить доступность сервера по соответствующему порту (port 901), возможно, настроить браузер, чтобы тот не использовал прокси для адреса файл-сервера, проверить запуск супердемона inetd.

После создания нужной конфигурации переходим на вкладку «STATUS» и при помощи кнопки «Restart All» перезапускаем «демоны», входящие в пакет Samba 3x (см. рис. 5).

Рисунок 5. Вкладка «STATUS», где нужно перезапустить «демоны» пакета Samba

Рисунок 5. Вкладка «STATUS», где нужно перезапустить «демоны» пакета Samba

Включаем наш сервер в домен:

fs# net ads join -U _Domain_Administrator_%_password_of_domain_admin_

Joined 'FS' to realm 'MYDOMAIN.RU'

Проверим правильность работы WinBIND:

fs# wbinfo -t

Система должна ответить:

checking the trust secret via RPC calls succeeded

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

Просмотрим список пользователей и компьютеров Active Directory при помощи команды:

fs# wbinfo -u

и список групп командой:

fs# wbinfo -g

Последнее, что мы должны посмотреть, – это аутентификацию в домене:

fs# wbinfo -a _имя_юзера_%_пароль_юзера_

При ответе:

plaintext password authentification succeeded

challenge/response password authentification succeeded

можно быть уверенным – аутентификация в Active Directory выполнена успешно.

Создание общих ресурсов

Поскольку сервер находится внутри периметра локальной офисной сети, куда закрыт доступ всем, кроме пользователей, находящихся внутри офиса, я решил организовать общие ресурсы следующим образом: создать общие папки \\fs\vol0, \\fs\vol1, \\fs\vol2, сделать их скрытыми, разрешив при этом гостевой доступ. Внутри этих папок создать подкаталоги, а уже на них средствами Windows установить ограниченные права. А пользователям подключать сетевые диски командой net use, например:

c:\> net use h: \\fs\vol0\_имя_каталога_

Что же касается общих принтеров, то с ними вообще не должно возникнуть проблем при подключении командой типа:

c:\> net use lpt2: \\fs\_printer_name_

Используя вкладки «SHARES» и «PRINTERS» управляющей веб-консоли SWAT, добавляем к своему конфигурационному файлу следующие опции:

[printers]

    comment = All Printers

    path = /var/spool/samba

    printable = Yes

    browseable = No

[vol0]

    comment = vol0

    path = /vol0

    read only = No

    guest ok = Yes

    hosts allow =

    browseable = No

[vol1]

    path = /vol1

    read only = No

    guest ok = Yes

    hosts allow =

    browseable = No

[vol2]

    path = /vol2

    read only = No

    guest ok = Yes

    hosts allow =

    available = No

[hp_LaserJet_1320_series_192.168.1.15]

    comment = hp LaserJet 1320 series

    path = /var/spool/samba

    read only = No

    guest ok = Yes

    printable = Yes

    printer name = hp_LaserJet_1320_series_192.168.1.15

    oplocks = No

    share modes = No

И снова перезапускаем «демоны» из вкладки «STATUS». Где vol0, vol1, vol2 – необходимые общие ресурсы, а hp_LaserJet_1320_series_192.168.1.15 – общий принтер, созданный для примера.

Все, теперь можно вводить в адресной строке Проводника Windows необходимое значение, скажем, \\fs\vol0\, создавать каталоги, назначать права и подключать их как сетевые диски (см. рис. 6).

Рисунок 6. Создаем каталоги и назначаем права обычными средствами Windows

Рисунок 6. Создаем каталоги и назначаем права обычными средствами Windows

Заключение

Идея использования операционных систем семейства UNIX в сети Microsoft Windows, пусть даже на вспомогательных ролях, всегда вызывала некоторое недоверие скептиков. Однако простота реализации и, главное, возможность делегирования полномочий, описанные в данной статье, способны пошатнуть устоявшееся мнение о трудности совместного использования UNIX- и Windows-платформ. Наличие таких удобных инструментов управления, как веб-консоли CUPS и SWAT, ACL и возможность управлять правами доступа из обычного Проводника Windows делают реальным администрирование сервера, даже не имея серьезного опыта работы с UNIX-подобными операционными системами.

  1. «Using Samba» By Jay Ts, Robert Eckstein, David Collier-Brown 2nd Edition, February 2003 O’Reilly & Associates, ISBN: 0-596-00256-4 – http://us3.samba.org/samba/docs/using_samba/toc.html.
  2. «SAMBA с авторизацией в AD и поддержкой NT ACL» – http://www.lissyara.su.

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru