НА СЕГОДНЯШНИЙ ДЕНЬ СИТУАЦИЯ НА ХОСТИНГОВОМ РЫНКЕ РУНЕТА НАПОМИНАЕТ НОВОГОДНЮЮ ЯРМАРКУ: ОГРОМНЫЙ ВЫБОР ТАРИФНЫХ ПЛАНОВ, ШИРОКИЙ АССОРТИМЕНТ РАЗНООБРАЗНЫХ УСЛУГ. ЛОГИЧНО БУДЕТ ПРЕДПОЛОЖИТЬ, ЧТО ЭТО ОБЪЯСНЯЕТСЯ ДОСТУПНОСТЬЮ ТЕХНОЛОГИИ, ОДНАКО ЭТО НЕ СОВСЕМ ТАК. ДЕЛО В ТОМ, ЧТО СУЩЕСТВУЕТ МНОЖЕСТВО ГОТОВЫХ ХОСТИНГОВЫХ РЕШЕНИЙ, УСТАНОВИТЬ КОТОРЫЕ НЕ СОСТАВИТ ТРУДА – БЫЛИ БЫ ДЕНЬГИ. СЕЙЧАС МЫ ПОСТРОИМ СВОЙ ХОСТИНГ, - С САМОГО НАЧАЛА, И НЕ ПРИБЕГАЯ К ПЛАТНЫМ УСТАНОВОЧНЫМ ПАКЕТАМ ВРОДЕ CPANEL

[выбор ОС.]

На самом деле вариантов не так уж и много. Windows, Linux, BSD, Solaris. У каждой из этих операционок в плане реализации хостинга есть свои плюсы и минусы. Windows дает нам поддержку ASP и еще некоторых MS-only технологий и визуально несложное администрирование, но, в то же время, накладывает существенные ограничения на производительность и увеличивает наши затраты. Linux – достойная кандидатура, но обилие багов в ядре и наличие в паблике вполне рабочих эксплойтов стало уже закономерностью. Solaris – хорошая система, однако платная; встанет не на любое железо, да и с некоторым софтом возникают траблы. Остается BSD. Из BSD я лучше всего знаю FreeBSD, поэтому строить наш хостинг мы будем на примере этой ОС.

[нелегкий выбор.]

Теперь необходимо выбрать версию операционки. На сегодняшний день существует три основных ветки FreeBSD:

4.* - Old stable (Старая стабильная ветка). Последняя версия 4.11. По сути, она уже не поддерживается.

5.* - Legacy production (Старая production-ветка). Последняя (на момент написания статьи) версия 5.4. Стабильный, зарекомендовавший себя релиз.

6.* - Production (Production ветка). Разработчики неожиданно сделали прыжок с 5.4 до 6.0, по сути не внеся никаких революционных изменений. Changelog 6.0 довольно весомый, но на практике - кроме небольшого прироста производительности на SMP ядрах – в нашем случае ничего не дает.

Итог: 4.* - уже практически мертва, в 6.* ожидается много изменений, а значит и сюрпризов. Как приятных, так и не очень. Кроме того, релиз 6.0 вышел относительно недавно, и в нем еще могут обнаружиться серьезные недочеты. Поэтому мы остановим свой выбор на 5.4. Собирать хостинговый сервер мы будем на тестовой машине – P4 2.8 Ghz, 512 DDR, 5x200 gb SATA RAID 0+1. Разумеется, если ты планируешь поднять крупный хостинг – стоит подумать о более шустром железе.

[pre-install.]

Я не буду рассказывать о том, как установить систему - это довольно просто, да и документации по этому поводу в Сети хватает. Я остановлюсь лишь на вещах, которые критически важны для нашего хостинга. Очень важно правильно разбить диск. Swap partition должен находиться как можно ближе к началу диска (физически), поэтому его нужно создавать сразу после /. Размер свопа принято рассчитывать по формуле:

Swap = количество оперативки * 2 + 20-30 MB

Я разбил диск следующим образом:

/ - 512 Мб
Swap – 1124 Мб
/tmp – 512 Мб
/usr – 30 Гб
/var – 30 Гб
/usr/home – все остальное, в моем случае – примерно 130 Гб

