Администрирование ОС Solaris

         

Протокол PPP


Протокол PPP (Point-to-Point Protocol) был разработан для связи по последовательным каналам, таким как коммутируемые телефонные каналы, соединения через последовательные порты и т.д. С помощью протокола PPP можно установить канал связи и передавать по нему пакеты любых протоколов - TCP/IP, IPX/SPX, NetBIOS. Нас в приложении к UNIX интересует настройка работы с TCP/IP поверх PPP.

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

установление связи; согласование параметров передачи (скорость, четность и т.п.); согласование параметров сетевого интерфейса (IP-адрес, маска, адрес сервера имен и пр.); передача пакетов между интерфейсами; разрыв связи.

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

Подробная документация по настройке PPP в Solaris 9 содержится, в частности, в документе "Solaris 9 System Administrator Collection System Administration Guide: Resource Management and Network Services" по адресу http://docs.sun.com/db/doc/806-4076?q=ppp, а обзор PPP в Solaris 9 имеется по адресу http://docs.sun.com/db/doc/806-4076/6jd6amr63?q=ppp&a=view.



Протоколы в SMC


ПО Solaris Management Console (smc) представляет собой набор утилит и общую графическую оболочку, которые выполняют функции высокоуровнего интерфейса администратора. Возможности SMC обсуждаются в лекции 26, сейчас же в наши задачи входит знакомство с системой протоколирования, доступной в SMC .

Прежде всего, здесь доступна внутренняя система протоколирования всех событий, зарегистрированных "внутри" оболочки smc. В левом нижнем углу окна SMC можно выбрать закладку Console events (см. рис. 16.1) и далее следовать по ссылке All events.


Рис. 16.1.  Внутренние события Solaris Managmenet Console

Окно Console Events откроется по щелчку на All Events, и в окне можно просмотреть список событий . Детали события доступны по клику на соответствующей строке. Протокол событий SMC полезен в том случае, если администратору нужно восстановить последовательность своих действий и проанализировать их (рис. 16.2).


Рис. 16.2.  Список событий SMC

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


Рис. 16.3.  Просмотр протокола в Solaris Managmenet Console

НАЗАД ВПЕРЕД

<
/td>



 

Проверка маршрутов: traceroute и route


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

Она прослеживает весь путь пакета, при этом по умолчанию инспектируются и показываются не более чем тридцать "hop'ов". Hop (читается "хоп") - это один переход от одного сетевого интерфейса до другого. Если говорят, что до получателя - один hop, это значит, что в дороге пакет не пройдет ни через один маршрутизатор, выполнит только один переход - от отправителя к получателю:

traceroute to ftp.chg.ru (193.233.9.194), 64 hops max, 40 byte packets 1 gw-lost.nw.ru (195.19.204.65) 1.138 ms 1.083 ms 1.153 ms 2 vo-lergo.nw.ru (195.19.203.71) 1.589 ms 2.071 ms 1.734 ms 3 ing-e0.nw.ru (195.19.194.68) 1.173 ms 0.920 ms 0.939 ms 4 msk-ix.nw.ru (193.232.244.225) 11.615 ms 12.053 ms 12.310 ms 5 rbnet-ian.nw.ru (195.19.194.2) 13.991 ms 13.800 ms 11.989 ms 6 MSK-M9-RBNet-4.RBNet.ru (195.209.14.157) 12.579 ms 13.382 ms 12.549 ms 7 Moscow-BNS045-ATM4-0-2.free.net (147.45.20.33) 14.262 ms 14.077 ms 12.622 ms 8 Moscow-BNS042-Gig0-1-21.free.net (147.45.21.2) 13.695 ms 15.291 ms 13.944 ms 9 ftp.chg.ru (193.233.9.194) 19.936 ms 20.208 ms 18.559 ms

Идея traceroute такова: программа отправляет пакеты с адресом получателя, путь до которого мы хотим проследить. В поле TTL 1) IP-пакета для начала ставится число 1. В поле номера порта ставится номер заведомо неиспользуемого порта (обычно это большое число). Естественно, первый же маршрутизатор на пути пакета сообщает, что TTL пакета истекло. Ответ маршрутизатора учитывается и выводится на экран, а затем посылается пакет с TTL, равным двум. Ответ про истечение времени присылает следующий маршрутизатор по пути следования пакета, и так происходит до тех пор, пока пакет не дойдет до получателя. Когда это случится, сообщение об ошибке будет иным: "порт не обслуживается" (ведь порт специально задан таким, чтобы он не обслуживался).

Программа traceroute посылает три пакета с каждым из значений TTL, чтобы подсчитать среднее время прохождения пакета до каждого из промежуточных маршрутизаторов.
Если ответ от какого- нибудь маршрутизатора не пришел за пять секунд, traceroute выводит звездочку (*) вместо времени ответа маршрутизатора, и это символизирует превышение тайм-аута.

Анализ маршрута пакета с помощью traceroute не всегда возможен, так как в некоторых сетях пересылка пакетов на нестандартные порты запрещена, а в некоторых - запрещена пересылка пакетов ICMP, в которые пакуются ответы маршрутизаторов типа "истекло TTL вашего пакета". Кроме того, пакеты разных типов могут проходить через маршрутизаторы по разным путям. Одинаковые пакеты могут быть направлены разными путями, в зависимости от загрузки сети. Поэтому маршрут пакета, показанный с помощью traceroute, верен только на момент выполнения этой программы. Вы можете применять traceroute и для проверки маршрутизации вашей сети. Например, если пакеты, предназначенные внешней сети, не отправляются на основной шлюз, а ищут другой путь (это будет видно посредством traceroute при попытке отследить путь пакета), то это верный признак сбоя в настройках.

Программа traceroute имеет ряд ключей для изменения параметров пересылаемых пакетов - смотрите man traceroute.

Для анализа и модификации локальной таблицы маршрутизации применяется программа route. В лекции 13 обсуждались ее синтаксис и воздействие на таблицу маршрутов в ядре. Используйте программу route для добавления статических маршрутов и внесения оперативных изменений в маршрутизацию через ваш компьютер, когда это необходимо.


Проверка настроек: ifconfig


Если вы не уверены в том, что сетевой интерфейс вашего компьютера работает или что он верно настроен, потребуйте эту информацию от ifconfig

ifconfig -a lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 elxl0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.168.5.33 netmask ffffff00 broadcast 192.168.5.255 ether 0:60:8:cb:3b:c0 elxl0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST, IPv4> mtu 1500 index 2 inet 194.200.0.1 netmask ffffff00 broadcast 194.200.0.255

Обратите внимание: псевдонимы интерфейсов и интерфейсы, не являющиеся сетевыми адаптерами Ethernet, не имеют MAC-адреса.

Сетевые интерфейсы, от которых ожидается работа в данный момент, должны присутствовать, иметь корректные IP-адреса, маски и верные MAC-адреса (00:00:00:00:00 в поле MAC-адреса вывода ifconfig говорит о том, что драйвер сетевого адаптера не считал адрес или не нашел адаптер). Кроме того, работающий интерфейс обязан находиться в состоянии UP. Не забывайте давать команду

ifconfig имя_устройства plumb

для активизации интерфейса, если интерфейс добавлен вручную. Эта команда создает необходимые драйверу сетевого адаптера потоки для работы с TCP/IP и открывает доступ к устройству. До того, как будет дана эта команда, интерфейс не будет показан в выводе ifconfig -a, даже если драйвер и сетевой адаптер работают нормально.

Как узнать, работает ли ваша сеть? Попробуйте зайти по адресу www.playboy.com и сразу узнаете, есть ли доступ в Интернет. Лично я использую для проверки, есть ли связь с Сетью, менее одиозные сайты, например, домашнюю страницу главной финской сети FUNET. Это не так отвлекает от работы. В частности, потому, что на www.funet.fi почти все написано по-фински, а финский язык я знаю в объеме приветствий на вокзале. Может быть, стоит попробовать www.playboy.fi?



Проверка настроек сервера времени


Для просмотра и изменения параметров xntpd используйте программу ntpq. В частности, для вывода информации об известных источниках точного времени запустите ее с ключом -p:

ntpq -p remote refid st t when poll reach delay offset disp =================================================================== ensb.cpsc.ucalg montpelier 2 u 26 64 1 189.36 2879.39 15875.0

Если надо проследить цепочку, по которой точное время добирается до вашей сети, пригодится программа ntptrace:

ntptrace ntp.cpsc.ucalgary.ca ensb.cpsc.ucalgary.ca: stratum 2, offset 2.867748, synch distance 0.05968 montpelier.ilan.caltech.edu: stratum 1, offset 2.863728, synch distance 0.00113, refid '' ntptrace localhost localhost: stratum 16, offset 0.000014, synch distance 1.00270



Проверка пакетов ПО с помощью pkgchk


Чтобы узнать, изменялись ли файлы установленных пакетов с момента их установки, используйте pkgchk:

bash-2.05# pkgchk SMCtop bash-2.05#

Как видим, сообщений от pkgchk не последовало. Отсутствие новостей - лучшие новости. Если программа pkgchk не выдала сообщений, стало быть, проблем нет.

Можно проверить, изменилось ли содержимое файла пакета с момента его установки:

pkgchk -p /etc/shadow ERROR: /etc/shadow modtime <11/04/02 01:06:28 > expected <03/18/04 05:05:29 > actual file size <253> expected <298> actual file cksum <17353> expected <20785> actual

Файл изменился с момента установки системы. Это естественно: ведь мы добавили новых пользователей и назначили им пароли.

Для более подробной информации можно использовать ключ l:

pkgchk -l -p /etc/shadow Pathname: /etc/shadow Type: editted file Expected mode: 0400 Expected owner: root Expected group: sys Referenced by the following packages: SUNWcsr Current status: installed



Проверка работоспособности служб NFS


Теперь необходимо проверить, правильно ли запущены mountd и nfsd. Сначала это делается с помощью команды rpcinfo -p. Вывод программы должен показать что-то похожее на следующее:

100000 4 tcp 111 rpcbind 100000 3 tcp 111 rpcbind 100000 2 tcp 111 rpcbind 100000 4 udp 111 rpcbind 100000 3 udp 111 rpcbind 100000 2 udp 111 rpcbind 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100005 3 udp 1023 mountd 100005 3 tcp 1023 mountd 100005 1 udp 1023 mountd 100005 1 tcp 1023 mountd

Как видно, rpcbind успешно анонсирует службы.

Если в ответ на rpcinfo -p мы получили сообщение

rpcinfo: can't con

или

RPC_PROG_NOT_REGISTERED

или нечто похожее вместо ожидаемого - стало быть, rpcbind не доступен (отключен). Возможно, в файлах /etc/hosts.allow или /etc/hosts.deny есть настройки, запрещающие программе rpcbind отвечать нам.

Для перезапуска служб NFS можно завершить выполнение демонов nfsd, mountd и rpcbind, и потом запустить их вновь в таком порядке: rpcbind, затем mountd и nfsd. Программе nfsd может быть передан числовой аргумент - число потоков, которые следует запустить при старте. Программа "распараллелится" в указанном количестве потоков.

Более стандартным выходом является запуск скрипта

/etc/init.d/nfs.server

вначале с параметром stop, затем с параметром start.

При штатной работе mountd и nfsd запускаются на сервере NFS при старте системы из стартовых скриптов. Это можно проверить командами

ps -ef | grep mountd ps -ef | grep nfsd

Программа rpcbind объявляет свои службы независимо от того, продолжают ли работать программы, ранее зарегистрировавшиеся и (возможно) прекратившие работу вследствие аварии.

Следовательно, вышеприведенная проверка с помощью ps обязательна, если служба NFS перестала работать.

Не забудьте перед настройкой сервера NFS изучить страницы руководства, рассказывающие о rpcbind, mountd, nfsd, dfstab.



Проверка содержимого пакетов и перечня установленного ПО


Чтобы узнать, какие пакеты уже установленны в системе, а также узнать подробную информацию по каждому из этих пакетов, следует пользоваться программой pkginfo:

