Linux Navigator

"Барышня, дайте срочно Смольный!"

Для начала настроим простую рабочую станцию. Имеется локальная сеть Ethernet с протоколом TCP/IP. Первоначально требуется скомпилировать ядро с соответствующими драйверами. Первоначально требуется поставить в соответствии IP?адресу имя компьютера (если у вашего компьютера оно есть), для в файле /etc/hosts требуется добавить строку

#IP		полное имя			псевдоним
127.0.0.1	localhost.localdomain	 	localhost
195.14.21.11	blade.hell.com			blade

Первая строка это комментарий, вторая это описание loopback и третья это добавленная нами строка для сети. Дальнейшее конфигурирование происходит при помощи команды ifconfig, она предназначена для сопоставления сетевого интерфейса и IP?адреса. Она имеет следующий синтаксис

ifconfig  [[-net -host] 
 [parameters]]

Интерфейсы для Ethernet устройств называются как eth0, eth1, и т.д. Адрес сопоставляемый интерфейсу берется либо из файла /etc/hosts (ключ -host) или из /etc/network (ключ -network). Файл /etc/network является аналогом файла /etc/hosts и предназначен для сопоставления адреса и имени для сегмента сети. parameters может принимать следующие значения

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

route [add del] [-net -host]  [parameters]

Параметр обозначает сеть (при ключе -net) и может браться из файла /etc/network. Если настраивать маршрутизацию на отдельный компьютер, то следует использовать ключ -host. А parameters может принимать значения аналогичные параметрам ifconfig, с дополнением параметра gw (gateway).

Следующим этапом настройки, является установка шлюза. Шлюз предназначен для соединения различных сетей. Если в вашей сети этим компьютером является компьютер с именем shield и адресом 195.14.21.13, то следует добавить в список hosts его характеристики, а затем использовать команду route с параметром gw. Например

route add -net 199.221.14.0 gw shield

После всего написанного стало простым настроить шлюз, для этого нужно только настроить два интерфейса по отдельности и присвоить им уникальные IP-адреса. Полезно так же добавить оба в /etc/hosts.

Если вы все это настроили один раз, то после перезагрузки все настройки потеряются. Для это чтобы избежать этого следует включать команды ifconfig и route в сценарий загрузки сети rc.inet1 точно также как вы только что их набирали. Однако способ, когда в каждом компьютере приходится создавать один и тот же файл, не является изящным. Более удобные средства предоставляют демон gated (это аналог демона Максвелла) и метод proxy ARP (Address Resolution Protocol). Демон gated занимается тем, что динамически создает таблицу маршрутов в системе. Он необходим для больших сетей и работы с линиями "точка-точка", которые меняются динамически.

Самым мощным по сей день средством обеспечения безопасности служит так называемый firewall. Это компьютер или просто программа, которая закрывает доступ к сетевым службам и протоколам тем кому не положено. Для этого имеется минимум 2 управляющих файла: /etc/hosts.deny и /etc/hosts.allow. Структура этих файлов очень проста, в каждом только 2 столбца: сервис и хост (если вы умеете программировать консоль, то можно добавить третий столбец, но ТОЛЬКО ЕСЛИ УМЕЕТЕ). Для любого компьютера, который не служит сервером в Интернете, файл /etc/hosts.deny имеет очень простой вид

ALL:ALL

После этого можно добавить нужные адреса в файл /etc/hosts.allow.
Для проверки служит команда netstat. Она имеет следующие ключи

Так же для проверки служат команды ping и traceroute. Они посылают пакеты на компьютер указанный вами в значении параметров, а затем отображают статистику.

Однако простой установкой сокета мало кто ограничивается. Нужно еще настроить сетевых демонов. Для помощи в продвижении демонологии служит файл /etc/inetd.conf, это управляющий файл суперсервера демонов Интернета. С точки зрения демонологии словом "Интернет" называют самое большое из известных скопление демонов, как диких, так и домашних. Все записи в этом файле имеют вид

Теперь пояснения.

