1)apache
2)php (4.3.5 или выше)
3)mysql

Установка:

sudo apt-get install apache2
sudo apt-get install php5
sudo apt-get install mysql

Также понадобятся библиотеки: php5-mysql, libapache2-mod-auth-mysql,

Проверить поддерживает ли php работу с mysql можно с помощью простого скрипта, назовем его phpinfo.php

после обращения к нему в браузере смотрим на выведенные переменные и параметры и ищем секцию под названием mysql, если ее нет, то необходимо установить библиотеку
php5-mysql.
В случае отсутствия libapache2-mod-auth-mysql установка останавливается на шаге лоступа к базе данных и выдается ошибка- “Your web server does not appear to support any common database types.
Check with your hosting provider to see if they offer any databases that Drupal supports”.

Установка библиотек для работы с mysql:

sudo apt-get install php5-mysql
sudo apt-get install libapache2-mod-auth-mysql

Рекомендую до начала установки скачать и распаковать в каталог drupal его русификатор (если это сделать сразу, уже на этапе установки возможно будет выбрать русский язык),
потом необходимо скопировать и переименовать файл default.settings.php в settings.php

cp sites/default/default.settings.php sites/default/settings.php

Далее даем права на запись на каталог sites/default и на сам файл settings.php.

chmod o+w sites/default/settings.php

Создаем папку files в папке sites/default,
даем права на запись:

chmod o+w sites/default/files

Создаем базу данных для drupal вручную, с помощью клиента mysql:

create database название_базы;

базу также можно создать с помощью оболочки
phpmyadmin.

Настройка параметров через Web-интерфейс:
1 выбираем язык
2 заполняем имя созданной базы данных, имя пользователя и пароль,
также можно заполнить префикс имен таблиц (рекомендуется, если у Вас для всего 1 база данных на хостинге, потом будет проще разбираться в назначении таблиц)

Забираем права на запись на каталог sites/default и на сам файл settings.php.

chmod a-w sites/default/settings.php
chmod a-w sites/default

Также Drupal потребовал установки модуля gd для php.
устанавливаем его командой:

sudo apt-get install php5-gd

После чего проверяем нашим скриптом phpinfo.php появился или нет раздел gd,
если нет в файл php.ini в раздел Dynamic Extensions добавляем строку:
extension=gd.so (имено так без путей, т.к. они прописываются в другой переменной)

После чего перезапускаем Apapche:

sudo service apache2 restart

Выставляем даты в нормальном режиме, и первый день – понедельник (умолчание – вокресенье)

В случае с CentOS имеем так же быструю и беcпроблемную установку, благодаря наличию munin в репозитории rpmforge.

Итак, если не поключен, подключаем репозитоий (пример для CentOS 5, i386):
rpm -Uhv http://apt.sw.be/redhat/el5/en/i386/rpmforge/RPMS/rpmforge-release-0.3.6-1.el5.rf.i386.rpm

Устанавливаем пакеты munin и munin-node:
yum install munin munin-node

Munin состоит из двух частей, пакет munin-node должен работать на сервере, который хотим мониторить, а пакет munin может быть в другом месте. В нашем случае все будет на одном и том же сервере. По умолчанию, в конфигурационном файле /etc/munin/munin-node.conf доступ разрешен только локально.

Создадим папку, в которой munin будет генерировать файлы (параметр htmldir в /etc/munin/munin.conf):
mkdir /var/www/html/munin
chown munin:munin /var/www/html/munin

Запускаем munin-node:
service munin-node start

Не забываем про init-скрипты:
chkconfig --level 345 munin-node on

Раз в 5 минут, по крону (/etc/cron.d/munin), munin будет обновлять графики, которые будет складывать в /var/www/html/munin.

Все что осталось – настроить веб-сервер для доступа к /var/www/html/munin. В случае с apache, заготовка уже лежит в /etc/httpd/conf.d/munin.conf, осталось только отредактировать ее, и может быть закрыть папку паролем. Надо отметить, что генерирует munin только статику, веб-сервер можно использовать любой.

Сайт проекта: http://munin.projects.linpro.no/

Apache:

sudo apt-get install apache2

Все зависимости установятся автоматически. Для запуска Apache2 используем :

sudo invoke-rc.d apache2 start

Проверяем набрав в браузере http://localhost

Устанавливаем PHP

sudo apt-get install php5 libapache2-mod-php5

и перезапускаем Apache:

sudo invoke-rc.d apache2 restart

или

sudo /etc/init.d/apache2 restart

кто как привык.

Устанавливаем MySQL

sudo apt-get install mysql-server

При установке запросят пароль root к серверу БД в некоторых сборках нет:

Тогда ставим сами:

sudo mysqladmin -u root password пароль

Перезапускаем Apache2.

Все должно работать. Для проверки PHP пишем небольшой скрипт:

sudo nano /var/www/test.php

И записываем в него одну сроку

Набираем браузере http://localhost/test.php, должны увидить инфу PHP. Если нет включаем модуль a2enmod php5

Прежде чем мы начнем “защищать” Apache, мы должны определить, какие
функции должен выполнять наш сервер. На данный момент Apache
используют для решения совершенно разных задач, поэтому очень сложно
написать универсальное руководство по установки защищенного web
сервера. Именно по этому в этой статье мы будем опираться на следующие
функциональные возможности:
* Web сервер будет доступен через Интернет;
* Будут использоваться только статические HTML страницы
* Сервер будет поддерживать name-based virtual hosting механизм
* Некоторые Web страницы будут доступны только пользователям с
определенным IP адресом
* Сервер будет записывать все Web запросы (включая информацию о Web
браузерах)

Стоит подчеркнуть, что приведенная выше модель не поддерживает PHP,
JSP, CGI или любые другие технологии, которые дают возможность
взаимодействовать с Web службами. Использование таких технологий может
серьезно повлиять на безопасность сервера. Даже маленький неприметный
сценарий может очень сильно уменьшить уровень защиты Web сервера.
Почему? Прежде всего, приложения ASP/CGI могут содержать уязвимость
защиты (например SQL injection или cross-site-scripting). Во вторых,
сама технология может быть опасной (уязвимости в PHP и Perl модулях и
т.д.). Именно поэтому я настоятельно рекомендую использовать такие
технологии только, когда обойтись без них просто невозможно.

Проектирование защиты
———————

Одним из наиболее важных элементов любого компьютерного проекта
является проектирование защиты. Эта операция должна быть выполнена еще
до того, как проект будет закончен. Вот как мы спроектируем защиту
нашего Web сервера:
* Операционная система должна быть максимально защищена как от
локальных, так и от удаленных атак;
* Сервер не должен предоставлять какие-либо сетевые сервисы, кроме
HTTP: (80/TCP);
* Удаленный доступ к серверу должен быть под контролем файерволла,
который должен блокировать подключения к любым другим портам,
кроме 80/TCP (порт Web сервера);
* Apache Web server должен быть единственной службой, запущенной в
системе;
* Только самые необходимые модули Apache должны быть включены;
* Всякие Web-страницы диагностики должны быть отключены;
* Сервер должен выдавать как можно меньше информации о себе;
* Apache Web сервер должен быть запущен под уникальными UID/GID,
которые не используются другими процессами;
* Процесс Apache должен иметь ограниченный доступ к файловой системе
(chrooting); и
* Никакие оболочки командного интерпритатора не должны находиться в
chroot окружении (/bin/sh, /bin/csh и т. д.).

Установка операционной системы
——————————

Перед установкой Apache мы должны выбрать операционную систему, на
которой будет работать наш Web сервер. Здесь мы имеем широкий выбор,
потому что Apache может быть скомпилирован и установлен практически на
любой операционной системе. Оставшаяся часть статьи покажет, как
обеспечить высокий уровень безопасности Apache Web сервера на ОС
FreeBSD (4.7), однако описанные методы можно применить и на других
UNIX/Linux системах. Единственная операционная система, которую я не
рекомендую использовать – MS Windows – главным образом из-за
ограничений в настройке безопасности Apache.

Первым шагом в обеспечении хорошей защиты Web сервера является
улучшение/укрепление безопасности операционной системы. К сожалению,
эта тема выходит за рамки данной статьи. Однако, существует множество
статей/документов/заметок в сети по этому чрезвычайно важному вопросу.

После того как система установлена и защищена должным образом, мы
должны добавить новую группу и обычного пользователя “apache” (пример
на FreeBSD):

pw groupadd apache
pw useradd apache -c “Apache Server” -d /dev/null -g apache -s /sbin/nologin

По умолчанию, процесс Apache запущен с привилегиями пользователя
nobody (за исключением главного процесса, который запущен с
привилегиями root) и GID’ом группы nogroup. Это может привести к
серьезной угрозе защиты. При удачном проникновении, взломщик может
получить доступ ко всем другим процессам, которые запущены под теми же
UID/GID.

Следовательно, оптимальным решением будет запуск Apache под UID/GID
уникального пользователя/группы, которые будут работать только с нашим
Web сервером и ни с каким другим софтом.

Подготовка Программного обеспечения
———————————–

Следующий шаг – вы должны загрузить самую последнюю версию [78]Apache
Web server. Некоторые опции Apache могут быть включены только при
компиляции, таким образом очень важно скачать исходный код, а не так
называемую “binary-версию”.

