Широкие возможности WWW -
технологии по представлению
пользователям Internet информации,
включая текст, картинки, графики,
видео и звуковые дорожки,
обусловили процесс бурного роста
сети WWW - серверов и Internet в целом.
Целью данного пособия является
освещение технологии работы и
процессов установки и
администрирования WWW - сервера, т.е.
той части сети, которая отвечает за
предоставление гипертекстовой
информации по запросам
пользователей сети.
3.2 ОБЩАЯ ЧАСТЬ
3.2.1 Назначение WWW - сервера. Общая
схема работы. Определение
WWW сервер - это такая часть
глобальной или
внутрикорпоративной сети, которая
дает возможность пользователям
сети получать доступ к
гипертекстовым документам,
расположенным на данном сервере.
Для взаимодействия с WWW сервером
пользователь сети должен
использовать специализированное
программное обеспечение - броузер
(от англ. browser), другое название -
программа просмотра.
Схема работы
Рассмотрим более подробно, чем в
предыдущих главах, схему работы
WWW-сервера. В общем виде она
выглядит так:
Пользователь сети запускает
пакет программного
обеспечения, называемый броузером,
в функции которого входит
Установление связи с
сервером
Получение требуемого
документа
Отображение полученного
документа
Реагирование на действия
пользователя - доступ к
новому документу
После запуска броузер по
команде пользователя или
автоматически
устанавливает связь с
заданным WWW - сервером и
передает ему запрос на
получение заданного
документа (см рис.3-1).
WWW сервер ищет запрашиваемый
документ и возвращает
результаты броузеру (см. рис.
3-2).
Броузер, получив документ,
отображает его пользователю и
ожидает его реакции. Возможные
варианты:
Ввод адреса нового
документа
Печать, поиск, другие
операции над текущим
документом
Активизация (нажатие)
специальных зон
полученного документа,
называемых связями
(link) и ассоциироваными с
адресом нового документа.
В первом и третьем случае
происходит обращение за новым
документом.
Адрес
Как было описано в главе 2,
адрес документа указывается в виде
специальной строки, называемой URL.
Для протокола HTTP, используемого при
взаимодействии WWW клиента и WWW
сервера, URL состоит из следующих
компонент:
Наименование протокола, по
которому работает сервер (http).
Имя машины - сервера в Internet или
ее IP - номер.
Порт TCP, обращение к которому
обрабатывает сервер.
Место (путь) документа на
машине - сервере.
Например: http://www.cnit.nsu.ru:80/welcome.html
Здесь http означает
протокол работы с WWW - сервером
':' - разделитель
"www.cnit.nsu.ru" - имя
машины - сервера в Internet
"80" - номер tcp -
порта
/welcome.html - путь до
документа на машине - сервере
Из общей схемы работы видно, что
функции WWW сервера заключаются в
следующем:
Установление соединения с
клиентским ПО по протоколу tcp.
Принятие запроса на документ
по протоколу http.
Поиск документа в локальных
ресурсах.
Возврат результатов поиска по
протоколу http.
В общем случае, WWW - сервером
будем называть программно -
аппаратный комплекс,
предназначенный для выполнения
вышеперечисленных действий.
Среда работы сервера
В настоящее время все известные WWW
- серверы представляют собой
компьютер общего назначения с
многозадачной операционной
системой. Один или несколько
процессов такой системы отвечают
за поддержку специфических для WWW -
сервера функций. Другие процессы ОС
отвечают за обеспечение других
функций, не обязательно связанных с
поддержкой технологии WWW (см. рис.
3-3).
Такая структура приводит к тому,
что под WWW сервером начинают
подразумевать только часть
программного обеспечения,
единственными функциями которой
являются функции WWW сервера, а
остальную часть - компьютер,
операционную систему, другие
процессы, сетевую структуру
называют средой работы WWW сервера
или платформой. Ниже приведена
таблица 3-1, содержащая список
наиболее распространенных
платформ для WWW - сервера.
Таблица 3-1
Компьютер
Операционная Система
IBM PC
Unix (UnixWare, Open Server, Solaris, BSD,
Linux и т.д.
Microsoft Windows NT
IBM OS/2
Novell NetWare
Sun SparcStation и SparcServer
SunOS
Solaris
Silicon Graphics
серверы и
рабочие станции
IRIS
3.2.2 Непосредственные функции
сервера. Базовые определения
В простейшем случае
гипертекстовый документ
представляет собой совокупность
файлов. Представление этих файлов
как единого документа производится
броузером. По каждому файлу
документа броузер делает запрос к
WWW - серверу. Таким образом, сервер
не имеет представления о структуре
и составе документов, он отвечает
только за выдачу локальных файлов
по запросам.
На различных платформах, в
различных операционных системах
пути файлов выглядят по разному.
Например: D:\DOCUMENTS\HTML\INDEX.HTM - в Windows, /u/data/www/html/index.html - в Unix -
системах, USR:WWW/HTML - в NetWare и т.д.
Путь файла, указываемый в URL, имеет
стандартный вид:
/<имя_каталога>/ ...
/<имя_каталога>/<имя_файла>
Таким образом, в функции WWW -
сервера входит преобразование
адреса из внешнего единого формата
в платформенно ориентированный
внутренний формат. Появляется ряд
понятий, специфичных для такого
преобразования, необходимых для
него.
Исходный каталог документов
Это каталог реальной файловой
системы сервера, от которого идет
вычисление пути, указанного в URL.
Например, если исходным каталогом
документов являетсяD:\Documents\HTML\,
то на запрос к этому серверу
документа по URL
http://<имя_сервера>/index.htm
будет возвращен файл
D:\Documents\HTML\index.htm
Синонимы
В случае, когда необходимо
осуществить обращение к
конкретному каталогу или файлу,
находящемуся вне иерархии Исходного
каталога документов,
используется механизм синонимов.
Синоним позволяет явно определить
соответствие между путем,
указанным в URL, и путем локальной
файловой системы.
Например:
Синонимом для /Harvest
объявляется /projects/www/harvest или
В первом случае все обращения к
файлам каталога /Harvest будут
обрабатываться в каталоге /projects/www/harvest.
Второй пример показывает работусинонима
с конкретным файлом файловой
системы.
Индексный файл
Для каждого сервера определено
имя так называемого индексного
файла. Обычно этот файл содержит
ссылки на другие файлы данного
каталога. Содержимое индексного
файла выдается сервером в случае,
если в URL указан каталог без
конкретного файла.
Пользовательский раздел
Для многопользовательских
операционных систем (таких как Unix)
ПО WWW - сервера позволяет каждому
пользователю предоставлять доступ
к своему собственному набору
гипертекстовых документов вне
основной иерархии (Исходного
каталога документов, Синонимов
и т.д.). Этот набор документов должен
находиться в собственном (т.н.
"домашнем") каталоге
пользователя. Для доступа к таким
документам в URL перед путем
ставится знак тильда и имя
пользователя:
~<имя_пользователя>.
Например:
На сервере Indy.cnit.nsu.ru создан
пользователь с именем fancy и
"домашним" каталогом /home/fancy.
Собственные гипертекстовые
документы он хранит в каталоге /home/fancy/public_html.
При обращении по URL http://Indy.cnit.nsu.ru/~fancy/start.html,
WWW - сервер будет искать документ start.html
в каталоге /home/fancy/public_html.
3.2.3 Протокол MIME
Протокол MIME - многоцелевое
расширение электронной почты, был
создан как способ передачи
нетекстовой информации:
изображений, звука, видео в письмах
электронной почты. Механизм
оказался удачным, и его перенесли и
в on-line сервисы, в том числе WWW. Здесь
MIME используется для передачи
документов от сервера к клиенту.
В общем виде MIME основывается на
передаче вместе с основными
данными дополнительной информации,
описывающей что это и в каком виде
передается. Эта дополнительная
информация называется заголовок
MIME. Базовой частью заголовка
является строка, описывающая тип
передаваемого сообщения. Формат
строки:
Content-Type: <тип_MIME>
Перечень типов MIME (т.е. видов
передаваемых данных) постоянно
пополняется и может быть дополнен
даже пользователем для описания
своего собственного вида данных.
Формат типа MIME:
<Тип>/<Подтип>
[ ;<параметры> ]
Где <Тип> - определяет общий тип
данных:
Audio - для звуковых данных
Application - данные, являющиеся входными
для какого-либо приложения
(программы)
Image - для графических образов
Message - для сообщения, которое само по
себе является MIME - документом
Multipart - для сообщения, состоящего из
нескольких MIME - документов
Text - для текстовых данных в
различном виде
Video - для видеоданных.
<Подтип> - указывает на
специфический формат данных типа
<Тип>
Например: text/html - текстовые данные в
формате HTML image/giff - графические данные в
формате gifF
<Параметры> - список параметров,
необходимых для интерпретации
данных.
Для ведения специфичной
обработки файлов различных типов и
форматов на клиентской и серверной
частях поддерживаются списки
соответствий типов MIME и расширений
файлов. Формат записи такого
списка:
<Тип>/<Подтип><расширение1> ... <расширениеN>
Эти списки сопоставляют всем
файлам, имеющим определенные
расширения, определенные типы MIME.
Например: image/giff gif giff text/html html htm
В первой строке всем файлам с
расширением gif и giff приписывается
тип содержимого image/giff. Если для
типа содержимого image/giff определены
специальные правила обработки
(например, отображение на экране в
определенной области), то так будут
обрабатываться все файлы с
расширениями gif и giff.
3.2.4 Протокол HTTP
Протокол HTTP определяет язык
запросов от WWW - клиента к WWW -
серверу. Сам запрос состоит из
следующих компонент:
<Заголовок> <Метод> <Источник / Данные>
где
Заголовок - определяет версию
протокола HTTP и другие служебные
параметры;
Метод - одно из ключевых слов: GET - для передачи запросов на
выдачу документов PUT, POST - для передачи данных
от клиента к серверу (например, из
форм)
Пример запроса: HTTP/1.1 GET /index.html
Описывает запрос на получение
файла index.html из корневого каталога
документов сервера.
3.2.5 Интерфейс CGI
Помимо доступа к статическим
документам сервера существует
возможность получения документов
как результата выполнения
прикладной программы. Такая
возможность реализуется на сервере
WWW благодаря использованию
интерфейса CGI (Common Gateway Interface).
Спецификация CGI описывает формат и
правила обмена данными между ПО WWW
сервера и запускаемой программой.
Для инициирования CGI необходимо,
чтобы в запрашиваемом URL был указан
путь до запускаемой программы. ПО WWW
сервера исполняет эту программу,
передает ей входные параметры и
возвращает результаты ее работы,
как результат обработки запроса,
клиенту. CGI - программой может
являться любая программа локальной
операционной системы сервера - в
двоичном виде или в виде программы
для интерпретатора (Basic, SH, Perl и т.д.).
С целью облегчения
администрирования CGI - программ, а
также для удовлетворения
требованиям безопасности CGI -
программы группируются в одном или
нескольких явно указанных серверу
каталогах. По умолчанию это каталог
cgi-bin в иерархии серверных
каталогов, однако, его имя и
положение могут отличаться.
Например:
клиент, обращающийся к CGI -
программе test-query, будет
использовать URL http://<имя_сервера>/cgi-bin/test-query
Интерфейс CGI позволяет расширить
границы применения WWW - технологии.
CGI - программа может обрабатывать
сигналы с датчиков установок,
взаимодействовать с мощным
сервером баз данных, переводить и
т.п. Полное описание интерфейса и
требований к приложениям,
использующих его, приведены в главе
4 настоящего отчета.
3.3 СЕРВЕР NCSA
Национальный Центр по
Суперкомпьютерным Приложениям (NCSA)
Иллинойского университета стал
второй организацией после ЦЕРН,
интенсивно взявшейся за развитие WWW
- технологии. Семейство ПО WWW -
серверов NCSA прошло длинный путь
развития. Последние версии
поддерживают все современные
возможности, включая виртуальные
узлы, управление доступом,
параллельную обработку запросов и
т.п.
3.3.1 Требования к ресурсам
Программное обеспечение сервера
NCSA представляет собой прикладное
программное обеспечение,
предназначенное для работы под ОС
Unix. В зависимости от аппаратной
платформы требуемый размер
оперативной памяти и дискового
пространства существенно
изменяются. Для семейства "Unix для
PC" (Solaris, SCO, UnixWare, Linux, BSD, BSDI),
необходимо ориентироваться на 2 Mb
оперативной памяти. Дисковое
пространство, требуемое при
установке, составляет около 2Mb,
однако при планировании установки
нужно учитывать, что при
интенсивном доступе к серверу
статистика доступа будет
составлять до нескольких сот
килобайт в день и нескольких
десятков мегабайт в месяц.
3.3.2 Состав дистрибутива сервера
NCSA. Варианты дистрибуции
Сервер NCSA поставляется как в виде
исходных текстов, так и в виде
исполняемых модулей для различных
операционных систем. Распакованный
дистрибутив размещается в каталоге
httpd_<номер
версии>-<модификация> где
<номер версии> - версия
программного обеспечения WWW
сервера, <модификация> -
модификация текущей версии.
Например: httpd_1.5.1-export
В этом каталоге содержатся
следующие файлы и подкаталоги:
README - текстовый файл для
первоначального ознакомления.
Содержит список всех значимых
файлов и каталогов с объяснением их
назначения.
COPYRIGHT - текстовый файл с
описанием лицензионного
соглашения на использование ПО WWW -
сервера NCSA.
CHANGES - текстовый файл со
списком изменений между различными
версиями ПО сервера.
Makefile - файл верхнего
уровня для утилиты make. Содержит
список команд, которые необходимо
выполнить для сборки и установки ПО
WWW - сервера.
src - каталог с исходными
текстами ПО сервера.
conf - каталог, содержащий
примеры конфигурационных файлов ПО
сервера.
icons - каталог, содержащий
иконки, необходимые для работы
сервера.
cgi-src - каталог, содержащий
исходные тексты примеров CGI -
программ.
support - каталог с
программным обеспечением, не
являющимся часью ПО сервера, но
полезным при работе с ним.
3.3.3 Процедура установки сервера
NCSA
Для запуска процедуры сборки и
установки сервера необходимо в
корневом каталоге сервера,
описанном в предыдущем параграфе,
запустить утилиту make. Для
сборки сервера необходимо указать
команде make аббревиатуру
операционной системы:
aix3, aix4, sunos, sgi4, sgi5, hp-cc, hp-gcc, solaris,
netbsd, svr4, linux, next, ultrix, osf1, aux, bsdi.
Полный список поддерживаемых
систем можно получить, выполнив
команду make без параметров. Каждая
аббревиатура ассоциирована с
конкретной операционной системой.
Появление дополнительных
параметров после дефиса указывает
на специфику конкретной
конфигурации в одной и той же ОС.
Например, hp-cc и hp-gcc
указывают на общий тип ОС - HP-UX,
однако ориентированы на
использование разных компиляторов
- базового C - компилятора (cc) или GNU C
(gcc). Для сборки сервера под ОС UnixWare
необходимо использовать команду make
svr4.
Ряд основных параметров сервера -
пути файлов, режимы работы задаются
по умолчанию на этапе сборки. В
случае, если нужна их корректировка
под конкретные условия, необходимо
отредактировать файл src/config.h.
После сборки сервера необходимо
разместить его компоненты в
файловой системе. Исполняемый
модуль сервера httpd
размещается в каталоге серверных
программ - /usr/local/sbin или /usr/sbin.
Файлы конфигурации, журналы и
стандартные cgi-программы
размещаются в подкаталогах
каталога, определяемого параметром
ServerRoot. Обычно это /usr/local/etc/httpd,
однако его можно изменить либо
изменив параметр HTTPD_ROOT файла src/config.h,
либо указав ключ -d при
запуске сервера.
Например: /usr/local/sbin/httpd -d /var/httpd
В каталоге, определяемом
параметром ServerRoot, размещаются три
подкаталога:
conf/ - содержащий файлы
конфигурации сервера
logs/ - содержащий журналы
работы сервера
cgi-bin/ - содержащий
стандартные cgi-программы,
поставляемые с сервером.
3.3.4 Конфигурационные файлы.
Режимы работы сервера
Главный файл конфигурации (ГКФ)
сервера содержит все параметры,
необходимые серверу для начала
работы, а также пути других
конфигурационных файлов. По
умолчанию, главный файл
конфигурации сервера находится в
подкаталоге conf/ каталога и
имеет имя httpd.conf. При запуске
серверу можно указать другой путь,
используя ключ -f.
Ниже приведены параметры,
указываемые в главном файле
конфигурации сервера, с
необходимыми пояснениями. Значения
параметров отделяются от названия
одним или несколькими пробелами
или табуляциями. Если одному
параметру соответствуют несколько
значений, они разделяются запятыми.
Параметры запуска серверных
процессов
ServerType
Определяет
способ запуска сервера:
ServerType inetd серверный
процесс запускается в ответ на
каждое обращение клиента через
механизм inetd. После обработки
запроса, сервер прекращает
свою работу.
ServerType standalone серверный
процесс запускается один раз и
находится в состоянии ожидания
запросов клиентов. После
обработки запроса, сервер
остается запущенным.
Port
Определяет порт tcp,
по которому сервер принимает
запросы клиентов. Этот
параметр используется только
для сервера типа standalone. При
механизме старта inetd порт
определяется конфигурационным
файлом сервера inetd - inetd.conf.
Стандартный порт для WWW -
сервера - 80.
Пример: Port 80
StartServers и MaxServers
Для
режима standalone определяют
количество процессов сервера
при многопоточной обработке. StartServers
- указывает число процессов
сервера, создаваемых при
запуске httpd. MaxServers
определяет максимальное число
одновременно работающих
процессов сервера.
Пример: StartServers 3 MaxServers 5
TimeOut
Определяет время
(в секундах), которое серверный
процесс, запущенный в режиме
standalone, будет ожидать
повторного обращения клиента.
По умолчанию используется 1200
секунд.
Пример: TimeOut 3600
User и Group
Определяют
имя пользователя и группу,
права которого получает сервер
при запуске в режиме standalone.
Изменение прав сервера
производится с целью
предотвращения доступа WWW -
клиентов к файлам операционной
системы, не являющимися
общедоступными. Например:
User nobody
Group nobody
Информационные параметры для WWW
- клиентов
ServerName
Определяет имя
сервера, которое пересылается
клиенту вместе с другими
параметрами запроса.
Используется в случае, если
сервер имеет несколько имен
(синонимов).
Например: ServerName Indy.cnit.nsu.ru
ServerAdmin
Определяет
адрес электронной почты
администратора сервера. При
возникновении каких - либо
ошибок в работе сервера, он
выдает клиенту сообщение с
просьбой проинформировать о
них администратора сервера по
указанному Email.
Например: ServerAdmin fancy@nsu.ru
Расположение необходимых
файлов и каталогов
ServerRoot
Определяет
местоположение каталога ServerRoot.
По умолчанию, это /usr/local/etc/httpd
или измененное значение
параметра HTTPD_ROOT файла src/config.h.
Например: ServerRoot /var/httpd
ErrorLog
Определяет
местоположение файла - журнала
ошибок, в который заносятся все
сообщения об ошибках,
возникающих в процессе работы
сервера. Если значение не
начинается со slash (/),
подразумевается путь
относительно ServerRoot.
Например: ErrorLog logs/errlog
Журналом ошибок является
файл /var/httpd/logs/errlog
TransferLog
Определяет
местоположение файла - журнала
доступа, в который заносятся
данные обо всех передачах
данных между WWW - клиентом и WWW -
сервером. Если значение не
начинается со slash (/),
подразумевается путь
относительно ServerRoot.
Например: TransferLog logs/translog
Журналом доступа является
файл /var/httpd/logs/translog
AgentLog
Определяет
местоположение файла - журнала
клиентов, в который заносятся
данные о программном
обеспечении, используемом WWW
клиентами при доступе к
данному серверу. Если значение
не начинается со slash (/),
подразумевается путь
относительно ServerRoot.
Например: TransferLog logs/agentlog
Журналом клиентского
программного обеспечения
является файл /var/httpd/logs/agentlog
RefererLog
Определяет
местоположение файла в который
записываются все факты
обращений к данным сервера в
виде ссылок от клиентов к
данным. Если значение не
начинается со slash (/),
подразумевается путь
относительно ServerRoot.
Например: RefererLog logs/reflog
Журналом ссылок является
файл /var/httpd/logs/reflog
PidFile
Определяет
местоположение файла,
хранящего номер процесса
запущенного WWW - сервера.
Используется для остановки
работы сервера путем посылки
сигнала командой kill.
Если значение не начинается со
slash (/), подразумевается путь
относительно ServerRoot.
Например: PidFile logs/httpd.pid
Номер процесса - сервера
записывается при старте в файл /var/httpd/logs/httpd.pid
AccessConfig
Определяет
местоположение файла
управления доступом. Если
значение не начинается со slash
(/), подразумевается путь
относительно ServerRoot.
Например: AccessConfig conf/access.conf
TypesConfig
Определяет
местоположение файла,
содержащего список
соответствий расширений
файлов ОС типам MIME. По
умолчанию используется файл
conf/mime.types в каталоге,
определяемом ServerRoot. Если не
начинается с backslash (/),
подразумевается путь
относительно ServerRoot.
Например: TypesConfig /etc/mime.types
CoreDirectory
Определяет
местоположение каталога, в
который записывается файл
дампа памяти при возникновении
сбоя.
Например: CoreDirectory /tmp
Параметры протоколирования
LogOptions
Определяет,
будут ли несколько протоколов
записываться в один файл (Combined)
или каждый будет записан в свой
файл (Separate).
Например: LogOptions Separate
RefererIgnore
Определяет
имена серверов, обращения от
которых не будут
протоколироваться.
Например: RefererIgnore Indy.cnit.nsu.ru
Другие режимы работы
DNSMode
Определяет
интенсивность обращений WWW
сервера к серверу имен
Интернет. Minimum означает,
что сервер будет обращаться к
DNS только при необходимости
проверить ограничения доступа
по домену. Standard
означает, что сервер будет
обращаться к серверу имен
каждый раз при обработке
запроса клиента. Maximum
означает, что сервер будет
дважды обращаться к серверу
имен при каждой обработке
запроса.
Например: DNSMode Standard
Процедура определения
конфигурации сервера
После запуска основного
серверного процесса сервер
пытается открыть главный
конфигурационный файл. Этот файл
ищется по умолчанию в каталоге /usr/local/etc/http/conf
с именем httpd.conf. Умолчание
можно изменить при сборке системы
редактированием файла src/config.h.
За каталог отвечает параметр HTTPD_ROOT,
за имя файла - параметр SERVER_CONFIG_FILE.
Изменить значения по умолчанию
можно при запуске сервера, указав
ключи -h и-f (см. выше).
Местоположение файлов
конфигурации доступа, документов,
типов MIME, а также файлов журналов
сервер получает из главного
конфигурационного файла. Если
каких - либо параметров там нет, их
значения берутся по умолчанию (см. src/config.h).
Конфигурация ресурсов
Расположение файлов данных, их
интерпретация сервером и поведение
сервера при обращении к разным
типам файлов определяются
параметрами файла конфигурации
ресурсов. Ниже приведен список
основных параметров с пояснениями.
DocumentRoot
Определяет
каталог локальной файловой
системы, от которого
начинается отсчет
виртуального пути URL.
Например: DocumentRoot /apply/www
UserDir
Определяет
название публичного
подкаталога пользователей. ПО
WWW - сервера позволяет
обеспечить внешний доступ к
гипертекстовым документам
пользователей базовой
операционной системы. Для
этого пользователям
необходимо создать в своем
домашнем каталоге подкаталог с
именем, определяемым
параметром UserDir. После
этого все обращения по URL:
http://<имя_сервера>/~<имя_пользователя_ОС>
будут транслироваться в
реальный путь до подкаталога,
определенного параметром UserDir
в домашнем каталоге
пользователя
<имя_пользователя_ОС>.
Например: UserDir public_html
при этом при обращении по URL
http://www.nsu.ru/~fancy/index.html
сервер будет искать файл Index.html
в подкаталоге public_html/
домашнего каталога
пользователя fancy.
Redirect
Переадресует
запрос к одной иерархии в
запрос к другой иерархии,
возможно расположенной на
другом сервере.
Определяет
синоним для документа или
каталога на локальном сервере.
Пример:
Alias /icons /var/opt/images
ScriptAlias
Определяет
синоним для каталогов,
содержащих CGI - программы.
Пример:
ScriptAlias /hrv-cgi /var/opt/cgi
DirectoryIndex
Определяет
имена файлов, трактующихся
сервером как индексные. Их
содержимое выдается сервером
при обращении к данному
каталогу.
Пример:
DirectoryIndex index.html index.htm index.cgi
AccessFileName
Определяет
имя файла, трактующегося
сервером как файл управления
доступом (см. раздел об управлении
доступом).
Пример:
AccessFileName .htaccess
3.3.5 Выполнение основных операций
администрирования
3.3.5.1 Контроль работоспособности
сервера
Проверка работоспособности
сервера может осуществляться
различными способами. На Unix -
платформе, в режиме standalone, можно
посмотреть список процессов,
выделив среди них процессы с именем
httpd:
Мы увидим несколько процессов, у
одного из которых собственником
является root, а у других -
пользователь, определенный
параметром User главного
конфигурационного файла (ГКФ).
Процесс с собственником root
запускается первым. Он
контролирует работу остальных
процессов - серверов. По
использованному процессорному
времени (колонка 8 примера) можно
судить о загруженности серверов.
Если сервер работает в режиме inetd
или необходимо проверить
работоспособность сервера извне,
нужно выполнить команду telnet,
указав ей имя машины - сервера и
номер порта. После установления
соединения наберите команду GET /.
Сервер должен выдать содержимое
корневого каталога документов или
индексного файла, находящегося в
этом каталоге. Номер порта обычно
равен 80. В режиме standalone он
определяется параметром Port ГКФ. Для
режима inetd он определяется парой
файлов - services и inetd.conf,
определяющих соответствие между
входными tcp - портами и сервисами Unix.
Например:
$ telnet www.cnit.nsu.ru 80 Trying 193.124.209.70... Connected to Indy. Escape character is '^]'. GET / <HTML> <HEAD> <TITLE>Novosibirsk Center of New Information
Technologies</TITLE> </HEAD> <BODY . . . </BODY> </HTML> Connection closed by foreign host. $
3.3.5.2 Обработка журналов
Время от времени возникает
необходимость уменьшить размер
файлов статистики путем их
удаления или переноса в другое
место. Если сервер находится в
режиме inetd, можно свободно удалять и
переносить файлы статистики. Они
снова создадутся по указанным в ГКФ
путям. Если же сервер работает в
режиме standalone, эти файлы постоянно
открыты процессами - серверами.
Удаление или перенос их не
освободят место на диске и не
приведут к созданию новых файлов.
Для корректной работы с журналами в
этом случае, необходима остановка
работы сервера. Необходимо
"убить" процессы - серверы,
перенести файлы журналов и
перезапустить сервер. "Убить"
процессы - серверы можно послав
команду kill процессу с номером,
указанном в файле PidFile (см.
параметры ГКФ). Пример
последовательности команд для
выполнения такой операции:
Для анализа файлов статистики
существует большое количество
программного обеспечения,
делающего "вытяжку" из них в
виде диаграмм, сравнительных
таблиц и т.д.
3.3.5.3 Управление доступом
Сервер NCSA содержит гибкие
средства управления доступом. С их
помощью можно централизованно или
децентрализованно управлять
доступом, основываясь на структуре
адреса WWW - клиента, создавать пары
имя/пароль для документов или целых
подразделов, создавать несколько
пар имя/пароль.
Управление доступом с
использованием пар имя/пароль
Для введения ограничений на
доступ ко всем документам
определенного каталога необходимо
создать в этом каталоге файл
управления доступом. Этот файл
имеет фиксированное имя,
определяемое параметром AccessFileName
файла конфигурации доступа. По
умолчанию, это файл .htaccess.
AuthUserFile указывает путь
файла паролей, который должен
находиться вне данного каталога.
Limit GET ограничивает доступ
по методу GET, предоставляя его
только пользователю pumpkin. Для
ограничения других методов доступа
(например, в каталогах CGI)
используется перечисление всех
методов:
<Limit GET POST PUT> require user pumpkin </Limit>
Для создания файла паролей
необходимо воспользоваться
утилитой htpasswd, входящей в
состав дистрибутива сервера:
htpasswd -c /otherdir/.htpasswd pumpkin
После запуска она дважды запросит
пароль для пользователя pumpkin и
создаст файл паролей /otherdir/.htpasswd.
Использование нескольких пар
имя/пароль
Использование нескольких пар
имя/пароль достигается путем
описания группы, в которую входят
несколько пользователей, и
указания имени группы в операторе Limit.
Необходимо создать несколько
записей в файле паролей. Этого
можно достичь, не указывая
ключа -c (create) для htpasswd:
Все документы данного
каталога будут доступны всем
членам группы my-users
после проведения процедуры
аутентификации (ввода пароля).
Ограничение доступа по сетевому
имени
В этом случае управление доступом
осуществляется на основе сравнения
сетевого имени машины - клиента с
заранее заданным образцом. Если
выявится совпадение, начинают
действовать специальные правила
доступа.
Пример ограничения доступа на
чтение. Чтение разрешено всем
пользователям машин домена cnit.nsu.ru:
<Limit GET> order allow, deny deny from .nstu.nsk.su allow from all </Limit>
3.3.6 Поддержка русскоязычных
кодировок
Исторически сложилось, что в
России распространены несколько
русскоязычных кодировок, в
основном ориентированных на разные
платформы. Наиболее известные из
них:
КОИ - 8 8 - битовая кодировка по
ГОСТ
Microsoft Code Page 866
("Альтернативная") -
кодировка, используемая в MS-DOS
ISO-8859-5 - кодировка, утвержденная
международной организацией по
стандартизации
Microsoft Code Page 1251 ("Windows") -
кодировка, используемая в Microsoft
Windows.
Специалисты утверждают что всего
в России имеют хождение 11 кодировок
русского алфавита.
Если Ваш WWW сервер ориентирован на
использование внутри организации
или его пользователями будет
являться ограниченный круг людей с
однотипными рабочими местами, Вы
можете ограничиться одной
кодировкой русскоязычной
информации на сервере.
Сложности возникают, когда Вы
захотите расширить круг клиентов
сервера. Вам необходимо будет
организовать поддержку нескольких
кодовых страниц для русскоязычных
документов. Приведенный выше
список из четырех кодировок
удовлетворит более 99% всех
возможных абонентов сервера.
Вообще говоря, в составе языка HTML
имеются теги, определяющие
кодировку документа и должные
позволить корректно прочитать
документ в любой кодировке. Однако
в связи с тем, что эти теги не
поддерживаются ни одним из
известных броузеров, надеяться на
них не стоит. Возможно, в будущем
эта ситуация изменится, и проблема
с кодировками будет решена.
Для поддержки нескольких кодовых
страниц применяется множество
методов, которые можно разбить на
две группы:
использование файлов - копий
одного документа в разных
кодировках
динамическое преобразование
документов из кодировки, в
которой они лежат на сервере, в
кодировку, поддерживаемую WWW -
клиентом.
В первом случае, на
сервере физически
присутствуют все файлы во всех
поддерживаемых кодировках.
Документы в различных
кодировках отличаются между
собой по правилам образования
путей и имен.
Например: indexw.html, indexa.html
- добавление суффиксов,
определяющих кодировку. Или
.../koi8/index.html, .../win/index.html
- различные базовые каталоги
для разных кодировок.
При этом выделяется одна
мастер - кодировка, в которой
новые документы располагаются
на сервере, а все остальные
варианты документов
получаются после работы
специальной программы -
перекодировщика. Программа -
перекодировщик может
запускаться вручную -
администратором WWW сервера или
автоматически, с
использованием команд cron,
at.
Во втором случае, доступ к
документам осуществляется
через дополнительную
программу - перекодировщик,
динамически перекодирующую
документы сервера в кодировку
WWW - клиента. Эта программа
может быть CGI - программой,
через которую всегда
осуществляется доступ к
русскоязычной части сервера.
На вход такой программе
передается реальный путь
документа и кодировка WWW -
клиента, в которую нужно
перекодировать указанный
документ (см. рис. 12.1)
Программа - перекодировщик
может также располагаться
между WWW - клиентом и сервером
(см.рис.12.2). В таком варианте она
называется PROXY.
Однако здесь возникает
проблема с перекодировкой всех
данных, включая графику, видео,
аудио и других нетекстовых
материалов. Для ее решения PROXY
придается дополнительный
интеллект - определять тип
передаваемых данных по
заголовку MIME и решать,
перекодировать документ или
нет, на основе его типа.
Программы - перекодировщики с
различными кодировками
обрабатывают обращения к
разным портам tcp сервера.
Клиенту работа с PROXY видна в URL.
Например: http://www.nsu.ru:80/index.html -
для кодировки КОИ-8, http://www.nsu.ru:8000/index.html
- для кодировки ISO-8859-5 и т.д.
Знаете ли Вы, что, как не тужатся релятивисты, CMB (космическое микроволновое излучение) - прямое доказательство существования эфира, системы абсолютного отсчета в космосе, и, следовательно, опровержение Пуанкаре-эйнштейновского релятивизма, утверждающего, что все ИСО равноправны, а эфира нет. Это фоновое излучение пространства имеет свою абсолютную систему отсчета, а значит никакого релятивизма быть не может. Подробнее читайте в FAQ по эфирной физике.