Файл этот достаточно большой, и я не написал и четверти его строк. Но если вы откроете его, то увидите, что большинство строк закомментированы. Это связано с соображениями безопасности. Ни для кого (кроме разработчиков очередного "безопасного" продукта из Micro$oft) не секрет, что есть сетевые сервисы, которые содержат дыры и есть сервисы, которые даже без дыр не способны хоть что-то засекретить. Среди программистов и root'ов существует поверье, что известных дыр не содержит только самая последняя версия сервиса. Однако бывает что это не верно. Например, я специально привел строку с сервисом tftp (Trivial FTP), он предназначен для загрузки бездисковых рабочих станций, а на деле являет собой незатыкаемую дыру. Обычно, для того чтобы он корректно и относительно безопасно работал, сеть, в которой он устанавливается, делают полностью закрытой от внешнего мира файерволом. На самом загрузочном компьютере создают специальный дисковый раздел, в который только tftp и сможет адресоваться. Затем присваивают ему категорию nobody, а номера ethernet карточек фиксируют. Также опасным является сервис finger, поскольку он предоставляет информацию о работе компьютера всему миру. Нешифрованные авторизуемые службы ftp и telnet это вообще целая песнь хакера, их не ловит только ленивый.

Работа сетевого демона несколько отличается от работы обычного демона. Обычный домашний демон большую часть своей жизни спит и просыпается только для совершения необходимой работы при получении сигнала от ядра. Демон же сетевой спит редко и мониторит подотчетный ему сетевой интерфейс. При поступлении на этот интерфейс требования о соединении, демон немедленно раздваивается. Одна его локальная копия продолжает мониторить интерфейс, а другая обрабатывает соединение. После закрытия соединения локальная копия уничтожается. Исходя из этого следует строить политику запуска сетевых демонов. Службы, запуск которых обрабатывается редко, следует поручить демону tcpd, а специфическим демонам - часто используемые службы. Например, служба telnet даже в самом активно посещаемом MUD'е запускается не чаще одного - двух раз в минуту, а служба http на www-сервере средней нагрузке обрабатывает несколько десятков, а то и сотен, запросов в минуту.

Записывать все известные компьютеры в файл /etc/hosts занятие неблагодарное, а потому его полезно перепоручить компьютеру. Обычно этим занимается демон named. На самом деле это не самостоятельный демон, а часть большой библиотеки, называемой библиотекой резолвера. Задачей этой библиотеки является выполнение двух функций языка C - gethostbyname() и getnamebyhost(). Очень полезно иметь этого демона не только на сервере имен всей сети, но и на каждом компьютере, поскольку локальный демон named позволяет кешировать работу общего и разгружает сеть. Местный резолвер управляется несколькими файла, самый простой и самый важный из них - /etc/host.conf. Число его параметров очень ограничено

Для того чтобы использовать удаленный сервер имен DNS (параметр order имеет значение bind), необходимо указать, где этот сервер находится. Для этого служит файл /etc/resolv.conf, в котором только 2 параметра domain и nameserver. Значением domain является домен, в котором работает хост. А значением nameserver является IP-адрес сервера имен. Можно указывать не более трех серверов имен, причем порядок их просмотра определяется их положением в списке. Если этот файл отсутствует, то предполагается что сервер имен работает локально.

Локальный демон named управляется несколько нестандартным файлом /etc/named.boot (в нем коментарии обозначаются ;). Для примера

;/etc/named.boot для blade.hell.net
directory	/tmp/named
;порядок	домен				файл
cache		.				named.ca
primary	hell.net.			named.hosts
primary	0.0.127.in-addr.arpa.		named.local
primary	14.195.in-addr.arpa.		named.rev
;и т.д.

Перед описанием параметров обратите внимание как здесь пишутся имена, задом наперед, вместо неизвестной части ставится .in-addr.arpa., причем ОБЯЗАТЕЛЬНО заканчивается на точку. В этом файле ВСЕГДА должна присутствовать строка о loopback интерфейсе 127.0.0.1, как о primary, иначе многие ваши внутренние программы полезут наружу и никогда не вернутся. Теперь остальные параметры