После успешной загрузки Apache, мы должны его распаковать. Затем нам
предстоит решить, какие модули нам пригодятся, а какие нет. Короткие
описания всех модулей можно найти на http://httpd.apache.org/docs/mod/

Модули Apache

Выбор модулей – один из наиболее важных шагов в обеспечении хорошей
защиты Apache Web server. Мы должны руководствоваться одним хорошим
правилом: чем меньше, тем лучше. Чтобы задействовать нужные нам
функциональные возможности и обеспечить хорошую защиту, должны быть
включены следующие модули:

httpd_core – Ядро Apache, требуется при каждой установке Apache.

mod_access – Контроль доступа к каталогам сервера в зависимости от IP-адреса или
имени узла клиента.

mod_auth – Требуется, чтобы осуществлять авторизацию пользователей, используя
текстовые файлы.

mod_dir – Требуется, чтобы искать индексные файлы: “index.html”, “default.html”,
и т. д.

mod_log_config – Обеспечивает регистрацию запросов, направляемых серверу.

mod_mime – Содержит директивы, способствующие организации на сервере различных
типов MIME.

Все остальные модули Apache должны быть выключены. Мы можем спокойно
их отключить, потому что они нам не понадобятся. Отключая ненужные
модули, мы предотвращаем возможность взломщика эксплуатировать
уязвимость, которая была найдена в одном из этих модулей.

Также стоит обратить внимание, что два модуля Apache (mod_autoindex и
mod_info) являются наиболее опасными. Первый модуль позволяет
автоматически проиндексировать каталог и он включен по умолчанию.
Чтобы посмотреть, как он работает, введите, например,
http://server_name/icons/ и если в этом каталоге нет индексных
файлов, то будет выведено содержание всего каталога. Второй модуль,
mod_info, никогда не должен быть доступен через Интернет, потому что
он показывает всю конфигурацию Web сервера Apache.

Следующий вопрос – как компилировать модули. Мне кажется, что
статический метод – самый лучший (коды встраиваются в исполняемые
файлы), нежели динамическая (коды собираются в момент запуска
программы). Выбирая статический метод, мы также устраняем потребность
в еще одном модуле – mod_so.

Компилирование программного обеспечения
—————————————

Прежде всего, если существуют патчи, то их нужно немедленно
установить. Затем вы должны скомпилировать и установить сервер так:

./configure –prefix=/usr/local/apache –disable-module=all \
–server-uid=apache –server-gid=apache –enable-module=access \
–enable- module=log_config –enable-module=dir \
–enable-module=mime –enable-module=auth
make
su
umask 022
make install
chown -R root:sys /usr/local/apache

Chroot’им сервер
—————-

Делая следующий шаг, мы ограничим доступ процессу Apache к файловой
системе. Достигнуть этой цели мы можем, путем chroot’a главного демона
Apache (httpd). Вообще, chroot – это создание новой структуры каталога
root, перемещение всех демонов в новый каталог и запуск надлежащих
демонов в этой новой среде. Благодаря этому, daemon (и все порожденные
им процессы) будет иметь доступ только к этой новой структуре
каталога.

Теперь создадим новую структуру каталога root (/chroot/httpd):

mkdir -p /chroot/httpd/dev
mkdir -p /chroot/httpd/etc
mkdir -p /chroot/httpd/var/run
mkdir -p /chroot/httpd/usr/lib
mkdir -p /chroot/httpd/usr/libexec
mkdir -p /chroot/httpd/usr/local/apache/bin
mkdir -p /chroot/httpd/usr/local/apache/logs
mkdir -p /chroot/httpd/usr/local/apache/conf
mkdir -p /chroot/httpd/www

Владельцем вышеперечисленных каталогов должен быть root, и права
доступа должны быть 0755. Затем мы создадим специальный файл:
/dev/null:

ls -al /dev/null
crw-rw-rw- 1 root wheel 2, 2 Mar 14 12:53 /dev/null
mknod /chroot/httpd/dev/null c 2 2
chown root:sys /chroot/httpd/dev/null
chmod 666 /chroot/httpd/dev/null

Можно использовать разные методы, чтобы создать /chroot/httpd/dev/log.
В случае с FreeBSD, в файл /etc/rc.conf нужно добавить следующую
строчку:

syslogd_flags=”-l /chroot/httpd/dev/log”

Мы должны перезапустить систему или демон syslogd, чтобы сделанные
нами изменения вступили в силу.

Сейчас нам следует скопировать главную httpd программу в новое дерево
каталогов со всеми необходимыми файлами. Чтобы осуществить это, мы
должны приготовить список всех требуемых файлов. Чтобы сделать этот
список, мы можем воспользоваться следующими командами (их присутствие
зависит от конкретной операционной системы):

ldd – Показывает динамическую зависимость исполняемых файлов или
общедоступных библиотек.

ktrace/ktruss/kdump (*BSD) – Включает отслеживание вызовов ядра

sotruss (Solaris) – Трассирует вызовы функций из разделяемых библиотек.

strace/ltrace (Linux) – Отслеживает системные вызовы, которые делает
программа в процессе своей работы

strings – Позволяет просмотреть в любом (в том числе выполнимом) файле
все строки (в коде ASCII)

trace (AIX) – Записывает выбранные системные вызовы

truss (FreeBSD, Solaris, AIX 5L, SCO Unixware) – Трассирует системные вызовы и сигналы

trusc (HP-UX>11) – Трассирует системные вызовы в HP-UX 11

Ниже приведен пример использования команд ldd, strings и truss:

localhost# ldd /usr/local/apache/bin/httpd
/usr/local/apache/bin/httpd:
libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x280bd000)
libc.so.4 => /usr/lib/libc.so.4 (0x280d6000)

localhost# strings /usr/local/apache/bin/httpd | grep lib
/usr/libexec/ld-elf.so.1
libcrypt.so.2
libc.so.4

localhost# truss /usr/local/apache/bin/httpd | grep open
(…)
open(“/var/run/ld-elf.so.hints”,0,00) = 3 (0×3)
open(“/usr/lib/libcrypt.so.2″,0,027757775370) = 3 (0×3)
open(“/usr/lib/libc.so.4″,0,027757775370) = 3 (0×3)
open(“/etc/spwd.db”,0,00) = 3 (0×3)
open(“/etc/group”,0,0666) = 3 (0×3)
open(“/usr/local/apache/conf/httpd.conf”,0,0666) = 3 (0×3)
(…)

Вышеупомянутые команды должны применяться не только по отношению к
httpd, но и ко всем требуемым библиотекам и бинарным файлам. В случае
с FreeBSD, следующие файлы должны быть скопированы в новую root
директорию:

cp /usr/local/apache/bin/httpd /chroot/httpd/usr/local/apache/bin/
cp /var/run/ld-elf.so.hints /chroot/httpd/var/run/
cp /usr/lib/libcrypt.so.2 /chroot/httpd/usr/lib/
cp /usr/lib/libc.so.4 /chroot/httpd/usr/lib/
cp /usr/libexec/ld-elf.so.1 /chroot/httpd/usr/libexec/

Используя команду truss мы обнаружим, что следующие конфигурационные
файлы также должны присутствовать в новой среде:

cp /etc/hosts /chroot/httpd/etc/
cp /etc/host.conf /chroot/httpd/etc/
cp /etc/resolv.conf /chroot/httpd/etc/
cp /etc/group /chroot/httpd/etc/
cp /etc/master.passwd /chroot/httpd/etc/passwords
cp /usr/local/apache/conf/mime.types /chroot/httpd/usr/local/apache/conf/

Обратите внимание, что в файле /chroot/httpd/etc/passwords мы должны
удалить все строчки кроме “nobody” и “apache”. Таким же образом мы
должны удалить все строчки, кроме “apache” и “nogroup” в
/chroot/httpd/etc/group. Затем нам нужно создать базу данных паролей:

cd /chroot/httpd/etc
pwd_mkdb -d /chroot/httpd/etc passwords
rm -rf /chroot/httpd/etc/master.passwd

Теперь нам предстоит проверить, правильно ли работает httpd сервер в
новой среде. Для этого нам нужно скопировать файл конфигурации Apache
и файл index.html, как показано в примере:

cp /usr/local/apache/conf/httpd.conf /chroot/httpd/usr/local/apache/conf/
cp /usr/local/apache/htdocs/index.html.en /chroot/httpd/www/index.html

После окончания копирования вышеупомянутых файлов, мы должны заменить
директиву DocumentRoot (в /chroot/httpd/usr/local/apache/conf/httpd.conf):

DocumentRoot “/www”

Теперь мы можем попробовать запустить сервер:

chroot /chroot/httpd /usr/local/apache/bin/httpd

Если появились проблемы, я рекомендую проанализировать log файлы
Apache (/chroot/httpd/usr/local/apache/logs). Как альтернативу, вы
можете использовать следующую команду:

truss chroot /chroot/httpd /usr/local/apache/bin/httpd

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

Конфигурирование Apache
———————–

Для начала, удалите старый
/chroot/httpd/usr/local/apache/conf/httpd.conf файл и создайте на его
месте новый, примерно со следующим содержанием:

# =================================================
# Basic settings
# =================================================
ServerType standalone
ServerRoot “/usr/local/apache”
PidFile /usr/local/apache/logs/httpd.pid
ScoreBoardFile /usr/local/apache/logs/httpd.scoreboard
ResourceConfig /dev/null
AccessConfig /dev/null