При выборе установки обязательно поставь галочки у src, ports, linux, perl, compat4x.

[the beginning.]

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

# dmesg | more
# cat /var/log/messages

[make.]

Так как нам предстоит компилировать ядро и кучу разнообразного софта, то сначала необходимо оптимизировать процесс компиляции. Многие часто не придают этому значения, не зная, что таким образом мы не только выигрываем время при сборке, но и оптимизируем все под наше железо и ОС. Идем в /etc/make.conf и там пишем:

Листинг файла make.conf

# Тип твоего процессора.
# Для AMD - athlon-mp, athlon-xp, athlon-4, athlon-tbird, athlon, k6-3, k6-2, k6, k5.
# Для Intel - p4, p3, p2, i686, i586/mmx, i586, i486, i386.
CPUTYPE?=p4
CPUTYPE=p4
# Совместимость с BSD 4.X
COMPAT4X=true
# Указываем дополнительные флаги
CFLAGS=-O1 -pipe -march=pentium4 -mtune=pentium4
# Говорим, что флаги включать обязательно
NO_CPU_CFLAGS=false
NO_CPU_COPTFLAGS=false
# Отключаем сборку ненужных библиотек и софта
MAKE_KERBEROS4=false
MAKE_KERBEROS5=false
NO_BIND=true
NO_SENDMAIL=true
NO_GAMES=true
# Настройки Perl
PERL_VER=5.8.8
PERL_VERSION=5.8.8
PERL_ARCH=mach
NOPERL=no
WITH_PERL=yes
WITHOUT_PERL=no
# Решаем проблемы с портами
FORCE_PKG_REGISTER=yes

[update.]

В наш век разгула скрипткидисов и прочей нечисти крайне важно держать систему и софт обновленными. Исходники 5.4 обновляются очень редко, только в случае, если обнаружилась критическая уязвимость, а вот порты и документация - довольно часто. Сразу оговорюсь: в FreeBSD все надо ставить из портов. Это очень важно, поскольку в портах лежат уже адаптированные под нужную ось проги со всеми необходимыми патчами. Идем в /usr/ports/net/cvsup-without-gui и собираем порт:

# make install clean

После окончания процесса сборки нужно написать конфиг для cvsup. Идем в /etc, открываем там файл cvsupfile (я обычно переименовываю в cvsup.conf).

# Сервер, с которым будем синхронизироваться.
*default host=cvsup.FreeBSD.org
# Куда будем складывать свеженькое:
*default base=/usr
*default prefix=/usr
*default release=cvs
# Тег ветки нашей системы
*default tag=RELENG_5_4
*default delete use-rel-suffix
# Используем сжатие при передаче данных
*default compress
# Что будем синхронизировать?
# Все исходники
src-all
*default tag=RELENG_5_4
*default tag=.
# Все порты
ports-all
# Весь RTFM
doc-all

После сборки cvsup-without-gui в /usr/local/bin у тебя появился бинарник cvsup. Запускать его надо со следующими параметрами:

/usr/local/bin/cvsup -g -L 2 -z /путь/к/конфигу

Согласись, держать команды в памяти неудобно. Поэтому мы напишем скрипт и автоматизируем процесс обновлений. Создаем файл cvs_up:

# touch cvs_up

Открываем его любым редактором и пишем такой скрипт:

#!/bin/sh
echo "Starting CVSup..."
case "$1" in
-t)
/usr/sbin/ntpdate -v ru.pool.ntp.org
;;
-q)
/usr/sbin/ntpdate -v ru.pool.ntp.org 2>&1 > /dev/null
/usr/local/bin/cvsup -g -L 2 -z /etc/cvsup.conf 2>&1 > /dev/null
;;
*)
/usr/local/bin/cvsup -g -L 2 -z /etc/cvsup.conf
;;
esac
echo "Packages needed to update:"
/usr/sbin/pkg_version -v |grep '<'
exit 0

Кладем скрипт в нужное место, выставляем chmod и chown:

# mv cvs_up /usr/local/sbin/cvs_up
# chown root:wheel /usr/local/sbin/cvs_up
# chmod 0700 /usr/local/sbin/cvs_up

Теперь, для того чтобы синхронизировать исходники, порты, документацию и даже время на сервере, у нас есть один скрипт, который после синхронизации еще и покажет, что обновилось. Как видишь, его можно запускать с флагом –q, который перенаправит всю отчетность скрипта в /dev/null.

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

# cd /usr/ports/sysutils/portupgrade
# make install clean

И запускаем наш скрипт. По окончании своей работы скрипт выдаст отчет о том, какие порты требуют обновлений. Обновить софтину или библиотеку очень просто:

# portupgrade порт1 порт2 ... порт22

Если хочешь, - можешь прописать этот скрипт в cron на выполнение раз в сутки, желательно ночью, или в то время, когда нагрузка на твой сервер минимальна. Например так:

0 4 * * * /usr/local/sbin/cvs_up >/dev/null 2>&1

Лично я предпочитаю запускать его вручную, так как cvsup сервер часто не пускает с первого раза, и скрипт остается висеть в процессах, что не есть хорошо.

Пора приступать к самой важной части настройки системы – к ядру. При инсталле системы автоматически устанавливается ядро GENERIC. В нем включена поддержка устройств, необходимых для старта системы на любой конфигурации. Оптимизировав ядро под свою систему, мы убираем поддержку ненужных устройств и функций, уменьшая таким образом время загрузки и, что еще важнее, улучшая производительность системы в целом. Давай посмотрим, сколько весит ядро до оптимизации:

# ll /boot/kernel/kernel
-r-xr-xr-x 1 root wheel 5940286 Feb 23 2004 /boot/kernel/kernel
#

Почти шесть мегабайт - для *BSD это очень много. Для сборки своего ядра нам понадобятся исходники (src) системы. Если ты не послушал моей рекомендации и не сделал этого при установке, то вставь диск с операционкой и установи их, используя /stand/sysinstall. Не забудь после этого обновить исходники скриптом cvs_up.

[Kernel::Config>.]

Конфиги ядра лежат в папке /sys/<архитектура>/conf. Если у тебя обычный PC, то в /sys/i386/conf. Заходи туда, найди там файл GENERIC и скопируй его с другим названием. Да-да, именно скопируй. Если что-то вдруг пойдет не так как надо, у нас останется рабочий конфиг. Итак, копируем:

# cd /sys/i386/conf
# cp GENERIC HOSTING

Теперь открываем конфиг HOSTING любимым редактором. Опции настройки ядра указаны в виде устройств (device) и расширений/модулей. Все строчки, которые начинаются с символа “#” – закомментированы, а проще говоря, они не будут учтены при сборке нового ядра. Наша задача - закомментировать ненужные нам строчки, оставив только необходимое (рекомендуется ни в коем случае не удалять, а именно комментировать строки конфига, иначе потом придется долго вспоминать «как же называлась эта опция, после удаления которой ничего не собирается?..» – прим. автора).

Конфиг ядра составляем по принципу “все, что не критично – не нужно”. Вряд ли хостинговому серверу так сильно необходимы USB сканер, десяток драйверов к Wi-Fi карточкам и PCIMCA. Некоторые устройства имеют статус обязательных - без них ядро просто не соберется. Они помечены комментарием required. После того, как ты закомментировал все ненужное, пришло время добавить недостающее.

Options IPFIREWALL # Включаем ipfw
Options IPFIREWALL_VERBOSE
Options IPFIREWALL_VERBOSE_LIMIT=1000
Options TCP_DROP_SYNFIN # Запрещаем SYN/FIN пакеты
Options ACCEPT_FILTER_DATA # Включаем accept фильтры
Options ACCEPT_FILTER_HTTP

Сохраняем конфиг и собираем ядро:

# cd /usr/src
# make buildkernel KERNCONF=HOSTING
# make installkernel KERNCONF=HOSTING

Все, после ребута загрузится свежесобранное ядро. Но ребутиться мы пока не будем - нам надо отредактировать /etc/rc.conf.