pkginfo application SMCtop top system SUNW1251f Russian 1251 fonts ALE SUNW5ttf Traditional Chinese BIG5 True Type Fonts Package ALE SUNW5xmft Traditional Chinese (BIG5) X Window s Platform minimum required Fonts Package system SUNWGlib GLIB - Library of useful routines f or C programming system SUNWGtkr GTK - The GIMP Toolkit (Root) system SUNWGtku GTK - The GIMP Toolkit (Usr) system SUNWTcl Tcl - Tool Command Language system SUNWTiff libtiff - library for reading and w pkginfo -l SMCtop PKGINST: SMCtop NAME: top CATEGORY: application ARCH: intel VERSION: 3.5 BASEDIR: /usr/local VENDOR: William LeFebvre PSTAMP: Steve Christensen INSTDATE: Апр 21 2004 14:47 EMAIL: steve@smc.vnet.net STATUS: completely installed FILES: 13 installed pathnames 4 shared pathnames 5 directories 1 executables 1 setuid/setgid executables 258 blocks used (approx)



Проверка соответствия адресов: arp


Если попытка "пинговать" тот или иной адрес в локальной сети дает странные результаты, может пригодиться программа arp, которая показывает локальную таблицу соответствий MAC-адресов и IP-адресов в сети:

arp -a Net to Media Table: IPv4 Device IP Address Mask Flags Phys Addr ------ --------------- --------------- --- --------------- elxl0 hp5l 255.255.255.255 00:50:ba:03:b6:47 elxl0 baclan.q.spb.ru 255.255.255.255 00:60:b0:3c:99:05 elxl0 ip-119.q.spb.ru 255.255.255.255 00:10:5a:72:dd:9c elxl0 192.168.5.72 255.255.255.255 00:e0:29:9b:79:cd elxl0 lib.q.spb.ru 255.255.255.255 00:e0:29:9e:f3:3b elxl0 sunny 255.255.255.255 SP 00:60:08:cb:3b:c0 elxl0 192.168.5.11 255.255.255.255 00:e0:29:44:66:08 elxl0 mask.q.spb.ru 255.255.255.255 00:e0:29:48:63:64 elxl0 192.168.1.29 255.255.255.255 00:e0:b0:5a:66:90 elxl0 192.168.5.225 255.255.255.255 00:10:5a:73:6c:6b elxl0 192.168.5.208 255.255.255.255 00:e0:29:64:9e:e7 elxl0 192.168.5.183 255.255.255.255 00:e0:29:61:29:42 elxl0 192.168.5.158 255.255.255.255 00:e0:29:64:8f:b9 elxl0 BASE-ADDRESS.MCAST.NET 240.0.0.0 SM 01:00:5e:00:00:00

Если сбой в arp-таблице произошел на компьютере, который является основным шлюзом для многих компьютеров в сети, то выход из сети может оказаться заблокированным для всех пакетов, которые пытаются выйти за пределы сети.



Проверка связи: ping


Для того чтобы выяснить, работает ли сеть в офисе, достаточно обратиться к соседнему компьютеру. А вдруг на нем нет web-сайта? Тогда на помощь приходит маленькая, но важная программа ping:

ping IP-address

Вместо IP-адреса можно использовать имя компьютера:

ping geba.urupinsk.ru

Программа ping посылает маленький (обычно - 56 байт) пакет указанному компьютеру, а тот должен ответить таким же пакетом. Наш компьютер измеряет время прохождения пакетов туда и обратно и показывает его. Некоторые версии ping, в том числе и ping в Solaris 9, по умолчанию сообщают не время прохождения пакета, а сам факт ответа ("host is alive"). Если все же требуется время прохождения, вызывайте ping с ключом s:

ping -s ftp.chg.ru PING ftp.chg.ru: 56 data bytes 64 bytes from ftp.chg.ru (193.233.9.194): icmp_seq=0. time=63. ms 64 bytes from ftp.chg.ru (193.233.9.194): icmp_seq=1. time=51. ms 64 bytes from ftp.chg.ru (193.233.9.194): icmp_seq=2. time=26. ms 64 bytes from ftp.chg.ru (193.233.9.194): icmp_seq=3. time=18. ms 64 bytes from ftp.chg.ru (193.233.9.194): icmp_seq=4. time=42. ms 64 bytes from ftp.chg.ru (193.233.9.194): icmp_seq=5. time=18. ms 64 bytes from ftp.chg.ru (193.233.9.194): icmp_seq=6. time=19. ms 64 bytes from ftp.chg.ru (193.233.9.194): icmp_seq=7. time=95. ms 64 bytes from ftp.chg.ru (193.233.9.194): icmp_seq=8. time=48. ms ^C ----ftp.chg.ru PING Statistics---- 9 packets transmitted, 9 packets received, 0% packet loss round-trip (ms) min/avg/max = 18/42/95

Если ping показывает, что пакеты не проходят, это может случиться по нескольким причинам. Иногда ping выдает однозначную диагностику, а иногда приходится прерывать его, т.к. программа замирает в ожидании ответа, который никак не приходит.

Диагностика host is down говорит о том, что маршрутизация пакетов до искомого компьютера работает, а сам компьютер - нет. Возможно, его выключили, отключили от компьютерной сети или перевели в однопользовательский режим для профилактики.

Диагностика no route to host показывает, что маршрутизация пакетов до адресата не работает. Возможной причиной может быть сбой в таблице маршрутизации вашего компьютера (например, отсутствует запись об основном шлюзе).



Работа над ошибками


Если при работе NIS возникают непредвиденные ошибки (например, не происходит передача карт NIS с главного сервера на подчиненные), следует изучить файлы протоколов /var/yp/ypxfr.log на всех серверах. Если такого файла не существует, его надо создать и убедиться, что пользователь, от имени которого работают службы NIS, имеет право записи в этот файл.

Если не удается сменить пароль пользователя, то это может быть вызвано как недоступностью карт для демона yppasswdd, так и тем, что такой демон вовсе не запущен на главном сервере NIS. Проверяйте, какой сервер NIS каждый из компьютеров считает главным с помощью команды

ypwhich



Работа с web-браузерами Netscape, Mozilla, Internet Explorer в Solaris


Особенностью браузера Netscape, в частности, в системах под управлением Solaris 9, является отвратительная поддержка русского языка. Так, даже если переменные среды окружения LC_* и LANG установлены верно, а в системе по умолчанию установлены русские шрифты, Netscape может показывать русскоязычные страницы в совершенно нечитаемом виде. Скорее всего, это связано с рассогласованием реального шрифта и представления Netscape о том, какой кодировке русского алфавита соответствуют шрифт и отображаемая страница. Однако если в Solaris установлена локализация RU.UTF-8 (Unicode), то Netscape отображает символы кириллицы верно.

Если с Netscape возникают проблемы (а это браузер по умолчанию при установке Solaris 9), то можно установить браузер Mozilla. Он может быть бесплатно получен с сайта http://www.intuit.ru/department/os/adminsolaris/15/www.sun.com. Перед скачиванием потребуется зарегистрироваться на сайте. Объем архива, который требуется скачать для установки Mozilla, примерно равен 68 мегабайтам. Поэтому быстро скачать этот архив, дозвонившись до провайдера по обычному телефону обычным модемом, будет затруднительно (и накладно!). Для поддержки русского языка браузеру Mozilla требуется дополнительный модуль (его можно скачать с той же страницы, что и сам браузер). Размер модуля - около двух мегабайт.

Следует помнить, что по умолчанию в Mozilla и Netscape не установлен proxy-сервер. Так как для доступа к web-сайтам многие используют кэширующий proxy-сервер squid или подобный ему, надо при настройке браузера вписать адрес и номер порта proxy-сервера в соответствующие поля.

Настройки Mozilla и Netscape доступны в пункте меню Edit->Preferences в каждой из этих программ.

В начале этого века были попытки реализовать браузеры Internet Explorer и Opera под Solaris. В результате были выпущены их версии под Solaris для платформы SPARC. Компания Microsoft прекратила поддержку своего Internet Explorer для Solaris вообще, а Opera продолжает выпускать свой браузер для Solaris, но по-прежнему только для SPARC-систем.

НАЗАД ВПЕРЕД

<
/td>

 

Распространенные схемы аутентификации


В системах UNIX, как правило, выполняется стандартная аутентификация, с использованием файла паролей (/etc/passwd, /etc/shadow). Для централизованной аутентификации на нескольких компьютерах в сети были разработаны разные схемы, связанные с централизованным хранением базы данных пользователей и паролей.

Конечно, надо вспомнить NIS и NIS+ (см. лекцию 19), если мы говорим о централизации. Кроме того, аутентификация может происходить по протоколу TACACS (широко распространен в серверах удаленного доступа Cisco) или RADIUS (в серверах удаленного доступа Nortel). Бывают и другие возможности аутентификации. Единого общепринятого механизма, который давал бы общий интерфейс аутентификации для любой сетевой службы и любого способа аутентификации, пока не существует, хотя с течением времени появляются новые стандарты, претендующие на эту роль.



Размер пространства свопинга


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

Для управления пространством свопинга (получения информации о нем, добавления и удаления разделов свопинга) используется программа swap. Получить информацию о текущем состоянии пространства свопинга можно с помощью swap -l.

Для выяснения общего объема виртуальной памяти, который включает в себя объем оперативной памяти и пространства свопинга вместе, следует использовать swap -s или sar -r.

Если своп-раздел смонтирован в /tmpкак файловая система типа tmpfs, команда

df -k /tmp

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



Регулирование приоритетов


Регулировать приоритет процесса, как показано выше, можно с помощью команды priocntl. Ключ -s означает требование установить приоритет. Ключ -p позволяет задать относительное изменение приоритета, а для указания конкретного признака процесса (идентификатора и т.п.) следует использовать ключ -i (признак идентификатора обозначается pid, другие признаки поименованы в руководстве по priocntl).

Например, для понижения приоритета процесса с PID, равным 200, используйте

priocntl -s -c TS -p -20 -i pid 200

Для вывода списка части процессов вместе с заголовком, используйте POSIX-совместимую программу grep:

/usr/bin/ps -ecL |/usr/xpg4/bin/grep -E 'nscd|PID'



Рекомендации по запуску демонов


Всегда запускайте ровно столько демонов, сколько требуется. Например, если компьютер не является сервером NFS, не следует создавать файл /etc/dfs/dfstab, так как при его наличии автоматически запускается некоторое количество сетевых демонов. Мало того, что ненастроенные демоны могут дать злоумышленнику незапланированный доступ к компьютеру, так они еще и память занимают. Всегда используйте

ps -ef

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

Некоторые программы, такие как web-сервер Apache или прокси-сервер squid, запускают несколько процессов, размножая самих себя или вспомогательные службы для увеличения производительности. По умолчанию количество запускаемых ими процессов сделано "средним", т.е. для слабо нагруженной системы оно слишком велико, а для перегруженной внешними запросами - слишком мало. Постарайтесь установить оптимальное значение - так вы сможете выиграть от нескольких мегабайт до нескольких десятков мегабайт памяти.



Решение проблем:изменение размеров разделов диска


Если необходимо увеличить размер конкретного раздела, то есть два пути: физически изменить размер раздела или создать метаустройство, которое физически будет состоять из нескольких разделов на одном или нескольких дисках, но система будет его считать одним логическим разделом. Второй путь напоминает создание Volume Set в системах Windows.

Чтобы физически изменить размер раздела, надо, чтобы на диске вслед за этим разделом было свободное пространство, еще не отданное ни одному разделу. Если там есть какой-то другой раздел, то его придется удалить, предварительно сохранив нужные данные из него. После этого потребуется выполнить резервное копирование всех данных увеличиваемого раздела в какой-то каталог другого раздела, удалить старый раздел, создать на его месте новый, больший, с помощью команды newfs, и затем восстановить файлы из резервной копии. Этот метод рекомендован для использования в любых системах UNIX. Однако он требует значительных затрат времени и дискового (или ленточного, в зависимости от того, где вы создаете резервную копию) пространства.

Второй способ годится только для Solaris (другие коммерческие системы UNIX имеют свои собственные средства решения этой проблемы, которые здесь не обсуждаются). Метаустройство создается командой metainit. Программа growfs, которая служит для увеличения размера файловой системы, может модифицировать таблицу индексных дескрипторов и другие управляющие структуры так, чтобы можно было работать с увеличенной файловой системой без потери старых файлов. Увеличение возможно только после создания метаустройства, причем как для смонтированной, так и для несмонтированной файловой системы, в том числе даже во время работы других пользователей с этой файловой системой.

Синтаксис команды growfs:

/usr/sbin/growfs [-M точка_монтирования] [параметры_newfs] [rawdevice]

Аргументы команды growfs обозначают:

точка_монтирования - точка монтирования файлововй системы, которую требуется расширить. При этом на время расширения произойдет блокировка файловой системы функцией lockfs(). параметры_newfs - те же параметры, которые может принимать программа newfs при создании новой файловой системы, см.
описание newfs. rawdevice - имя файла прямого доступа для метаустройства в каталоге /dev/md/rdsk. Команда growfs увеличивает размер файловой системы до размера указанного раздела.
Увеличение размера раздела выполняется посредством добавления нового раздела к метаустройству и последущего запуска growfs. При увеличении размера зеркала (т.е. уже существующего метаустройства с реализованным зеркалированием, или, иначе говоря, с RAID уровня 1) следует вначале увеличить каждую из частей зеркала с помощью metaattach, как показано ниже, а затем - всю файловую систему с помощью growfs.
Особым случаем является расширение журналируемого метаустройства (trans metadevice), которое состоит из двух устройств - главного и журналирующего. Увеличивается только размер главного устройства, а затем growfs "напускается" на само журналируемое метаустройство. Вообще говоря, можно увеличить и размер журналирующего устройства, но это не является обязательным.
Програма growfs на время модификации файловой системы блокирует запись в нее. Можно сократить время блокировки файловой системы, выполняя ее увеличение по частям. Например, мы хотим увеличить файловую систему размером 2 Гбайт до размера 8 Гбайт. Можно это делать поэтапно, добавляя по 16 Мбайт за этап, дав ключ s для явного указания размера общего размера новой файловой системы на каждом этапе. Число, следующее за ключом s, интерпретируется как общее число секторов новой файловой системы на каждом этапе и должно быть кратно размеру цилиндра в секторах. Иначе говоря, файловая система должна содержать целое число цилиндров.
Подробнее об ограничениях, связанных с размером разделов, рассказано в руководстве по newfs и growfs.
Представим себе, что требуется увеличить размер раздела /dev/dsk/c1t0d0s3, на котором расположена файловая система /export. Для этого нам потребуется вначале преобразовать этот раздел в метаустройство, поскольку добавлять дополнительное пространство можно только к метаустройству. Допустим, добавлять к существующему разделу мы будем пока еще пустой, не содержащий файловой системы раздел /dev/dsk/c2t0d0s3:


metainit -f d8 2 1 c1t0d0s3 1 c2t0d0s3
Эта команда вызывает объединение разделов /dev/dsk/c1t0d0s3 и /dev/dsk/c2t0d0s3 в новое метаустройство d8. Теперь изменяем /etc/vfstab так, чтобы файловая система /export монтировалась на метаустройство d8:
#device device mount FS fsck mount mount #to mount to fsck point type pass at boot options /dev/md/dsk/d7 /dev/md/dsk/d7 /export ufs 2 yes -
Демонтируем /export и снова монтируем его (при монтировании будет использовано новое устройство из /etc/vfstab):
umount /export mount /export
Запускаем growfs для расширения файловой системы на новый раздел:
growfs -M /export/dev/md/rdsk/d8
Ключ M нужен программе growfs для того, чтобы можно было увеличить размер смонтированной файловой системы. В процессе изменения размера запись в файловую систему блокируется программой growfs.
Файл /etc/lvm/md.tab содержит таблицу метаустройств, которая служит файлом настроек для запуска программы metainit при старте системы.

Роли


Роли могут быть назначены пользователям. Предопределенных ролей не существует, но можно легко создать новые роли, назначив им один из трех предопределенных профилей. Предполагается, что системный администратор будет самостоятельно создавать роли и назначать их, по мере необходимости, тем или иным пользователям. Соответствие ролей и пользователей (т.е. разрешение конкретному пользователю играть ту или иную роль) описывается файлом /etc/user_attr:

# Copyright (c) 1999-2001 by Sun Microsystems, Inc. # All rights reserved. # # /etc/user_attr # # user attributes. see user_attr(4) # #pragma ident "@(#)user_attr 1.5 01/12/11 SMI" # root::::auths=solaris.*,solaris.grant;profiles=All lp::::profiles=Printer Management adm::::profiles=Log Management printmgr::::type=role;profiles=All

Значащих полей в этом файле всего два: имя пользователя (или роли) и атрибуты. Среди атрибутов выделяется атрибут type: он имеет значение role для записи о роли и normal - о пользователе. По умолчанию подразумевается запись о пользователе.

Формат записей в /etc/user_attr следующий:

user:qualifier:res1:res2:attr

где:

user - имя пользователя, такое как в /etc/passwd;

qualifier - зарезервировано;

res1 - зарезервировано;

res2 - зарезервировано;

attr - атрибуты, разделенные точкой с запятой, вида имя=значение; допустимые атрибуты - это auths, profiles, roles, type and project.

Атрибут auths предназначен для перечисления предопределенных прав (authorizations), в том числе и групп прав, где значение "все возможные" представляется символом "звездочка" (*), например,

auths=solaris.printer.*

обозначает все возможные права набора прав solaris.printer.

Атрибут roles позволяет разрешить пользователю играть различные роли, здесь они перечисляются через запятую. Если в строке, описывающей пользователя, не указан атрибут roles, пользователю запрещается играть какие бы то ни было роли. Например, запись о ролях может быть такой:

roles=printmgrs, useradmin

Атрибут type служит для определения того, относится ли текущая запись к обычному пользователю или же описывает роль. Для обычного пользователя следует указывать атрибут

type=normal

и для роли -

type=role

Аналогичным образом может быть назначен проект (project) и профиль прав (profiles) для пользователя или роли.



Rpcbind: объявление служб RPC


Для начала следует запустить программу rpcbind, если она еще не запущена. Скорее всего, она запускается при старте вашей системы, если это действительно Solaris. Эта программа, как мы помним, преобразует номера вызовов процедур RPC в номера портов TCP и UDP. При запуске любого RPC-сервера, т.е. программы, работающей с протоколом RPC, программа rpcbind получает от этого RPC-сервера информацию о том, какие номера процедур RPC он намерен обслуживать и через какой порт TCP (UDP) ему следует направлять запросы.

Когда клиент делает RPC-вызов, происходит выяснение требуемого номера порта на машине сервера у rpcbind.

Поэтому rpcbind должен быть запущен до того, как будет запущен любой из RPC-серверов. При аварийном завершении rpcbind необходимо вначале перезапустить rpcbind, и затем перезапустить все RPC-серверы.

Для проверки готовности всех служб NFS к работе через rpcbind используется команда rpcinfo -p:

rpcinfo -p program vers proto port service 100000 4 tcp 111 rpcbind 100000 3 tcp 111 rpcbind 100000 2 tcp 111 rpcbind 100000 4 udp 111 rpcbind 100000 3 udp 111 rpcbind 100000 2 udp 111 rpcbind 100232 10 udp 32772 sadmind 100083 1 tcp 32771 100221 1 tcp 32772 100068 2 udp 32773 100068 3 udp 32773 100068 4 udp 32773 100068 5 udp 32773 100229 1 tcp 32773 metad 100230 1 tcp 32774 metamhd 100242 1 tcp 32775 metamedd 100001 2 udp 32774 rstatd 100001 3 udp 32774 rstatd 100001 4 udp 32774 rstatd 100002 2 udp 32775 rusersd 100002 3 udp 32775 rusersd 100002 2 tcp 32776 rusersd 100002 3 tcp 32776 rusersd 100008 1 udp 32776 walld 100012 1 udp 32777 sprayd 100011 1 udp 32778 rquotad 100024 1 udp 32779 status 100024 1 udp 32777 status 100133 1 udp 32779 100133 1 tcp 32777 100021 1 udp 4045 nlockmgr 100021 2 udp 4045 nlockmgr 100021 3 udp 4045 nlockmgr 100021 4 udp 4045 nlockmgr 100021 1 tcp 4045 nlockmgr 100021 2 tcp 4045 nlockmgr 100021 3 tcp 4045 nlockmgr 100021 4 tcp 4045 nlockmgr 300598 1 udp 32784 300598 1 tcp 32781 805306368 1 udp 32784 805306368 1 tcp 32781 100249 1 udp 32785 100249 1 tcp 32782 1289637086 5 tcp 32787 1289637086 1 tcp 32787 100005 1 udp 32814 mountd 100005 2 udp 32814 mountd 100005 3 udp 32814 mountd 100005 1 tcp 33201 mountd 100005 2 tcp 33201 mountd 100005 3 tcp 33201 mountd 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100227 2 udp 2049 nfs_acl 100227 3 udp 2049 nfs_acl 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100227 2 tcp 2049 nfs_acl 100227 3 tcp 2049 nfs_acl

При запуске системы в многопользовательском режиме 3 rpcbind запускается автоматически, а службы NFS - в случае, если существует файл /etc/dfs/dfstab.



Сервер NFS и бездисковые станции


Для бездисковых станций через сеть с помощью NFS экспортируются все файловые системы, которые им нужны, и даже область свопинга. Поэтому, настраивая экспорт файловой системы для бездисковых станций, следует убедиться, что для них экспортируется корневая файловая система и область свопинга.

Под "корневой файловой системой" мы здесь понимаем определенный заранее каталог на сервере NFS, играющий роль корневой файловой системы для бездисковой станции. Собственный корневой каталог сервера не следует экспортировать вообще.

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

Табл. 18.1 демонстрирует соответствие экспортируемых на сервере каталогов и точек монтирования на бездисковых рабочих станциях.

Таблица 18.1. Соответствие каталогов сервера NFS и точек монтирования бездисковых рабочих станций

Экспортируемые каталоги на сервере

Импортируемые каталоги на бездисковом компьютере

Пояснение

Параметры монтирования

/export/root/<hostname> / корневой каталог -o nosuid
export/exec/<platformname> /usr Каталог выполняемых файлов (Shared Product Object Tree - SPOT). Содержимое этого каталога зависит от аппаратной платформы, разным платформам должны монтироваться разные каталоги -o ro
/export/home/<hostname> /home возможно потребуется -o nosuid
/export/share /usr/share -o ro
/export/swap/<hostname> Применяется на бездисковых клиентах в качестве удаленного пространства подкачки

Обычным пользователям сервера доступ к каталогу /export обычно запрещают, ибо этот каталог предназначен только для монтирования его клиентами, управление этим каталогом осуществляет администратор, работая от имени root.

Каталог /export/root следует экспортировать с правами пользователей на чтение и запись.

Параметр nosuid запрещает клиентам устанавливать бит setuid для файлов на смонтированной файловой системе NFS.
Этот параметр может быть полезен для случаев, когда файл принадлежит пользователю root клиента или пользователю, чей uid совпадает с uid наделенного большими правами пользователя в какой-либо из систем сети (особенно - сервера NFS).

Вместо того чтобы использовать при монтировании каталога /export/root параметр nosuid, может оказаться достаточным запретить пользователям сервера NFS доступ к этому каталогу.

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

При экспорте каталога /export/home можно пойти двумя путями:

экспортировать каталог /home сервера, так, чтобы дать возможность пользователям работать на сервере интерактивно в своем домашнем каталоге и монтировать этот же каталог по сети при работе на других компьютерах; экспортировать каталог /export/home сервера с тем, чтобы пользователи на сервере не имели домашних каталогов (или же, что менее удобно, имели разные домашние каталоги при работе на сервере и при работе на остальных компьютерах сети).

В первом случае следует обязательно указать параметр nosuid для монтирования этого каталога через NFS.


Сетевые службы


Сетевые службы делятся на два типа: запускаемые в начале работы системы и запускаемые по запросу. Те, что запускаются в начале, обычно функционируют постоянно, до завершения работы системы или до аварийного завершения. К таким службам относятся все демоны с относительно высокой постоянной нагрузкой, которые должны давать быстрый ответ клиенту: почтовые серверы, web-серверы, демоны sshd и многие другие. К запускаемым по запросу относятся службы, которые нужны реже, и между скоростью доступа к ним и эффективностью использования ресурсов часто выбирается эффективность (незачем отнимать ресурсы у системы, запуская постоянно действующие, но редко требуемые процессы). К службам второго типа относятся telnetd, ftpd и другие.

Службы по запросу запускает демон inetd. При запуске или при получении сигнала SIGHUP он читает файл конфигурации /etc/inetd.conf, где определено, какие службы можно запускать по запросу, и какие программы при этом следует запускать.



Система контроля версий


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

В разных системах UNIX могут использоваться разные системы контроля версий. Очень широко распространена CVS, применяющаяся, в частности, для обновлений FreeBSD. В Solaris такая система носит название SCCS (Source Code Control System). Общим для всех систем такого типа является наличие репозитория, т.е. каталога, в котором хранятся копии документов (файлов) и их описания.

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

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

