Главная » Статьи » Веб » Администратирование |
НА СЕГОДНЯШНИЙ ДЕНЬ СИТУАЦИЯ НА ХОСТИНГОВОМ РЫНКЕ РУНЕТА
НАПОМИНАЕТ НОВОГОДНЮЮ ЯРМАРКУ: ОГРОМНЫЙ ВЫБОР ТАРИФНЫХ ПЛАНОВ, ШИРОКИЙ
АССОРТИМЕНТ РАЗНООБРАЗНЫХ УСЛУГ. ЛОГИЧНО БУДЕТ ПРЕДПОЛОЖИТЬ, ЧТО ЭТО
ОБЪЯСНЯЕТСЯ ДОСТУПНОСТЬЮ ТЕХНОЛОГИИ, ОДНАКО ЭТО НЕ СОВСЕМ ТАК. ДЕЛО В
ТОМ, ЧТО СУЩЕСТВУЕТ МНОЖЕСТВО ГОТОВЫХ ХОСТИНГОВЫХ РЕШЕНИЙ, УСТАНОВИТЬ
КОТОРЫЕ НЕ СОСТАВИТ ТРУДА – БЫЛИ БЫ ДЕНЬГИ. СЕЙЧАС МЫ ПОСТРОИМ СВОЙ
ХОСТИНГ, - С САМОГО НАЧАЛА, И НЕ ПРИБЕГАЯ К ПЛАТНЫМ УСТАНОВОЧНЫМ ПАКЕТАМ
ВРОДЕ 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 Добавляем скрипт в крон, чтобы обновлять статистику раз в 9 минут. */9 * * * * /usr/local/awstats/tools/awstats_updateall.pl now >/dev/null 2>&1 Просмотреть статистику для домена мы сможем по адресу: http://hosting.ru/cgi-bin/awstats.pl | |
Просмотров: 536 | Комментарии: 2 | Рейтинг: 0.0/0 |
Всего комментариев: 1 | ||
| ||