# Поддержка линуксовых бинариков
linux_enable="YES"
# Запускаем sshd
sshd_enable="YES"
# Вырубаем лишнее
usbd_enable="NO"
sendmail_enable="NONE"
inetd_enable="NO"
# Включаем сислог
syslogd_enable="YES"
syslogd_flags="-ss"
# Очищаем /tmp при старте системы
clear_tmp_enable="YES"
# Включаем фаервол
firewall_enable="YES"
firewall_script="/etc/rc.firewall"
firewall_type="client"
firewall_quiet="NO"

Все. Наша система настроена и готова к бою :). Если ты работаешь удаленно, пропиши в /etc/rc.firewall разрешающее правило для себя, иначе после ребута потеряется доступ к машине. Если у тебя локальная консоль – смело идем в ребут:

# init 6

Как только сервер поднялся, нужно еще раз проверить, что не возникло проблем с железом, софт не плевался ошибками и вообще все в шоколаде. Помнишь, мы смотрели размер ядра до пересборки? Посмотрим еще раз:

# ll /boot/kernel/kernel
-r-xr-xr-x 1 root wheel 2675196 Mar 10 04:10 /boot/kernel/kernel
#

2.6 мегабайт. Совсем другое дело :).

[intro::Services.]

Итак, в первую очередь важно определиться с тем, какие именно сервисы наш хостинг будет предоставлять клиентам. Основные вещи, которые любой хостинг предоставить обязан - это Web + PHP/Perl, FTP, БД и статистику посещений сайта. Многие хостеры подходят к вопросу поднятия хостинга просто: купили Cpanel, запустили install.sh и продаем аккаунты юзерам. Мы же соберем свой собственный хостинг, с самого начала и до победного конца :).

[выбор софта.]

Сразу оговорюсь, что предпочитаю использовать стабильный и надежный софт, нежели новый и крутой. Нам важна стабильность и функциональность. А всякие, грубо говоря, свистелки и перделки мы оставим скрипткидисам на разнос. Итак, для www, я думаю, не возникнет сомнений - Apache. Ветка 2.* еще довольно сыровата, да и почти под каждую новую версию двойки появлялся бронебойный эксплойт, зачастую даже в паблике. Использовать будем проверенный временем 1.3. FTP - тут выбор не столь однозначен, есть много разных FTPd, но мы остановимся на pure-ftpd. У него удобный и понятный конфиг, отлично реализована работа с виртуальными юзерами, достаточная функциональность и много других достоинств, о которых - ниже. БД, разумеется, MySQL. И опять мы берем самую стабильную версию - 4.0.*. Статистика: можно взять Webalaizer, но лично я предпочитаю AwStats. Его отчетность намного лучше выглядит, интуитивно более понятна, да и подробности анализа ему не занимать.

Структура директорий

Условимся, что мы используем следующую структуру директорий:

/usr/home/юзер – домашняя дира юзеров;
/usr/home/юзер/web – рутовая веб-папка юзера;
/usr/home/юзер/tmp – темп-дира юзера;
/usr/home/юзер/cgi-bin – cgi-bin юзера;
/etc и /usr/local/etc – папки с конфигами;
/etc/awstats – папка конфигов статистики;
/var/db/awstats – папка с БД статистики;
/var/log/www – папка с логами виртуальных хостов

[Apache.]

Кроме обычных клиентов с мега-порталами (привет, VinT :)) и домашними страничками, услугами хостинга пользуются еще и много коммерческих организаций, в частности, инет-магазины. Поэтому нам нужна возможность предоставлять им https. На сегодняшний день существуют две основные релизации SSL для Apache. Это Apache-ssl, поддерживаемый самой Apache Group и сторонняя разработка – mod_ssl. Последняя дает намного больше возможностей и намного активней поддерживается, поэтому используем ее. Итак, собираем Apache:

# cd /usr/ports/www/apache13-modssl
# make install clean

И переходим к настройке. Основной конфиг Апача лежит в /usr/local/etc/apache и зовется httpd.conf. Конфиг совсем не маленький, поэтому я опишу лишь самые основные и важные параметры, а полностью ты сможешь найти его на диске.