# =================================================
# Performance settings
# =================================================
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
MinSpareServers 5
MaxSpareServers 10
StartServers 5
MaxClients 150
MaxRequestsPerChild 0

# =================================================
# Apache’s modules
# =================================================
ClearModuleList
AddModule mod_log_config.c
AddModule mod_mime.c
AddModule mod_dir.c
AddModule mod_access.c
AddModule mod_auth.c

# =================================================
# General settings
# =================================================
Port 80
User apache
Group apache
ServerAdmin Webmaster@www.ebank.lab
UseCanonicalName Off
ServerSignature Off
HostnameLookups Off
ServerTokens Prod

DirectoryIndex index.html

DocumentRoot “/www/vhosts”

# =================================================
# Access control
# =================================================

Options None
AllowOverride None
Order deny,allow
Deny from all

Order allow,deny
Allow from all

Order allow,deny
Allow from all

# =================================================
# MIME encoding
# =================================================

TypesConfig /usr/local/apache/conf/mime.types

DefaultType text/plain

AddEncoding x-compress Z
AddEncoding x-gzip gz tgz
AddType application/x-tar .tgz

# =================================================
# Logs
# =================================================
LogLevel warn
LogFormat “%h %l %u %t “%r” %>s %b “%{Referer}i” “%{User-Agent}i”" combined
LogFormat “%h %l %u %t “%r” %>s %b” common
LogFormat “%{Referer}i -> %U” referer
LogFormat “%{User-agent}i” agent
ErrorLog /usr/local/apache/logs/error_log
CustomLog /usr/local/apache/logs/access_log combined

# =================================================
# Virtual hosts
# =================================================
NameVirtualHost *

DocumentRoot “/www/vhosts/www.ebank.lab”
ServerName “www.ebank.lab”
ServerAlias “www.e-bank.lab”
ErrorLog logs/www.ebank.lab/error_log
CustomLog logs/www.ebank.lab/access_log combined

DocumentRoot “/www/vhosts/www.test.lab”
ServerName “www.test.lab”
ErrorLog logs/www.test.lab/error_log
CustomLog logs/www.test.lab/access_log combined

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

- www.ebank.lab (www.e-bank.lab)
- www.test.lab

Контент вышеупомянутых сайтов находится в следующих каталогах:

- /chroot/httpd/www/vhosts/www.ebank.lab
- /chroot/httpd/www/vhosts/www.test.lab

Каждый сайт имеет собственные log файлы, которые находятся в следующих
каталогах:

- /chroot/httpd/usr/local/apache/logs/www.ebank.lab
- /chroot/httpd/usr/local/apache/logs/www.test.lab

Эти каталоги должны быть созданы еще до того, как вы в первый раз
запустите Apache – иначе Apache не будет работать корректно.
Владельцем вышеупомянутых каталогов должен быть root:sys, а права
доступа должны быть 0755.

По сравнению с настройками по умолчанию, в файле конфигурации Apache
были сделаны следующие изменения:

- Число доступных/включенных модулей значительно уменьшен
- Apache не выдает информацию о номере версии (директивы:
ServerTokens, ServerSignature)
- Процессы Apache (за исключением процесса root) выполняются с
привилегиями уникального пользователя/группы (директивы: User, Group)

- Apache предоставит доступ только к тем каталогам,
подкаталогам и файлам, которые явно прописаны в файле конфигурации
(директивы: Directory, Allow); по умолчанию, все остальные запросы
будут отклонены

- Apache записывает гораздо больше информации о HTTP запросах

Последние штрихи
—————-

Теперь мы сделаем скрипт запуска “apache.sh”, содержание которого
должно выглядеть примерно так:

——————————–

#!/bin/sh

CHROOT=/chroot/httpd/
HTTPD=/usr/local/apache/bin/httpd
PIDFILE=/usr/local/apache/logs/httpd.pid

echo -n ” apache”

case “$1″ in
start)
/usr/sbin/chroot $CHROOT $HTTPD
;;
stop)
kill `cat ${CHROOT}/${PIDFILE}`
;;
*)
echo “”
echo “Usage: `basename $0` {start|stop}” >&2
exit 64
;;
esac

exit 0

——————————–

Данный скрипт вы должны скопировать в надлежащий каталог (зависит от
конкретной UNIX системы), где находятся все скрипты запуска. В случае
с FreeBSD это – /usr/local/etc/rc.d каталог.

В этой статье я НЕ буду описывать как установить Apache,php,mysql в одно единое. С настройкой можете ознакомиться в этом разделе по след статьям:
Apache2 + php5 + mod_fastcgi
Настройка хостинга под apache + PHP + MySQL

Установка и настройка Lighttpd.

# cd /usr/ports/www/lighttpd
# make install clean
# cd /usr/local/etc/
# cp ./lighttpd.conf.sample ./lighttpd.conf
# ee ./lighttpd.conf

Редактируем файл /usr/local/etc/lighttpd.conf. Так как Lighttpd будет обрабатывать только статику, настроек по минимуму:

server.modules = (
“mod_rewrite”,
“mod_redirect”,
“mod_alias”,
“mod_access”,
“mod_proxy”,
“mod_accesslog” )

Общая настройка Lighttpd описана в этой статье.
Добавим в конце файла последнее:

$HTTP["url"] =~ “^.*(html|php|cgi|/|\?|\?.*)$” {
proxy.server = (“” => ( (
“host” => “127.0.0.1″,
“port” => 8080 ) ) )
}

Все скрипты, оканчивающиея на .php,.cgi отправляем на Apache.

В конфиге Apache httpd.conf нужно всего лишь изменить следующие строки:

Listen 127.0.0.1:8080
Port 8080

На этом настройка связки закончена.
Не забудьте добавить в /etc/rc.conf: lighttpd_enable=”YES”

Если вы используете несколько виртуальных хостов в httpd.conf, то их нужно описать и в lighttpd.conf.
На пример, домен – www.domain.com
Добавим в lighttpd.conf:

$HTTP["host"] =~ “(^|\.)domain\.com$” {
server.document-root = “/usr/home/user/public_html/domain.com”
accesslog.filename = “/usr/home/user/log/access.log”
server.errorlog = “/usr/home/user/log/error.log”
}

Accesslog и Errorlog можно обрабатывать через WebAlizer, Awstats и др.
Несколько очень полезных ссылок:
1. Lighttpd and Joomla – A How To
2. Howto: Lighttpd web server setting up virtual hosting

Если есть желание поиграться с оптимизацией отдачи файлов через Lighttpd, можете поэкспериментировать со следующими настройками в lighttpd.conf:

server.max-worker=50
server.max-keep-alive-requests=250
server.max-keep-alive-idle=120
server.max-read-idle =120

Взято с lissyara.su

Легкие веб-сервера набирают обороты. По статистике Google Online Security Blog в Интернете стоит около 4% веб серверов на Nginx. Всем известный rambler.ru крутится на nginx. Nginx действительно отличный веб-сервер который достоин внимания.

Перед нами стоит задача, поставить Nginx как frontend что бы он обрабатывал только некоторые типы файлов, как мы знаем типы файлов – css, js, jpg, gif, exe, tar, pdf и другие подобные – это статика, обрабатывая такие типы файлов легким веб-сервером nginx мы снизим нагрузку на веб-сервер Apache и получим хороший прирост к производительности.

Шаг 1. Установка Nginx

Установка Nginx занимает несколько секунд.
Debian:

apt-get install nginx

FreeBSD:

cd /usr/ports/www/nginx
make install clean

Конфигурационный файл nginx вы найдете у себя в
Debian – /etc/nginx/nginx.conf
FreeBSD – /usr/local/etc/nginx/nginx.conf

Шаг 2. Подготовка Apache.
Настроим Apache, открываем конфигурационный файл, имя файла зависит от версии Apache и платформы. У меня вторая ветка Apache (2.2.x) на Debian и FreeBSD платформах.

Debian – /etc/apache2/ports.conf
FreeBSD – /usr/local/etc/apache2/httpd.conf

Находим строку вида Listen 80.100.100.10:80 где “80.100.100.10″ IP вашего сервера и устанавливаем порт 81

Listen 80.100.100.10:81

Больше ничего не меняйте в конфиге Apache.

Шаг 3. Настройка Nginx

server {
listen 80.100.100.10:80; # ip вашего сервера и порт
server_name myexample.com www.myexample.com; # Имя вашего домена с www и без
location / {
proxy_pass http://80.100.100.10:81/;

…

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarder_for;
}
location ~* \.(jpeg|jpg|gif|png|css|js|pdf|txt|tar)$ { # Обрабатываемые типы файлов
root /home/www/myexample.com/httpdocs; # Путь к коренвевому каталогу вашего сайта
}
}

Строки заголовка запроса X-Real-IP и X-Forwarded-For нужны будут вам если вы в своих скриптах используете информацию об IP-адресе посетителя или хотите скрыть от скриптов разделение на фрондэнд/бэкэнд и видеть нормальные IP пользователей, вместо IP фронтэнда, в таком случае вам необходимо будет дополнительно установить и настроить модуль mod_rpaf.

Шаг 4. Установка mod_rpaf
FreeBSD

cd /usr/ports/www/mod_rpaf
make install clean

