Linux Gazette на русском

Здравствуйте!

Сегодня вашему вниманию предлагается небольшая заметка, посвященная настройке минималистского веб-сервера для "домашних" нужд. Такие рекомендации не кажутся лишними, исходя из двух обстоятельств:

Во-первых, мне нравятся статьи, подчеркивающие доступность для "конечного пользователя" всех параметров его компьютера, даже если это наполовину игра, а не продиктовано практическим интересом. Такая гибкость -- преимущество Linux и его стоит всячески подчеркивать:)

Во-вторых, в дистрибутивах по умолчанию часто все ставится "по максимуму" и с уклоном в сторону "рабочих серверов". Но для личных нужд Linux часто ставиться не на самые мощные машины. И в этом случае возможность перейти с относительно тяжелых решений на "облегченные" кажется оправданной. Linux Gazette уже писала, например, о замене кэширующего сервера DNS named на более легкий PDNSD (http://gazette.linux.ru.net/lg65/articles/rus-sunil.html). А в этой статье описывается, как можно заменить Apache более легким сервером, если нет необходимости во всей мощи последнего.

Но хватит болтать, я обещал сделать "работу над ошибками". В статье про "сетевых котов" я допустил ошибку, в исходном коде было:

Launch hub in the console A: ConA % ./hub 10240 10000 2
From console B, connect a netcat: ConB % nc localhost 10000
From console C, connect another netcat: ConC % nc localhost 10000
Then you could type in ConC and read the output in ConB, vice versa.

А у меня:

Запустите hub в консоли. Вот так: ConA % ./hub 10240 10000 2
Из консоли B подсоединитесь netcat'ом: ConB % nc localhost 10000
Из консоли C подключите еще один netcat: ConC % nc localhost 10240
Можете печатать текст в ConC, а читать в ConB и наоборот.

На что и обратил внимание Павел Цибулин (надеюсь, не переврал фамилию, в письме она была в транслите):

Обратите внимание на аргументы у вызовов nc
Хотя лично я бы попробовал из ConB цепляться к порту 10001

Исправляюсь. Кроме того, Павел написал:

Хотя по поводу статьи, как оригинала, как так и перевода есть некоторые мысли(шки):
1) Может быть Вы помните, но в дни моего далекого детства :-) был такой
журнальчик "Юный техник", в котором статьи из цикла "делай с нами, делай..."
просто изобиловали ошибками. Но эти ошибки не были по сути фатальными, как и в
Вашем переводе.

Но, если у человека было некоторое терпение и он доходил до сути сам,
докапываясь "почему не работает, как написано", то его познания в этой области
были все-таки значительно больше, чем у того, кто просто бездумно втыкнул, как
есть - и вдруг оно все само собой заработало, как в MS XP :-)).

Я не призываю делать насильственные ошибки, но может таки оно так и
лучше, с учетом "отечественного менталитета"?

2) Лично я бы слегка переделал программу hub. Опять-же, это мое личное
мнение:

а) Вместо того, чтобы принимать n соединений по одному порту, я бы
принимал по одному соединению на n последовательных портах, что IMHO
более соответствует реальному хабу и более наглядно для применения cable,
в какие дырки хаба он втыкается.

Т.е. ./hub 10240 10000 3 слушал бы на трех портах, причем гнездо A
соответствовало бы порту 10000, B - 10001, C - 10002
Иначе втыкать два конца кабеля в один порт 10000 - как-то странно...

б) Приделал бы примитивную ASCII-мордочку, отображающую состояние хаба,
какие в нем "дырочки" есть, в какие кабель воткнут и по каким идет реальная
передача данных.

Мне это кажется разумным (не про желательность ошибок, конечно:). Хотя я и не ожидал, что кто-то непременно попробует внимательно прочесть заметку, собрать программу и даже предложить ее улучшение:)

