Робота з
Web-сервером Russian Apache
Російська
Apache
Найпоширеніший Web-сервер
у світі - це Apache. За даними компанії Netcraft (http://www.netcraft.com/
Survey /) загальна кількість Web-сайтів, що працюють під його керуванням, до кінця 1998
досягло 2 млн. (55% загального числа вузлів) і постійно зростає. Для порівняння: на
частку серверів Microsoft припадає 25%, Netscape -7%. Будучи безкоштовної
відкритою програмою, призначеною для безкоштовних ж Unix-систем (FreeBSD,
Linux та інші), Apache по функціональних можливостях і надійності не поступається
комерційним серверів, а широкі можливості конфігурування дозволяють
налаштувати його для роботи практично з будь-якою конкретною системою. Існують
локалізації сервера для різних мов, у тому числі і для російського.
Історично склалося так, що
російські тексти в Internet можуть бути представлені в різних кодуваннях, з
яких найбільш поширені koi8-r (або просто koi8) і Windows-1251: з
перший працює більшість серверів і робочих станцій під управлінням Unix,
другий є стандартною для всіх версій Windows. Оскільки кодування
Windows-1251, природно, застосовується на переважній більшості клієнтських
машин, частка тих, хто подорожує з російської частини WWW, використовуючи koi8, не
зараз перевищує 5%. Однак у цьому кодуванні зберігаються документи на багатьох
Unix-серверах, в ній найчастіше передаються поштові повідомлення і практично
завжди - листи в телеконференції, з нею ж працюють багато російськомовних
канали IRC (до речі, КОИ абревіатура розшифровується як "код обміну
інформацією "). Щоб вирішити проблеми, що виникають при розбіжності кодувань
тексту на сервері і клієнтської машині, і був створений російський модуль Apache-RUS
для Web-сервера Apache.
У статті ми розглянемо процес
установки і настройки як самого сервера, так і механізму перекодування
документів "на льоту".
Установка
Свіжу версію Apache-RUS можна
отримати за адресою ftp://apache.lexa.ru/pub/apache-rus/ ( "старша"
частина номера версії, наприклад 1.3.3, відповідає версію оригінального Apache,
"молодша", наприклад PL27.3, - так званому patch level, тобто
версією російського модуля). Рекомендується встановлювати ті версії, які
зарекомендували себе як "стабільні". Тут настройка сервера
описується на прикладі Apache_1.3.3rusPL27.3.
Отже, насамперед ми
переписуємо на свою машину архів (менше 1,5 Мбайт) і розпаковуємо його:
# ftp ftp://apache.lexa.ru/pub/apache-rus/ apache_1.3.3rusPL27.3.tar.gz
# tar xvzf apache_1.3.3rusPL27.3.tar.gz
Після цього входимо в створений
при розпакуванні каталог apache_1.3.3rusPL27.3 і запускаємо сценарій configure:
# cd apache_1.3.3rusPL27.3
#./configure
При необхідності сценарієм можна
в явній формі вказати аргументи (їх список видається за командою configure
-help). Так, якщо потрібно встановити сервер в інший каталог, ніж
стандартний, потрібно виконати "configure
-prefix =".
Коли configure відпрацює,
слід, як завжди, дати і команди make make install (ці дії виконуються
користувачем root).
# make
# make install
Тепер сервер встановлений в
каталозі/usr/local/apache, але запускати його поки не можна - спочатку ми повинні
відредагувати файли настройки httpd.conf, access.conf і srm.conf в каталозі
/ usr/local/apache/etc/(починаючи з версії 27.4 -/usr/local/apache/conf).
Налаштування
Налаштування конфігураційних
файлів Web-сервера - найвідповідальніший крок під час його встановлення. Тут ми
розглянемо тільки найбільш поширені директиви і їх параметри, оскільки
повний перелік з описом займе не один десяток сторінок. Сервер перечитує
конфігураційні файли при запуску, а також при отриманні сигналу-HUP (жорсткий
рестарт) або-uSR1 (м'який рестарт). Якщо сервер знаходиться в робочому стані,
то при зміні конфігурації його рекомендується перезапустити командою
# kill-USR1 `cat/usr/local/apache/logs/httpd.pid`
У цьому випадку наявні
з'єднання не закриваються примусово і завершуються звичайним способом, а
наступні клієнти працюють вже з новими файлами налаштувань.
Файл
access.conf
У access.conf містяться
директиви, що описують права доступу до каталогів і файлів Web-сервера. Перш
всього вирішите, в якому каталозі будуть зберігатися документи. За умовчанням це
/ usr/local/apache/share/htdocs, однак багато адміністратори вважають за краще
розміщувати документи починаючи з каталогу/www//, оскільки при
такої організації простіше орієнтуватися в структурі файлів. Нехай, наприклад, ми
створили каталоги:
/www/rmt.ru/
/www/radio-msu.net/
/www/people.radio-msu.net/
Вони будуть кореневими для
відповідних віртуальних серверів.
Файл access.conf може містити
секції Directory, Location і Files, які обмежені однойменними
директивами. У параметрах цих директив можуть використовуватися символи
"?" і "*", а також регулярні вирази, що передують
тильда, наприклад. У секції
Directory містяться інструкції, що відносяться до певного каталогу на диску,
в секції Location - пов'язані з віртуальному шляху, в секції Files --
що відносяться до файлу або групи файлів.
# директиви, що відносяться до всіх
документів, що зберігаються в
каталозі/www/rmt.ru і вкладених
в нього
# директиви, що відносяться до всіх
документів, доступним за
адресою
http:///cgi-bin/
# директиви, що відносяться до файлу
form.html з каталогу
/www/rmt.ru
Різниця між секціями
Directory і Location полягає в тому, що перше відноситься до каталогів на диску,
другий - до віртуального шляху (URL), який браузер запитує в Web-сервера.
І в тій, і в іншій можуть бути присутніми директиви order, allow і deny, які
дозволяють обмежити доступ до каталогу або URL з різних машин.
Наступні дві директиви
відносяться до секції.
Options [options ...]
Можливі значення параметрів:
ExecCGI - дозволити виконання
CGI-сценаріїв у цьому каталозі і його піддереві;
FollowSymLinks - дозволити переходи
по символічним посиланням (створюваним командою ln);
Includes - дозволити SSI (Server Side
Includes);
Indexes - дозволити видачу
лістингу каталогу, якщо в ньому немає файла index.html (або файлу індексу,
заданого директивою DirectoryIndex);
MultiViews - дозволити підтримку
багатьох мов; за замовчуванням вона відключена, і включати її, як правило, не
потрібно; підтримка перекодування "на льоту" для російської мови
встановлюється за допомогою інших директив, які ми розглянемо пізніше;
All - встановити відразу всі
перераховані режими крім MultiViews.
При відсутності спеціальних
вимог до безпеки цілком допустимо вказати "Options All" в
секції; інакше потрібно описати параметри
кожного каталога окремо.
AllowOverride [options ...]
Більшість директив можуть
задаватися не тільки у конфігураційних файлах сервера, але і у файлах. htaccess
в каталогах сервера. Директива AllowOverride визначає набір директив,
допустимих у файлах. htaccess. Параметри можуть бути зазначені наступні:
AuthConfig - дозволити встановлення
авторизації по імені користувача і паролю;
FileInfo - дозволити директиви,
що відповідають за типи документів;
Indexes - дозволити директиви,
пов'язані з лістингом каталогів;
Limit - дозволити команди allow
і deny, які обмежують доступ до файлів в залежності від адреси
клієнтського комп'ютера;
Options - дозволити описану
вище директиву Options.
Врахуйте, що при включенні
останнього режиму користувачі отримують можливість створювати власні файли
. htaccess і вирішувати в них виконання CGI-сценаріїв. Тому якщо потрібно
контролювати CGI-сценарії користувачів, що не слід поширювати на
користувацькі каталоги дію директиви AllowOverride Options.
Однак у багатьох випадках (у
Зокрема, коли права на зміну вмісту сервера є тільки у
адміністратора) файл access.conf може виглядати так, як в лістингу 1.
Файл srm.conf
Файл srm.conf містить
директиви, пов'язані із загальними налаштуваннями структури каталогів сервера. Як
правило, в ньому достатньо змінити лише кілька рядків.
DocumentRoot
Шлях до каталогу за замовчуванням,
індексний файл якого користувач отримає при зверненні до сервера
(http:///). Цю директиву слід задати і для кожного з
віртуальних серверів (в секції файлу httpd.conf).
UserDir
Каталог, в якому користувачі
повинні розміщувати свої файли, щоб вони були доступні за адресою
http:/// ~ /. Стандартно public_html.
Іноді, щоб полегшити життя користувачам, адміністратори дають директиву
"UserDir www".
DirectoryIndex
Файл індексу - це той файл,
який буде передано клієнту при зверненні до каталогу. Якщо вказати декілька
імен, сервер буде шукати відповідну файл "зліва направо". За
замовчуванням список містить лише одне ім'я - index.html, але прийнято додавати в
нього й інші поширені імена індексних файлів. Наприклад, директива
може мати вигляд: DirectoryIndex. index.html index.html index.htm index.cgi
index.shtml home.html home.htm default htm default html
Щоб включити на сервері
підтримку CGI-сценаріїв, слід прибрати знак коментарю перед директивами
ScriptAlias і AddHandler cgi-script. Cgi. Перша задає каталог на диску, в
якому будуть зберігатися виконуються програми, а другий визначає, що всі
файли з розширенням. cgi повинні оброблятися як сценарії.
Директива ErrorDocument
дозволяє замінювати стандартні повідомлення сервера про помилки на свої. Наприклад,
у разі найпоширенішою помилки - 404 (файл не знайдено) - вважається
гарним тоном видавати користувачеві сторінку з пропозицією продовжити свій
шлях по серверу або форму для пошуку по сайту. Реалізується це досить
просто: в настройках сервера ми прибираємо знак коментарю з рядка
ErrorDocument 404/missing.html
B кореневому каталозі кожного
віртуального сервера створюємо файл missing.html. Рекомендується дати в ньому посилання
на основні розділи сервера - і для зручності користувачів, і для того, щоб
надати необхідну інформацію пошуковим роботам, індексуються сервери.
Файл httpd.conf
Конфігураційний файл httpd.conf
є основним і містить налаштування, пов'язані з роботою Web-сервера,
віртуальних серверів, а також усіх його програмних модулів. Крім того, саме
в ньому настроюється перекодування російських букв при передачі від сервера до
клієнта і назад.
Директива Port, поміщена в
самому початку файлу, визначає номер порту для http-сервера; за замовчанням
80. При необхідності можна приписати сервера інший порт або кілька портів,
для чого служить директива Listen.
Директива HostnameLookups з
параметром on або off включає або, відповідно, відключає перетворення
чисельних IP-адрес клієнтів, які отримали документи з сервера, в доменні
імена. Таке перетворення декілька уповільнює роботу сервера, але при числі
відвідувань менше 10 000 на добу це, як правило, практично не помітно.
Директиви User Group і задають
користувача, який буде адмініструвати сервер. З точки зору
безпеки небажано вказувати тут існуючого користувача, що має
доступ до будь-яких інших ресурсів або файлів. Краще створити окремого
користувача і групу спеціально для http-сервера, наприклад:
User www
Group www
Директиви ServerRoot, ErrorLog,
CustomLog визначають відповідно кореневий каталог http-сервера, шлях до
журналу реєстрації помилок (error_log) і шлях до загального журналу звернень до
сервера (access_log).
Директива CacheNegotiatedDocs
дозволяє кешування документів, отриманих із сервера. За замовчуванням цей режим
відключений, але, оскільки пропускна здатність вітчизняних Internet-каналів
ще довго буде залишати бажати кращого, добре б його включити: тоді
користувачеві не доведеться чекати завантаження зображень при кожному зверненні до вашої
сторінці.
Налаштування
віртуальних серверів у файлі httpd.conf
У більшості випадків один
http-сервер здатний обробляти запити, що надходять на різні, так
звані віртуальні, Web-сервери. Віртуальні сервери можуть мати як один і
той же IP-адресу, але різні доменні імена, так і різні IP-адреси. З точки
зору користувача другий варіант трохи більш кращий, оскільки запит
до сервера, що відрізняється від основного тільки доменним ім'ям, повинен містити
його ім'я, а деякі старі браузери, які не підтримують протокол HTTP/1.1
(наприклад, Microsoft Internet Explorer 2.0), не включають до запиту цю
інформацію. Однак такі браузери виходять з ужитку (зараз їх уже менше
0,5% загальної кількості), з іншого боку, виділення власного IP-адреси кожному
віртуального сервера може бути невиправданою розтратою адресного простору
компанії.
Для опису адрес і доменних
імен віртуальних серверів служать директиви ServerName, ServerAlias,
NameVirtualHost і VirtualHost. Вони необхідні, тільки якщо вам потрібно встановити
більше одного віртуального сервера.
У лістингу 2 показано фрагмент
конфігураційного файлу для випадку віртуальних серверів з різними
IP-адресами, в лістингу 3 - аналогічний фрагмент для випадку, коли сервери
розрізняються тільки доменним ім'ям.
Директива ServerName,
що знаходиться поза секцій VirtualHost, визначає ім'я основного сервера, тобто
сервера, кореневий каталог якого задано директивою DocumentRoot у файлі
srm.conf. Віртуальні сервери успадковують налаштування основного і при необхідності
спеціального настроювання відповідні директиви поміщаються в секції
VirtualHost, що відноситься до цього сервера. Допустимі будь-які директиви, які
можуть зустрітися в файлах httpd.conf та srm.conf, наприклад DocumentRoot,
ErrorLog, CustomLog, Location, ServerAdmin.
З лістингу 3 видно, як
використовується директива ServerAlias, якщо необхідно створити кілька
віртуальних серверів з однаковим змістом. Після того як ви занесете в
конфігураційні файли інформацію про наявні на диску віртуальних серверах
(зрозуміло, вони повинні бути описані і в конфігураційних файлах DNS), можна
приступити до останнього кроку налаштування Apache-RUS.
Налаштування перекодування
російськомовних документів
Модуль підтримки російських
кодувань був розроблений в 1996 р. Дмитром Крюковим ([email protected]), а з
Лютий 1997 підтримується робочою групою Apache-RUS Team на чолі з
Олексієм Тутубаліним ([email protected]). За час свого розвитку модуль зазнав
значних змін і тепер володіє практично необмеженими можливостями
налаштування для будь-якої конкретної конфігурації.
Інструкції, що відповідають за
перекодування, поділяються природним чином на три групи. До першої
відносяться дві директиви, які вказують, в якому кодуванні зберігаються файли на
диску: CharsetSourceEnc і CharsetByExtension
...
Наприклад, файл httpd.conf може
містити рядки:
CharsetSourceEnc koi8-r
CharsetByExtension windows-1251. txt
Такий запис означає, що всі
файли зберігаються на диску в кодуванні koi8-r; виключення складають текстові
файли з розширенням txt, для яких використовується Windows-1251.
Якщо кодувань більше однієї і
документи в кожній кодуванні зберігаються в своєму каталозі, директиви
CharsetSourceEnc поміщаються у відповідні секції або в
файли. htaccsess всередині каталогів.
Другу групу складають
директиви CharsetDecl, CharsetAlias CharsetRecodeTable і CharsetWideRecode
Table, які визначають назви кодувань, їх синоніми та таблиці
перекодування. Усі вони розміщуються в секції --
і в більшості випадків не мають потреби в зміні.
У третьому, найчисленнішу
групи входять директиви, які визначають порядок перекодування символів від сервера
клієнта і назад.
Прийнято, щоб при потраплянні на
російськомовний сервер користувач отримував сторінку в "своїй"
кодуванні, яка визначається автоматично на основі тієї інформації про операційну
системі, яку передає серверу браузер: наприклад, встановивши, що
користувач працює в Windows, сервер видає йому сторінку в кодуванні
Windows-1251, а встановивши, що він працює в Unix, видає сторінку в koi8. Якщо
вибрана таким чином сторінка не підходить, клієнт може змінити кодування
вручну. Основних схем вибору три: за префікс каталогу, на ім'я віртуального
сервера і за номером порту. У кожної з них є свої переваги і свої
недоліки.
1)
http://www.rmt.ru/koi/document.html
http://www.rmt.ru/win/document.html
- Вибір кодування по префікс каталогу,
2)
http://koi.www.rmt.ru/document.html
http://win.www.rmt.ru/document.html
- Вибір кодування на ім'я сервера,
3)
http://www.rmt.ru:8000/document.html
http://www.rmt.ru:8001/document.html
- Вибір кодування по порту.
Для організації вибору кодування
по префікс каталогу потрібно або внести в секцію VirtualHost рядок виду
Alias/koi/www/rmt
або створити у відповідному
каталозі символічну посилання на себе:
# cd/www/rmt
# ln-s. koi
Зусилля, що витрачаються на
початкове конфігурування, невеликі, але для великих серверів з
розгалуженою структурою така схема не дуже підходить: навряд чи вдасться
проконтролювати коректність посилань на різні сторінки сайту з зовнішніх
серверів, так і за внутрішніми посиланнями простежити не так-то просто (в
більшості випадків вони повинні бути відносними).
При виборі кодування на ім'я
сервера необхідно, щоб інформація про відповідні імена була задана в
настройках DNS-сервера, що обслуговує даний домен, а в файл httpd.conf в
секцію VirtualHost вносяться рядки:
ServerName www.rmt.ru
ServerAlias *. www.rmt.ru
...
Якщо в якості імені піддомену
виступає один з синонімів назви кодуванняі (CharsetAlias), то це кодування
вважається кодуванням клієнта. При такому підході посилання всередині сервера можуть
бути будь-якими, і єдиний недолік даної схеми в тому, що перекодування
не виконується для браузерів, не вказують у запиті ім'я сервера, - втім,
їх, як уже говорилося, залишилося вкрай мало. Якщо ж сумісність зі старими
браузерами категорично необхідна, можна призначити кожному піддомену свій
IP-адресу.
Щоб застосувати вибір за номером
порту, необхідно у файлі httpd.conf видалити директиву Port і зняти коментарі
з рядків
Listen 80
Listen 8100
Listen 8101
Listen 8102
Listen 8103
CharsetByPort koi8-r 8100
CharsetByPort windows-1251 8101
CharsetByPort ibm866 8102
CharsetByPort iso-8859-5 8103
Номери портів не дуже важливі. У
стандартної налаштування Apache-RUS нумерація, як бачимо, починається з 8100, але
частіше її починають з 8000 або 8080.
Дана схема не вимагає внесення
додаткових записів в DNS і дозволяє працювати з віртуальними серверами навіть
клієнтам, які не підтримують протокол HTTP/1.1, - адже кодування
вибирається виходячи з числа, що вказує на номер порту Web-сервера (по
Типовою є 80). Однак мережні брандмауери іноді забороняють роботу з
певними портами, і якщо таким брандмауером захищена мережа клієнта, він не
зможе встановити з'єднання з вашим сервером. На жаль, подібна ситуація
виникає частіше, ніж хотілося б.
Схема вибору кодування задається
директивою CharsetSelectionOrder. Її параметри визначають порядок застосування
правил вибору. Так, вибору по префікс каталогу відповідає рядок
CharsetSelectionOrder Dirprefix Useragent Portnumber Hostname
UriHostname
Вибору на ім'я домену - рядок
CharsetSelectionOrder Hostname UriHostname Useragent Portnumber Dirprefix
Для вибору за номером порту
слід записати
CharsetSelectionOrder Portnumber Useragent Hostname UriHostname
Dirprefix
Зауваження
Щоб документи, кодування
яких була обрана автоматично, не осідали в кешах проксі-серверів,
Apache-RUS дає їм спеціальний HTTP-заголовок, що забороняє кешування. У
результаті при поверненні на сторінку (наприклад, на кнопку Back) вона зчитується
з сервера заново, що, по-перше, уповільнює роботу, а по-друге (і це більш
серйозна проблема) очищає всі текстові форми, які були на сторінці (то
ж відбувається при використанні JavaScript). Дозволити кешування дозволяє
директива CharsetDisableForcedExpires On, яка задається у секції
для даного віртуального шляху або у відповідному файлі. htaccess,
але тоді виникає ризик, що користувачі іноді будуть одержувати сторінки в
"чужий" кодуванні. Існують і проміжні варіанти: наприклад,
можна встановити CharsetDisableForcedExpires On (у секції) тільки
для тих документів, які містять форми, вікна або JavaScript-сценарії.
Для повного відключення
перекодування в каталозі або на віртуальному сервері служить директива Charset
Disable On.
При виборі кодування на ім'я
сервера або за префікс каталогу гарним тоном є використання для
графічних файлів абсолютних посилань із зазначенням імені сервера (наприклад,
). Тоді при
переході клієнта від основного сервера до вибраної кодуванні зображення будуть
братися з локального кеша браузера, а не перечитувати заново. Це особливо
актуально при великому обсязі графічної інформації на сервері.
Запуск
сервера
Після закінчення процедури настройки
слід запустити httpd-сервер. Для цього потрібно увійти в систему з привілеями
користувача root і дати команду
#/usr/local/apache/sbin/apachectl start
(починаючи з версії 27.4 - #
/ usr/local/apache/bin/apachectl start)
Якщо у конфігураційних файлах
є серйозні помилки, сервер не запуститься, а на екран буде виведено
відповідне повідомлення. У будь-якому випадку після запуску сервера має сенс
переглянути файли error_log і access_log, які знаходяться в каталозі logs.
Для перевірки працездатності сервера достатньо створити в його кореневому
каталозі файл index.html і звернутися з браузера за адресою сервера. Правильну
встановлення режимів перекодування слід перевіряти за допомогою браузерів для
різних операційних систем. Не забудьте додати Apache до переліку програм,
запускаються при старті системи. Успіхів вам у поповненні російської
Web-простору!
Про автора
Артем Подстрешний - програміст,
працює в компанії "Радіо-МГУ". У "Світі ПК" опублікована
його стаття "Імена Internet". E-mail: [email protected]
;
http://www.radio-msu.net/
Посилання
http://www.apache.org/ --
офіційний сервер розробників Apache
http://apache.lexa.ru/ - сервер
групи розробників російського модуля Apache
Лістинг 1 Фрагмент простого
файлу access.conf
# # access.conf - Apache HTTP server configuration file
# #
# access.conf: Global access configuration
# Online docs at http://www.apache.org/
Options FollowSymLinks
AllowOverride None
Options All
AllowOverride All
order allow, deny
allow from all
# You may place any other directories or locations you wish
to have access information for after this one.
Лістинг 2 Опис віртуальних
серверів з різними IP-адресами
...
ServerName www.radio-msu.net
DocumentRoot/www/radio-msu.net
ServerName www.radio-msu.net
ErrorLog/var/log/error_log.radio-msu.net
CustomLog/var/log/access_log.radio-msu.net combined
...
DocumentRoot/www/rmt.ru
ServerName www.rmt.ru
ErrorLog/var/log/error_log.radio-msu.net
CustomLog/var/log/access_log.radio-msu.net combined
...
Лістинг 3 Опис віртуальних
серверів, що розрізняються тільки доменним ім'ям
...
ServerName www.radio-msu.net
NameVirtualHost 193.124.134.2
DocumentRoot/www/radio-msu.net
ServerName www.radio-msu.net
ErrorLog/var/log/error_log.radio-msu.net
CustomLog/var/log/access_log.radio-msu.net combined
...
DocumentRoot/www/people.radio-msu.net
ServerName people.radio-msu.net
ServerAlias *. people.radio-msu.net
ErrorLog/var/log/error_log.people.radio-msu.net
CustomLog/var/log/access_log.people.radio-msu.net combined
...
Список
літератури
Артем Подстрешний. Робота з
Web-сервером Russian Apache.