После установки откройте конфигурационный файл Apache и проверьте наличие следующей строки :

LoadModule rpaf_module libexec/apache22/mod_rpaf.so

если такой строки нет, добавьте, но указывайте свой путь к файлу mod_rpaf.so
И немного ниже добавьте следующие строки предварительно заменив “80.100.100.10″ на свой IP

RPAFenable On
RPAFsethostname On
RPAFproxy_ips 80.100.100.10
RPAFheader X-Forwarded-For

Взято с server-help.ru

Был у конторы хостинг, для клиентов, бесплатный – как дополнение к тарифным планам с большим траффиком. Десятка полтора сайтов на FreeBSD4.11, apache1.3, php4, mysql4.0 – ничё особенного. Достался он мне по наследству, от старых админов, всё настроено, работает, что называется – не трожь. Но однажды переполнился раздел /var – почтовый спул занял всё свободное место. Недолгое разбирательство выяснило – все письма отправлены с какого-то из сайтов, и в них спам. С какого – выяснить не представлялось возможным – письма шли от пользователля www. Спул почистил, залочил в php.ini функцию mail(), сел думать – что можно сделать подручными средствами. У всех знакомых, работавших у хостеров, были самописные фичи на эту тему – они меняли идентификатор пользователя процесса apache. Апач меня не интересовал – у него своих средств для защиты хватало, а вот php, крутившийся модулем, – работал от того же пользователя, что и апач, – а это не есть гуд. Из других решений – php как CGI. Почитав, понял – подойдёт. Работать будет медленней, чем модулем, т.к. будут дополнительные затраты на порождение дополнительного процесса, но во FreeBSD это досточно шустрый процесс (хотя и накладный, не отрицаю), поэтому особого замедления быть не должно.
Итак, начинаем с апача – нам нужен suexec – он позволяет выполнять пользовательские программы от его имени, незавимо от того, под каким пользователем работает сам http-сервер. Таким образом, для апача нам надо будет лишь предоставить доступ на чтение, включив его в группу пользователя, а всем – запретить вообще доступ. Ставим апач (если стоял – сносим и ставим заново), для начала добавив в файл /etc/make.conf такие строки:

# Директория где лежат порты
PORTSDIR?= /usr/ports

# APACHE
.if ${.CURDIR} == ${PORTSDIR}/www/apache13
# Для запуска CGI-скриптов от gid и uid пользователя, а не WEB-сервера
WITH_APACHE_SUEXEC=yes
# Где будет работать suexec (ещё будет в userdir)
APACHE_SUEXEC_DOCROOT=/usr/local/hosting
# Пользовательские директории, в которых будет работать suexec
APACHE_SUEXEC_USERDIR=”/usr/local/hosting/*/cgi-bin”
# Настройки производительности (без комментов – объяснений толковых не нашёл,
# а может торопился и плохо искал…)
APACHE_SUEXEC_LOG=/usr/local/var/log/httpd-suexec.log
APACHE_HARD_SERVER_LIMIT=yes
WITH_APACHE_PERF_TUNING=yes
APACHE_HARD_SERVER_LIMIT=1024
.endif

После чего, собственно, пересобираем:

/usr/home/lissyara/>cd /usr/ports/www/apache13
/usr/ports/www/apache13/>make deinstall && make clean && make \
? && make install && make clean

После этого, создаём новый класс пользователей, которых будем ограничивать, у меня он называется “webuser”. Для этого, в файл /etc/login.conf добавляем такую секцию:

# конфиг для клиентов. Сразуже – пояснения:
# copyright – файл содержащий информацию о копирайтах
# welcome – приветсвенное сообщение, выводится при входе по ssh. Я пока не
# планирую давать доступ по ssh – но на будущее возможно пригодится.
# setenv – устанавливаем переменные пользователя
# path – пути к исполняемым программам
# manpath – пути к манам
# nologin – местоположение программы, вывоящей сообщение о блокировке аккаунта
# cputime – предел использования CPU
# datasize – максимальный размер данных пользователя (в памяти)
# stacksize – максимальный размер стека
# memorylocked – максимальный размер залоченой памяти ядра
# memoryuse – ограничение размера используемой памяти ядра
# filesize – максимальный размер файла
# coredumpsize – максимальный размер создаваемого дампа (при ошибках)
# openfiles – максимальное число открытых файлов, на процесс
# maxproc – максимальное число процессов
# sbsize – максимальный разрешённый размер буфера сокета
# priority – приоритет исполняемых процессов
# requirehome – для логина пользователя требуется реально существующая
# домашняя директория
# umask – начальная umask для создаваемых файлов
# tc – остальные переменные берём из указанного класса

webuser:\

:copyright=/etc/COPYRIGHT:\
:welcome=/etc/motd:\
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,EDITOR=ee:\
:path=/bin /usr/bin /usr/local/bin:\
:manpath=/usr/share/man /usr/local/man:\
:nologin=/sbin/nologin:\
:cputime=5m:\
:datasize=512M:\
:stacksize=4M:\
:memorylocked=64M:\
:memoryuse=256M:\
:filesize=512M:\
:coredumpsize=0:\
penfiles=1024:\
:maxproc=64:\
:sbsize=unlimited:\
:priority=20:\
:requirehome:\
:umask=026:\
:tc=default:

Пересобираем БД классов пользователей:

/usr/home/lissyara/>cap_mkdb -v /etc/login.conf
cap_mkdb: 10 capability records
/usr/home/lissyara/>

Теперь надо поставить квоты на файловую систему, где у нас хостинг (надеюсь, вы не пускаете юзеров пастись в /usr и прочих системных разделах?). Вначале, я попробовал воткнуть её слёту:

/usr/home/lissyara/>echo ‘enable_quotas=”YES”‘ >> /etc/rc.conf

Перезагрузился, и попробовал поставить квоту:

/usr/home/lissyara/for_hosting/>
/usr/home/lissyara/for_hosting/>edquota -u user_name2
edquota: warning: quotas are not compiled into this kernel
edquota: creating quota file /usr/local/quota.user

Непрокатило . Для этого в ядре должна быть её поддержка, для чего вносим в конфиг такую опцию:

options QUOTA

Надо заметить ещё такой момент, во FreeBSD есть ограничение, пользователь не может входить более чем в 16 групп, это очень старое ограничение, связянное каким-то боком с NFS. В данном случае, в процессе экспериментов, я в него очень быстро упёрся – согласно создаваемой системе, у каждого пользователя будет своя персональная группа, в которую кроме пользователя входит пользователь www – от него работает apache. Если его не включить в неё, то он не сможет читать файлы в дирекориях пользователя. При других раскладках – типа, все пользователи в одной группе – косяк с безопасностью – есть возможность, что прочтут чужие файлы. Поэтому пришлось найти где это ограничение забито и подправить. Это файл /usr/src/sys/sys/syslimits.h, в нем редактируем такую строку:

#define NGROUPS_MAX 64 /* max supplemental group id’s */

Из минусов – надо помнить про эту опцию, при обновлениях, ну и при передаче дел неплохо бы упомянуть. Вроде как с 7.0 должны сделать это ограничение “мягким” – можно будет его менять через sysctl. На данный момент, во всех версиях, его менять нельзя – переменная есть, но не меняется:

/usr/home/lissyara/>sysctl -a | grep ngroup
kern.ngroups: 16
/usr/home/lissyara/>sysctl kern.ngroups=64
sysctl: oid ‘kern.ngroups’ is read only
/usr/home/lissyara/>

Короче – ставим сколько надо (всё не тестил, но вроде как всё рабтает нормально, правда, для верности, пересобирал вообще всё – мир, ядро, и все установленные приложения. Каюсь – метод, всёже косячный, но умней ничё в башке не родилось, да и время поджимало). Пересобираем ядро. Это описано у меня, и в хандбуке. Пока ядро пересобирается, готовимся, надо подправить /etc/fstab. Правим строку, относящуюся к монтированию раздела где живут сайты пользователей. У меня, в итоге, оно выглядит так:

# устройство Куда моунтим ФС опции дамп
/dev/ad2s1e /usr/local/hosting ufs rw,userquota,nosuid 2 2

Также, добавляем такую строку в /etc/pw.conf, чтобы при создании пользователя, генерились рандомные пароли:

defaultpasswd=random

По окончании сборки ядра перезагружаемся, и снова пробуем запустить edquota – если пройдёт без ошибок – значит всё нормально. (не забываем добавить вышеописанную строчку про ‘enable_quotas=”YES”‘ в /etc/rc.conf!). Далее, я настругал небольшой скриптик, для администрирования всего этого добра:

#!/bin/sh -

# Скрипт для создания клиентской шары, и заведения нужного пользователя
# в системе. Написан lissyara 2006-10-02 – 2006-10-09 www.lisssyara.su

# Ограничения заводимого пользователя – сколько может занимать места,
# и сколько инод ему выделять (фактически, это – максимальное число файлов
# и директоий которые он сможет завести. Но не точно.
# Реально – может быть меньше). 0 – анлим.
user_datasize=”500000″ # В килобайтах в 4.11 и в Mb в 6.1, почему так -
# я не понял. будте внимательны.
user_inode=”100000″ # Иноды не резиновые. Оцените число командой
# `df -i` и решайте какие у вас должны быть лимиты
# Файловая система, на которую вносим ограничения
fs=”/usr/local/hosting”
# Данные для MySQL
mysql_user=”root”
mysql_passwd=”"

