The WebDevil » lighttpd

PowerDNS URL records and redirector

dm — Fri, 25 Jul 2008 19:43:21 +0000

В PowerDNS есть пара плюшек, которые я раньше не замечал. Одну из них – записи “URL” я сегодня попробовал, настроил и остался вполне доволен.

Что же такое URL-запись? Это фича PowerDNS, при помощи которой можно делать редирект домена на заданный URL.
Например, запись выглядит как

some.domain.com URL http://other.domain.com/some_domain_com

На самом деле в поле со значением записи может быть ссылка куда угодно.
В конфиге сервера нужно указать

...
fancy-records=yes
urlredirector=77.120.99.180
...

Когда приходит запрос к DNS’у для домена some.domain.com отдается 77.120.99.180, указанный в конфиге, как если бы это была обычная “А”-запись.
Браузер отрезолвив имя идет на http://some.domain.com. На этом адресе висит http-сервер (я повесил lighttpd), у которого скрипт лезет в БД и для указанного домена ищет соответствующую ему URL-запись и редиректит браузер туда. Все просто и тривиально.

Для lighttpd у меня конфиг дополнился такими строками:

$SERVER["socket"] == "77.120.99.180:80" {
$HTTP["host"] =~ "(.*)" {
magnet.attract-raw-url-to = ("/var/www/lighttpd/pdns-url-redirector.lua")
}
}

То есть все что приходит незамедлительно обрабатывается упомянутым lua-скриптом. Почему lua? С ним работает mod_magnet, и мне было интересно написать этот скриптик. Вот он:

require "luasql.mysql"
env = assert (luasql.mysql())
con = assert (env:connect("dnsdb", "dns_user", "dns_pass_for_readonly_records_table", "localhost"))
domain = lighty.request["Host"]

mysql_replacements = {
["\0"] = "\\0",
["\n"] = "\\n",
["\r"] = "\\r",
["\'"] = "\\'",
["\""] = "\\\"",
["\026"] = "\\Z",
["\b"] = "\\b",
["\t"] = "\\t",
}

function fixsql (s)
return (string.gsub (tostring (s), "[%z\n\r\'\"\026\b\t]",
function (str)
return mysql_replacements [str] or str
end ))
end -- fixsql

cur = assert (con:execute( string.format("SELECT content FROM records WHERE `type` = 'URL' AND `name` = '%s'", fixsql(domain) ) ) )
result = cur:fetch()
if result then
redirect_to = string.format("%s", result)
else
redirect_to = "http://daemons.org.ua/"
end

cur:close()
con:close()
env:close()

--lighty.content = { string.format("SELECT content FROM records WHERE `type` = 'URL' AND `name` = '%s'", fixsql(domain) ) }
--lighty.header["Content-Type"] = "text/plain"
--return 200

lighty.header["Location"] = redirect_to
return 301

Комментарий начинается с “–”. Закоментарены строки для отладки скрипта.
Для соединения с мускулем из lua доставил пакет liblua5.1-sql-mysql-2.

Скрипт писал долго, но это было интересно. И небесполезно =)

UPD: во избежание DoS/DDoS атаки на мускуль возможны два варианта апгрейда метода:
1. По крону раз в 5 минут генерить sqlite-БД состоящую из одной таблицы из двух полей – domain, target
2. Раз в 5 минут генерить сам скрипт с вынесенными в него в виде хеша записями. Тогда скрипт вообще никуда подглядывать не будет.

Lighttpd and execwrap

dm — Thu, 24 Jul 2008 18:32:09 +0000

В качестве вэб-сервера я использую lighttpd. И сегодня я наткнулся на старую проблему – вэб-сервер работает из-под пользователя www-data, и когда пользователь pupkin загружает какой-то файл – этот файл принадлежит не pupkin’у, а www-data. И через ftp удалить его он не может, и вынужден искать некие web-file-manager’ы.

Так вот я погуглил и наткнулся на execwrap. Он очень мелкий, почти ничего ему не нужно стороннего для работы, конфигурировать и использовать его крайне просто (да-да, я знаю про suExec, но он мне не сильно понравился).

