Выбор, установка и настройка сервера
Если Website организуется на базе специально разработанной для этой цели платформы, то выбирать, что называется, не приходится. Чаще всего это будет либо Netscape Enterprise Server или Netscape Fastrack. Если речь идет об Windows NT, то в этом случае кроме продуктов Net-scape имеет смысл рассмотреть и IIS от Microsoft. В принципе это почти одно и то же.
Если же система устанавливается на произвольной платформе, то здесь выбор также не очень большой: сервер WN или Apache. WN - это самостоятельный продукт, который не использует код NCSA. До середины 1996 года это был пожалуй наилучший сервер. Однако, в настоящее время предпочтение следует все-таки отдать серверу Apache, который является развитием NCSA 1.3R в сторону построения модульной структуры и повышения безопасности обмена данными.
Тем не менее при рассмотрении установок и настроек мы будем параллельно описывать как тот, так и другой серверы.
Найти ftp-архив с дистрибутивом сервера не сложно. Для этого следует обратиться в каталог Yahoo (http://www.yahoo.com/) и там в разделе программного обеспечения серверов World Wide Web, можно найти адреса первоисточников. Если по каким-то причинам передача данных с сервера первоисточника происходит недостаточно быстро, то можно воспользоваться "зеркалами", которые расположены в пределах родного отечества. Ссылка на эти зеркала находится на домашней странице каждого сервера. Apache и WN имеются также и в ftp-архивах ftp.kiae.su и ftp.demos.su(ftp.ru).
После того как дистрибутив получен, его следует разархивировать и внимательно причитать файлы README, INSTALLATION, TODO. Как правило в составе дистрибутива есть скрипт configure( необходимо установить perl), который создает make-файл для компиляции и сборки сервера. Если в системе нет perl, и заниматься его установкой нет желания, то в этом случае надо отредактировать make-файл-источник для скрипта в соответствии с особенностями своей операционной системы. В данном случае имеется в виду Unix, т.к. для NT лучше воспользоваться уже собранным кодом.
В ряде случаев компилировать и собирать ничего не надо. Выполняемые модули для наиболее популярных платформ, как правило, уже есть в ftp-архиве. В этом случае надо только скопировать эти модули и документацию.
После того, как сервер собран или переписан, его устанавливают в то место файловой системы, где администратор предполагает его использовать. Наиболее популярное место - это директория /usr/local/etc/httpd. Но администратор может разместить сервер и в другом месте.
При размещении сервера в другом месте, следует отредактировать Makefile, если вы сами собирали сервер. В Makefile'е обычно есть переменная, которая определяет место расположения сервера и его служебных файлов. Кроме того, что эта переменная влияет на результат выполнения команды make install , по которой программное обеспечение сервера копируется в корневую директорию сервера, она же используется и для установки директории по умолчанию. В исполняемых модулях, которые получают по сети, именно /usr/local/etc/httpd указана в качестве такой директории по умолчанию.
Домашнюю директорию можно изменить не только при перекомпиляции, но и при запуске сервера. У сервера WN эта директория указывается в качестве последнего аргумента в командной строке:
/usr/paul>swn -p port [other options] /path/to/wn_root
При запуске apachie также можно указать корневую директорию:
/usr/paul>httpd -d /users/etc/httpd
Кроме сервера в корневой директории сервера могут располагаться еще служебные фалы и директории. Если для WN это условие не является обязательным, то при работе с Apache, для согласования его структур данных с сервером NCSA, надо создать еще несколько поддиректорий:
drwxr-xr-x 2 root wheel 512 Oct 11 07:01 cgi-bin drwxr-xr-x 2 root wheel 512 Oct 11 07:02 conf drwxr-xr-x 14 root wheel 1024 Oct 12 06:13 htdocs -rwxr-xr-x 1 paul wheel 21739520 Oct 11 07:37 htdocs.tar -rwxr-xr-x 1 root wheel 162003 Oct 11 07:16 httpd drwxr-xr-x 2 root wheel 2048 Oct 11 07:01 icons drwxr-xr-x 2 root wheel 512 Oct 11 07:19 logs drwxr-xr-x 2 root wheel 2560 Oct 11 07:01 src drwxr-xr-x 2 root wheel 512 Oct 11 07:01 support
Как видно из приведенного списка, это:
- cgi-bin - для размещения скриптов SGI;
- conf - для размещения конфигурации сервера;
- htdocs - корень дерева website;
- icons - место размещения иконок;
- logs - место размещения журналов контроля доступа.
Другие файлы и директории не являются обязательными и могут быть опущены. При анализе листинга, указанного выше, обратите внимание на флаги прав доступа к файлам и директориям. Обязательным условием функционирования обоих серверов является наличие флагов "чтения" и "выполнения" для всех файлов и директорий, к которым сервер будет обращаться( "r-x"). Если файл выполнения не будет установлен, то это заблокирует ряд функций сервера, например, команды cd в рамках текущей директории, что приведет к отказам на обслуживание.
Запуск сервера из командной строки - это только один из двух способов его запуска. И сервер WN и сервер Apache можно запускать из сервиса inetd. Для этого в файл /etc/services следует внести следующую запись:
wn 80/tcp
А в файл настроек inetd (inetd.conf) следует внести строчку:
wn stream tcp nowait nobody /full/path/to/wn wn
Аналогичные изменения можно произвести и для Apache.
Если при установке сервера, не предполагается, что к нему будут обращаться по миллиону раз за сутки, то сервер можно запускать через inetd. Однако, этот способ не является распространенным. Чаще всего сервер запускают в режиме stand alone, т.е. просто в качестве демона, который обслуживает запросы от клиентов.
Если у сервера WN все параметры задаются, как правило, в командной строке, то Apache настраивается при помощи файлов настройки. Всего этих файлов три: httpd.conf, srm.conf, access.conf. Существует еще один файл - mime.conf, который определяет обработку файлов других форматов, отличных от текстовых файлов с HTML-документами.
Разберем содержание файла httpd.conf. Начинается файл с определения типа запуска сервера:
ServerType standalone
Опция ServerType в данном случае установлена в значение standalone, т.е. сервер запускается как демон.
Вслед за этим определяется номер TCP-порта, на котором сервер осуществляет обслуживание. Стандартным портом является 80 порт TCP. Однако, обслуживание можно заказать и на другом порте: Port 80
За этим определяется режим запроса имени хоста или IP-адреса, с которого осуществляется запрос к website: HostnameLookups on
Вслед за этой опцией определяется идентификатор пользователя и идентификатор группы, под которыми сервер осуществляет обслуживание запроса:
User nobody Group #-1
Здесь следует сделать небольшое пояснение. Дело в том, что для обслуживания каждого запроса сервер порождает процесс или поток (в зависимости от версии, производителя и операционной системы). При этом сам сервер стартует в момент запуска ОС и, следовательно, в этот момент имеет права администратора системы. Для того, чтобы эти права не получил обычный пользователь, в момент обслуживания запросов клиентов на каждый запрос порождается новый сервер, и уже этот сервер имеет права, которые определяются параметром User. Типичным пользователем, права которого доступны пользователю при доступе к Web-site, является пользователь nobody.
В файле конфигурации указывается и почтовый адрес администратора:
ServerAdmin paul@kiae.su
Этот адрес используется в сообщениях об ошибках, если ошибки происходят по вине администратора сервера или в сообщениях о перенаправлении запросов.
За почтовым адресом обычно следует определение корня Website. На этот корень будут опираться относительные адреса программного обеспечения. Данный адрес не надо путать с адресом корня страниц Website, который указывается далее:
ServerRoot /users/etc/httpd DocumentRoot /users/etc/httpd/htdocs
Далее определяется местоположение файлов сообщений об ошибках:
ErrorLog logs/error_log TransferLog logs/access_log PidFile logs/httpd.pid ScoreBoardFile logs/apache_status AccessConfig conf/access.conf ResourceConfig conf/srm.conf
Здесь же определяется параметр, по которому прекращается ожидание запроса от клиента:
Timeout 400
При стандартных настройках сервера ничего больше менять в файлах настройки не надо. Из всех параметров, которые еще могут быть указаны серверу важны только те, что определяют число запросов, которые может обслужить сервер-потомок, т.е. тот, который порождается на запрос пользователя, длительность сессии и виртуальные серверы, там же указываются параметры кэша и режим proxy(посредника). Ниже представлен фрагмент описания параметров кэш-сервера и сервера-посредника:
# Proxy Server directives. Uncomment the following line to # enable the proxy server: ProxyRequests On # To enable the cache as well, edit and uncomment the following lines: CacheRoot /users/etc/httpd/proxy СacheSize 5 CacheGcInterval 4 CacheMaxExpire 24 CacheLastModifiedFactor 0.1 CacheDefaultExpire 1 #NoCache olga.polyn.kiae.su
Далее в файле настроек можно определить дополнительные порты и IP-адреса сервера:
# Listen: Allows you to bind Apache to specific IP addresses and/or # ports, in addition to the default. See also the VirtualHost command Listen 3000 Listen 12.34.56.78:80
Кроме этого при организации сервера можно использовать так называемые hardware и software виртуальные-серверы:
# VirtualHost: Allows the daemon to respond to requests for more than one # server address, if your server machine is configured to accept IP packets # for multiple addresses. This can be accomplished with the ifconfig # alias flag, or through kernel patches like VIF. # Any httpd.conf or srm.conf directive may go into a VirtualHost command. # See alto the BindAddress entry. <VirtualHost host.foo.com> ServerAdmin webmaster@host.foo.com DocumentRoot /www/docs/host.foo.com ServerName host.foo.com ErrorLog logs/host.foo.com-error_log TransferLog logs/host.foo.com-access_log </VirtualHost>
При определении виртуальных серверов можно указывать любые команды, которые могут быть указаны и для описания главной базы данных. Вообще говоря, описания главной базы данных может и не быть, а могут быть определены только виртуальные серверы.
Следующий файл, который имеет прямое отношение к описанию базы данных -
access.conf: Ix: {13} cat access.conf # access.conf: Global access configuration # This file defines server settings which affect which types of services # are allowed, and in what circumstances. # Each directory to which Apache has access, can be configured with respect # to which services and features are allowed and/or disabled in that # directory (and its subdirectories). Originally by Rob McCool # This should be changed to whatever you set DocumentRoot to. <Directory /> # This may also be "None", "All", or any combination of "Indexes", # "Includes", "FollowSymLinks", "ExecCGI", or "MultiViews". # Note that "MultiViews" must be named *explicitly* --- "Options All" # doesn't give it to you (or at least, not yet). #Options Indexes FollowSymLinks ExecCGI Includes MultiViews Options All # This controls which options the .htaccess files in directories can # override. Can also be "All", or any combination of "Options", "FileInfo", # "AuthConfig", and "Limit" # AllowOverride None # Controls who can get stuff from this server. order allow,deny allow from all </Directory> # /usr/local/etc/httpd/cgi-bin should be changed to whatever your Scrip-tAliased # CGI directory exists, if you have that configured. <Directory /users/etc/httpd/cgi-bin> AllowOverride None Options None </Directory> # Allow server status reports, with the URL of http://servername/status # Change the ".nowhere.com" to match your domain to enable. #<Location /status> #SetHandler server-status #order deny,allow #deny from all #allow from .nowhere.com #</Location> # You may place any other directories or locations you wish to have # access information for after this one.
Данный файл определяет только основные принципы доступа к странице Website и способы работы со скриптами. Для каждой директории могут быть определены свои собственные права доступа и способы генерации страниц. Делается это либо добавлением новых предложений <Directory> и <Location> в данный файл, либо за счет создания в каждой директории файла описания прав доступа. В Apache - это файлы .access, а в WN - это файлы index. При этом принципы описания генерации страниц и доступа к ним в этих двух серверах совершенно разные. К генерации страниц мы вернемся немного позже, пока поговорим еще об одном файле описания настроек Apache - srm.conf. Мы обратим внимание на особенности представления страниц Website:
DocumentRoot /users/etc/httpd/htdocs UserDir public_html DirectoryIndex index.html FancyIndexing on AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip AddIconByType (TXT,/icons/text.gif) text/* AddIconByType (IMG,/icons/image2.gif) image/* #... здесь определены другие иконы для разных типов файлов DefaultIcon /icons/unknown.gif ReadmeName README HeaderName HEADER # IndexIgnore is a set of filenames which directory indexing should ignore # Format: IndexIgnore name1 name2... IndexIgnore */.??* *~ *# */HEADER* */README* */RCS # AccessFileName: The name of the file to look for in each directory # for access control information. AccessFileName .htaccess # DefaultType is the default MIME type for documents which the server # cannot find the type of from filename extensions. DefaultType text/plain # AddEncoding allows you to have certain browsers (Mosaic/X 2.1+) uncompress # information on the fly. Note: Not all browsers support this. AddEncoding x-compress Z AddEncoding x-gzip gz Alias /icons/ /users/etc/httpd/icons/ ScriptAlias /cgi-bin/ /users/etc/httpd/cgi-bin/ # To use CGI scripts: AddHandler cgi-script .cgi # To use server-parsed HTML files AddType text/html .shtml AddHandler server-parsed .shtml # If you wish to use server-parsed imagemap files, use AddHandler imap-file map # To enable type maps, you might want to use AddHandler type-map var #AddHandler foot-action foot #Action foot-action /cgi-bin/footer # Or to do this for all HTML files, for example, use: #Action text/html /cgi-bin/footer # MetaDir: specifies the name of the directory in which Apache can find # meta information files. These files contain additional HTTP headers # to include when sending the document #MetaDir .web # MetaSuffix: specifies the file name suffix for the file containing the # meta information. #MetaSuffix .meta
В данном фрагменте многие опции остались в виде комментариев. Если их необходимо использовать, то просто надо убрать символ "#" из первой позиции строки.
Как видно из этих опций, в современных версиях серверов пользователю дается возможность выбора между внешними по отношению к серверу реализациям imagemap и модулем сервера, который реализует те же функции. Кроме того, сервер позволяет реализовать стандартные заголовок и окончание документа (header и footer).
В случае, когда для разных частей базы данных нужны заголовки страниц разного типа, пользуются так называемые server-side includes, т.е. вставки в тело документа, которые сервер делает перед тем как отправить документ программе-клиенту. Делается это при помощи HTML-комментариев типа:
<!-- #include file.html -->
При анализе документа, содержащего эту строку, вместо нее будет вставлено содержание файла file.html. Синтаксис таких предложений варьируется от сервера к серверу. Некоторые серверы, например WN, разрешают выполнять условные подстановки типа:
<!-- #if accept ~ "image/jpeg" --> <a href="picture.jpg"> Here is the jpeg version of picture.</a> <!-- #else --> <a href="picture.gif"> Here is the gif version of picture.</a> <!-- endif -->
В данном случае условная подстановка выполняется на основе анализа заголовка запроса программы-клиента, в котором есть список предложений Accept.
Пример заголовка запроса по протоколу HTTP 1.0.
GET /httpddoc/setup/startit.htm HTTP/1.0 Referer: http://144.206.192.101/httpddoc/Overview.htm User-agent: Mozilla/1.1N (Windows; 16bit) Accept: */* Accept: image/gif Accept: image/x-xbitmap Accept: image/jpeg
Последние четыре строки этого примера сообщают серверу форматы графических данных, которые могут быть отображены программой-интерфейсом Mozilla версии 1.1N (Mozilla - 16 разрядный интерфейс Netscape Communication для Windows 3.1).
Существуют и другие способы вставки файла в текст документа. Наиболее интересным из них является создание "скелета" документа, состоящего только из вставок. Необходимость в этом появляется например при создании печатной копии гипертекстовой базы данных.
Возможность ссылаться только на часть файла основана на механизме "зон" (ranges). Для того чтобы этот механизм работал, сервер должен понимать запросы типа: <http://host/dir/file;lines=20-30>. В этом случае в качестве ответа будут получены строки с 20-й по 30-ю, а не весь файл. Обычно, такую ссылку используют для работы с плоским текстом.
Еще одна важная особенность современных серверов - это фильтры, позволяющие выполнять некоторые подготовительные операции над файлом прежде, чем им займется сам сервер. Наиболее часто фильтры применяются для распаковки или преобразования графических файлов.
"Зоны" и фильтры не указываются и не прописываются разработчиком в телах документов базы данных сервера, а обычно настраиваются через файлы конфигурации сервера. Сервер NCSA, например, имеет специально выделенную директорию для своих файлов конфигурации. Аналогичную структуру имеет и популярный сервер для Windows 3.1 и
Windows NT - Winhttpd. Другие серверы, например WN, в каждом каталоге дерева базы данных имеют соответствующий файл конфигурации ресурсов.
Описание файлов со специальным назначением следует начинать с файла index.html, который предназначен для тех случаев, когда пользователь не указывает в своем запросе конкретный файл базы данных, а просто обращается к серверу или к одной из директорий:
http://polyn.net.kiae.su/
или http://www.w3.org/hypertext/
В этом случае по умолчанию обращение происходит к файлу index.html. Вообще говоря, таким файлом может быть любой другой файл, который будет назначен при конфигурировании вместо index.html, но это приведет к необходимости постоянно помнить о том, что на вашем сервере все не так как у всех остальных.
Важным свойством сервера является перенаправление запроса, когда в файле конфигурации появляется указание на другой файл. Все, кто пробовал работать с Line Mode Browser'ом, наверняка сталкивались со следующей ситуацией: на экран выдается странное сообщение "Сервер выполнил перенаправление запроса. Программа-клиент не умеет делать автоматический перевызов ресурса...". После подобной фразы предлагается выбрать одну из ссылок для перехода к требуемой WWW странице. До сих пор с этим приходится сталкиваться при обращении по адресу http://www.w3.org/ или http://info.cern.ch/. В данной ситуации происходит перенаправление запроса на другой ресурс, а так как программа просмотра Line Mode Browser или www не выполняет повторного запроса ресурса с новым адресом, то приходится делать его вручную. Вообще говоря, перенаправление чрезвычайно полезный механизм, при отсутствии которого во время перемещения страниц с одного сервера на другой в сети творилась бы жуткая неразбериха.
Кроме простого перенаправления существует еще одна интересная возможность переадресации запросов, связанная со временем хранения файла в базе данных. В заголовке HTTP существует предложение Refresh, которое заставляет клиента периодически, через определенный промежуток времени, без дополнительного требования со стороны пользователя, обращаться к серверу за новой копией файла. При этом сервер, например WN, имеет возможность перенаправить запрос к другому файлу базы данных. Используя этот механизм, можно организовать цикл из нескольких страниц, которые будут замещать друг друга. Применение такого механизма очевидно: рекламные ролики, галереи картинок, информационные доски. В сочетании с CGI-скриптами такой механизм дает возможность простыми средствами организовать довольно сложные динамические страницы.
Последним, о чем следует упомянуть в связи со структурой базы данных сервера WWW, являются файлы-индексы. Эти файлы не следует путать с index.html, используемым для доступа по укороченному URL. Главное назначение файлов-индексов - обеспечение поиска информации в базе данных WWW сервера по ключевым слова. Такие серверы как CERN httpd или WN имеют специальный модуль, который реализует функции поисковой машины. Сервер NCSA обычно настраивается на использование внешней поисковой машины, например WAIS, а индексный файл - это инвертированный список, где каждому слову ставится в соответствие список документов, где это слово встречается. Часто считают, что поиск по ключевым словам реализует полнотекстовый поиск по базе данных: однако это не так. Реально в файлы-индексы попадают только те слова, которые содержатся в части документа, предназначенной для построения индекса. Так многие серверы позволяют строить индексы по заголовкам документов, по специальным полям пользователя или по спискам ключевых слов, указанных в файле конфигурации. В принципе, существует возможность построения индекса с использованием полного текста документа, но при этом следует учитывать следующее: в полном тексте много общих слов, которые будут занимать место, но не прибавят точности поиску. При создании таких индексов база данных будет фактически продублирована, но только в другом формате.
Все серверы поддерживают возможность запуска внешних программ через спецификацию Common Gateway Interface. Обычно CGI скрипты расположены в специальной директории базы данных сервера. Однако, в ряде случаев, скрипт может храниться и в произвольном месте файловой системы. Сервер распознает скрипт либо по месту хранения, либо по расширению имени скрипта - как правило это "cgi". Как это определяется, мы видели из файлов настройки сервера Apfche.