# Переменные:
domain_name=”$1″
user_name=”$2″

# программы
cat=”/bin/cat” # Перенаправление потоков ввода-вывода
awk=”/usr/bin/awk” # Язык обработки шаблонов
echo=”/bin/echo” # Вывод строк на экран
grep=”/usr/bin/grep” # Выбор строк по шаблону
pw=”/usr/sbin/pw” # Управление учётками, группами пользователей
rm=”/bin/rm” # Удаление файлов и директорий
mkdir=”/bin/mkdir” # Создание директорий
chown=”/usr/sbin/chown” # Выставление владельца файлов и директорий
php=”/usr/local/bin/php-cgi” # Бинарник PHP для использования в виде CGI
cp=”/bin/cp” # Копирование файлов и директорий
mysql=”/usr/local/bin/mysql” # MySQL – клиент
wc=”/usr/bin/wc” # подсчёт числа строк
cut=”/usr/bin/cut” # Обрезка строк
md5=”/sbin/md5″ # подсчёт md5 файлов, строк
jot=”/usr/bin/jot” # генерация случйного числа
tail=”/usr/bin/tail” # Показывает последнюю часть файла
edquota=”/usr/sbin/edquota” # редактор квот
ls=”/bin/ls” # Kbcnbyu диреткорий, файлов
chflags=”/usr/bin/chflags” # Утановка флагов на файл
tr=”/usr/bin/tr” # Замена, удаление символов в строке
mysqldump=”/usr/local/bin/mysqldump” # Содание дампов MySQL
gzip=”/usr/bin/gzip” # Архиватор
rm=”/bin/rm” # Удаление файлов и директорий
mv=”/bin/mv” # Перемещение файлов и директорий
basename=”/usr/bin/basename” # Вывод базового имени файла (из полного пути)
uname=”/usr/bin/uname” # Информация о локальной машине

# Файл с настройками php
php_ini=”/usr/local/etc/php.ini-for-hosting”
# Временный файл – для технических нужд
tmp_file=”/tmp/$$.file.tmp”
# Файл с системными альясами (для почты – отлупы на письма с сайтов будут
# возвращаться на этот сервер, надо их пересылать на пользователя, у меня
# забито как info@домен_пользователя)
aliases_file=”/etc/aliases” # На самом деле, во фре, это симлинк на
# файл /etc/mail/aliases.
# Директория хостинга
hosting_preffix=”/usr/local/hosting/sites”
# Директория для бэкапов удалённых сайтов
backup_dir=”/usr/local/hosting/backup”

# Строим префикс для работы с БД
query_preffix=”${mysql} –user=${mysql_user} –password=${mysql_passwd} \
–database=mysql”

# Проверяем наличие приложений – в разных версиях FreeBSD разные пути
for application in ${cat} ${awk} ${echo} ${grep} ${pw} ${rm} ${mkdir} \
${chown} ${php} ${cp} ${mysql} ${wc} ${cut} ${md5} ${jot} ${tail} \
${edquota} ${ls} ${chflags} ${tr} ${mysqldump} ${gzip} ${rm} ${mv} \
${basename} ${uname} ${php_ini}
do
if [ ! -s ${application} ]; then
echo “Приложение \`\`${application}” не найдено! Проверьте путь!”
exit
fi
done

# Поехали ))
case “$3″ in
create)

# Проверяем, не начинается ли имя пользователя с цифры (у `pw`, в этом случае
# будут проблемы с созданием группы пользователя. Либо руками, либо эта
# проверка. Я решил что лучше с цифры не начинать.)
${echo} “11111111111″ >> ${tmp_file}
${echo} ${user_name} | ${grep} -v “^[0-9]” > ${tmp_file}
# проверяем размер файла – не равен ли нулю
if [ -s ${tmp_file} ]
then
# Ничё не делаем
${rm} ${tmp_file}
else
# Пытаются пользователя с первой цифрой всандалить.
${echo} “Имя пользователя не может начинаться с цифры!!”
${rm} ${tmp_file}
exit
fi

# Проверяем, не содержит ли имя пользователя точки:
${echo} ${user_name} | ${tr} -d “[:alnum:]” | ${grep} “\.” > ${tmp_file}
if [ -s ${tmp_file} ]
then
# Пытаются пользователя с точками в имени всандалить.
${echo} “Имя пользователя не может содержать точки!!”
${rm} ${tmp_file}
exit
else
# Ничё не делаем
${rm} ${tmp_file}
fi

# Проверяем уникальность имени пользователя
${cat} /etc/passwd | ${awk} -F “:” ‘{print $1}’ | ${grep} “^[:alnum:]” |
{
while read existing_user_name
do
if [ ${existing_user_name} = ${user_name} ]
then
# Есть такой юзер. Ругаемся, выходим
${echo} “Пользователь с именем \”${user_name}\” существует!”
# пишем временный файл, чтоб передать инфу из цикла
${echo} 1 > ${tmp_file}
exit
fi
done
}
# Проверяем наличие и содержимое временного файла.
if [ -s ${tmp_file} ]
then
if [ `cat ${tmp_file}` -eq 1 ]
then
${rm} ${tmp_file} # удаляем временный файл
exit # выходим
fi
fi

# проверяем, нету ли такого виртуалхоста в apache
if [ -s ${hosting_preffix}/../httpd_configs/${domain_name}.conf ]
then
# Уже есть такой виртуалхост
${echo} “Хост с именем \”${domain_name}\” уже есть в конфиге!”
exit
fi

# такого пользователя нет – заводим в системе
user_passwd=”`${pw} useradd ${user_name} -c \”UserDomain = \
${domain_name}\” -L webuser -s /bin/csh -d ${hosting_preffix}/${user_name}`”
# Добавляем апаче в группу пользователя
${pw} groupmod ${user_name} -m www

# Создаём структуру директорий для пользователя
${mkdir} -p ${hosting_preffix}/${user_name}/log
${mkdir} -p ${hosting_preffix}/${user_name}/www
${mkdir} -p ${hosting_preffix}/${user_name}/cgi-bin
${mkdir} -p ${hosting_preffix}/${user_name}/tmp

# копируем файлы в CGI
${cp} ${php} ${hosting_preffix}/${user_name}/cgi-bin/
${cp} ${php_ini} ${hosting_preffix}/${user_name}/cgi-bin/

# Даём права на эти директории
${chown} -R ${user_name}:${user_name} ${hosting_preffix}/${user_name}

# Ставим флаги на php.ini
${chflags} sunlnk ${hosting_preffix}/${user_name}/cgi-bin/php.ini
${chflags} schg ${hosting_preffix}/${user_name}/cgi-bin/php.ini

# Добавляем пользователя в список тех, кто chroot`ится при
# заходе по FTP
${echo} ${user_name} >> /etc/ftpchroot

# Стругаем квоты для пользователя
${edquota} -e \
${fs}:${user_datasize}:${user_datasize}:${user_inode}:${user_inode} \
${user_name}

# Стругаем пароль для MySQL
mysql_user_passwd=”`${jot} -r 1 0 9000000 | ${md5} -p | ${tail} -1 \
| ${cut} -c 1-8`”

