Личный веб-сервер. Сегодня такой есть почти у каждого пользователя Linux.
Кто-то с его помощью и в самом деле предоставляет доступ к информации в сети.
Или занимается разработкой программ на PHP или CGI. А кому-то сервер требуется
лишь для того, чтобы читать в браузере программную документацию, да время от
времени "играть в веб-мастера". Если вы решили, что Apache - слишком
сильно для ваших скромных личных потребностей, то эта статья для вас. Нам нужен
простой доступ к статическим веб-страницам и файлам и нет смысла "гонять
в бэкграунде" здоровенного Apach'а.
Результатом этих рассуждений стало прекращение эксплуатации собственного
веб-сервера Apache с его заменой на микро-сервер, запускаемый только тогда,
когда поступают запросы. Это экономит определенный объем оперативной памяти
и дискового пространства. Новая программа, которая хотя и выглядит, как игрушка,
но тем не менее работает и исправно выполняет возложенные на нее задачи.
Что же нам
нужно от собственного веб-сервера? Две простые функции, не имеющих отношения
к PHP или CGI:
- обеспечение
доступа к небольшому числу статических страниц и предоставление друзьям возможности загружать файлы;
- чтение
документации к пакетам в броузере по протоколу http.
Есть важный момент: совершенно
необходимо, чтобы сервер хотя бы минимально поддерживал индексирование каталогов.
То есть, если URL завершается именем каталога, то необходимо перенаправление
в эту директорию (добавление завершающей косой черты) с последующей обработкой
находящегося там файла index.html. Такое перенаправление необходимо для правильной
работы относительных ссылок. Хотя индексирование можно выполнить с помощью скриптов,
автоматически запускаемых планировщиком (cronjobs), предпочтительнее все же
простые встроенные решения. А вот сами по себе превосходные дополнительные возможности
индексирования, имеющиеся в Apache, нам не нужны.
Итог: нам подойдет почти любой сервер, поддерживающий протокол http,
но без излишних наворотов.
Нужно ли нам богатство дополнительных настроек? Не нужно. Все проблемы
решаются с помощью символических ссылок на ресурсы за пределами корневой директории
сервера. Нет нужды в директиве "Alias" (псевдоним) или в других заковыристых
опциях. Только указание корневой папки. Ну, может быть, нужна возможность указать
порт, на котором сервер будет слушать.
Что выбрать: независимый сервер или сервер, "завернутый"
в сервис TCP? Остановимся на варианте с TCP wrapper'ом. Исполнимый файл сервера
вызывается только тогда, когда поступает запрос. Никакой возни со скриптами
инициализации. Несложная строка в /etc/inetd.conf'е -- и готово.
Производительность такой конфигурации, как говорится,
"не очень". На самом деле, если вы планируете нечто большое, чем такие
спонтанные обращения, то лучше запустить самостоятельный сервис http, работающий
постоянно.
micro_httpd. Оставив в стороне несколько воистину
корявых вариантов ("на сетевых просторах" можно найти веб-серверы,
написанные на Java, bash или awk), остановимся на компилируемой программе.
На http://www.acme.com/software/micro_httpd/
есть веб-сервер под названием micro_httpd. Примерно 150 строк на простом C,
делает в точности то, что нам нужно. Можно запускать через сервис TCP, никакого
CGI, никакого PHP, просто обслуживание запросов на передачу файлов и возможности
индексирования.
В исходный код можно добавить несколько дополнительных
mime-типов, и все заработает
прямо "из коробки".
Итак, для установки, получите
исходники micro_http и распакуйте их. Необходимая для установки последовательность
команд такова:
- tar xvzf micro_http.tar.gz
- cd micro_httpd
- если
нужно, подкорректируйте исходный код, например, подгоните "по себе"
все строки с #define
- make
- su -c "make install"
В /usr/local/sbin
появится двоичный файл micro_httpd. Теперь,
из-под root'a отредактируйте /etc/initd.conf в своем любимом редакторе. Добавьте
в него строку следующего вида:
http stream tcp nowait wwwrun /usr/sbin/tcpd /usr/local/sbin/micro_httpd /var/httpd/wwwroot/
и перезапустите
суперсервер Internet inetd. Например, такой командой из-под root'а: /etc/init.d/inetd
restart.
Проследите, чтобы "/var/httpd/wwwroot/ в примере выше был заменен
правильным путем к новой корневой директории документов веб.
А wwwrun замените именем любого реально существующего в вашей системе
пользователя, для пущей безопастности лучше выбрать "побесправнее".
Пришло время испытаний: поместите в новый "WWW-корень" несколько
html-файлов, доступных на чтение пользователю, под которым запускается сервер.
Нацельте свой любимый браузер на http://localhost/. Вы должны либо увидеть содержимое
файла index.html, либо автоматически создаваемый список файлов в каталоге. Так
и есть? Отлично, ваш маленький, даже микроскопический веб-сервер заработал!
Замечание: сервис TCP wrapper записывает журнал соединений в /var/log/messages.
Но не следует ожидать от него подробного отчета в стиле Apache. Там будут всего
лишь простые записи вида:
micro_httpd[886]: connect from x.x.x.x (x.x.x.x)
Но, опираясь
на знание протокола http и с учетом наличия исходного кода, вполне возможно
расширить возможности ведения журнала. Оставляем это в качестве самостоятельного
упражнения для пытливого читателя.
Подведем итоги: любой веб-сервер, который можно
запускать из inetd, настраивается схожим образом. Поищите такие серверы на Freshmeat.
Заключение. Если ваши потребности не выходят
за рамки описанных выше, то замена Apach'а на "минималистский" вариант
займет всего несколько минут.
Все нормально работает, но конструкция, очевидно,
не выдержит слишком большого числа запросов. Впрочем, для простого личного веб-сервера
с небольшим траффиком ее должно хватить.
Замечание. Есть еще Tux, миниатюрный веб-сервер в виде модуля ядра Linux. Он работает
похожим на micro_httpd образом и даже может перенаправлять запросы, с которыми
не может справится самостоятельно (например, обработку скриптов CGI) на более
"серьезный" веб-сервер. Однако, micro_httpd и Tux занимают разные
ниши. Tux предназначен для загруженных веб-сайтов, предоставляющих доступ к
большому числу простых файлов (например, с картинками), в этом случае, чтобы
избежать перегрузки системы, требуется сделать расход ресурсов на каждый запрос
минимальным. А micro_httpd, работающий через inetd, предназначен для сайтов
с небольшой нагрузкой, где потребность в дополнительных ресурсов, требующиеся
для выполнения каждого запроса в своем процессе, перекрываются тем обстоятельством,
что при отсутствии запросов ресурсов не требуется вовсе.
И micro httpd, и Tux, конечно, вместе занимают еще одну нишу: а именно нишу
маленьких симпатичных утилит, поиграть с которыми -- одно удовольствие. Или,
как говорит редактор LG Дан Вайлдер: "маленькие инструменты, хорошо заточенные
под одну задачу, в лучших традициях инструментария UNIX".
Если хотите больше
узнать про Tux, то смотрите Руководство
по Tux 2.1 от Red Hat.
Статья подготовлена
при помощи заметок Матиаса Арндта