В результате конфиг для сайта у меня выглядит так:

$HTTP["host"] == "pupkin.com" {
server.name = "pupkin.com"
site-root = "/home/pupkin/www/" + server.name
server.document-root = site-root + "/www"
accesslog.filename = site-root + "/log/access.log"
setenv.add-environment = ( "AWSTATS_FORCE_CONFIG" => server.name )
auth.backend.htpasswd.userfile = site-root + "/awstats.passwd"

fastcgi.server = ( ".php" => ((
"bin-path" => "/var/www/lighttpd/execwrap",
"socket" => "/tmp/" + server.name + ".phpsocket",
"max-procs" => 10,
"bin-environment" => (
"UID" => "9999",
"GID" => "9999",
"TARGET" => site-root + "/cgi-bin/php",
"CHECK_GID" => "1",
"CGI_BIN_DIR" => site-root + "/cgi-bin/",
"PHP_FCGI_CHILDREN" => "2",
"PHP_FCGI_MAX_REQUESTS" => "5000"
)
)))
}

где 9999 – ID пользователя и группы (у меня они часто совпадают).

А в директории /home/pupkin/www/pupkin.com/cgi-bin лежит два файла – симлинк на php.ini и исполняемый файлик “php” следующего содержания:

#!/bin/bash

cd $CGI_BIN_DIR
exec /usr/bin/php-cgi -c ./php.ini

Как видите, если надо то конфиг php.ini можно пользователю задать персональный. А файлик php обязательно должен принадлежать этому же пользователю.

Когда все сделано – рестартуем lighttpd и смотрим, нет ли в логах ругательств с кодом ошибки 22 – это, как видно из сорса execwrap, несоответствие прав.

Enjoy =)

UPD: execwrap умер и воскрес тут: http://cgit.stbuehler.de/gitosis/execwrap/

Webservers benchmark

dm — Sun, 03 Feb 2008 05:08:54 +0000

Решил потестировать PHP в разных связках, а именно – Apache + mod_php, Apache + mod_fcgid + php, Lighttpd + mod_fastcgi + php. Все это еще в двух вариантах – с APC (Advanced PHP Cache) и без него.

Тестировал выполнением вот такой команды:

ab -c 5 -n 500 http://dmitry.shaposhnik.name/

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

И вот что получилось в результате:

Вот полный вывод в текстовом виде:
testing results

UPD: вот на том же сервере решил протестировать приложение-блогодвижек (Записки айтишника) на рельсах той же командой.

Document Length: 13176 bytes