И еще, другой читатель пожаловался, что у него примеры не собирались:( Я даже попросил прислать неработающий код мне -- все напрасно:( У меня собирается, у него -- нет. Ну, правда мы не слишком рогом уприрались. Так что не все так просто, как может показаться:)

Сергей Скороходов suralis-s@mtu-net.ru

Миниатюрный веб-сервер:
экономим циклы процессора и место на диске
 
Автор: (C) Маттиас Арндт [Matthias Arndt]
Перевод: (C) Сергей Скороходов

Введение

Личный веб-сервер. Сегодня такой есть почти у каждого пользователя Linux. Кто-то с его помощью и в самом деле предоставляет доступ к информации в сети. Или занимается разработкой программ на PHP или CGI. А кому-то, как, например, мне, сервер требуется лишь для того, чтобы читать в браузере программную документацию, да время от времени "играть в веб-мастера". Я решил, что Apache -- слишком сильно для моих скромных личных потребностей. Сейчас у меня есть доступ к провайдеру с CGI и PHP, так что дома мне эти возможности не нужны. Мне нужен простой доступ к статическим веб-страницам и файлам и нет смысла "гонять в бэкграунде" здоровенного 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 и распакуйте их.

1. tar xvzf micro_http.tar.gz
2. cd micro_httpd
3. если нужно, подкорректируйте исходный код, например, подгоните "по себе" #define'ы
4. make
5. su -c "make install"

Стукнувшись о земь обернитесь root'ом (su - плюс пароль:) и отредактируйте /etc/initd.conf в своем любимом редакторе. Добавьте в него строку

http  stream  tcp  nowait  wwwrun  /usr/sbin/tcpd  /usr/local/sbin/micro_httpd /var/httpd/wwwroot/

На моем SuSE 7.2 я набираю 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)

Подведем итоги: любой веб-сервер, который можно запускать из inetd, настраивается схожим образом. Поищите такие серверы на Freshmeat.

Заключение

Если ваши потребности не выходят за рамки описанных выше, то замена Apach'а на "минималистский" вариант займет всего несколько минут.

Все нормально работает, но конструкция, очевидно, не выдержит слишком большого числа запросов. Впрочем, для простого личного веб-сервера с небольшим траффиком ее должно хватить.

По крайней мере, я стал немножко счастливие. Решайтесь, можт быть, это сможет решить и часть ваших проблем?

[Есть еще Tux, миниатюрный веб-сервер в виде модуля ядра Linux. Он работает похожим на micro_httpd образом и даже может перенаправлять запросы, с которыми не может справится самостоятельно (например, обработку скриптов CGI) на более "серьезный" веб-сервер. Однако, micro_httpd и Tux занимают разные ниши. Tux предназначен для загруженных веб-сайтов, предоставляющих доступ к большому числу простых файлов (например, с картинками), в этом случае, чтобы избежать перегрузки системы, требуется сделать расход ресурсов на каждый запрос минимальным. А micro_httpd, работающий через inetd, предназначен для сайтов с небольшой нагрузкой, где потребность в дополнительных ресурсов, требующиеся для выполнения каждого запроса в своем процессе, перекрываются тем обстоятельством, что при отсутствии запросов ресурсов не требуется вовсе. И micro httpd, и Tux, конечно, вместе занимают еще одну нишу: а именно нишу маленьких симпатичных утилит, поиграть с которыми -- одно удовольствие. Или, как говорит редактор LG "с правом написания" [contributing editor] Дан Вайлдер [Dan Wilder]: "маленькие инструменты, хорошо заточенные под одну задачу, в лучших традициях инструментария UNIX".

Если хотите больше узнать про Tux, то смотрите Руководство по Tux 2.1 от Red Hat. Я думал, что Tux входит в стандартное ядро, но в 2.4.17 я его не нашел, так что вам придется искать его где-нибудь еще. -Iron]

Матиас Арндт [Matthias Arndt]

Я энтузиаст Linux из северной Германии. Мне нравится простой rock'n'roll пятедесятых годов, люблю писать истории и, естественно, публиковать их в Linux Gazette. В настоящее время изучаю информатику [computer cience] в применении к экономике.

Copyright (C) 2002, Matthias Arndt.
Copying license http://www.linuxgazette.com/copying.html
Published in Issue 74 of Linux Gazette, January 2002

Команда переводчиков:

Владимир Меренков, Александр Михайлов, Иван Песин, Сергей Скороходов, Александр Саввин, Роман Шумихин

Со всеми предложениями, идеями и комментариями обращайтесь к Сергею Скороходову (suralis-s@mtu-net.ru)

Сайт рассылки: http://gazette.linux.ru.net
Эту статью можно найти на: http://gazette.linux.ru.net/lg74/articles/rus-arndt.html