 |
|
|
|
Создаём интегрированный в 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-гигабайтном диске решил зарезервировать для резервного копирования конфигурационных файлов. Таким образом, была запланирована следующая организация дискового пространства (см. таблицу). Организация дискового пространства
Начало установки Наверное, не имеет смысла подробно рассказывать, как устанавливать саму операционную систему и как размечать первые два диска. Со всем этим прекрасно справляется программа /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-массивов:
Я выбрал 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# 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 На что система нам выдаст ответ:
Аналогично:
Все, теперь можно смело монтировать наши созданные файловые системы. Монтирование и проверка созданных разделов Создаем каталоги для монтирования новых файловых систем (в моем случае это были каталоги: /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 Проверяем:
Запись «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 Ответ системы в положительном случае:
После ввода правильного пароля система выдаст ответ:
Если введен неверный пароль, система выдаст сообщение:
Если возникли какие-либо дополнительные проблемы, нужно более тщательно проверить конфигурационный файл /etc/krb5.conf. С приведенными здесь настройками у меня в сети данная схема работает. Если возникли дополнительные трудности, рекомендую книгу «Active Directory для Windows Server 2003. Справочник администратора», авторы Стен Реймер и Майк Малкер, СП ЭКОМ. Москва, 2004 г. Проверим состояние соединения;
Все. Поддержка 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):
После некоторого этапа компиляции появится окно с выбором опций для сборки 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 После чего перезагружаемся и проверяем запущенные сервисы:
Настройка системы печати 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
Рисунок 2. Консоль управления подключенным принтером Возможные проблемы и пути их разрешения:
fs# ps aux | grep 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 порту:
После чего вводим в строке интернет-браузера адрес http://192.168.1.3:901, в ответ на запрос пароля вводим логин и пароль root. Все, мы подключились к серверу Samba через веб-консоль программы SWAT. Нас интересуют в первую очередь вкладки «GLOBALS» и «WIZARD». Управляя параметрами, приведенными в них, необходимо создать соответствующий конфигурационный файл. Изменения сохраняются при нажатии кнопки «Commit». Проконтролировать его содержание можно во вкладке «VIEW» (см. рис. 3, 4, 5).
Рисунок 3. Так выглядит вкладка «GLOBALS» для задания общих параметров
Рисунок 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 Включаем наш сервер в домен:
Проверим правильность работы WinBIND: fs# wbinfo -t Система должна ответить:
Если мы получили данное сообщение, это означает, что учетная запись компьютера в Active Directory создана успешно. Просмотрим список пользователей и компьютеров Active Directory при помощи команды: fs# wbinfo -u и список групп командой: fs# wbinfo -g Последнее, что мы должны посмотреть, – это аутентификацию в домене: fs# wbinfo -a _имя_юзера_%_пароль_юзера_ При ответе:
можно быть уверенным – аутентификация в 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 Заключение Идея использования операционных систем семейства UNIX в сети Microsoft Windows, пусть даже на вспомогательных ролях, всегда вызывала некоторое недоверие скептиков. Однако простота реализации и, главное, возможность делегирования полномочий, описанные в данной статье, способны пошатнуть устоявшееся мнение о трудности совместного использования UNIX- и Windows-платформ. Наличие таких удобных инструментов управления, как веб-консоли CUPS и SWAT, ACL и возможность управлять правами доступа из обычного Проводника Windows делают реальным администрирование сервера, даже не имея серьезного опыта работы с UNIX-подобными операционными системами.
|
Алексей Бережной
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