Получить информацию с другого компьютера в сети можно только с помощью обычных сетевых протоколов. Для этого служит еще и RPC (Remote Procedure Call). Основных применения для RPC два - это NIS (Network Information Service) и NFS (Network File System). Есть еще два побочных, понятно последствия творчества Microsoft, IIS (Internet Information Service) и SMB (сервер NetBIOS для сетей UNIX). NIS (и IIS) служит для получения информации по сети, например, с его помощью можно организовать общие пароли для всех компьютеров в локальной сети. А NFS (и SMB) служит для получения доступа к удаленным каталогам, как к локальным. Локальная сеть, организованная на NIS и NFS, очень легка для администрирования и работы, пользователь даже не должен знать, где расположен компьютер с его личным каталогом, а где с необходимой программой, он просто садится за ближайший. К сожалению, та версия NIS, с которой имел дело я, была сильно устаревшей, не обеспечивала режима теневых паролей, шифрованных соединений и надежной авторизации. Потому я напишу только об NFS.

Для того чтобы можно было начинать работу с томами (здесь это слово аналогично "удаленная файловая система") NFS, следует запустить демона NFS и установить поддержку NFS в ядре. Демоны NFS запускаются не через суперсервер демонов Интернета, а самостоятельно, через сценарий загрузки. Для этого в файле /etc/rc.d/rc.inet2 должна быть запись

if [ -x /usr/sbin/rpc.mountd ]; then
	/usr/sbin/rpc.mountd; echo -n " mountd"
fi
if [ -x /usr/sbin/rpc.nfs ]; then
	/usr/sbin/rpc.nfsd; echo -n " nfsd"
fi
if[ -x /usr/sbin/rpc.ugidd ]; then
	/usr/sbin/rpc.mountd; echo -n " ugidd"
fi

Первый блок запускает монтировщика (он обычно включен по умолчанию), второй - NFS (он обычно закомментирован), третий - демона имен и групп ugidd.

Для управления подключением клиентов, на сервере создается управляющий файл /etc/exports. Только прописанные в этом файле клиенты имеют доступ к тому NFS на сервере. Обычно он имеет следующий вид

#/etc/exports на сервере blade
/home/users	bow(rw, kerberos), arrow(rw, kerberos), riposte(rw, kerberos)
/usr/games	bow(ro), arrow(ro), riposte(ro), blaze(ro)

Структура этого файла понятна (не путать с понятием "интуитивно понятно"), первый столбец - каталог на сервере, второй - список клиентов с параметрами. В названиях можно употреблять символы * и ? если строка клиентов пуста, то доступ открыт всем. Параметры могут иметь следующие значения

Теперь можно приступить к монтированию тома NFS клиентом. Для этого используется уже знакомый файл /etc/fstab. В него следует внести строки вида

Где параметры могут быть следующими

После этого можно монтировать том вручную или посредством автомонтировщика autofs.

Я описал лишь малую часть работы демонов Интернета и демонов RPC. Например, в последнее время стали повсеместно использоваться алгоритмы шифрования и надежной авторизации, устойчивые к перехвату пакетов хакером. Это демоны sshd (Secured SHell), slogind (Secured LOGIN) и другие. Так же я не коснулся такого вопроса как организация Интернет-сервера с демоном httpd, сервером Apache и других Интернет-служб. Не ограничиваются описанными и применения RPC, это очень мощная система, которая позволяет легко (например, одной командой export DISPLAY=blade) устанавливать достаточно сложные соединения, вроде Remote Desktop Connection из арсенала Windows2000. При этом не требуется передавать все содержимое рабочего стола, если вам требуется лишь запустить одну программу. В общем, это самостоятельное творчество, которому могут помочь только собственные усилия.

Однако еще сохранились люди, которые для соединения с Интернетом используют модем. Вы уже установили драйвера, перекомпилировали ядро и теперь хотите дозвониться провайдеру. Если вы простой пользователь, то для этого достаточно просто создать соответствующее PPP-соединение в одной из программок, и дальше не ваша забота. Если же вы root, то для того чтобы юзеры смогли так просто существовать придется потрудиться именно вам (особенно если единственный юзер - это вы).