# Запускаем сервер через inetd или самостоятельным демоном, # inetd у нас в системе выключен, так что выбор невелик :).
ServerType standalone
# Рутовая директория веб-сервера
ServerRoot "/usr/local"
# Таймаут соединений в секундах.
Timeout 300
# А вот об этом – поподробней. KeepAlive - механизм, позволяющий, не прерывая # соединения с сервером, отправить ему несколько запросов. Это позволяет
# экономить ресурсы за счет того, что не создается новый процесс, а на запросы
# отвечает уже существующий. Количество запросов и таймаут указываются
# следующими опциями:
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
# Следующие три настройки сильно зависят от загруженности веб-сервера. Они
# указывают на то, сколько серверов минимум и максимум может быть загружено, и сколько # процессов сервера запускать при старте.
MinSpareServers 10
MaxSpareServers 70
StartServers 10
# Сколько клиентов может одновременно обслуживать сервер
MaxClients 150
# Сколько запросов может одновременно обрабатывать один процесс сервера
# (0 – не ограничено). Ноль ставить не рекомендуется.
MaxRequestsPerChild 7000
Дальше у нас идут настройки Listen и Bind - тут ничего хитрого нет. А сразу за ними – список модулей, которые подгружает сервер. Смело комментируй ненужные:

mod_userdir, mod_info, mod_proxy, mod_imap, mod_auth_db

Обрати внимание, что каждый модуль нужно закомментировать дважды – в секции LoadModule и в секции AddModule. Дальше идет конфигурация основного сервера, но мы там почти ничего менять не станем, т.к. «основной» сервер использоваться у нас не будет – мы будем основываться на виртуальном хостинге. Смело стираем блок и раскомментируем строки:

AddType text/html .shtml
AddHandler server-parsed .shtml

Затем находим и раскомментируем строчку “NameVirtualHost *:80” – она включит виртуальные хосты. Настройки SSL - по вкусу, но лучше ничего не трогай, если точно не знаешь, что значит тот или иной параметр. И, наконец, последней строчкой конфига добавим:

Include etc/apache/vhosts/

Эта строчка скажет серверу, где находятся дополнительные конфиги. Учти, что перед дирой, которую мы укажем, добавляется значение ServerRoot.

[PHP/Perl/CGI.]

Веб-сервер это, конечно, хорошо, но на голом хтмл далеко не уедешь. И сейчас мы добавим использование php, perl и cgi-скриптов. Начнем с php:

# cd /usr/ports/lang/php4/
# make config

Появится менюшка, поставим галочку на Apache, на zend multibyte support, и, если надо, на IPv6.

# make install clean

Модуль должен поставиться без проблем и сам вписать себя в конфиг Apache. Открой на всякий случай конфиг и проверь, что все прошло нормально, конфиг жив и никто не пострадал. Теперь к нашему модулю нужно собрать расширения PHP.

# cd /usr/ports/lang/php4-extensions/
# make install clean

Опять появится менюшка с кучей расширений на выбор. Нам обязательно установить следующие (кроме уже отмеченных):

Bcmath, bz2, curl, ftp, gd, iconv, mbstring и sockets.

Остается лишь откинуться на спинку стула и наслаждаться установкой :). Как только установка завершится, идем в /usr/local/etc и копируем рекомендуемый конфиг:

# cd /usr/local/etc
# cp php.ini-recommended php.ini

Открываем php.ini и вносим следующие изменения:

; Включаем safe_mode
safe_mode = On
; Максимальное время выполнения скрипта
max_execution_time = 20
; Максимальное время обработки скриптом данных
max_input_time = 40
; Максимум выделяемой памяти
memory_limit = 10M
; Максимальный размер файла для аплоада
upload_max_filesize = 5M

Разумеется, эти настройки варьируются в зависимости от специфики хостящихся сайтов. Я указал наиболее оптимальные значения, проверенные опытным путем, но, разумеется, тебе ничего не мешает указать их по-своему. Некоторые важные настройки, касающиеся безопасности PHP, мы затронем подробнее в разделе «Защита».