Кроме того, комментарии, которыми следует снабжать все файлы, помещаемые в репозиторий, помогут разобраться в смысле давно сделанных изменений и, при необходимости, установить их авторство. Согласитесь, системный администратор иногда очень хочет знать, кто из двух его помощников-стажеров изменил пароль босса и сам того не заметил... Система SCCS поможет узнать, кто автор самых полезных и самых вредных изменений в системе.

Поскольку SCCS создает копии файлов, которые, возможно, не предназначены для публичного доступа к ним, при создании каталога репозитория следует соблюдать осторожность в назначении прав доступа к нему. Например, вы можете счесть полезным запрет чтения такого файла всем, за исключением пользователя root и ответственной за резервное копирование роли.



если перед вами стоит задача


Итак, если перед вами стоит задача проектирования системы на платформе x86, постарайтесь учесть опыт (в том числе и печальный!) автора этих строк.

Во-первых, используйте ту аппаратуру, которая точно находится в HCL Solaris вашей версии. Описание сложностей, которые связаны с пренебрежением этим правилом, содержится в лекции 3, например.

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

В-третьих, жесткий диск должен быть произведен на заводе с хорошей репутацией, справьтесь у хорошо знакомого вам продавца и нескольких независимых экспертов, особенно занимающихся ремонтом жестких дисков, какие жесткие диски в данный момент считаются самыми надежными. Часто бывает, что какой-нибудь производитель выпускает отличные SCSI-диски на одном заводе и отвратительные IDE-диски - на другом под той же маркой. Избегайте привлекательных знакомых товарных знаков самих по себе - всегда интересуйтесь качеством именно того товара, который покупаете.

В-четвертых, НИКОГДА не пробуйте самые последние новинки на том оборудовании, которое должно выполнять какие-то жизненно важные функции. Если душа просит экспериментов, проведите их на том компьютере, крах которого никому не принесет слез или потерянных данных.

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



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

Самодельные устройства, регулирующие напряжение в сети, оголенные провода, плохие контакты в розетках и старая проводка приводят (как ни странно!) к пожарам. Автор был свидетелем нескольких пожаров, вызванных именно такими тривиальными причинами - поверьте, качеству проводки и электрооборудования надо уделить самое пристальное внимание при монтаже любой компьютерной системы.

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

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

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

Планируйте замену оборудования заранее! Сервер на платформе x86 не должен работать как часы в течение десятилетий; такое оборудование потребует полной замены через пять лет, более того, уже через год-два оно потеряет в цене половину. Если вы заботитесь не только о надежности работы системы, но и об экономической эффективности, следует планировать замену оборудования с продажей старого не реже, чем раз в два года.


Служба печати на сервере печати


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

По пути от приложения, инициирующего печать, до принтера задание на печать должно быть обработано несколькими программами: программой lp (или lpr) - для постановки в очередь на печать, lpsched - для обработки очереди, возможно, программами inetd и in.lpd - в случае, если задание отправлено на удаленную машину.

Рассмотрим наиболее обычный вариант печати - с клиентской машины командой lp на удаленный принтер, который доступен через компьютер printbox.

Мы распечатываем текстовый файл data.txt с помощью команды

lp -d printbox:hplj data.txt

Команда lpr в Solaris - это символическая ссылка на команду lp, поэтому что вызывать - lpr или lp - безразлично, будет вызвана одна и та же программа. Название lpr сохранено ради совместимости с другими системами UNIX.