Если соединение осуществляется с помощью протокола PPP (а сегодня это почти всегда так), то этим соединением управляет демон pppd. Это необычный демон, он отличается от всех предыдущих тем, что ЛЮБОЙ пользователь может им управлять (даже guest). Осуществляется управление с помощью аргументов командной строки и управляющих файлов. Этих файлов может быть много, один основной, и по одному на каждого юзера. Основной файл называется /etc/ppp/options, а пользовательские файлы .rcppp, и содержатся они в домашних каталогах. Правило здесь следующее: параметры для всех файлов одинаковые, но в первую очередь просматриваются параметры из основного файла, затем из пользовательских. Параметры основного файла общедоступны и общеприняты, т.е. каждый пользователь их употребляет, но не может изменить. Параметры же пользовательских файлов личные, т.е. только владелец их знает и может изменять. Таким образом, пароли следует хранить в пользовательских файлах, а настройки модема - в общем.

Так же в качестве параметров при желании можно указать требуемую скорость соединения, IP-адрес своего хоста и IP-адрес удаленного. Последние параметры частично противоречат параметру noipdefault, и записываются как local_addr:remote_addr. Кроме того для работы в режиме сервера требуется настроить последовательный порт таким образом, что бы он не отсылал полученные команды назад, как эхо. Для этого следует отдать следующие команды для порта

mesg n
stty -echo

Таким образом для дозвона до провайдера можно использовать следующий сценарий (если все необходимые параметры находятся в /etc/ppp/options)

pppd connect "my_scenario"

Однако не на всех компьютерах удобно использовать такой механизм. Дополнительные параметры вызова демона pppd позволяют использовать его постоянно, таким образом, чтобы он сам устанавливал соединение в случае необходимости. Куда их помещать, зависит от конкретных требований.

Есть еще 2 файла, которые управляют демоном pppd, они называются /etc/ppp/ip-up и /etc/ppp/ip-down. Их назначение это маршрутизация в удаленную сеть при помощи протокола PPP. Они используют те же параметры, что и описанные файлы, и если вы используете PPP только для связи с Интернетом, то их можно оставить как есть.

Тогда для пользователя основным станет создание и запуск сценария его соединения. Этот процесс давно автоматизирован с помощью специальных программ, которые разные в разных дистрибутивах Linux. Но иногда может возникнуть необходимость создания или запуска сценария вручную. Для следует создать файл с названием вроде my_scenario. А для параметра connect указать значение "chat -f my_scenario". chat это программа общения с модемом по принципу диалога, ключ -f означает, что этот диалог берется из файла. Пример части такого файла

ATZ
OK	ATDT3208080
CONNECT	' '
ogin: ghoort
word: forget

При его запуске на модем посылается команда ATZ (инициализация), затем он ожидает ответа OK. После его получения, программа chat высылает телефонный номер ATDT3208080 в импульсном наборе, и ждет ответа CONNECT. После получения ответа, она не делает ничего, на что указывает пустая строка. Получение приглашения ogin: приводит к ответу ghoort, причем такой вид не ошибка, это требуется, поскольку буквы L и l здесь различаются. Затем вводится пароль.

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

И жили они долго и счастливо...

Развитие индустрии сказалось и на Linux. Хотя и есть люди, которые ругают Linux (кстати, обоснованно) за шатание из стороны в сторону, постоянное переписывание уже готовых частей ядра, не достаточно быстрое добавление новых и необходимых, да мало ли за что... Юниксовая братия уже разделилась на 2 направления - BSD и SysV, которые различаются структурой ядра и методами межпроцессовых коммуникаций. Начинает оформляться течение, которое требует интеграции графической среды на уровень ядра, хотя бы на уровне модуля (к этим отщепенцам отношусь и я). И многое другое. Но последние годы появилось новое идеологическое требование, которое просто хорошо забытое старое.

Операционная система и программы должны минимально зависеть от архитектуры процессора. В идеале они не должны зависеть вообще.

А все-таки интересно, будет ли версия Microsoft Office для Linux?