Теперь нам нужно установить Zend Optimizer, чтобы юзеры хостинга смогли запускать скрипты, зашифрованые зендом. Тут все не так просто, и придется сделать небольшой финт ушами. Идем на zend.com, выбираем Products -> Zend Optimizer, free download. Нас попросят зарегистрироваться: мыло можно вводить любое, оно не проверяется. После регистрации нас перебросит на страницу закачки оптимайзера. В разделе Zend Optimizer 3.0.0 выбирай FreeBSD x86 5.x. Полученный файл ZendOptimizer-3.0.0-freebsd5.4-i386.tar.gz клади в /usr/ports/distfiles и собирай порт:

# cd /usr/ports/devel/ZendOptimizer
# make install clean

Установка не должна занять много времени. Обрати внимание, что Zend попросит тебя добавить несколько строк в конец файла php.ini. В моем случае:

[Zend.]
zend_optimizer.optimization_level=15
zend_extension_manager.optimizer="/usr/local/lib/php/20020429-zts/Optimizer"
zend_extension_manager.optimizer_ts="/usr/local/lib/php/20020429-zts/Optimizer_TS"
zend_extension="/usr/local/lib/php/20020429-zts/ZendExtensionManager.so"
zend_extension_ts="/usr/local/lib/php/20020429-zts/ZendExtensionManager_TS.so"

Обычно это происходит автоматически при установке, но проверить лишний раз не помешает. Теперь, по аналогии с php, нам нужно собрать еще и mod_perl. Можно, конечно, дать веб-юзерам использовать системный перл – но делать это крайне не рекомендуется, хотя бы по тем же соображениям безопасности. О производительности я уже молчу. Собираем mod_perl:

# cd /usr/ports/www/mod_perl
# make install clean

Модуль перла так же пропишет себя в конфиг httpd.conf, не лишним будет проверить, что все ок. Разумеется, таким образом можно добавить многие полезные модули, например поддержку Python, различные модули авторизации, поддержку frontpage extensions и много других нужных вещей.

[Vhosts.]

Как известно, протокол HTTP 1.1 дает возможность передавать в запросе параметр Host, что позволяет держать несколько сайтов на одном IP адресе. Это называется виртуальным хостингом. Для каждого сайта, который будет у нас хоститься, мы создадим отдельный конфиг, что позволит делать гибкие настройки для каждого домена в отдельности. Первый конфиг, который мы создаем, будет служебного характера. Для начала создадим папку для конфигов, которую мы указали Apache:

# mkdir /usr/local/etc/apache/vhosts
# cd /usr/local/etc/apache/vhosts

И создаем там первый конфиг:

# touch 001.hosting.ru

Открываем конфиг и пишем:

# Мыло админа (будет показываться при HTTP ошибках)
ServerAdmin admin@hosting.ru
# Рутовая папка вхоста
DocumentRoot /home/revol.ru/web
# Домен и алиасы, по которым мы будем видеть вхост
ServerName hosting.ru
ServerAlias www.hosting.ru
ServerAlias main.hosting.ru
# Где располагаются логи
ErrorLog /var/log/www/hosting.ru -error.log
CustomLog /var/log/www/hosting.ru-custom.log combined
# Настройки .htaccess и запрет просматривать его из браузера
AccessFileName .htaccess

Order allow,deny
Deny from all

Чтобы применить настройки апача и вхостов – используй команду apachectl graceful.

[MySQL.]

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

# cd /usr/ports/databases/mysql40-server

На всякий случай сделаем бэкап Makefile

# cp Makefile Makefile.back

Открываем Makefile, находим там строчку:

--enable-thread-safe-client \

И после нее добавляем:

--with-client-ldflags=-all-static \
--with-mysqld-ldflags=-all-static \
--enable-assembler \
--with-named-thread-libs='-lpthread -D_THREAD_SAFE'

Закрываем, сохраняем и собираем порт с помощью трех магических слов – make install clean. Установка порта MySQL должна пройти без проблем. После установки топаем в /var/db/mysql и находим там несколько дефолтных конфигов:

my-huge.cnf – для серверов, работающих с огромными по размеру базами (сотни гиг) my-large.cnf – если базы просто большие :).

