- Подписка на печатную версию:
- Подписка на электронную версию:
- Подшивки старых номеров журнала (печатные версии)
LXF113-114:Apache
Материал из Linuxformat.
- Сети Свяжем Linux-машины и заставим их обслуживать нас
Содержание |
Apache: Твой web-сервер
- ЧАСТЬ 1. Нейл Ботвик запускает новую серию уроков для любителей поколдовать над проводами и разъемами. То есть, для нас с вами!
Сеть всегда была самым сердцем Linux. В Web уже появились блог-посты на тему «Станет ли 2009 годом настольного Linux?», и пророки-скептики объясняют, что этому не бывать, но куда важнее то, что Linux и сейчас служит всем пользователям компьютеров. Даже если программа запущена на единственной системе, она часто реализует сценарий «клиент–сервер»: одно приложение работает в фоновом режиме, а другие шлют ему свои запросы. Яркий пример – служба печати CUPS: демон cupsd сидит себе на задворках, а остальные программы отправляют ему задания на печать.
В данной серии уроков мы рассмотрим типы серверов, устанавливаемых в Linux, научимся их настраивать и узнаем, какую пользу можно из этого извлечь. Физических сетей касаться не будем – об этом позаботится инсталлятор вашего дистрибутива; опустим также подробности установки приложений – сбережем место для вещей поважнее. Большинство приводимых здесь программ вполне заурядны: вы без труда найдете их в репозитории любого дистрибутива и установите стандартным менеджером пакетов. Если понадобится скомпилировать нечто сверхновое из исходников – мы сделаем это, когда (и если) понадобится. Некоторые серверы мы посетим не раз, возвращаясь к ним на все более сложных уровнях освоения. Но главное – мы узнаем, что и как с ними можно сделать.
Часть 1 Где живет Apache и файлы его настройки
Задача данного урока – настройка web-сервера. Мы расскажем, как организовать обслуживание web-страниц для локальной сети; как обеспечить к ним доступ через интернет-подключение; и как получить доменное имя, чтобы ваш сайт имел не только (зачастую динамический) IP-адрес.
Попросите любого назвать web-сервер для Linux, и этот любой назовет Apache. Другой сервер? А что, и другие есть? Да, есть, но Apache – вездесущ. Другие серверы имеют свои преимущества (некоторые, например, полегче). Но представьте себе, что вы решили перенести сайт с локального сервера на коммерческий. Почти наверняка на нем работает Apache, а значит, настройки не пропадут.
Зачем устанавливать web-сервер? Тому есть множество причин, и любая из них может стать решающей.
- Разработка и тестирование web-сайтов перед передачей их на «живой» сервер.
- Совместная работа с документами в локальной сети.
- Организация частного сайта для семьи и друзей.
- Эксперименты с различными web-программами.
- Просто потому, что вы это можете!
С чего начать
Apache имеется в репозиториях едва ли не любого дистрибутива, поэтому просто установите его (часто он даже присутствует по умолчанию). Web-серверы, как правило, не работают через inetd, они запускаются при загрузке как самостоятельные процессы. Воспользовавшись менеджером служб своего дистрибутива, проверьте, что Apache работает, затем наберите http://localhost в адресной строке любимого браузера. Вы увидите либо начальную страницу Apache, с уведомлением об отсутствии контента, либо сообщение об ошибке (мол, директория с данными пуста). Увидев нечто вроде ‘cannot connect’ [соединение невозможно], возвращайтесь к менеджеру служб и проверьте, выполняется ли Apache.
Расположение HTML-страниц, которые обслуживает Apache, устанавливается в файле конфигурации, в разных дистрибутивах по-разному. Стандартное место для них – /var/www/localhost/htdocs, но некоторые используют /srv/www/htdocs или просто /var/www. Какая бы директория не была выбрана в качестве базовой для сайтов Apache, наиболее популярное и общепринятое место для хранения их HTML- файлов – hostname/htdocs. Таким образом вы можете содержать сайты более чем для одного хоста в единой структуре. Подкаталог htdocs здесь затем, что существуют некоторые необходимые сайту файлы, доступ к которым из web-браузера должен быть закрыт: например, файлы паролей. Их можно смело помещать в hostname: Apache ничего «выше» htdocs не обслуживает. Потерпите, скоро станет яснее.
Некоторые дистрибутивы не держат отдельных каталогов для каждого сайта: Ubuntu, например, помещает все подряд в /var/www – и для личных файлов безопасного места хранения нет. Для начала, исправим это.
Файлы конфигурации Apache находятся в /etc/apache2, но внутреннее строение этого каталога зависит от дистрибутива. Главный файл – httpd.conf. Его редактируют редко: вся информация о сайтах берется из других файлов и каталогов, подключаемых директивой Include. Например, OpenSUSE хранит настройки сайта по умолчанию в default-server.conf, а прочие сайты – в каталоге vhosts.d. В Ubuntu настройки всех сайтов хранятся в sites-available и вариант по умолчанию имеет очевидное имя default. На файлы в этом каталоге создаются символьные ссылки из sites-enabled («активные сайты»), так что включение и выключение сайта сводится к созданию и удалению символьной ссылки. Сами настройки остаются в неприкосновенности.
Не забывайте перезапускать Apache после каждого изменения настроек. Иначе будете недоумевать: куда девались изменения?
Создайте каталог, где будут храниться файлы, скажем, /var/www/localhost/htdocs, затем загрузите настройки сайта по умолчанию в любимый текстовый редактор (да хоть Emacs) и найдите инструкцию DocumentRoot. Это базовый каталог, где Apache ищет файлы. Укажите здесь свою директорию, затем найдите секцию <Directory…>…</Directory>, соответствующую первоначальному значению DocumentRoot, и измените путь в открывающем тэге Directory на нужный. Затем должен идти такой блок (возможно, с массой комментариев):
<Directory “/var/www/localhost/htdocs”> Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory>
Разберем его построчно. Конфигурация Apache иерархична по двум направлениям: файлы и каталоги в /etc/apache2 упрощают организацию нескольких сайтов, но это только для удобства пользователя, ведь использование Include означает, что при передаче Apache все данные объединяются в один большой файл. Внутри этой кучи параметров существует другая иерархия: настройки могут быть глобальными, а могут относиться к конкретным разделам. Наш блок Directory – пример второго случая: его настройки касаются только указанного каталога и его подкаталогов (для которых они также могут быть изменены соответствующим блоком Directory). Здесь мы видим две опции: Indexes предписывает Apache генерировать HTML-список содержимого каталога (индекс), если по указанному URL не обнаружен файл index.html. Без этого параметра, при попытке входа в каталог без индексного файла будет возвращено сообщение об ошибке.
Опция FollowSymLinks понятна по названию («следовать по символьным ссылкам») – это предписание Apache переходить по ссылкам в DocumentRoot. Строки Options аддитивны: например, если для коренного каталога сайта установлено Options Indexes, а для его подкаталога – Options FollowSymLinks, то для подкаталога действительны обе строки. Если, например, индексирование требуется сугубо в родительском каталоге, то для подкаталога следует использовать Options -Indexes.
Параметр AllowOverride управляет использованием файлов .htaccess (еще один шаг по иерархии). Конфигурацию какого-либо каталога можно поправить, поместив нужные директивы в расположенный в нем файл .htaccess. И хотя это дает больше гибкости в администрировании сайта, лучше избегать применения такого подхода, если есть возможность редактировать файлы в /etc/apache2. И дело даже не в снижении уровня безопасности: если AllowOverride активирован, то при загрузке каждой страницы Apache проверяет файл .htaccess в каталоге запрашиваемой страницы, а также в вышестоящих каталогах вплоть до DocumentRoot, что значительно снижает производительность. Две последних строки относятся к управлению доступом – подробнее об этом после.
Письмо админу
Своей настройкой мы «научили» Apache обслуживать статические HTML-файлы из уместно названного каталога, поэтому скопируйте туда контент и посмотрите, как все это действует. Обычно Apache работает под пользователем apache:apache. Может понадобиться проверка прав доступа пользователей и групп; позаботьтесь, чтобы пользователь apache имел право на чтение ваших файлов. Настроек для файлов у Apache уйма, но сейчас достаточно будет проверить всего пару.
ServerAdmin – адрес электронной почты администратора сервера. Он включается в некоторые части генерируемого сервером контента, например, в сообщения об ошибках. Если указанный вами URL ссылается не на страницу, а на каталог, например, www.linuxformat.ru [в данном случае полностью отформатированный URL имеет вид http://www.linuxformat.ru/, в качестве конечного элемента присутствует / – корневой каталог web-сайта, – прим.ред.], то Apache будет разыскивать там индексный файл (обычно index.html). Инструкция DirectoryIndex задает имя индексного файла. Если он не один, то Apache ищет в каталоге все варианты по очереди.
DirectoryIndex index.php index.html index.htm
сначала поищет index.php, затем остальные и воспользуется первым обнаруженным. Если ничего найти не удастся, будет проиндексирован каталог или возвращена ошибка, в зависимости от настройки Indexes.
Глоссарий
- Daemon (демон) Программа, работающая в фоновом режиме в ожидании подключений. Обычно это серверы, имеющие название с окончанием на ‘d’, например sshd или ftpd. Прежние версии Apache прикидывались httpd, но теперь своего имени не прячут.
- Inetd Особый демон, иногда называемый «супердемоном»; он прослушивает все подключения подряд, а затем раздает их соответствующим программам. Некоторые серверы могут ожидать вызова от inetd или его «наследника» xinetd, вместо того чтобы постоянно работать в фоне и ждать подключения. Apache не таков.
- Directive (инструкция, директива) Так в документации Apache (а ее нам придется перечесть немало) называется элемент настройки в любом файле конфигурации.
Часть 2 Стой, кто идет!?
Если вы намерены запускать на одном компьютере несколько серверов, используйте директиву Listen для прослушивания ими разных портов, и соответствующим образом настройте маршрутизатор.
Управлять доступом к своему серверу можно разными способами. Инструкция Listen указывает серверу IP-адрес и порт для прослушивания. Стандартным портом считается 80 на всех локальных IP, но это можно легко изменить.
Listen 8080
Если у вас две сетевые карты (одна подключена к Интернету, а другая – к локальной сети), то инструкцией Listen можно предписать Apache отвечать только на запросы LAN-интерфейса:
Listen 192.168.0.3
или комбинации интерфейса и порта:
Listen 192.168.0.3:8080
Доступом управляет и инструкция Allow. Выше мы уже видели Allow from all («Принимать ото всех»), что пояснений не требует. А можно и так:
Allow from 192.168.1 Allow from example.com
и пройдут только 192.168.1.* и *.example.com. Инструкций Allow может быть несколько, а доступ получат подключения, которые соответствуют хотя бы одной из них. Инструкция Deny работает точно так же, но блокирует доступ; а инструкция Order устанавливает порядок их взаимодействия:
Order allow,deny Order deny, allow
В первом случае сначала обрабатываются Allow и запрос отклоняется, если нет ни одного совпадения; затем обрабатываются Deny и запрос отклоняется, если есть хотя бы одно совпадение. Любой запрос, не соответствующий ни Allow', ни Deny, отклоняется, и чтобы быть принятым, он должен соответствовать как минимум одному Allow и ни одному Deny. Во втором случае Deny обрабатываются первыми и отклоняют любые совпадения, если только они затем не соответствуют Allow. В противоположность первому методу, запрос, не соответствующий ни Deny, ни Allow, принимается.
Волшебные слова
Доступом к Apache можно управлять и с помощью паролей – настраивается это добавлением в файл конфигурации следующих строк:
AuthType basic AuthName “Registered users only” AuthUserFile /var/www/hostname/.htpasswd Require valid-user
Первая строка устанавливает тип авторизации; вторая – текст, который видит пользователь при попытке войти на сайт. AuthUserFile – это полный путь к файлу паролей (заметьте, он находится вне DocumentRoot), и, наконец, Require предписывает Apache не открывать доступ до тех пор, пока пользователь не авторизуется. Инструкция также может содержать перечень имен пользователей или групп.
Require user alice bob Require group admin
Эти пользователи и группы определяются в файле AuthUserFile, и чтобы исключить его загрузку посторонними, он должен располагаться вне DocumentRoot. Одна из причин, по которой мы использовали /var/www/hostname/htdocs как DocumentRoot – в этом случае мы можем поместить файл паролей уровнем выше, и он останется «привязанным» к определенному хосту. Создайте файл и добавьте пользователя, вот так:
htpasswd -c /var/www/hostname/.htpasswd alice
а остальных пользователей добавляйте без ключа -c. Таким образом создастся новый файл паролей, перезаписывающий любой существовавший до этого с таким же именем. При каждом вызове htpasswd у вас будут спрашивать пароль для указанного пользователя, совсем как с системной командой passwd.
Контроль доступа
А нельзя ли скомбинировать методы контроля доступа? Например, на сайте локальной сети есть страницы, к которым нужно обеспечить доступ извне, но не всем. Инструкция Satisfy позволит объединить оба метода управления доступом.
AuthType basic AuthName “Registered users only” AuthUserFile /var/www/hostname/.htpasswd Require valid-user Allow from 192.168.1 Satisfy Any
Это означает, что достаточно совпадения любого из критериев, Allow или Require. Для локальных пользователей вход свободный, но при подключении извне офиса им придется авторизоваться. Satisfy All требует соответствия всем критериям, то есть вход будет разрешен только подтвердившему свою личность пользователю локальной сети.
Доступ root
Для установки и настройки сервера обычно необходим доступ в режиме суперпользователя. Инструмент администрирования вашего дистрибутива при необходимости спросит ваш пароль, но, редактируя файлы конфигурации, вам придётся подумать об этом самому. Запускайте любимый редактор в терминале root, или используйте для этого команду sudo. Например:
sudo gedit /etc/apache2/httpd.conf
Эта команда сработает на Ubuntu и других дистрибутивах, использующих sudo. В некоторых системах нужно ввести su и пароль суперпользователя. Помните, что, работая в таком режиме, вы способны изменить важные системные файлы, поэтому будьте предельно осторожны! Узнать о том, что вы вошли как root, можно по смене системного приглашения с ‘$’ на ‘#’
Часть 3 Виртуальные хосты
Запрашивая web-страницу с сервера, браузер представляет ему, среди прочего, имя хоста, использовавшееся, чтобы «добраться» до данного сервера. Apache пользуется этим обстоятельством для создания виртуальных хостов, где сайты обслуживаются в зависимости от присланного URL. Это может принести немало пользы. Предположим, вы хотите установить на сервер клиент web-почты, чтобы просматривать свои сообщения вдали от дома, но вам нужен и сайт на этом сервере. Если ваше доменное имя – example.com, и www.example.com и mail.example.com указывают на один и тот же IP-адрес, можете сделать на вашем сайте все, что хотите, как пояснялось выше, затем создайте еще один каталог в /var/www/mail.example.com/htdocs и поместите файлы сервера web-почты туда. Чтобы велеть Apache использовать этот каталог для mail.example.com, достаточно добавить в файл конфигурации всего несколько строк. Впишите следующие директивы в отдельный файл – webmail.conf, например – и поместите его в каталог виртуальных хостов (vhosts.d в OpenSUSE или sites-available в Ubuntu):
<VirtualHost mail.example.com:80> DocumentRoot /var/www/mail.example.com/htdocs <Directory “/var/www/mail.example.com/htdocs”> Options -Indexes Order allow,deny Allow from all </Directory> </VirtualHost>
Повторите все это для каждого создаваемого виртуального хоста, затем укажите Apache на них, поместив
NameVirtualHost *:80
в основной конфигурационный файл. Теперь перезапустите Apache, чтобы вынудить его перечитать настройки, и зайдите на mail.example.com через браузер. Если у вас еще нет доменного имени, не беспокойтесь: в целях тестирования можно самостоятельно придумать домен и поместить его в /etc/hosts. Собственно говоря, вам даже придется это сделать, если для доступа в Интернет используется маршрутизатор, так как запрос к mail.example.com вызовет DNS-поиск, возвращающий внешний IP-адрес при попытке получить локальный адрес компьютера, поэтому поместите такую строку:
192.168.1.1 www.example.com mail.example.com
в /etc/hosts, и запрос на любое из этих имен вернет 192.168.1.1, но Apache, работающий на данном сервере, вернет разные сайты для каждого домена. Кстати о маршрутизаторах: если у вас NAT-маршрутизатор (а это так, если у вас типичный широкополосной интернет-доступ), то необходимо прописать ему перенаправление всех запросов на порт 80 на компьютер с Apache.
Регистрация домена
Чтобы иметь доступ к своему web-сайту извне, вам понадобится доменное имя и, желательно, статический IP-адрес. О последнем должен позаботиться ваш провайдер (может быть, небесплатно). Затем обратитесь в одну из хостинговых компаний. Рекламы здесь хватает, но можно просто поискать службы регистрации в Сети и зарегистрировать доменное имя с их помощью. Сделав это, укажите им свой IP-адрес. Убедитесь, что зарегистрировавшая вас компания действительно создала DNS-запись для вашего домена и IP-адреса. Некоторые ловкачи используют HTTP- и даже HTML-трюки, чтобы передавать ваш контент браузерам при том, что ваше доменное имя указывает на их сервер. Обычно услуга регистрации доменного имени в зоне .ru стоит несколько сотен рублей в год.
Если у вас нет статического IP-адреса, можно получить доменное имя на сайте динамического DNS-хостинга, например, dyndns.org. Ваше доменное имя будет поддоменом одного из предлагаемых службой домена, и при каждом подключении вы будете запускать специальную программу, передающую ваш текущий IP-адрес на их сервер. Некоторые модемы/маршрутизаторы оснащаются функцией работы с такими службами и автоматически обновляют данные при смене вашего IP-адреса. Для профессионалов такой способ, конечно, не годится, но для домашнего употребления вполне сойдет.
Что дальше?
Наладив работающий сервер, сделайте резервную копию каталога конфигурации. Вдруг вы забудете или потеряете что-то: нетрудно будет восстановить.
Если Apache удалось настроить и запустить, с ним можно сделать все что угодно. Некоторые программы имеют web-интерфейсы, и этим можно воспользоваться: установите MythWeb и записывайте телепередачи MythTV откуда хотите через интернет-подключение. А можно использовать PhpMyAdmin как графический интерфейс администрирования баз данных MySQL. Gallery превратит ваш сервер в полноценный сайт фотогалерей. Можно испытать работу с wiki, блогом или CMS, прежде чем раскрыть все это великому и ужасному Интернету. Многие из этих программ используют PHP, работающий на сервере, поэтому может понадобиться установка некоторых дополнительных пакетов вроде Apache-php, в зависимости от вашего дистрибутива. LXF