Задание на печать формируется командой lp и отправляется на компьютер printbox. Там его должен ждать демон inetd. Как только задание добирается до порта 515 на компьютере printbox, демон inetd на нем запускает программу in.lpd (согласно записи о службе printer в /etc/inetd.conf) и передает ей пришедшее задание. Программа in.lpd помещает задание в область буферизации (/var/spool/lp/*) и сообщает программе lpsched, что ей пришло задание. Дальнейшая обработка задания ложится на службу печати, т.е. на lpsched. Именно эта программа запускает интерфейсную программу принтера, которая уже непосредственно взаимодействует с принтером.

Такая схема, показанная на рис. 22.1, иллюстрирует взаимодействие клиента и сервера печати при условии, что версия системы клиента печати не ниже Solaris 2.0, а версия системы сервера печати - не ниже Solaris 2.6.

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



Рис. 22.1. Взаимодействие подсистем печати на компьютере - клиенте Solaris 2.6 и сервере печати Solaris 8

программа lp положит задание в локальную область буферизации (spool) на клиенте печати и передаст запрос локальному демону lpsched; локальный демон lpsched обратится к локальному демону lpNet, который запустит дочерний процесс lpNet, а тот передаст задание на сервер печати; на сервере печати демон listen передаст запрос местному демону lpNet, который, в свою очередь, запустит дочерний процесс; этот дочерний процесс lpNet на сервере печати положит задание в область буферизации на сервере печати и передаст задание lpsched; lpsched на сервере печати отправит задание на принтер.

Это иллюстрирует рис. 22.2.

Рисунки взяты из Методического пособия компании Sun Microsystems "Системное администрирование ОС Solaris 8, часть 1".


Рис. 22.2.  Взаимодействие подсистем печати на компьютере - клиенте Solaris 2.0 и сервере печати Solaris 2.5.1


Службы имен


В любой сети всегда возникает вопрос централизованного хранения информации о пользователях и компьютерах. Такого рода информация включает в себя:

учетные записи пользователей; имена компьютеров и их соответствие IP-адресам; псевдонимы адресатов электронной почты (такие как postmaster, abuse и т.п.).

Помимо этих основных элементов, удобно централизованно хранить не только имена и пароли, но и все остальные свойства существующих в сети объектов.

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

Смысл работы NIS состоит в том, чтобы сделать некую конфигурационную информацию общедоступной в пределах группы компьютеров. Большая группа компьютеров вместе со своими пользователями и группами называется доменом NIS. В домен NIS, например, могут входить все компьютеры и сотрудники организации.

В то же время в пределах домена NIS могут быть выделены так называемые сетевые группы, логически объединяющие некоторые компьютеры и пользователей. Сетевые группы описываются файлом /etc/netgroup. Этот файл, наряду с /etc/passwd и /etc/group, является одним из тех, что делаются общедоступными и централизованными в сети NIS.

Информация о компьютерах, пользователях, группах, сетевых группах и т.п. разделяется между компьютерами в сети посредством создания из текстовых файлов /etc/passwd, /etc/netgroup и ряда других так называемых карт NIS.
Карта NIS - это хэшированная база данных, которую использует сервер NIS для ответа на запросы клиентов.

Для превращения файлов типа /etc/passwd в карту NIS требуется программа ypmake. Программы, связанные с NIS, имеют имена, начинающиеся с yp, поскольку в момент создания NIS носила название Sun Yellow Pages, но название пришлось изменить, поскольку словосочетание Yellow Pages оказалось зарегистрированной маркой другой компании. На именовании программ это не отразилось. Программа ypmake не изменяет исходный файл, она лишь генерирует на его основе новый файл - карту NIS.

На основе некоторых системных файлов из тех, что подлежат разделению через NIS, например, passwd, потребуется сгенерировать две карты, так как хэширование базы данных можно осуществить только по одному ключу, а искать в карте может понадобиться по нескольким ключам. В случае passwd это именно так - надо искать и UID по имени пользователя, и имя пользователя по UID. Поэтому генерируются две карты - passwd.byname и passwd.byuid.

Запуск сервисов NIS на компьютере осуществляется командой /usr/lib/netsvc/yp/ypstart, а их остановка - командой /usr/lib/netsvc/yp/ypstop.

Ниже рассказано, какие именно демоны запускаются на серверах и клиентах NIS, в том числе и при выполнении команды /usr/lib/netsvc/yp/ypstart.

Узнать о том, к какому домену причисляет себя компьютер, можно командой

domainname

Если эта команда сообщает, что компьютер не входит в домен NIS, ввести компьютер в домен можно командой domainname имя_домена_NIS, после чего следует проверить наличие и создать при необходимости файл /etc/defaultdomain и каталог /var/yp/binding/имя_домена_NIS.

В каталоге /etc/ могут быть заготовки файлов nsswitch.conf для разных конфигураций сети. Если вы просто копировали /etc/nsswitch.nis в /etc/nsswitch.conf, не забудьте о том, что при желании использовать DNS для поиска адресов компьютеров в сети, следует исправить строку, определяющую порядок использования служб имен для поиска адресов компьютеров так, чтобы dns предшествовало nis:

hosts: dns nis files

Для запрещения загрузки служб NIS при старте системы достаточно удалить файл /etc/defaultdomain.

В каталоге /var/yp может находиться файл makefile или Makefile для автоматизированной модификации настроек NIS и распространения карт по сети. Если он есть, имеет смысл изучить его и пользоваться, при необходимости, командой make для выполнения описанных в нем действий.


Снижение частоты синхронизации файлового кэша с диском


При частых и объемных операциях с файлами, файловый кэш быстро заполняет значительный объем памяти. В системах Solaris до версии 8 он даже конкурировал с процессами за оперативную память. Процесс fsflush регулярно (по умолчанию - раз в 30 секунд) "сбрасывает" на диск содержимое кэша, обеспечивая таким образом синхронизацию кэша и файловой системы. Если количество открытых файлов велико, эта синхронизация может приводить и к потерям времени и к чересчур высокой загрузке дисковой подсистемы.

Демон fsflush руководствуется значением двух переменных, squid и tune_t_fsflushr, - значение им можно присвоить в файле /etc/system. Для систем с большим объемом памяти установленное по умолчанию значение squid в 30 с делает процесс fsflush чересчур дорогостоящим.

Для того чтобы поубавить аппетит fsflush, время цикла синхронизации следует увеличить, изменив в бо'льшую сторону значение squid. Поскольку fsflush оказывает влияние на всю систему, лучше всего, чтобы он работал в течение более коротких промежутков времени. Для этого значение tune_t_fsflushr (время, отведенное fsflush на синхронизацию) должно быть меньше: выделив демону меньшее число секунд, вы заставите его выполнять меньшую по объему запись.



Совместимость NFS и других служб разделяемых каталогов


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

Служба NFS предполагает работу модели клиент-сервер, причем на компьютерах-клиентах и компьютерах-серверах запускаются разные программы для обеспечения доступа к общим каталогам на сервере.

Поскольку компьютеры на рабочих местах сотрудников в России обычно управляются Windows-системами, в качестве файловых серверов часто используются также Windows-системы. Однако нередко возникает желание установить UNIX на файл-сервер, чтобы повысить надежность, сократить затраты на оборудование или использовать этот же сервер для ряда других корпоративных нужд: в качестве web-сервера, сервера баз данных и т.п. Чтобы не устанавливать дополнительное ПО для поддержки NFS, в таком случае достаточно установить пакет samba на UNIX-машину. Он позволит ей "прикинуться" Windows-сервером так, чтобы все клиентские компьютеры воспринимали его как самый обычный файл-сервер или принт-сервер Windows-сети. Пакет samba обеспечивает поддержку "родного" для Windows-сетей протокола SMB.

В тех случаях, когда в сети работают несколько UNIX-компьютеров и им нужно обращаться к одному файл-серверу, имеет смысл использовать механизм NFS (network file system).

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



Создание файла rules


Программа suninstall в процессе установки методом Custom JumpStart использует файл rules для определения профиля установки, соответствующего каждому конкретному компьютеру. Поэтому сейчас необходимо создать файл rules в каталоге /jumpstart. Этот файл должен содержать однозначные указания программе suninstall, на основании каких свойств компьютера можно выбрать для него тот или иной профиль установки.

Критерии выбора могут разниться - от IP-адресов сети, в которой находится компьютер, до его архитектуры, объема памяти или модели. Список основных доступных ключевых параметров содержится в таблица 24.1.

Таблица 24.1. Некоторые ключевые параметры для файла rules

Ключевой параметр

Значение

Смысл

Пример

arch

processor_type

может быть sparc или i386

Тип процессора, можно узнать по команде uname -a arch sparc
disksize actual_disk_name size_range

actual_disk_name

имя диска в форме cxtydz, например c0t3d0 или ключевое слово rootdisk

rootdisk означает, что это либо диск с предустановленным образом загрузки (новая система с Factory JumpStart), либо диск c0t3d0s0, либо первый обнаруженный при включении машины диск

size_range - размер диска в мегабайтах, указывается диапазон возможных значений

disksize c0t3d0 250-300
domainname actual_domain_name Имя домена NIS, к которому себя относит эта система, имеет смысл только для случаев обновления уже установленной системы, имя можно узнать по команде domainname domainname ENGNR
hostaddress actual_IP_address IP-адрес системы hostaddress 192.168.1.3
hostname actual_host_name Имя комьютера, выдается по команде uname -n hostaname synny.pu.ru
installed slice version

slice имя раздела диска в форме cwtxdysz, например c0t3d0s3, или rootdisk

version - имя версии или слово upgrade. Последнее означает любую версию, начиная с Solaris 2.1

Слово any означает любую версию SunOS или Solaris.

installed c0t3d0s1 Solaris_9
karch actual_platform_group

Допустимые значения sun4m, sun4u, i86pc, prep. Список соответствий моделей этим значениям содержится в Solaris 9 Sun HardwarePlatform Guide

Если система уже установлена, значение этого параметра можно получить командой arch -k или uname -m

karch i86pc
memsize physical_mem

Размер физической (оперативной памяти), указывает диапазон в мегабайтах или конкретное значение (также в мегабайтах)

Уже установленная система сообщает это значение по команде prtconf (во второй строке вывода)

memsize 64-128
model actual_platform_name

Имя системной платформы. Список соответствий содержится в Solaris 9 Sun Hardware Platform Guide

Можно узнать на уже установленной системе с помощью команды uname -i

Если этот параметр должен содержать пробелы, замените их на подчеркивания, как в примере

SUNW, Sun_4_50
network network_num Номер сети, в которой располагается система, определяется из IP-адреса и маски, в том числе и если параметры IP получены по DHCP при загрузке network 192.168.3.0
osname Solaris_x Версия уже установленной на компьютере системы Solaris osname Solaris_8

Предположим, наши компьютеры отличаются прежде всего адресами сетей, в которых им предстоит работать: компьютеры SPARC будут работать в сети 192.168.1.0, а x86 - в 192.168.2.0. Тогда файл rules приобретет такой вид:

network 192.168.1.0 - eng_prof network 192.168.2.0 - mark_prof

Чтобы завершить процедуру создания файла rules, следует проверить его командой check:

cd /jumpstart ./check

Если скрипт check не найдет ошибок, он создаст файл rules.ok.



Создание файла sysidcfg


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

echo "system_locale=en_US" > sysidcfg echo "timezone=US/Pacific" >> sysidcfg echo "network_interface=primary {hostname=YOUR HOSTNAME" >> sysidcfg echo " ip_address=YOUR HOST'S IP" >> sysidcfg echo " netmask=255.255.255.0" >> sysidcfg echo " protocol_ipv6=no}" >> sysidcfg echo "terminal=vt100" >> sysidcfg echo "security_policy=NONE" >> sysidcfg echo "root_password=PASSWORD FROM SHADOW FILE" >> sysidcfg echo "name_service=NONE" >> sysidcfg echo "timeserver=localhost" >> sysidcfg chmod 777 sysidcfg

После этого файл sysidcfg готов к употреблению.



Создание каталога /jumpstart и профилей установки


После копирования дистрибутива следует создать каталог /jumpstart, который будет содержать файлы, необходимые для установки методом Custom JumpStart. В него надо копировать файлы, которые содержатся в образце такого каталога в дистрибутиве:

cp -r /export/install/sparc/Solaris_9/Misc /jumpstart_sample /jumpstart

Теперь следует сделать этот каталог доступным в сети, добавив соответствующую команду в /etc/dfs/dfstab:

share -F nfs ro,anon=0 /jumpstart

А затем потребовать экспортировать все указанные в /etc/dfs/dfstab каталоги командой

shareall

Теперь для каждой группы однотипных компьютеров, на которые будет производиться установка, создаются профили установки. Для примера возьмем два профиля - eng_prof и mark_prof, для компьютеров на платформе SPARC и x86 соответственно. Оба профиля следует разместить в каталоге /jumpstart:

cat /jumpstart/eng_prof install_type initial_install system_type standalone partitioning default cluster SUNWCprog filesystem any 512 swap

Первая строка говорит о том, что мы выполняем установку новой системы, а не обновление. Вторая строка выбирает тип установки, третья определяет, что разбиение дисков будет выполнено по умолчанию, четвертая определяет группу ПО, которая будет установлена (в данном случае - Developer System Support). Пятая строка говорит о том, что на всех устанавливаемых системах объем раздела свопинга будет равен 512 Мбайт:

cat /jumpstart/mark_prof install_type initial_install system_type standalone partitioning default cluster SUNWCuser package SUNWaudio

Все строки, кроме последней, нам уже знакомы. Строка cluster указывает на то, что на компьютеры, для которых будет выбран этот профиль, следует установить группу ПО End User, а строка package требует установить дополнительный пакет ПО поддержки подсистемы звука.



Список свободных страниц (free list)


Список свободных страниц - это набор страниц, из которого страницы извлекаются по запросу процессов. Управление распределением памяти между процессами основано на этом списке. Процессы берут память из него и возвращают ее обратно по завершении. Сканер страниц также возвращает память в список свободных страниц так, как это описано в лекции 7 в разделе "Алгоритм пейджинга".

Каждый раз, когда процесс запрашивает память, происходит так называемая страничная ошибка2) (page fault). Страничные ошибки делятся на три типа:

Легкая страничная ошибка (minor page fault) - процесс попытался получить доступ к странице, которая была изъята сканером страниц, но пока еще не использована повторно другим процессом. Значительная страничная ошибка (major page fault) - процесс пытается получить доступ к странице, изъятой сканером страниц, которая использована повторно и в данный момент уже отдана другому процессу. Ошибка копирования при записи (copy-on-write fault) - процесс пытается записать данные в страницу памяти, которая используется совместно с другими процессами.

О том, как реализовано управление списком свободных страниц в Solaris, говорится в лекции 17. Сейчас нам важны некоторые основные моменты, связанные с производительностью процессов.

После загрузки системы вся виртуальная память распределяется между процессами постранично. Кроме того, в ядре инициализируется специальная таблица, в которой хранятся состояния страниц. Несколько мегабайт памяти ядро резервирует для себя, а оставшееся пространство отходит списку свободных страниц. В какой-то момент, когда процесс запрашивает память, из списка свободных страниц извлекается одна страница, которая и поступает в распоряжение процесса. Такая схема, при которой память выдается по принципу "когда потребуется", называется выделением страниц по запросу (demand paging).

Если список свободных страниц уменьшается до размера lotsfree (см. лекцию 17), ядро запускает специальный поток внутри себя - сканер страниц.
Он начинает искать страницы, которые можно выгрузить на диск с тем, чтобы увеличить размер свободной памяти и пополнить список свободных страниц. Дабы не выгрузить страницы, к которым часто обращаются, сканер страниц работает по двухшаговому алгориму. Просматривая оперативную память в порядке возрастания адресов, он очищает бит MMU (бит "используемости") для каждой страницы. Этот бит устанавливается, когда идет обращение к странице. Сканер страниц ведет просмотр далее, но через некоторое время проверяет бит используемости ранее просмотренных страниц, ожидая доступа к этим страницам и установки их битов используемости. Параметры slowscan и fastscan определяют то время, которое пройдет между очисткой бита MMU и его повторной проверкой так, как это описано в лекции 17, а именно:

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

Если при повторном просмотре ссылочный бит какой-то страницы по-прежнему в исходном состоянии, это значит, что к данной странице не обращались.

Те страницы, чей бит "используемости" не был изменен в течение некоторого времени, выгружаются на диск, и освобожденная память пополняет список свободных страниц.

Некоторые страницы (например, принадлежащие разделяемым библиотекам) могут разделяться между многими процессами, и при записи в такую страницу возникает ошибка копирования при записи (copy-on-write fault). Как только это произойдет, из списка свободных страниц извлекается чистая страница и создается копия первоначальной разделяемой страницы для того процесса, который требовал записать данные; в дальнейшем процесс работает именно со своей копией разделяемой страницы. Когда процесс завершается, все его страницы, за исключением тех, которые он делил с другими процессами, возвращаются в список свободных страниц.

О статистических показателях пейджинга и свопинга, говорящих о нехватке памяти в системе, речь пойдет в лекции 17.Сейчас же мы должны представлять себе, что если программа vmstat сообщает о постоянной активности устройства свопинга, а частота сканирования страниц высока (в Solaris 8 и более новых версиях она вообще должна быть близка к нулю в обычной ситуации), то следует подумать об уменьшении числа одновременно запущенных процессов или об увеличении объема оперативной памяти.


Статистика сервера NFS


Для получения статистики о работе сервера NFS следует использовать команду nfsstat на таком сервере:

nfsstat -s Server rpc: Connection oriented: calls badcalls nullrecv badlen xdrcall dupchecks 0 0 0 0 0 0 dupreqs 0 Connectionless: calls badcalls nullrecv badlen xdrcall dupchecks 33 0 0 0 0 3 dupreqs 0 Server nfs: calls badcalls 33 0 Version 2: (0 calls) null getattr setattr root lookup readlink 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% read wrcache write create remove rename 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% link symlink mkdir rmdir readdir statfs 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% Version 3: (33 calls) null getattr setattr lookup access readlink 0 0% 5 15% 1 3% 4 12% 13 39% 0 0% read write create mkdir symlink mknod 0 0% 1 3% 1 3% 0 0% 0 0% 0 0% remove rmdir rename link readdir readdirplus 0 0% 0 0% 0 0% 0 0% 1 3% 0 0% fsstat fsinfo pathconf commit 3 9% 3 9% 0 0% 1 3% Server nfs_acl: Version 2: (0 calls) null getacl setacl getattr access 0 0% 0 0% 0 0% 0 0% 0 0% Version 3: (0 calls) null getacl setacl 0 0% 0 0% 0 0%



Структура подсистемы PAM - присоединяемых модулей аутентификации


Новая модель аутентификации - присоединяемые модули аутентификации (PAM, Pluggable Authentication Modules) - была предложена в 1995 году сотрудниками SunSoft Самаром (V. Samar) и Шемерсом (R. Schemers). Эта модель предполагала, что любое приложение будет работать со стандартным интерфейсом аутентификации, а механизм аутентификации сможет быть различным - для аутентификации в разных базах данных пользователей (NIS, TACACS, файлах /etc/passwd и /etc/shadow, контроллерах домена Microsoft Windows и т.п.). Более того, предполагалось, что системный администратор должен иметь возможность выбрать, какой вид аутентификации будет использоваться в системе по умолчанию и/или для каждой из служб в отдельности: от ввода текстового пароля до биометрической проверки и использования смарт-карт.

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

В PAM с каждым приложением можно связать не один, а несколько механизмов аутентификации, например, потребовать от пользователей аутентифицироваться и через Kerberos, и через RSA.

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

Архитектура PAM - модульная, и позволяет добавить любой модуль с поддержкой какого угодно алгоритма аутентификации, но при этом для обратной совместимости PAM API поддерживает ранее существовавшие вызовы подпрограмм аутентификации.

Добавление PAM в Solaris не означает, что системный администратор обязан специальным образом настраивать систему аутентификации, PAM лишь предоставляет такую возможность. Если нет желания переделывать настройки по умолчанию, то для пользователей все останется, как было раньше. А системный администратор будет помнить, что каталог /etc/pam.d, в котором хранятся настройки PAM, трогать не следует.



Свопинг


Если системе в течение некоторого времени (обычно 30 секунд подряд) не хватает памяти (объем свободной оперативной памяти падает ниже desfree), то начинается свопинг процессов. Планировщик задач выгружает те процессы, которые не претендовали на процессорное время в течение более чем maxslp секунд. По умолчанию maxslp равно 20. Этот режим свопинга называется мягким.

Если дело дошло до того, что памяти меньше, чем desfree, и, кроме того, два и более процессов выстроились в очередь к процессору, а активность пейджинга превышает maxpgio, начинается жесткий свопинг. Это означает, что ядро выгружает модули и страницы кэша, а затем начинает последовательно выгружать процессы до тех пор, пока объем свободной памяти не станет больше desfree.

Не выгружаются:

процессы классов планирования SYS и RT; процессы, запускаемые в данный момент или остановленные по сигналу (например, при отладке); процессы, завершающие работу; процессы, находящиеся в состоянии зомби; системные потоки; процессы, которые блокируют другие, более высокоприоритетные потоки.



Tar


Для сжатия больших файлов в UNIX изначально использовалась программа compress. Она сжимала файл, после сжатия добавляла к имени файла .Z. Программа compress до сих пор поставляется практически со всеми диалектами UNIX. В IRIX и некоторых других системах она является стандартной утилитой сжатия. Чтобы вернуть файл, сжатый compress, к прежнему, несжатому состоянию используется uncompress.

В Linux и FreeBSD, а также во многих других диалектах для сжатия применяют gzip. Он использует тот же алгоритм сжатия LZW, что и WinZip или pkzip, известные вам по системам Microsoft, однако не совместим с ними по формату файлов. Программа WinZip for Windows понимает форматы gzip, а gzip ее форматы не понимает. Для распаковки файлов, сжатых gzip, используют gunzip. Большинство версий gzip не умеют сжимать каталоги с их содержимым - только файлы.

Есть еще утилиты zip и unzip, которые работают с теми же форматами файлов, что и pkzip, WinZip и другие архиваторы в Microsoft-системах. Они редко используются в UNIX, только если нужно обеспечить совместимость с Windows-системами.

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

Затем удобно сжать получившийся файл с помощью gzip, чтобы он занимал меньше места. Многие дистрибутивы программных пакетов в UNIX упакованы tar и gzip. У команды tar даже есть ключ z. Он говорит tar, что после упаковки файлов в архив нужно вызвать gzip для сжатия. Такой же ключ используется и для распаковки - когда tar перед тем, как начать свою работу, вызывает gunzip.

Например, мне нужно упаковать дистрибутив apache, который лежит в /home/apache:

cd /home tar cvzf apache.tar.gz apache/*

Всего три команды в UNIX принимают (и в некоторых версиях - требуют) ключи без знака "минус" перед ними.
Это ps, dump и tar. Мы использовали для создания архива следующие ключи:

с - create - создать архив; v - verbose mode - выводить имена всех пакуемых файлов на экран; z - zip - после упаковки вызвать gzip для сжатия; f - file - записать результат в файл, который указан после ключа f, а не на первый ленточный накопитель, как по умолчанию; apache.tar.gz - это имя архива, а apache/* - то, что надо упаковать. Лучше всего запаковывать целый каталог, а не входить в него и паковать содержимое, вот так:

# так делать не надо cd /home/apache tar cvzf apache.tar.gz *

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

tar xzvf apache.tar.gz

в том каталоге, где лежит архив, создастся подкаталог apache (помните, там было сказано "apache/*"?). И уже в него будут распакованы все файлы и подкаталоги архива. В этой команде tar мы использовали один незнакомый ключ - x. Он требует распаковать архив.


Терминология NFS


После настройки NFS-сервера UNIX-компьютер будет предоставлять доступ внешним пользователям к некоторым каталогам своей файловой системы. Такое предоставление доступа называется "экспортом": говорят, что система экспортирует свои каталоги. Как именно каталоги будут экспортироваться, определяется списком, который задает системный администратор. В большинстве систем UNIX этот список содержится в файле /etc/exports, но в Solaris он находится в другом файле - /etc/dfs/dfstab.

NFS работает посредством механизма удаленного вызова процедур (RPC - Remote Procedure Call).



Трансляция адресов и фильтрация пакетов


"Трансляция", или "подстановка" адресов (NAT - network address translation) широко распространена в таких системах UNIX, как Linux и FreeBSD. В Solaris нет поставляемого в комплекте с системой пакета, который позволял бы выполнять трансляцию адресов. Так как эта функция может понадобиться в сети, в том числе и там, где устанавливать FreeBSD или Linux нецелесообразно, существуют по крайней мере два пакета - совершенно бесплатный и бесплатный на определенных условиях - которые обладают функциональностью NAT. Это пакет IPFilter (бесплатен и доступен для многих систем UNIX) и пакет SunScreen от Sun Microsystems для Solaris. Оба дают возможность как подставлять "честные" адреса при передаче пакетов в Интернет из сетей с "приватными" IP-адресами, так и выполнять "фильтрацию" пакетов, т.е. разрешать только определенные виды соединений, с учетом адресов и портов отправителя и получателя пакетов, используемых протоколов и т.п. Первый управляется из командной строки, второй - с помощью графического интерфейса.

IPFiter и SunScreen являются полноценными фильтрами пакетов. Программы этого типа также называют брандмауэрами (brandmauer) или файрволами (firewall).

Особенностью IPFilter является то, что, в отличие от других популярных программ фильтрации пакетов, она выполняет проверку пакета на соответствие ВСЕМ правилам таблицы фильтрации, поэтому, если в таблице правил за более строгими идут менее строгие правила, к пакету будут применены менее строгие. Например, если запрещен входящий трафик с адреса 192.168.8.7, но, кроме того, разрешен входящий трафик из сети 192.168.8/25, то фактически пакеты с адреса 192.168.8.7 будут проходить сквозь фильтр. Подробнее о правилах фильтрации можно узнать из руководства по соответствующим пакетам.

Программа IPFilter доступна по адресу http://cheops.anu.edu.au/~avalon/ip-filter.html (текущая версия 4.1.12), а SunScreen - http://wwws.sun.com/software/securenet/lite/download.html.

 

1)   Строго говоря не номер компьютера, а номер сетевого интерфейса, поскольку IP-адрес назначается интерфейсу, а не компьютеру; далее мы для краткости будем употреблять термин "номер компьютера". Можем оправдывать это тем, что у компьютере в сети может быть несколько номеров - это же не серийный номер двигателя:

  2)   RFC - Request For Comments - стандарты, используемые в сети Интернет. Текст стандартов можно бесплатно получить на сайте www.ripn.net

  3)   ICANN - www.icann.org - координационная структура, ответственная за распределение IP-адресов и имен доменов в Интернете.

  4)   Для более короткой запаси маски часто указывают просто длину номера в сети в битах через слэш, или , что то же самое, количество двоичных единиц в маске, например, 199.14.8.0/22.

НАЗАД ВПЕРЕД

<
/td>

 

Управление оперативной памятью с помощью rcapd


В системе Solaris, начиная с версии 9 выпуска 12/03, появился демон укупорки ресурсов (Resource Capping Daemon), который управляет тем, как процессы используют оперативную память. Управление выполняется на попроектной основе, т.е. ресурсы ограничиваются для конкретных проектов.

Демон укупорки ресурсов rcapd занимается ограничением потребления физической памяти для процессов, относящихся к проектам с установленными ограничениями. Существуют также программы rcapstat и rcapadm, предоставляющие возможность управления работой rcapd и получения статистики.



Управление принтерами с помощью admintool


В версиях Solaris, более ранних, чем Solaris 8, управление принтерами осуществлялось посредством admintool. В настоящее время с помощью этой программы можно просмотреть свойства установленных в системе принтеров, но использовать ее для модификации этих свойств или добавления новых принтеров не следует. Для этого существует программа Solaris Print Manager, которая позволяет управлять всеми свойствами принтеров, добавлять новые и удалять ненужные принтеры из системы.



Управление принтерами с помощью Solaris Management Console


В настоящее время в Solaris (версия 9) не реализовано управление принтерами с помощью Solaris Management Console. В лекции 26 рассказывается о том, какие задачи можно выполнять в этой программе.



Управление ролями в Solaris Management Console


В Solaris Management Console возможно управление ролями (пункт Administrative Roles) в графическом интерфейсе. Для этого потребуется ввести имя и пароль роли, которая имеет право на такое администрирование (часто это пользователь root).

Рисунок 21.2 иллюстрирует сказанное: в главном меню Solaris Management Console следует выбрать Users, а для администрирования ролей в открывшемся окне справа - Administrative Roles.


Рис. 21.2.  Главное меню Solaris Management Console

НАЗАД ВПЕРЕД

<
/td>

 

Управление системой с помощью Solaris Management Console


Solaris Management Console (консоль управления Solaris) представляет собой графическую оболочку, написанную на языке Java и предназначенную для наглядного представления ряда настроек системы, а также для их изменения.

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

Solaris Management Console позволяет выполнять задачи системного администрирования с применением более наглядного интерфейса (не все системные администраторы и их ассистенты с легкостью обращаются с любыми командами в командной строке - попробуйте вспомнить без книги и man, какие ключи и какой порядок аргументов у команд setfacl или setquota).

Solaris Management Console - это модульное приложение, которое научено обращаться с низкоуровневыми утилитами управления системой. Редактируя список пользователей в SMC, можно не сомневаться, что в конечном счете будут (автоматически) запущены команды типа useradd или roleadd.

Применяя Solaris Management Console, вы сможете решить следующие задачи (см. рис. 26.1, демонстрирующий основное дерево объектов управления этой программы):

добавлять, изменять их свойства и удалять учетные записи пользователей; добавлять, изменять их свойства и удалять учетные записи проектов; устанавливать и удалять обновления системы (patches); просматривать и модифицировать настройки сети; управлять списком запланированных заданий; монтировать устройства в файловую систему, включая экспортируемые серверами NFS каталоги; управлять экспортом каталогов; управлять отказоустойчивыми наборами дисков или их объединениями (RAID разных уровней, создание псевдоустройств).

Для выполнения этих действий SMC может потребовать от вас дополнительной аутентификации. Некоторые задачи может выполнять не только root, но и пользователи, исполняющие определенные роли в рамках концепции RBAC (см. лекцию 21).

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

Программа Solaris Management Console работает не только в графическом, но и в текстовом режиме, и даже может быть вызвана из скрипта. При вызове графического интерфейса из командной строки достаточно дать команду

smc&

По команде smc запускается собственно консоль управления. При ее работе фактически используется еще два компонента: сервер SMC и программа smcboot, которая запускает этот сервер, как только к ней обратится с запросом консоль управления (при первом запуске smc). Серверы SMC могут быть запущены на одном или нескольких компьютерах для локального или удаленного управления ими.


Рис. 26.1.  Дерево объектов Solaris Management Console

Для того чтобы по приходе запроса от консоли SMC на компьютере стартовал сервер SMC, требуется, чтобы на этом компьютере была заранее запущена программа smcboot. Для ее запуска используется скрипт init.wbem:

/etc/init.d/init.wbem start

В системах до Solaris 8 включительно важно не допускать запуска этого скрипта при запущенном smcboot, так как это вызовет конфликт, который не сможет быть исправлен посредством рестарта smcboot. В Solaris Management Console 2.1 в Solaris 9 в скрипт уже добавлена проверка "не запущен ли уже smcboot?" и бояться повторного запуска скрипта не следует.

Самонастройка сервера и консоли SMC происходит в момент первого запуска и в Solaris Management Console 2.0 может занять много времени (более пяти минут). В версии 2.1 скорость настройки заметно увеличена. В этой версии вы можете наблюдать сообщения о самонастройке, если запустите из командной строки следующие команды подряд перед первым запуском консоли SMC:

/etc/init.d/init.wbem stop Shutting down Solaris Management Console server on port 898. /etc/init.d/init.wbem start Starting Solaris Management Console server version 2.1.0. endpoint created: :898 Solaris Management Console server is ready.

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

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

open - открыть окно консоли, это - действие по умолчанию;

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

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

-B | - -toolbox набор - загрузить указанный набор утилит, набор может быть указан как имя файла или полный URL (http://host.comany.com:port/path_to_file). URL должен указывать на компьютер, где запущен SMC-сервер, если порт не указан явно, подразумевается порт 898.

-D | - -domain домен - выполнять управление указанным доменом, синтаксис указания домена - тип:/имя_компьютера/имя_домена, тип может быть nis, nisplus, ldap, dns или file. Этот ключ применим только для конкретной утилиты, запущенной в режиме командной строки.

-H | - -hostname host_name:port - соединяться с указанным компьютером и портом в предположении, что именно там запущен SMC-сервер.

-Jjava_option - передать исполняющей системе Java указанные параметры, например

smc -J-Dcom.example.boolean=true

-r | - -rolename role_name - явным образом указать роль; для того, чтобы с гарантией был спрошен и пароль, следует использовать ключ -p.

-t - запустить SMC в терминальном режиме; если графический дисплей недоступен, этот ключ будет подразумеваться по умолчанию.

- -trust - безоговорочно доверять коду, который загружен в консоль с сервера, имеет смысл при запуске из скриптов, когда некому ответить на вопрос "доверяете ли вы этому коду?".

-u | - -username user_name - указать иное имя пользователя для аутентификации в SMC; если ключ опущен, подразумевается тот же пользователь, что запускает программу.

При работе с smc могут быть полезны утилиты smccompile(1M), smcconf(1M), smcregister(1M).

НАЗАД 

<

Установка новых шрифтов


Для установки новых шрифтов (например, нестандартных или ранее локализованных) следует использовать программу xfs, а для проверки установленных шрифтов - showfont.



Установка обновлений


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

Для работы с обновлениями и заплатками в Solaris предусмотрен ряд программ: patch, gpatch, patchadd, patchrm, smpatch.

Можно также устанавливать обновления системы с помощью Solaris Management Console. Это делается через пункт "Patches" (подробности см. в лекции 16).

Для того чтобы узнать точно версию вашей системы Solaris и получить информацию обо всех установленных обновлениях системы, следует использовать команду showrev:

showrev -a Hostname: sola Hostid: 284521a Release: 5.9 Kernel architecture: i86pc Aplication architecture: i386 Hardware provider: Domain: Kernel version: SunOS 5.9 Generic_112234-03 November 2002

OpenWindows version: Solaris X11 Version 6.6.1 16 October 2002 No patches are installed

Для изменения текстовых файлов (например, исходных текстов программ или файлов конфигураций) можно применять программу patch. Для ее работы нужно два файла: исходный текстовый файл, подлежащий изменению, и файл заплатки (patch-файл). Файл заплатки обычно имеет формат вывода программы diff, но patch понимает также формат скрипта редактора ed или контекстный вывод diff. Контекстным называется формат вывода, когда в файле различий, создаваемом diff, приводятся не только те строки файлов, которые отличаются друг от друга, но и контекст, в котором они появились (по три строки сверху и снизу от них). Типичный файл заплатки для исходного текста или файла конфигурации выглядит так:

cat system.patch --- system Mon May 17 02:15:34 2004 +++ system.new Tue Jun 22 10:50:48 2004 @@ -76,6 +76,6 @@ * * set test_module:debug = 0x13 -set semsys:seminfo_semmni=100 +set semsys:seminfo_semmni=110 set semsys:seminfo_semopm=100

Этот файл заплатки system.patch можно "приложить" к старому файлу system для того, чтобы внести в него изменения; предполагается, что старый файл имеет имя, совпадающее с именем в первой строке файла заплатки (то, что написано после ---):

patch -i system.patch system

Кроме программы patch в Solаris имеется программа gpatch (GNU Patch), которая, в отличие от традиционной команды patch, строго соответствует стандарту POSIX и несколько по-другому интерпретирует ключи и обрабатывает полные имена файлов в файлах заплаток. Применяйте ту программу, которая требуется согласно описанию заплатки; в трудных случаях имеет смысл изучить раздел Compatibility issues в man gpatch.

Программы patch и gpatch не предназначены для установки обновлений Solaris, которые Sun Microsystems регулярно выпускает по мере обнаружения ошибок в существующем коде или для усовершенствования тех или иных системных программ. Для установки обновлений системы (а это наборы двоичных файлов) используются программы patchadd. Для удаления обновления и возвращения системы в состояние, в котором она пребывала до обновления, используйте patchrm. Программы patchadd и patchrm работают с Solaris версий 2.x и новее.

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

НАЗАД ВПЕРЕД

<

Увеличение производительности дисковой подсистемы


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

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

Запись данных на диск бывает синхронной и асинхронной. В большинстве случаев процессы осуществляют асинхронную запись на диск: при выполнении записи данных в файл данные фактически записываются в кэш в памяти, и процесс получает уведомление об успешно завершившейся записи. На самом деле фактическая запись данных в файл происходит позднее, когда демон отложенной записи fsflush запишет сразу большую порцию данных из кэша на диск.

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

Вторая причина дисковой активности, свопинг или пейджинг, зависит от того, как объем памяти в системе соответствует реальным потребностям приложений. Настройку системы с целью оптимизации свопинга мы рассмотрим ниже в разделе "Эффективное использование памяти и свопинга", а сейчас обратимся к оптимизации операций записи и чтения данных.



Версии NFS


NFS, разработанная компанией Sun Microsystems, оказалась настолько удачной, что ее реализации были воплощены разными компаниями почти во всех операционных системах. Существует несколько принципиально разных реализаций NFS. Достаточно распространена версия NFS 2.0, хотя уже в Solaris 2.5 была введена NFS 3.0. В последующих версиях Solaris, включая Solaris 9, в NFS были внесены существенные дополнения, но сам протокол остался совместимым с реализациями NFS 3.0 в других системах. Начиная с NFS 3.0, поддерживается передача пакетов посредством TCP и UDP, ранее поддерживался только UDP.

Будьте внимательны! В сети следует использовать клиенты и серверы NFS одной и той же версии. NFS 2.0 можно встретить в старых системах, например, в HP-UX 10.0. Совместная работа систем, использующих разные версии NFS , нежелательна.



Виртуальная память в Solaris


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

Вся виртуальная память разбита на страницы объемом 4 Кбайт.

Некоторые компьютеры в силу их аппаратной реализации используют страницы памяти по 8 Кбайт. К ним относятся компьютеры с микропроцессорами DEC Alpha, первыми процессорами Sun SPARC (например, Ross RT601/Cypress CY7C601/Texas Instruments TMS390C601A, устанавливавшиеся в SPARCstation 2) и модели Sun UltraSPARC. В Solaris для определения фактического размера страницы памяти следует использовать программу /usr/bin/pagesize или функцию getpagesize(3C).

Потребителями виртуальной памяти в Solaris являются ядро системы, кэши файловой системы, тесно разделяемая память (intimately shared memory) и процессы. Тесно разделяемая память специфична для Solaris и представляет собой область разделяемой памяти, которую нельзя выгружать на диск. Тесно разделяемую память используют такие программы, как Oracle, Sybase, Informix.

Виртуальная память построена на четырех принципах, реализованных в системе.

Во-первых, каждый процесс получает отдельное виртуальное адресное пространство (virtual address space). Это значит, что процессу доступен определенный диапазон ячеек памяти. Максимальный размер этого диапазона памяти определяется длиной слова адреса в компьютере. Процесс, запущенный в 32-разрядной системе, будет иметь виртуальное адресное пространство размером 4 гигабайта (длина адреса - 32 бита). Подсистема виртуальной памяти соотносит (отображает) пользовательский кусочек виртуального адресного пространства и реальные страницы физической памяти.


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

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

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


Ввод-вывод без кэша


Значительный объем чтения и записи данных может вызвать нехватку памяти из-за стремления системы кэшировать весь ввод-вывод. При действительно существенных объемах ввода-вывода можно отменить кэширование и производить ввод-вывод напрямую.

Для этого можно использовать функцию directio() или параметр forcedirectio при монтировании файловой системы командой mount. Файловая система VxFS включает ввод-вывод в обход кэша всегда, когда объем операции ввода-вывода превышает значение параметра discovered_direct_iosz (см. man vxtunefs) (по умолчанию - 256 Kбайт).

Если в вашей системе преобладают множественные операции ввода-вывода небольших объемов данных и даже VxFS не помогает освободить память от большого количества кэшируемых данных, попробуйте уменьшить до приемлемого размера значение discovered_direct_iosz.

НАЗАД ВПЕРЕД

<
/td>

 

Выбор эталонного сервера времени


Как мы уже знаем, чтобы обеспечить синхронизацию времени, в Интернете существуют "эталонные" серверы времени. Для получения показаний времени локальный сервер времени в своей сети следует настроить для обращений ко вторичным серверам (слой 2), так как нагрузка на главные серверы (слоя 1) очень велика. В России есть по крайней мере один устойчиво функционирующий эталонный сервер слоя 2 - ntp.psn.ru (IP-адрес 194.149.67.130). Он расположен в Пущино; вот его регистрационные данные с сервера http://www.intuit.ru/department/os/adminsolaris/16/www.ntp.org:

Location: Pushchino, Moscow region, Russia Geographic Coordinates: 54:50N, 37:37E Synchronization: NTP secondary (stratum 2), Alpha/Linux Service area: Russia Access policy: open access, please send a message to notify Contact: clockmaster@psn.ru

Информация о других эталонных серверах времени и о режиме доступа к ним может быть получена по адресу http://www.ntp.org/.

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



Взаимодействие со службами имен


Для того чтобы корректно направить задание на печать к требуемому принтеру, программе lp необходимо знать содержимое файлов /etc/printers.conf и /etc/nsswitch.conf:

cat /etc/printers.conf ... lp:\ :bsdaddr=printbox,hplj, Solaris: ...

cat /etc/nsswitch.conf ... printers: dns, nisplus, files ...

Из первого файла lp выясняет, что для печати на принтер с локальным именем lp следует отправить задание принтеру hplj на компьютере printbox. Из второго файла становится ясно, что для того, чтобы найти IP-адрес компьютера printbox, следует воспользоваться службами имен в следующем порядке: обратиться к серверу имен службы DNS (согласно содержимому /etc/resolv.conf); если с помощью DNS найти адрес не удалось, надо обратиться к серверу NIS+, а если и эта попытка оказалась неудачной, посмотреть, нет ли записи о printbox в файле /etc/inet/hosts.

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



X-клиенты


Первым X-клиентом, с которым сталкивается пользователь Solaris, является dtlogin. Вообще, многие программы, работающие в Solaris с XWindow, называются dtчто-то, где dt - это производное от DeskTop (рабочий стол).

Каждый из X-клиентов может иметь собственный файл конфигурации, и кроме того, все Х-клиенты могут иметь как специфические, так и общие для всех ключи. Общими ключами являются:

-display display

этот параметр задает активный дисплей, т.е. адрес и экземпляр X-сервера, например, -display host.my.domain.com:0

-geometry

этот параметр задает начальный размер и положение окна на экране, например, можно запустить программу xterm (X-терминал) следующим образом:

xterm -geometry 80x25+5+5

что будет означать: запустить ее в окне размером в 80 столбцов по горизонтали, 25 строк по вертикали, с отступом в 5 строк и 5 столбцов от верхнего левого угла экрана (формат WxH+X+Y, где W-ширина, H - высота, X - отступ по горизонтали, Y - отступ по вертикали).

-bg color

обозначает цвет фона окна, например,

-bg yellow

-bd color -bordercolor color

являются синонимами и задают цвет рамки окна приложения.

-bw number -borderwidth number

задают ширину рамки в пикселях.

-fg color, -foreground color

задают цвет текста или выводимой в окне графики (по умолчанию).

-fn font, -font font

указывают шрифт, который будет использован для отображения текста в окне. Подробнее о шрифтах рассказано в man xfn, программа xfn используется для управления шрифтами в графической подсистеме X-Window.

-rv, -reverse

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

+rv

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

Кроме того, есть еще ряд общих ключей, которые употребляются реже.



X-серверы


Здесь мы будем говорить об X-серверах под UNIX. Наиболее распространены X-серверы из пакета программ X 11 Release 6. Это свободно распространяемое программное обеспечение, встроенное в Solaris 9. Для видеоадаптеров разных типов используют разные X-серверы, потому что каждый X-сервер оптимизирован для работы с конкретными типами видеоадаптеров. При компиляции X-серверов также учитываются особенности каждой операционной системы. Поэтому X-серверы от X11R6 в Solaris и Linux одинаковы по значительной части исходного кода, но их исполняемый код различен.

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

Для среды CDE X-сервером является программа XSun.

Настройки X-сервера не хранятся в едином файле, а распределены по разным местам. На работу Х-сервера в Solaris влияют следующие файлы (но не только эти):

$HOME/.Xdefaults

$HOME/.OWdefaults

/usr/lib/X11/Xdefaults

$HOME/.openwin-init

/usr/openwin/lib/openwin-init



Зачем нужно ролевое управление доступом


Слабым местом систем UNIX с давних пор была невозможность делегировать часть полномочий системного администратора другим пользователям. Мы хорошо знаем, как передаются полномочия в системах Windows: существуют предопределенные группы, которым дано право выполнять некоторые определенные администраторские действия (Printer Operator, Backup Operator и т.п.). В UNIX для делегирования части администраторских прав в свое время использовалась программа sudo. Второй выход заключался в том, чтобы установить в правах доступа к некоей административной программе типа useradd бит SUID, чтобы доверенный пользователь мог запустить ее от имени владельца, т.е. пользователя root.

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

В Solaris, начиная с версии 8, была введена новая для UNIX система управления доступом - RBAC (Role-Based Access Control). Основанное на ролях управление доступом имеет такую же функциональность, как разнообразие групп с некоторыми административными правами в Windows. Смысл его в том, что любому пользователю может быть назначена роль. Ответственность и право выполнения части администраторских функций делегированы роли, и пользователь имеет право ее играть.



Задачи NFS


Сетевая файловая система (Network File System - NFS) служит для обеспечения доступа компьютерам сети к общим каталогам на сервере. Централизованное хранение файлов на сервере облегчает организацию работы в большой сети, особенно там, где один и тот же пользователь может работать в разное время на разных компьютерах. С помощью файлового сервера решается сразу несколько задач:

регулярное резервное копирование всех данных: нереально выполнять эту операцию для нескольких десятков или сотен компьютеров, но вполне реально - с единственного сервера или нескольких серверов. повышение надежности хранения данных: неразумно каждый компьютер сети оснащать RAID-массивом, ведь подавляющее большинство файлов в компьютере, таких, как установленные пакеты программ, проще установить заново, чем защищать их от сбоя; но будет вполне разумным укомплектовать файловый сервер аппаратным RAID-массивом или организовать там программный RAID-массив, хотя бы простое зеркалирование дисков. уменьшение стоимости хранения данных: дорого и неэффективно в каждый компьютер устанавливать огромный диск на случай, если потребуется хранить много данных, но на сервере вполне можно установить масштабируемую дисковую подсистему большого объема. обеспечение доступа к одним и тем же данным с любого компьютера.



Загрузка модулей


Некоторые полезные модули, если они не требуются для выполняемых системой задач, могут не загружаться в начале работы системы. Для того чтобы обеспечить их загрузку, следует использовать вышеупомянутые настройки в /etc/system. Если требуется загрузить модуль во время работы системы, не перегружая ее, воспользуйтесь командой modload.

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

sysdef | tail -20

* * Streams Tunables * 9 maximum number of pushes allowed (NSTRPUSH) 65536 maximum stream message size (STRMSGSZ) 1024 max size of ctl part of message (STRCTLSZ) * * IPC Messages module is not loaded * * * IPC Semaphores module is not loaded * * * IPC Shared Memory module is not loaded * * * Time Sharing Scheduler Tunables * 60 maximum time sharing user priority (TSMAXUPRI) SYS system class name (SYS_NAME)

Стандартные модули располагаются в подкаталогах каталога /kernel:

ls -l /kernel

total 2856 drwxr-xr-x 2 root sys 512 Мар 17 10:42 dacf drwxr-xr-x 2 root sys 3072 Мар 17 11:16 drv drwxr-xr-x 2 root sys 512 Мар 17 11:10 exec drwxr-xr-x 2 root sys 512 Мар 17 10:52 fs -rwxr-xr-x 1 root sys 1438036 Ноя 4 2002 genunix drwxr-xr-x 2 root sys 512 Мар 17 11:07 ipp drwxr-xr-x 2 root sys 512 Мар 17 10:50 mach drwxr-xr-x 3 root sys 1024 Мар 17 11:07 misc drwxr-xr-x 2 root sys 512 Мар 17 10:43 sched drwxr-xr-x 2 root sys 1024 Мар 17 10:53 strmod drwxr-xr-x 2 root sys 512 Мар 17 10:49 sys

Загружаем модуль командой

modload /kernel/misc/ipc

Теперь он загружен и будет отображаться программами мониторинга:

modinfo | grep ipc 146 feab6fb2 332 - 1 ipc (common ipc code) sysdef | tail -28 * * IPC Messages * 2048 max message size (MSGMAX) 4096 max bytes on queue (MSGMNB) 50 message queue identifiers (MSGMNI) 40 system message headers (MSGTQL) * * IPC Semaphores * 100 semaphore identifiers (SEMMNI) 60 semaphores in system (SEMMNS) 30 undo structures in system (SEMMNU) 25 max semaphores per id (SEMMSL) 100 max operations per semop call (SEMOPM) 10 max undo entries per process (SEMUME) 32767 semaphore maximum value (SEMVMX) 16384 adjust on exit max value (SEMAEM) * * IPC Shared Memory * 8388608 max shared memory segment size (SHMMAX) 100 shared memory identifiers (SHMMNI) * * Time Sharing Scheduler Tunables * 60 maximum time sharing user priority (TSMAXUPRI) SYS system class name (SYS_NAME)


Для выгрузки модуля следует дать команду modunload:

modunload ipc usage: modunload -i <module_id> [-e <exec_file>] modunload -i 146 can't unload the module: Device busy

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

Изменим файл /etc/system:

set semsys:seminfo_semmni=101 set semsys:seminfo_semopm=101

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

modload misc/ipc sysdef * * IPC Semaphores * 101 semaphore identifiers (SEMMNI) 60 semaphores in system (SEMMNS) 30 undo structures in system (SEMMNU) 25 max semaphores per id (SEMMSL) 101 max operations per semop call (SEMOPM) 10 max undo entries per process (SEMUME) 32767 semaphore maximum value (SEMVMX) 16384 adjust on exit max value (SEMAEM) *

Вывод sysdef в этом примере сильно сокращен.


Загрузка систем клиентов для установки


После включения системы SPARC в строке OpenBoot следует выполнить команду

boot net - install

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

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

с первого или второго компакт-диска или DVD-диска дистрибутива; через сеть (если поддерживается BIOSом сетевого адаптера и компьютера); с дискеты.

Образ дискеты доступен по адресу:

http://soldc.sun.com/support/drivers/dca_diskettes.

Для загрузки может потребоваться указать дополнительные сведения. Так, сразу после загрузки системы x86 вы увидите меню выбора интерактивной установки или установки Custom JumpStart. Выбрав последнее, следует ввести команду:

b install [url:ask] [dhcp] [nowin]

В [] указаны необязательные параметры. Ниже объясняется их смысл. При загрузке SPARC-систем можно в команде boot install указывать эти же параметры в этом же порядке.

url - указывает расположение файла конфигурации JumpStart. Может иметь значения:

жесткий диск данного компьютера:

file://jumpstart_dir_path/compressed_config_file

сервер NFS:

nfs://server_name:IP_address/jumpstart_dir_path /compressed_config _file

web-сервер:

http://server_name:IP_address/jumpstart_dir_path /compressed_config_file&proxy_info

Если файл параметров установки sysidcfg помещен в файл архива .tar, следует указать IP-адрес сервера, на котором размещен файл:

http://131.141.2.32/jumpstart/config.tar

Если сжатый файл конфигурации размещен на web-сервере, доступ к которому возможен только через прокси-сервер, следует указать IP-адрес прокси-сервера:

http://www.jumpstart.company.com/jumpstart/config.tar&132.14.231.1

Здесь 132.14.231.1 - IP-адрес прокси-сервера.

ask - означает, что после загрузки и соединения с сетью программа установки спросит местоположение сжатого файла конфигурации установки; если отказаться от указания файла нажатием Enter, настройка будет произведена автоматически так, как программа установки посчитает нужным.

dhcp - означает требование использовать сервер DHCP; если этого не указать, программа установки будет пытаться использовать файл /etc/bootparams или карту NIS bootparams.

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

НАЗАД ВПЕРЕД

<

Запуск сервера времени


Демон xntpd при старте читает файл /etc/inet/ntp.conf или принимает параметры из командной строки. Однако ему необходимо сообщить адрес эталонных серверов и (или) режим работы.

Если файл /etc/inet/ntp.conf не удается прочесть и с ключом -c не указан иной файл конфигурации, демон, если он был заранее скомпилирован с поддержкой NetInfo, прислушивается к широковещательным сообщениям в сети и пытается сам найти себе эталон времени. Маловероятно, что в этом его ждет успех, если сервер времени находится за фильтром пакетов (межсетевым экраном, firewall - что одно и то же).

Программа ntpq позволяет получать информацию о текущей конфигурации прямо от сервера времени и изменять настройки xntpd "на ходу", без перезапуска сервера.

В командной строке вызова xntpd доступны следующие ключи:

-a - включить аутентификацию (по умолчанию - выключена);

-A - выключить аутентификацию;

-b - синхронизироваться по широковещательным сообщениям NTP;

-c conffile - использовать указанный файл вместо /etc/inet/ntp.conf;

-d - включить режим отладки;

-e authdelay - указать явно время в секундах, которое требуется данной системе для вычисления ключа;

-f driftfile - указать путь к файлу со значением сдвига часов;

-k keyfile - указывает файл с ключами для аутентификации в NTP;

-l logfile - указывает файл протокола; по умолчанию протоколи- рование ведется через syslog();

-m - синхронизировать часы по multicast-сообщениям NTP на группу multicast-адресов 224.0.1.1; требует поддержки multicast в ядре;

-p pidfile - указывает файл, в который пишется PID процесса xntpd.



Запуск службы экспорта файловых систем


Сервис NFS предоставляется двумя программами, которые обрабатывают соответствующие RPC-запросы. Это программы mountd и nfsd.

Программа mountd обрабатывает запросы на удаленное монтирование файловых систем. Для получения списка экспортируемых каталогов применяют команду showmount -e, которая обращается к mountd за информацией:

showmount -e export list for sunny: /nfst (everyone)

Для того чтобы на сервере NFS узнать, какие системы подсоединили к себе разделяемые каталоги этого сервера, следует дать команду showmount без параметров:

showmount www.eu.spb.ru

Программа nfsd - это обработчик файлового запроса удаленного клиента NFS к файловой системе сервера NFS .

Параметры службы NFS настраиваются в файле /etc/default/nfs, а запуск и останов службы осуществляются, соответственно, командами

/etc/init.d/nfs.server start

и

/etc/init.d/nfs.server stop

В файле /etc/default/nfs следует указать достаточное количество потоков, которые можно параллельно запускать для обслуживания одновременных запросов к файлам через NFS. За это отвечает параметр NFSD_SERVERS.

Значение этого параметра не должно быть меньшим максимального количества одновременных обращений к разделяемым файловым системам NFS на сервере. Слишком маленькое число потоков вызовет задержки в работе клиентов, поскольку им придется становиться в очередь на обработку запросов. В то же время, излишне большое число приведет к нерациональному расходу памяти NFS-сервера. Оптимальное число определяется из опыта, и единственное, что можно сказать определенно: оно не должно быть больше удвоенного общего количества компьютеров сети, настроенных для работы через NFS. По умолчанию это число равно 16, что для нагруженных серверов NFS очевидно мало.

Если из-за слишком большого количества потоков nfsd загрузка процессора возрастет до 100%, имеет смысл уменьшить число этих потоков.

С одной стороны, идеально иметь 2 потока на каждого активного клиента, постоянно обращающегося к ресурсам NFS, с другой - на один процессор рекомендуется запускать не более 16 потоков, если это достаточно медленный процессор типа тех, что установлены в системах SPARCstation 5.

В моей тестовой системе Solaris на компьютере x86 монтирование каталога сервера одним клиентом NFS привело к увеличению занимаемой nfsd памяти всего на 8 Кбайт, так что в современных системах скорее имеет смысл ожидать некоторого снижения производительности за счет нагрузки на процессор или кэширования больших файлов экспортируемых каталогов, чем нехватки памяти из-за слишком большого количества потоков nfsd.

Перед запуском mountd и nfsd следует убедиться, что в /etc/dfs/dfstab указаны все каталоги, которые вы собираетесь экспортировать, а также разумно настроены параметры безопасности.



Зарезервированные сетевые адреса


Надо иметь в виду, что один компьютер может иметь несколько сетевых интерфейсов, а каждый интерфейс может иметь несколько адресов. Некоторые адреса в каждой сети являются зарезервированными и не могут использоваться для адресации какого-либо интерфейса. Так, IP-адрес, в котором поле номера компьютера заполнено двоичными нулями, используется в качестве номера данной сети в целом. Например, адрес 131.45.0.0 обозначает целую сеть класса B. IP-адрес, в котором поле номера компьютера заполнено двоичными единицами, является широковещательным адресом сети (broadcast address) и используется для одновременной рассылки пакета всем компьютерам данной сети. Получив пакет с адресом получателя 131.45.255.255, каждый компьютер сети 131.45.0.0 (класс B) воспримет этот пакет как предназначенный ему. Эти зарезервированные адреса используются, например, в целях управления маршрутизацией.

Существуют и другие зарезервированные адреса. Адрес 127.0.0.1, всегда указывающий на локальный внутренний интерфейс системы "127.0.0.1", обозначает для системы то же самое, что для человека - слово "я". Этот локальный внутренний интерфейс требуется для того, чтобы одна программа (клиент) могла обратиться к другой программе (серверу), работающей на том же компьютере, стандартным образом. Например, можно обратиться из браузера на вашем компьютере к web-серверу на вашем же компьютере. Локальный интерфейс обычно называется lo или lo0 (от слова loopback - петля).

Адрес 0.0.0.0 используется для обозначения всех интерфейсов в сети вообще.