# Заводим пользователя в MySQL
${query_preffix} –execute=”CREATE DATABASE IF NOT EXISTS \`${user_name}_db\`”
${query_preffix} –execute=”GRANT ALL PRIVILEGES on \`${user_name}_db\`.* to \
‘${user_name}’@'localhost’ IDENTIFIED BY ‘${mysql_user_passwd}’”

# Создаём виртуалхост в апаче
${echo} “# Этот файл создан автоматически, скриптом `basename $0`

# Virtual host added by \`$USER\`, `date +%Y-%m-%d` in `date +%H:%M:%S`
# from host = \`$REMOTEHOST\`, host IP = \“echo $SSH_CLIENT | awk ‘{print $1}’`\`
ScriptAlias /cgi-bin/ ${hosting_preffix}/${user_name}/cgi-bin/
ServerAdmin support@${domain_name}
User ${user_name}
Group ${user_name}
DocumentRoot ${hosting_preffix}/${user_name}/www
ServerName ${domain_name}
ServerAlias www.${domain_name}
# Директория пользователя

Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order deny,allow
Allow from all

DirectoryIndex index.php index.html index.htm index.shtml index.php3
AddType application/x-httpd-php .php .php3
Action application/x-httpd-php /cgi-bin/php-cgi
ErrorLog ${hosting_preffix}/${user_name}/log/error.log
CustomLog ${hosting_preffix}/${user_name}/log/access.log common

” >> ${hosting_preffix}/../httpd_configs/${domain_name}.conf

# Создаём почтовый альяс для юзера (иначе его почта будет захламлять
# раздел /var). У меня стоит exim в простейшей (дефолтовой) конфигурации,
# т.к. мыльница для клиентов не на хостинге, а на отдельном сервере,
# и он работает с системными пользователями. Если будете делать по другому,
# перепишите этот кусок под себя.
$echo ”
# Alias for user = ${user_name}, domain = ${domain_name},
# added by \`$USER\`, `date +%Y-%m-%d` in `date +%H:%M:%S`
# from host = \`$REMOTEHOST\`, host IP = \“echo $SSH_CLIENT | awk ‘{print $1}’`\`
${user_name}: info@${domain_name}
” >> ${aliases_file}

${echo} “Имя домена: ${domain_name}”
${echo} “Имя пользователя: ${user_name}”
${echo} “Пароль пользователя(FTP, SSH): ${user_passwd}”
${echo} “Имя базы данных: ${user_name}_db”
${echo} “Пароль пользователя (MySQL): ${mysql_user_passwd}”
${echo} “Квота пользователя: ${user_datasize}”
${echo} -n “Альяс почты (${aliases_file}) ${user_name}@`${uname} -n`”
${echo} ” –> info@${domain_name}”
;;
delete)
${echo} “Вы действительно хотите удалить пользователя и домен?!”
${echo} “Наберите YES для подтверждения, или Ctrl+C для выхода…”
read confirmation
if [ $confirmation = YES ] > /dev/null 2>&1
then
# Подтверждено.
# Стругаем директорию
${mkdir} -p ${backup_dir}/${domain_name}
# снимаем флаги с директории юзера
${chflags} -R nosunlnk ${hosting_preffix}/${user_name}/*
${chflags} -R noschg ${hosting_preffix}/${user_name}/*
# Копируем содержимое
${echo} “Копируются пользовательские данные…”
${cp} -R ${hosting_preffix}/${user_name} \
${backup_dir}/${domain_name}
# Дампим БД пользователя
${echo} “Делается дамп БД пользователя….”
${mysqldump} –user=${mysql_user} –password=${mysql_passwd} \
–database ${user_name}_db | ${gzip} > \
${backup_dir}/${domain_name}/${user_name}_db.sql.gz
# Сносим всё нахрен:
# Перемещаем конфиг апача для этого домена
${mv} ${hosting_preffix}/../httpd_configs/${domain_name}.conf \
${backup_dir}/${domain_name}/
# Удаляем доки:
${echo} “Удаляются пользовательские данные…”
${rm} -Rf ${hosting_preffix}/${user_name}
# Удаляем БД
${echo} “Удаляется БД пользователя….”
${query_preffix} –execute=”DROP DATABASE IF EXISTS \
\`${user_name}_db\`”
# Удаляется пользователь из MySQL
${echo} “Удаляется пользователь из MySQL…”
${query_preffix} –execute=”REVOKE ALL PRIVILEGES \
ON *.* FROM ‘${user_name}’@'localhost’”
${query_preffix} –execute=”REVOKE GRANT OPTION \
ON *.* FROM ‘${user_name}’@'localhost’”
${query_preffix} –execute=”DELETE FROM mysql.user WHERE \
User=’${user_name}’ and Host=’localhost’”
# Удаляется пользователь из системы
${echo} “Удаляется пользователь из системы…”
${pw} userdel ${user_name}
${echo} “Удаляется группа пользователя из системы…”
${pw} groupdel ${user_name}
else
# не захотел удалять
${echo} “Пользователь и его сайт были оставлены”
fi
;;
update)
# Обновление версии php у всех пользователей.
${ls} ${hosting_preffix}/|
{
# идёт листинг сайтов, но т.к. имя пользователя и директории
# одинаковые – значит это ещё и именя пользователей
while read site_user_name
do
${echo} “Идёт обновление версии php для пользователя ${site_user_name}”
# Копируем новый
${cp} ${php} ${hosting_preffix}/${site_user_name}/cgi-bin/
# Даём права на него
${chown} ${site_user_name}:${site_user_name} \
${hosting_preffix}/${site_user_name}/cgi-bin/`${basename} ${php}`
done
}
${echo} “Обновление завершено!”
;;
*)

${echo} “”
${echo} “Этот скрипт создаёт пользователя в системе, генерит ему
пароль, создаёт базу данных MySQL, генерит для неё пароль,
выставляет квоты на использование ресурсов системы – на данный
момент все новые пользователи равноправны – смотрите в login.conf
класс ‘webuser’. Текущие ограничения:
Места: 500mb (правиться в этом файле)
Инод: 10000 (правиться в этом файле)
Процессов: 64 (правиться в login.conf)
Время работы процесса: 5 минут (правиться в login.conf)
Размер стека: 4mb (правиться в login.conf)
Размер блокируемой оперативки: 64mb (правиться в login.conf)
Макимальный объём оперативки: 256mb (правиться в login.conf)
Максимальный размер файла: 100mb (правиться в login.conf)
Открытых файлов на процесс: 1024 (правиться в login.conf)
Приоритет приложений: 20 (правиться в login.conf)

Внимание! На файл php.ini ставяться флаги \`schg\` и \`sunlnk\`,
не сняв их – файл не уалить и не изменить! Цель – не позволить юзеру
менять свои настройки php.
Удаление флагов:
chflags noschg php.ini
chflags nosunlnk php.ini
Установка:
chflags schg php.ini
chflags sunlnk php.ini
(Может понадобиться на случай если надо всё-таи чё-то поменять
в дефолтовом файле. Но не забывайте вернуть флаги!)

Также есть предложение придерживаться определённого именования
юзеров для их сайтов – типа если домен называется \`some.com\` то
юзер должен быть \`somecom\` – так понятней. Либо, как вариант,
завести таблицу, типа: 1- su, 2 – ru, 3 -com и т.п. и добавлять эти
цифры в конце. Кому как удобней будет. На данном сервере, под
FreeBSD 4.11, ограничение на длинну имени пользователя – 16 символов.
Если длинней – придётся обрубать с конца, или ещё как – чтобы не
совпадало с существующими.

Про удаление – перед удалением всё бэкаптся, кроме учётки пользователя.

Про обновления – имя пользователя и домен – любые. Нужно при обновлении
версии php на сервере. Обновляются все бинарники и перевыставляются права.

P.S. Не забывайте перезапускать апач после создания-удаления!”
${echo} “”
${echo} “Использование: `${basename} $0` \
{domainname username create|delete|update}” >&2
${echo} “”
exit 64
;;
esac

Можете воспользоваться моим, а можете делать всё руками – решать вам. Тока к скипту надо одно пояснение – он удалит любого системного пользователя, если по ошибке вы воткнёте его имя в качастве параметра с командой на удаление. Поэтому, если не понимаете, как оно работает – не надо пользоваться. Там есть защита от дурака, но от дурака умного. У меня он пашет, а как будет у вас – не знаю.
Небольшое замечание по поводу пути к файлу php.ini. В том файле, что копируется, я подправил лишь несколько пунктов, вот их настройки:

safe_mode = On
safe_mode_gid = On
disable_functions = system
# поправка – этот пункт лучше так не ставить – php некорректно
# это обрабатывает… может даже не php но у пары клиентов
# были проблемы с аплоадом файлов на сервер, пока
# не поставил абсолютный путь…
#upload_tmp_dir = ../tmp
session.save_path = ../tmp
session.auto_start = 1
upload_max_filesize = 4M
memory_limit = 64M

А вообще, возьмите файл /usr/local/etc/php.ini-recommended, и правьте его под свои нужды.
После проделанного, не забываем поставить парва на скрипт – в нём хранится рутовый пароль от MySQL (в принципе, можно заюзать флаг “-p”, чтобы запрашивал его каждый раз, или отдельную переменную, а потом подставлять её значение – смотрите сами.)

/usr/local/hosting/scripts/>chmod 700 create_client.sh
/usr/local/hosting/scripts/>chown root:wheel create_client.sh
/usr/local/hosting/scripts/>ls -alh create_client.sh
-rwx—— 1 root wheel 12K 24 окт 10:47 create_client.sh

Ну и пробуем скриптик:

/usr/local/hosting/scripts/>./create_client.sh testing.su testing create
Имя домена: testing.su
Имя пользователя: testing
Пароль пользователя(FTP, SSH): QBnOXa2k8DCnGY3
Имя базы данных: testing_db
Пароль пользователя (MySQL): 64cb2586
Квота пользователя: 500000
Альяс почты (/etc/aliases) testing@hosting.kontora.su –> info@testing.su
/usr/local/hosting/scripts/>
/usr/local/hosting/scripts/>
/usr/local/hosting/scripts/>
/usr/local/hosting/scripts/>
/usr/local/hosting/scripts/>./create_client.sh testing.su testing delete
Вы действительно хотите удалить пользователя и домен?!
Наберите YES для подтверждения, или Ctrl+C для выхода…
YES
Копируются пользовательские данные…
Делается дамп БД пользователя….
Удаляются пользовательские данные…
Удаляется БД пользователя….
Удаляется пользователь из MySQL…
Удаляется пользователь из системы…
Удаляется группа пользователя из системы…
/usr/local/hosting/scripts/>

Вот и всё. Соответствено, где надо подрихтуйте напильником под свои нужды (в 4.11 и 6.0 пару путей различаются), добавьте такие строки в конец конфига апача:

NameVirtualHost *:80

# Это первый виртуалхост – он должен быть этого сервера, т.к.
# иначе при обращении на несуществующие сайты будет выводиться
# самый первый виртуалхост – это может оказаться чей-то из клиентов,
# поэтому создаём скриптом, и копируем конфиг сюда.

ScriptAlias /cgi-bin/ /usr/local/hosting/sites/hosting/cgi-bin/
ServerAdmin support@hosting.kontora.su
User hosting
Group hosting
DocumentRoot /usr/local/hosting/sites/hosting/www
ServerName hosting.kontora.su
ServerAlias www.hosting.kontora.su
# Директория пользователя

Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order deny,allow
Allow from all

DirectoryIndex index.php index.html index.htm index.php3
AddType application/x-httpd-php .php .php3
Action application/x-httpd-php /cgi-bin/php-cgi
ErrorLog /usr/local/hosting/sites/hosting/log/error.log
CustomLog /usr/local/hosting/sites/hosting/log/access.log common

Include /usr/local/hosting/httpd_configs/*.conf

P.S.1 Настройки системы и php брались из головы, так, как я считал нужным. Может что-то и неправильно, или можно сделать лучше. Смотрите и думайте сами.
P.S.2 Насчёт ограничения в 16 групп и правки исходников – это правда плохая идея. Хотя проблем вроде нету. И если знаете, как можно сделать грамотней – поделитесь…
P.S.3 Настройки MySQL не рассмотрены сознательно, смотрите тут

Взято с lissyara.su

Пришла пора переходить на второй апач и пятый php (навеяно грядущим завершением поддержки php4 и будущим выходом php6). Пора ловить глюки на новой платформе Было решено заменить на своём сервере старую связку на более новую. Ввиду того, что все кричат более медленную работу php5 и apache2, да и крутится это будет не на FreeBSD 4.11, как в прошлый раз, а на FreeBSD 6.2, решил как-то всё это ускорить. Решение подсказали давно, тока опробовать не доходили руки. Дошли
Однако, предложенное там решение с полпинка не завелось – а разбираться было лениво – выходной всё же, порылся в портах, и нашёл другой модуль, его и будем ставить. Поехали – рихтуем /etc/make.conf, добавляем туда такие опции:

# default PHP version
DEFAULT_PHP_VER=5
PORTSDIR?= /usr/ports

# apache2
.if ${.CURDIR} == ${PORTSDIR}/www/apache20
# SSL – кому надо – включат – мне на этой машине не нужен
WITHOUT_SSL= YES
# Включение поддержки suExec
WITH_SUEXEC= YES
# Корневая директория suExec
SUEXEC_DOCROOT= /
# Cубдиректория пользователя
SUEXEC_USERDIR= www
# Файл лога suExec
SUEXEC_LOGFILE= /var/log/httpd/suexec.log
.endif

После чего ставим софт (подразумевается что установка чистая – иначе вначале снесите php4 и апачу 1.3) на машину. Апач:

host% make -C /usr/ports/www/apache20/ install clean

PHP:

host% make -C /usr/ports/lang/php5/ install clean

Лезет окошко, где выбираем такие опции – опять же – мне не нужна CLI версия, и я её не выбрал – вам может быть нужна:

+—————————————————————-+
| Options for php5 5.2.3 |
| |
|[ ] CLI Build CLI version |
|[X] CGI Build CGI version |
|[ ] APACHE Build Apache module |
|[ ] DEBUG Enable debug |
|[X] SUHOSIN Enable Suhosin protection system (not for jails) |
|[X] MULTIBYTE Enable zend multibyte support |
|[ ] IPV6 Enable ipv6 support |
|[X] MAILHEAD Enable mail header patch |
|[X] REDIRECT Enable force-cgi-redirect support (CGI only) |
|[X] DISCARD Enable discard-path support (CGI only) |
|[X] FASTCGI Enable fastcgi support (CGI only) |
|[X] PATHINFO Enable path-info-check support (CGI only) |
| |
| |
| [ OK ] Cancel |
+—————————————————————-+

Также ставим сам модуль mod_fastcgi:

host% make -C /usr/ports/www/mod_fastcgi install clean

Проверяем PHP:

host% echo ” | php-cgi
X-Powered-By: PHP/5.2.3
Content-type: text/html

test string
host%

Работает. Раскомментируем строчку установленного модуля в конфиге апача:

host% grep ” fastcgi_module ” /usr/local/etc/apache2/httpd.conf
LoadModule fastcgi_module libexec/apache2/mod_fastcgi.so

После чего в конец конфига апача дописываем такое:

# added by lissyara 2007-07-19 in 23:36

# конфиг модуля

# конфиг модуля.
# полный список опций – доступен по следующему адресу
# http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html
# тут приведены лишь те, которые я заюзал
# -singleThreshold – Целое число, мжду 0 и 100, используеммое
# для определения, может ли быть завершён последний экземпляр
# приложения FastCGI. Если менеджер процессов, вычисляет, что
# фактор загрузки для приложения меньше заданного порога, то
# последний экземпляр завершается. Для работы приложения в
# режиме “idle” долгого времени, вы должны задать значение
# ближе к 1, однако, если более приоритетна память, или время
# CPU, более применимо значение 100. Значение 0 предотвращает
# завершение последнего экземпляра приложения; это – значение
# по умолчанию, и менять его не рекомендуется (особенно, если
# установлена -appConnTimeout)
# -minProcesses – минимальное общее число динамических приложений
# FastCGI, разрешённых к работе в любое время, без убивания
# менеджером процессов.
# -restart – заставляет менеджер процессов повторно запускать
# приложения в случае сбоя (подобно статическим приложениям)
# -idle-timeout – число секунд бездействия приложения FastCGI,
# до прерывания запроса и логгирования события. Таймер бездейстаия
# применяется лишь к долго висящим соединениям приложений FastCGI.
# Если запрос будет находиться в очереди к приложению, но
# приложение не отвечает (путём записи и сброса) в течение этого
# периода, то запрос будет прерван. Если связь с приложением
# успешно завершается, но не завершается с клиентом, (ответ -
# buffered), таймаут не применяется.
# -killInterval – Определяет, как часто менеджером процессов
# применяется политика завершения динамических экземпляров
# приложения. Меньшее число приводит к более агессивной политике,
# большее – к менее агрессивной.
# -autoUpdate – вызывает проверку модулем mod_fastcgi проверку
# времени модификации приложения на диске до обработки каждого
# запроса. Если приложение на диске изменилось, уведомляется
# менеджер процессов и все работающие экземпляры программы
# уничтожаются. Вообще, предпочтительно, чтобы этот тип
# функциональности был встроен в приложение (например, каждый
# 100-й запрос проверяет, есть ли новая версия на диске, и выходит
# если это так). Могут быть ошибки, если эта опция применяется с
# опцией -restart
# -pass-header – имя заголовка запроса HTTP для передачи среде
# request. Эта опция делает доступным содержимое заголовков,
# которые обычно недоступны (например, Authorization) в окружении GCI.
FastCgiConfig -singleThreshold 30 -minProcesses 2 -restart \
-idle-timeout 400 -killInterval 200 -autoUpdate \
-pass-header HTTP_AUTHORIZATION
# используетс ядля включения враппера
FastCgiWrapper /usr/local/sbin/suexec
# директория где хранятся сокеты
FastCgiIpcDir /var/run/fastcgi
# предпринимаемые для такого типа файлов действия
Action application/x-httpd-fastphp /php-fcgi/php.sh
Action application/x-httpd-php /php-fcgi/php.sh
# добавляем типы файлов – у меня нету типа .php4 .php5 и т.д.
# если у вас есть – добавльте через пробелы в этой строке
AddType application/x-httpd-fastphp .php
# Обработка файлов апачем

Options ExecCGI FollowSymLinks
SetHandler fastcgi-script

# директория с данными

Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order deny,allow
Allow from all

# директория скриптов пользователя

AllowOverride None
Options None
Order allow,deny
Allow from all

# какие файлы считать индексными в директориях
# (выше, в конфиге есть такая же директива – я её закомментил)
DirectoryIndex index.php index.html index.htm

# включаем виртуалхосты основанные на именах
NameVirtualHost *:80

# первый виртуальный хост. Он будет показываться вместо всех
# несконфигирирвоанных виртуалхостов, при обращении к этому серверу

ServerAdmin admin@my-domain.ru
# AliasMatch ^/~([^/]+)(/.*)* /usr/home/$1/data$2
DocumentRoot /usr/home/my-domain/www/data
ServerName host.my-domain.su
SuexecUserGroup my-domain my-domain
Alias /php-fcgi/ /usr/home/my-domain/www/cgi-bin/
CustomLog /var/log/httpd/httpd-access.log combined
ErrorLog /var/log/httpd/httpd-error.log

# остальные сайты. Мне удобней, когда конфиги лежат в одном месте:
Include /usr/local/etc/apache2/configs/*.conf

Эти конфиги повторяют конфиг первого виртуалхоста, который приведён в предыдущем листинге. Где-то в процесе установки, не забываем создать юзера, от которого будет работать дефолтовый виртуалхост. У меня он называется ‘my-domain’. Также, для каждого виртуалхоста пишем скрипт такого виду:

host% more /usr/home/my-domain/www/cgi-bin/php.sh
#!/bin/sh

PHP_FCGI_CHILDREN=4
export PHP_FCGI_CHILDREN
#PHP_FCGI_MAX_REQUESTS=5000
#export PHP_FCGI_MAX_REQUESTS

exec /usr/local/bin/php-cgi

Делаем соответствующего пользователя его владельцем, и делаем его исполняемым:

host% chown my-domain:my-domain /usr/home/my-domain/www/cgi-bin/php.sh
host% chmod 555 /usr/home/my-domain/www/cgi-bin/php.sh
host%

Добавлям строчки в rc.conf:

# apache 2
apache2_enable=”YES”

Также, нужно в группу пользователя добавить пользователя www:

host% pw groupmod my-domain -m www

Остаются ограничения, описанные в прошлой статье – 16 групп, и, соответтсвенно максимум 15 пользователей. Лечится также – в исходниках ядра правим такую строку:

host% grep NGROUPS_MAX /usr/src/sys/sys/syslimits.h

Соответсвенно сюда вписываем нужное число, и пересобираем ядро. (Обещщают с семёрки сделать чтобы менялось штатными средствами, но пока не сделали…) Как вариант – возможно включение ACL на разделе – но это замедлит рбоату с ФС (не пробовал, но по идее должно замедлять ). Ну и всё. Можно создавать директорию для конфигов отсутствующих пока хостов, и запускать:

host% mkdir /usr/local/etc/apache2/configs
host% /usr/local/etc/rc.d/apache2.sh start
Starting apache2.
host% ps -aux | grep http
root 54653 0,0 1,1 4572 2872 ?? Ss 20:09 0:00,02 /usr/local/sbin/httpd
www 54654 0,0 1,1 4512 2828 ?? S 20:09 0:00,00 /usr/local/sbin/httpd
www 54655 0,0 1,2 4580 2904 ?? S 20:09 0:00,00 /usr/local/sbin/httpd
www 54656 0,0 1,2 4580 2904 ?? S 20:09 0:00,00 /usr/local/sbin/httpd
www 54657 0,0 1,2 4580 2904 ?? S 20:09 0:00,00 /usr/local/sbin/httpd
www 54658 0,0 1,2 4580 2904 ?? S 20:09 0:00,00 /usr/local/sbin/httpd
www 54659 0,0 1,2 4580 2904 ?? S 20:09 0:00,00 /usr/local/sbin/httpd
root 54661 0,0 0,2 1520 560 p1 R+ 20:09 0:00,00 grep http
host% ps -aux | grep php-cgi
my-domain 54663 5,1 4,1 17584 10440 ?? S 20:09 0:00,21 /usr/local/bin/php-cgi
my-domain 54662 1,6 2,6 14268 6676 ?? Ss 20:09 0:00,09 /usr/local/bin/php-cgi
my-domain 54664 0,0 2,7 14268 6688 ?? S 20:09 0:00,00 /usr/local/bin/php-cgi
my-domain 54665 0,0 2,7 14268 6688 ?? S 20:09 0:00,00 /usr/local/bin/php-cgi
my-domain 54666 0,0 2,7 14268 6688 ?? S 20:09 0:00,00 /usr/local/bin/php-cgi
root 54669 0,0 0,3 1604 880 p1 S+ 20:09 0:00,00 grep php-cgi
host% sockstat | grep /var/run/fastcg
my-domain php-cgi 54666 0 stream /var/run/fastcgi/dynamic/01922bbd806480551bf38bec
my-domain php-cgi 54665 0 stream /var/run/fastcgi/dynamic/01922bbd806480551bf38bec
my-domain php-cgi 54664 0 stream /var/run/fastcgi/dynamic/01922bbd806480551bf38bec
my-domain php-cgi 54663 0 stream /var/run/fastcgi/dynamic/01922bbd806480551bf38bec
my-domain php-cgi 54662 0 stream /var/run/fastcgi/dynamic/01922bbd806480551bf38bec
www httpd 54654 12 stream /var/run/fastcgi/dynamic/01922bbd806480551bf38bec
host%

Такой листинг вы увидите лишь если будет хоть одно обращение. Иначе – тока работающий апач. В случае любых проблем – уровень логов в конфиге – дебаг, и смотрим логи.

P.S. По итогам пары дней тестирования: Прилично быстрей чем в режиме чистого cgi.

Взято с lissyara.su

Установим Apache

urpmi apache

Сконфигурируем:

Поправим строчку listen

Listen 192.168.10.225:80

У меня 192.168.10.225 – внешний интерфейс, можно конечно оставить его слушать на всех интерфейсах по умолчанию.

Включим поддержку Virtual hosts. Сделаем Virtual host “test” допишем в конец

NameVirtualHost 192.168.10.225:80

Setenv VLOG

ServerName test

DocumentRoot /media/disk/out/self/sites/test

ErrorLog /media/disk/out/self/sites/test/test-error.log

CustomLog /media/disk/out/self/sites/test/test-custom.log common

DirectoryIndex index.php index.html index.htm

allow from all

</Directory>

</VirtualHost>

не забудем создать соответствующие файлы лога в DocumentRoot куда ссылается соответствующая директива.

Поправим /etc/hosts на машине с которой будем заходить (если мы домен “test” не зарегистрировали предварительно) наберем там

192.168.10.225 test

Дадим права пользователю apache на директорию test. Я это сделал с помощью ACL. (Насчет прав – можно )

setfacl -R -m u:apache:rwx test/
setfacl -R -m default:u:apache:rwx test/

Установим php

urpmi apache-mod_php

Установим поддержку mysql к php

urpmi -y php-mysql

Установим поддержку xml к php (нужно для появления функции utf8-encode)

urpmi php-xml

Остановимся немного подробнее на этом. В пхп существует некий набор модулей которые можно к нему подключать. В true варианте эти модули должны компилитьcя совместно с php движком – на выходе получим dynamic shared object – динамическую либу (с расширением .so), которую можно подключить уже напрямую к этому откомпиленному движку пхп. В мандриве все статические либы уже откомпилены. Достаточно просто набрать ее имя в инсталляторе и инсталлятор сам ее установит.

Фактически, инсталлятор, просто добавляет уже откомпиленную либу в /usr/lib/php/ (этот путь можно подсмотреть в заголовке Paths and Directories ) и пхп просто ее подгружает. В частности в нашем случае при загрузке пхп подключиются две либы которые нам нужны – xml.so и mysql.so.

После подключения либы в пхп появятся новые функции, в частности – функции работы с базой данных, или функция utf8-encode как в последнем случае.
Установим Mysql

urpmi mysql

Поменяем пароль к mysql (при новой инсталяции он пуст)

mysql -u root
use mysql
update user set Password=PASSWORD(‘new-password-here’) WHERE User=’root’;

где new-password-here – новый пароль на рута.

Жуки.

Как поменять пароль на рута, не зная рутовый пароль

Грузимся в безопасном режиме, меняем пароль.

mysqld_safe –skip-grant-tables & mysql –user=root mysql
mysql> update user set Password=PASSWORD(‘new-password-here’) WHERE User=’root’;
mysql> flush privileges;

Жуки.

Mysql не запускается – просит ввести hostname отличный от localhost.

Можно попробовать просто его поменять, но судя по всему баг сидит глубже ( https://qa.mandriva.com/show_bug.cgi?id=38398 )

По рецепту -

1. rpm -e mysql
2. rm -f /var/lib/mysql/mysql/*
3. /bin/hostname 127.0.0.1
4. urpmi mysql

Удаляем mysql если он есть чистим директорию от его либ и прочего, устанавливаем hostname 127.0.0.1 и ставим mysql заново.

Установим Phpmyadmin

urpmi phpmyadmin

Обратим внимание что при установке с помощью urpmi phpmyadmin создает свою рабочую директорию в директории апача по умолчанию.

Этой директорией будет /var/www/

Кроме того он создает конфиг файл в /etc/httpd/conf/webapps.d который собственно описывает то, где он находится.

доступен он будет с-нно после установки по адресу.

http://192.168.10.225/phpmyadmin/

Обратим внимание что я указал в качестве доменного имени простой ипишник – в этом случае ни один из Virtual hosts не сработает поскольку им нужно доменное имя описанное в их директивах, а сработает директива по умолчанию у которой DocumentRoot установлен на /var/www/ – собственно что нам и нужно.

Перенос сайта.

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

Лично мне это все было нужно для того чтобы перевести систему modx с хостинга на локальный сервер – чтобы поковыряться в ней не боясь уронить основной хост.

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

Заходим в интерфейс пхпмайадмин под рутовскими привелегиями, заходим в “Привилегии”, говорим создать нового пользователя. Вбиваем пароль, логин, создаем (например пользователя user).

Посмотреть под какими привилегиями движок коннектился к старой базе данных можно в файле config.inc.php который находится в manager/includes. Идем в “базы данных” создаем новую базу данных – одноименную с той что прописана в конфигах движка. Идем в привелегии, нажимаем рядом с нашим пользователем значок редактировать, “добавить привелегии на базу” – вбиваем имя базы данных, даем привилегии. Доступ – только с localhost. Привилегии я дал все кроме Администрирования.

Теперь делаем дамп базы данных с хостинга (я делаю под рутом, но это, собственно необязательно).

mysqldump -u root -p site_db > /home/igor/26_site_db.dump

Где site_db – база данных нашего сайта, /home/igor/ – директория куда делать дамп, 26_site_db.dump – имя дампа базы данных.

Копируем дамп на машину с поднятым mysql, копируем все файлы с сайта из корня.

Восстанавливаем дамп в нашу свежесозданную базу данных.

mysql -u user -p -D site_db < 26_site_db.dump

Ну вот и все. Теперь можно работать дальше.

Учтем только что при переносе базы данных может побиться кодировка. Перекодировать дамп базы можно функцией iconv.

По умолчанию наш мускль ставится в UTF8.

Взято с tht-s.ya.ru