 |
|
|
|
Настраиваем ASPLinux 7.3 Server Edition
Настраиваем ASPLinux 7.3 Server Edition Желание познакомиться с каким-либо из отечественных дистрибутивов Linux зрело у меня уже довольно давно, а тут еще приятель похвастался, что раздобыл ASPLinux 7.3 Server Edition. Поэтому когда знакомые попросили помочь им с установкой и настройкой сервера для подключения локальной сети к Интернету и хранения общих файлов, особых сомнений не возникло. Нехорошо, конечно, ставить эксперименты на пользователях, но соблазн был велик. Поэтому первый из двух входящих в комплект CD-дисков был помещен на подставку для кофе, и инсталляция началась. Размечать жесткий диск оказалось даже приятно. Графическая утилита позволяет легко и наглядно выбирать тип и размер файловой системы, а также задавать точку монтирования. Еще порадовало, что система без проблем распознала наличие на материнской плате 815-го чипсета и интегрированной видеокарты. Правда, установить для монитора режим 800х600 с частотой 85 Гц не удалось, пришлось ограничиться 60 Гц. Но на фоне воспоминаний о том, что выводилось на экран после установки RedHat 6.2 на компьютер с 810-м чипсетом, с этим легко можно было смириться. Также без проблем сами установились драйверы для сетевых карт Compex и Davicom, причем о существовании второй фирмы-изготовителя я до этого момента даже не слышал. Затем из предложенного списка, где среди прочих фигурировал пункт «сервер для работы с 1С» я выбрал «сервер для рабочей группы», потом наставил галочек против интересующих меня пакетов, согласился с предложением доставить неотмеченные, но необходимые для работы выделенных, компоненты, понаблюдал за их копированием и с удивлением понял, что процесс инсталляции в целом занял совсем немного времени. Единственное, что не удалось сделать – создать загрузочную дискету. После нескольких попыток, заканчивающихся сообщением об ошибке, было решено сделать это позднее. Пришло время для более интересного занятия – собственно настройки системы. Если помните, необходимо было обеспечить подключение локальной сети к Интернету. Причем дело не ограничивалось только доступом к ресурсам веб-серверов. Нужны были и ftp-клиент, и работа с почтой по протоколу POP3. Поэтому разумным показалось воспользоваться трансляцией адресов (Network address translation, NAT). ASPLinux 7.3 Server Edition базируется на ядре версии 2.4.18 и это значит, что соответствующие настройки нужно производить с помощью утилиты iptables, входящей в дистрибутив. В нашем случае выглядит это следующим образом: iptables -t nat –A POSTROUTING –s 192.168.100.0/24 –d 0/0 –j SNAT --to-source 207.46.249.27 Т.е. все адреса из частной сети 192.168.100.0 будут транслироваться в единственный реальный адрес 207.46.249.27. Но это не все. Созданные подобным образом правила сохраняются только в оперативной памяти и в случае перезагрузки сервера оказываются утерянными. Первое, что приходит в голову, – написать собственный сценарий и обеспечить его запуск во время старта системы, к примеру, поместив его (или ссылку на него) в каталог /etc/rc.d/rc3.d/. А заодно и в /etc/rc.d/rc5.d/. И в этом же сценарии разрешить, что тоже необходимо, перенаправление пакетов на другой сетевой интерфейс командой: echo 1 > /proc/sys/net/ipv4/ip_forward Примерно так я и сделал. Все заработало, но не покидало ощущение неправильности или, точнее, неизящности такого подхода. Пришлось подробнее ознакомиться с описанием iptables, где, среди прочего, упоминались два сценария: iptables-save и iptables-restore. Причем последний вызывался в сценарии /etc/rc.d/init.d/iptables. Как говорится в детской игре, стало «теплее». Последовало прочтение еще пары-тройки руководств – и все встало на свои места. Действительно, при старте системы скрипт /etc/rc.d/init.d/iptables пытается считать файл /etc/sysconfig/iptables и применить сохраненные в нем правила. Ровно то, что и требовалось. Осталось только сформировать этот самый /etc/sysconfig/iptables. Но запущенный без параметров iptables-save почему-то этот файл не создал и пришлось сделать это принудительно: service iptables save Осталось разрешить перенаправление пакетов. Здесь решение возникло в процессе просмотра log-файлов запуска и останова системы. Бросилось в глаза, что в них присутствует строка, содержащая примерно следующее: «sysctl: net.ipv4.ip_forward = 0». Т.е. при останове системы задача, обратная нашей, решается с помощью вызова команды sysctl, которая считывает предопределенные настройки из файла /etc/sysctl.conf. Исправляем в нем net.ipv4.ip_forward = 0 на net.ipv4.ip_forward = 1 и можно двигаться дальше. Задача номер два – организация доступа к совместно используемым файлам и подключенному к серверу принтеру решается без дополнительной установки каких-либо программ, необходимый пакет Samba версии 2.2.7 также входит в дистрибутив. Можно было бы, конечно, попробовать и 3-ю версию, но в мои планы на данном этапе это не входило. О том, как с помощью Samba реализовать доступ к файлам и эмуляцию контроллера домена, написано много. Да и проблем на этом этапе практически не возникло. А вот с чем реально пришлось побороться – так это с печатью. В «Руководстве пользователя» предлагается использовать для ее настройки графическую утилиту PrintTool. Однако если не устанавливать поддержку X Window System (а так ли нужны они на сервере?), воспользоваться ей, естественно, не удастся. Поэтому опишу, как выглядел процесс при использовании только текстовой консоли. Согласно большинству источников процедура настройки печати заключается в следующем. Сначала проверяется наличие в секции [printers] файла smb.conf параметра вида: path = /var/spool/samba Если его нет, нужно добавить. Кроме того, необходимо вставить в файл /etc/printcap следующие строки: lp|hp: :sd=/var/spool/samba: :mx#0: :sh: Проделав это и перезапустив с помощью расположенных в /etc/rc.d/init.d/ сценариев lpd и smb, я вместо распечатки тестовой страницы печати Windows c клиентского ПК получил следующее. Сценарий lpd выдал предупреждение о несоответствии прав на каталог /var/spool/samba и о том, что в системе отсутствуют принтеры. И действительно, файл /etc/printcap оказался пустым. А у каталога /var/spool/samba изменились владелец и права доступа. Пришлось смотреть, что же делает /etc/rc.d/init.d/lpd. Что происходит с файлом printcap, стало понятно достаточно быстро. Оказалось, что разработчики сценария теперь предложили хранить описания установленных принтеров в файле /etc/printcap.local, а в /etc/printcap просто переписывается его содержимое. А с правами все оказалось несколько сложнее. До конца разобраться в происходящем так и не удалось, но работоспособное решение появилось. Вот оно. В /etc/samba/smb.conf оставляем: path = /var/spool/samba Создаем файл /etc/printcap.local следующего содержания: lp|hp: :sd=/var/spool/samba/hp: :mx#0: :sh: На каталог /var/spool/samba устанавливаем права 1777. Затем создаем каталог /var/spool/samba/hp с правами по умолчанию. После чего перезапускаем /etc/rc.d/init.d/lpd restart. Появится предупреждение о несоответствии прав на каталог /var/spool/samba/hp и они изменятся на 700, а владельцем каталога станет пользователь lp. Теперь печать должна заработать. Дело осталось за малым – обеспечить запуск и остановку Samba. Ранее уже упоминался выполняющий эту процедуру сценарий /etc/rc.d/ini.d/smb. Можно было бы, как и на начальном этапе настройки iptables, создать на него ссылки в соответствующих каталогах, но нашелся более простой, на мой взгляд, способ – воспользоваться командой chkconfig. Для этого останавливаем Samba: service smb restart затем выполняем: chkconfig --add smb Но у меня так не получилось. Скорее всего дело в том, что для smb в chkconfig не прописаны уровни (run level) системы, для которых этот сервис должен выполняться. Поэтому пришлось сделать это следующим образом: chkconfig --level 345 smb on после чего выполнить проверку и снова запустить Samba: chkconfig --list smb service smb restart Теперь осталось завести пользователей для Linux (а сделать это можно было еще на этапе инсталляции) и Samba, и сервер готов к работе. Правда, по-хорошему необходимо еще дополнительно позаниматься обеспечением его безопасности, да и ядро не мешает пересобрать, но это уже другие темы. В заключение хотелось бы поделиться еще одним соображением. При установке сервера я оставил на нем предлагаемую по умолчанию поддержку русского языка и столкнулся со следующим неудобством, характерным, пожалуй, практически для всех локализованных продуктов, но по-разному проявляющимся. Речь идет о диагностических сообщениях и предупреждениях об ошибках. Если при работе с русифицированной версией какой-либо ОС из семейства Windows весьма сложно бывает понять, о чем идет речь в выводимых системой сообщениях (и тем более невозможно в том же англоязычном TechNet провести контекстный поиск), то в моем случае выводимые по-русски, но в кодировке KOI-8R, сообщения на клиентских компьютерах оказались просто нечитабельными. В связи с этим есть предложение к разработчикам, занимающимся локализацией продуктов. Если это возможно, кроме перевода, оставляйте в системных сообщениях их оригинальное написание. Тем самым вы существенно облегчите жизнь многим системным администраторам. Автор выражает большую благодарность порталу SysAdmins.RU и лично Липовцеву Алексею за участие в написании этой статьи. |
АЛЕКСАНДР ШИБЕНКОКомментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