Concurrency Level: 5
Time taken for tests: 15.141659 seconds
Complete requests: 500
Failed requests: 0
Write errors: 0
Total transferred: 6743500 bytes
HTML transferred: 6588000 bytes
Requests per second: 33.02 [#/sec] (mean)
Time per request: 151.417 [ms] (mean)
Time per request: 30.283 [ms] (mean, across all concurrent requests)
Transfer rate: 434.89 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 1
Processing: 6 100 1126.2 7 15141
Waiting: 4 98 1126.1 5 15139
Total: 6 100 1126.2 7 15141

Percentage of the requests served within a certain time (ms)
50% 7
66% 8
75% 9
80% 10
90% 11
95% 13
98% 110
99% 211
100% 15141 (longest request)

UPD: по коментариям Вадима сделал более жесткий тест:

ab -c300 -n3000 http://dmitry.shaposhnik.name/test.php

testing results, heavy testing
Без APC mod_fcgid отлетает (2 запроса). Подскажите как подтюнинговать.

Lighttpd and speed limits

dm — Sat, 26 Jan 2008 16:45:10 +0000

Надо сделать ограничения по скорости отдачи файлов. Да и в принципе саму отдачу.
Дело было под Debian etch.

Для того, чтобы отдать файл средствами php, например, надо сделать

header("Content-type: application/octet-stream");
header("Content-Disposition: attachment; filename=\"bigbinary.bin\"\n");
readfile("/var/www/lighttpd/bigbinary.bin");
?>

А теперь отдайте так файл 100 пользователям. Даже lighttpd+php(fastcgi) просядет. Из-за PHP.
Но если работа lighttpd – отдавать статические файлы, то почему же ее не переложить на него? Однако, не хочется давать прямую ссылку.
Именно для этого есть специальный заголовок: X-Sendfile

header("Content-type: application/octet-stream");
header("Content-Disposition: attachment; filename=\"bigbinary.bin\"\n");
header("X-Sendfile: /var/www/lighttpd/bigbinary.bin");
?>

В конфиге надо включить для 1.4 для fastcgi (в описании fastcgi-сервера):

allow-x-sendfile = "enable"

А для 1.5 fastcgi уже реализован через mod_proxy_core, соответственно

proxy-core.allow-x-sendfile = "enable"

Проверьте отдачу. Разница налицо.

Далее, стоял вопрос в контроле скорости отдачи.
Если правила для всего сервера одинаковы, то можно прописать в конфиге

connection.kbytes-per-second = 1000

или суммарную для всего сервера:

server.kbytes-per-second = 1000

Но если надо из скрипта управлять скоростью?
Делается вот таким образом:

header("Content-type: application/octet-stream");
header("X-LIGHTTPD-KBytes-per-second: 100");
header("Content-Disposition: attachment; filename=\"bigbinary.bin\"\n");
header("X-Sendfile: /var/www/lighttpd/bigbinary.bin");
?>

Однако ограничение скорости не работает. Во всем виноват mod_speed, точнее его отсутствие среди исходников.
Вот исходник модуля.
Итак, скачиваем его в папку src к остальным исходникам lighttpd, в src/Makefile.am добавляем:

lib_LTLIBRARIES += mod_speed.la
mod_speed_la_SOURCES = mod_speed.c
mod_speed_la_LDFLAGS = -module -export-dynamic -avoid-version -no-undefined
mod_speed_la_LIBADD = $(common_libadd)

Желательно это сделать до выполнения autogen.sh. Или же запустить

./configure --enable-maintainer-mode

и потом в конфиге дописать в загрузке модулей mod_speed.

ПРИМЕЧАНИЯ
В 1.5 появилась возможность обработки X-Sendfile из бэкэнда у proxy_core. В версии 1.4 эта возможность была в модуле mod_fastcgi и от бэкэнда-апача, например, заголовок такой поймать было нельзя.

В версии 1.5 есть возможность выбирать backend для отдачи файлов. Посмотреть на сравнение можно тут. А установить нужный можно так:

server.network-backend = "gthread-aio"

Также у меня возникал вопрос, а как можно сделать простую обработку входящих параметров на некоем встроенном языке? Для примера, у nginx есть встроенный perl-овый модуль, при помощи которого можно реализовать мини-логику прямо на вэб-сервере. В lighttpd такая возможность нашлась – mod_magnet и в качестве обработчика скрипт на LUA. Ну что ж, будет повод освоить LUA.

lighttpd and rails

dm — Sat, 05 Jan 2008 02:33:27 +0000

Сделал небольшую пачку оберток на сервере для управления приложениями.

Для начала воспользовался кластером mongrel:

gem install mongrel_cluster

и создал юзеря, от которого все монгрели будут выполняться:

adduser --system --no-create-home --shell /bin/false --group mongrel

Правда, мне понадобилось сделать vipw и vigr, чтобы подправить ID пользователя и группы – чтоб они совпадали.

Теперь, в папке с приложением сделал

mongrel_rails cluster::configure -e production -p 3000 -N 5 -c ./ -a 127.0.0.1 --user mongrel --group mongrel

и получил в результате в config/mongrel_cluster.yml конфиг для кластера монгрелей. Вот такого вида:

---
user: mongrel
cwd: /var/www/lighttpd/www.example.com
log_file: log/mongrel.log
port: "8000"
environment: production
group: mongrel
address: 127.0.0.1
pid_file: tmp/pids/mongrel.pid
servers: 5

Запускается оно через mongrel_rails cluster::start.
Но надо же что-то сделать, чтоб оно загружалось при старте системы. И вот что я нашел и сделал.

mkdir /etc/mongrel_cluster/
mkdir /etc/mongrel_cluster/available
mkdir /etc/mongrel_cluster/enabled
mv /var/www/lighttpd/www.example.com/config/mongrel_cluster.yml /etc/mongrel_cluster/available/www.example.com.yml
ln -s /etc/mongrel_cluster/available/www.example.com.yml /etc/mongrel_cluster/enabled/www.example.com.yml

Теперь создадим скрипт /etc/init.d/mongrel_cluster:

#!/bin/bash

set -e

mongrel_cluster_ctl -v -c /etc/mongrel_cluster/enabled $@

и выполняем

chmod +x /etc/init.d/mongrel_cluster
update-rc.d -f mongrel_cluster defaults

Также для удобства запуска-остановки отдельного приложения я сделал мелкий скрипт /etc/mongrel_cluster/operation.sh:

#!/bin/bash

set -e

CONFIGS=/etc/mongrel_cluster/enabled

mongrel_rails cluster::$1 -C $CONFIGS/$2.yml

Поьзоваться им можно так: /etc/mongrel_cluster/operation.sh start www.example.com
Собственно, на этом с монгрелем все.
Далее – lighttpd. Почему не nginx? Я не нашел никаких доводов за или против. В конце-концов, оба они работают как reverse-proxy к монгрелю, и несложно сменить демон – никаких переработок приложения не потребуется.

Итак, вот конфиг lighttpd:

server.modules = ( "mod_access", "mod_accesslog", "mod_compress", "mod_rewrite", "mod_proxy", "mod_redirect" )
server.document-root = "/var/www/lighttpd/default/"
server.errorlog = "/var/log/lighttpd/error.log"
server.port = 80
server.bind = "77.120.99.179"
server.pid-file = "/var/run/lighttpd.pid"
server.username = "www-data"
server.groupname = "www-data"
server.tag = "lighttpd"

index-file.names = ( "index.php", "index.html", "index.htm" )
url.access-deny = ( "~", ".inc" )
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )

accesslog.filename = "/var/log/lighttpd/access.log"

compress.cache-dir = "/var/cache/lighttpd/compress/"
compress.filetype = ("text/plain", "text/html", "application/x-javascript", "text/css", "text/xml" )

include_shell "/usr/share/lighttpd/create-mime.assign.pl"
include_shell "/usr/share/lighttpd/include-conf-enabled.pl"

var.basedir = "/var/www/lighttpd/"

#### SITES ####
$HTTP["host"] == "example.com" {
url.redirect = ("^/(.*)$" => "http://www.example.com/$1")
}
$HTTP["host"] == "www.example.com" {
server.name = "www.example.com"
server.document-root = basedir + server.name + "/public"
accesslog.filename = basedir + server.name + "/log/access.log"

$HTTP["url"] !~ "^/(stylesheets|javascripts|images|files)/" {
proxy.balance = "fair"
proxy.server = (
"/" => (
( "host" => "127.0.0.1", "port" => 8000 ),
( "host" => "127.0.0.1", "port" => 8001 ),
( "host" => "127.0.0.1", "port" => 8002 ),
( "host" => "127.0.0.1", "port" => 8003 ),
( "host" => "127.0.0.1", "port" => 8004 )
)
)
}
}

Я обеспечил прямой доступ к статике посредством lighttpd, не заворачивая статику через mongrel (везде я встречал заворачивание всего на монгрели, что, ИМХО, не есть хорошо).
Весьма настоятельно рекомендую в приложении создать файлик log/access.log и обеспечить в него запись пользователю www-data, от которого работает lighttpd.

Собственно, все. Ругайте.

UPD: в процессе работы проявились особенности Safari & IE. Для них надо в конфиге lighttpd добавить

$HTTP["useragent"] =~ "^(.*MSIE.*)|(.*AppleWebKit.*)$" {
server.max-keep-alive-requests = 0
}