О значении my-medium.cnf и my-small.cnf, думаю, догадаться не сложно :). В целом, конфиг my-large.cnf нам подойдет. Оптимизировать MySQL в конфиге имеет смысл только в том случае, когда ты точно знаешь, какие запросы составляют большинство нагрузки. Так как на хостинге сайты будут разные, и работать их движки с БД будут по-разному – оставим пока дефолтные настройки. Потом, исходя из специфики сайтов, некоторые параметры можно будет подкрутить.

[phpMyAdmin.]

Однако управлять MySQL из консоли очень и очень неудобно. Поставим phpMyAdmin: скачаем его с сайта (или возьми свежий дистриб на диске с журнала), и – в бой:

# tar zxvf phpMyAdmin-2.8.1.tar.gz
# mkdir /usr/home/hosting.ru/web/pmadmin
# cp -rf phpMyAdmin-2.8.1/* /usr/home/hosting.ru/web/pmadmin
# chown –R hosting.ru:hosting.ru /usr/home/hosting.ru/web/pmadmin
# cd /usr/home/hosting.ru/web/pmadmin

Открываем файл config.inc.php и меняем там:

$cfg['Servers'][$i]['auth_type'] = 'config';

на

$cfg['Servers'][$i]['auth_type'] = 'http';

Идем на http://hosting.ru/pmadmin/, вводим свой логин и пароль к SQL и наслаждаемся :).

[FTP.]

Для FTP-сервиса, как ты помнишь, мы выбрали pure-ftpd. Собираем порт:

# cd /usr/ports/ftp/pure-ftpd
# make install clean

В менюшке опций сборки поставь галочки на:

MySQL – авторизация юзеров через БД;
PRIVSEP – разделение юзерских привилегий;
PERUSERLIMIT – ограничение потоков для каждого юзера;
THROTTLING – ограничение канала для каждого юзера;
BANNER – не обязательно :).

После сборки порта в /usr/local/etc появятся дефолтные конфиги фтп-сервера. Создаем отдельную диру, переносим туда нужные конфиги, выставляем чмоды и удаляем ненужное:

# cd /usr/local/etc
# mkdir ftp
# mv pure-ftpd.conf.sample ftp/
# mv pureftpd-mysql.conf.sample ftp/
# chown –R root:wheel ftp/ && chmod –R 0600 ftp/
# rm pure*

Заходим в папку с конфигами, переименовываем их, оставляя бэкапы:

# cd ftp/
# cp pure-ftpd.conf.sample pure-ftpd.conf
# cp pureftpd-mysql.conf.sample pureftpd-mysql.conf

Теперь необходимо настроить наш фтп-сервер. Открываем pure-ftpd.conf:

Листинг файла pure-ftpd.conf

# Создавать виртуальный chroot для каждого пользователя
# Папка /home/<юзер> будет выглядеть как рутовая
ChrootEveryone yes
# Включить поддержку кривых фтп-клиентов
# Не рекомендуется выставлять в yes из соображений безопасности
BrokenClientsCompatibility no
# Сколько юзеров может одновременно подключаться
MaxClientsNumber 30
# Сколько юзеров может одновременно подключаться с одного IP
MaxClientsPerIP 3
# Подробный лог
VerboseLog yes
# Вход только авторизированым пользователям
NoAnonymous yes
# Не резольвить IP адреса
DontResolve yes
# Конфиг сервера для MySQL
MySQLConfigFile /usr/local/etc/ftp/pureftpd-mysql.conf
# Выключаем PAM и стандартную авторизацию
PAMAuthentication no
UnixAuthentication no
# Диапазон портов для passive mode
PassivePortRange 30000 50000
# Минимальный User ID, который может залогиниться
MinUID 1002
# Запрещаем/разрешаем FXP (по вкусу)
AllowUserFXP no
# Не создавать папку юзеру, если не существует
CreateHomeDir no
# Включаем квоты
Quota 1000:10
# Не пускать юзера, если на диске занято 95% места.
MaxDiskUsage 95
# Включаем лимиты на скорость download/upload
PerUserLimits 3:20
# Только IPv4
IPV4Only yes

