Російська 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 …]

Можливі значення параметрів:

  • ExecCGI — дозволити виконання CGI-сценаріїв у даному каталозі і його поддереве
  • FollowSymLinks — дозволити переходи по символічних посиланнях (створюваним командою ln)
  • Includes — дозволити SSI (Server Side Includes)
  • Indexes — дозволити видачу лістингу каталогу, якщо в ньому немає файлу index.html (або файл індексу, визначеного директивою DirectoryIndex)
  • MultiViews — дозволити підтримку багатьох мов; за замовчуванням вона відключена, і включати її, як правило, не потрібно; підтримка перекодування «на льоту» для російської мови встановлюється з допомогою інших директив, які ми розглянемо пізніше
  • All — встановити відразу всі перераховані режими крім MultiViews

All — встановити відразу всі перераховані режими крім MultiViews

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 » на чолі з Олексієм Тутубалиным (lexa@ lexa.ru). За час свого розвитку модуль зазнав безліч змін і тепер володіє практично необмеженими можливостями налаштування для будь-якої конкретної конфігурації.

Інструкції, що відповідають за перекодування, поділяються природним чином на три групи. До першої належать дві директиви, які вказують, в якому кодуванні зберігаються файли на диску: 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. Якщо обрана таким чином сторінка не підходить, клієнт може змінити кодування вручну. Основних схем вибору три: з префіксом каталогу, імені віртуального сервера, номером порту. У кожної з них є свої переваги і свої недоліки.

  • http://www.rmt.ru/win/document.html — вибір кодування з префіксом каталогу
  • http://win.www.rmt.ru/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
All Options
AllowOverride All
order allow,deny
allow from all
# You may any other place or directories 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