Сам сервер сконфигурирован и готов, осталось настроить авторизацию через MySQL. Редактируем /usr/local/etc/ftp/pureftpd-mysql.conf:

# Работаем с MySQL через локальный сокет
MYSQLSocket /tmp/mysql.sock
# Юзер, пароль, база
MYSQLUser ftp
MYSQLPassword nhjhf21j
MYSQLDatabase pureftpd
# Храним пароли в открытом виде или зашифрованые md5
MYSQLCrypt cleartext
# SQL запрос, ответом которого будет пароль юзера
MYSQLGetPW SELECT Password FROM users WHERE User="\L"
# SQL запрос, ответом которого будет uid юзера. По умолчанию uid/gid можно
# указывать цифрами (1003:1003). Чтобы получить возможность указывать юзеров
# как user:group поменяй тип полей Uid и Gid в дампе:
# Uid VARCHAR(16) NOT NULL default '-1',
# Gid VARCHAR(16) NOT NULL default '-1',
MYSQLGetUID SELECT Uid FROM users WHERE User="\L"
MYSQLGetGID SELECT Gid FROM users WHERE User="\L"
# SQL запрос, ответом которого будет домашняя директория юзера (она станет для
# него рутовой)
MYSQLGetDir SELECT Dir FROM users WHERE User="\L"
# SQL запрос, ответом которого будет лимит на кол-во файлов
MySQLGetQTAFS SELECT QuotaFiles FROM users WHERE User="\L"
# SQL запрос, ответом которого будет квота юзера в мегабайтах
MySQLGetQTASZ SELECT QuotaSize FROM users WHERE User="\L"
# SQL запрос, ответом которого будет лимит скорости Upload для юзера (кб/с)
MySQLGetBandwidthUL SELECT ULBandwidth FROM users WHERE User="\L"
# SQL запрос, ответом которого будет лимит скорости Download для юзера (кб/с)
MySQLGetBandwidthDL SELECT DLBandwidth FROM users WHERE User="\L"

Конфиг фтп-сервера завершен. Осталось только создать базу MySQL с параметрами, которые мы указали в конфиге, и залить в эту самую базу дамп. phpMyAdmin у нас есть, так что с созданием юзера и базы проблем не возникнет. А дамп базы в природе существует в двух местах – глубоко в дебрях оффсайта pure-ftpd и на диске, прилагаемом к журналу. Надеюсь, вбить дамп в базу труда не составит. Также не забудь - чтобы ftpd запустился при старте системы – добавить в /etc/rc.conf строчки:

pureftpd_enable="YES"
pureftpd_config="/usr/local/etc/ftp/pure-ftpd.conf"

[статистика.]

Awstats 6.5 присутствует в портах FreeBSD, но версия 6.5 содержит очень опасную уязвимость, поэтому ставить мы будем ручками версию 6.6. Качай Awstats с оффсайта, или возьми дистрибутив на диске, прилагаемом к журналу. Разахривируй файл и устанавливай:

# mkdir /etc/awstats
# cd awstats-6.6/wwwroot/cgi-bin/
# mv awstats.model.conf /etc/awstats
# cp –rf * /home/пользователь/cgi-bin/

Все конфиги статистики будут находиться в папке /etc/awstats. Чтобы добавить там конфиг для определенного домена – скопируй файл awstats.model.conf, заменив model именем домена (без www). Например:

# cd /etc/awstats
# cp awstats.model.conf awstats.hosting.ru.conf

Сам конфиг Awstats довольно длинный, я укажу лишь основные параметры:

# Какой лог парсить
LogFile="/var/log/www/hosting.ru-acess.log"
# Тип лога (W – web, F – FTP, M – mail, S - streaming)
LogType=W
# Домен(ы) сайта
SiteDomain="hosting.ru"
HostAliases="www.hosting.ru REGEX[hosting\.ru$]"
# Путь к БД статистики
DirData="/var/db/awstats"
И, наконец, скрипт, который будет обновлять статистику:
# cd awstats-6.6
# mkdir /usr/local/awstats
# mv tools/ /usr/local/awstats