Записи с меткой ‘directadmin’

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

Факты: DirectAdmin умеет ограничивать количество отправляемых писем в сутки с доменов пользователя, ограничение можно выставить общие для всех. С новой версией exim.pl, которая еще не идет со стабильным релизом DirectAdmin, можно задавать ограничения для определенного пользователя.

Мысли: например мы выставили ограничение в 500 писем в сутки, тогда эти 500 писем можно отправить все сразу, так и периодически. Из этого следует, что это не вариант предотвращения спама, потому что:

• все письма можно отослать сразу (спамеру этого вполне достаточно);
• так же есть веб ресурсы, которым требуется большое количество отправок корреспонденции и данное ограничение для них не подойдет.

Вывод: Хороший вариант – это ограничение количества писем в час, настраиваемое как для всех аккаунтов сервера, так и для определенного пользователя.

Решение: Все не только просто, а очень просто. DirectAdmin использует для подсчета количества писем и ограничение скрипт написанный на perl. Посмотрев содержимое /etc/exim.pl можно сразу найти функцию check_limits, где все и считается. Итак, открываем этот файл на редактирование и заменяем эту функцию с ее содержимым на:

sub check_limits
{
my $count = 0;
my $last_send = 0;
my $cur_time = 0;
my $diff_time = 0;

if (open (LIMIT, "/etc/virtual/limit_$name"))
{
$email_limit = int(LIMIT);
close(LIMIT);
}
else
{
open (LIMIT, "/etc/virtual/limit");
$email_limit = int(LIMIT);
close(LIMIT);
}

#find the curent user
$uid = find_uid();

#log_str("Found uid: $uid\n");

if (uid_exempt($uid)) { return "yes"; }

my $name="";

#check this users limit
$name = getpwuid($uid);

if (!defined($name))
{
$name = "unknown";
}

if ($email_limit > 0)
{
$last_send = (stat("/etc/virtual/usage/$name"))[9];

if ($last_send eq "")
{
open(USAGE, ">/etc/virtual/usage/$name");
close(USAGE);
chmod (0660, "/etc/virtual/usage/$name");
}

$time_lock = (stat("/etc/virtual/usage/$name.time"))[9];

if ($time_lock eq "")
{
open(TIMELOCK, ">/etc/virtual/usage/$name.time");
close(TIMELOCK);
$time_lock = (stat("/etc/virtual/usage/$name.time"))[9];
}

$cur_time = time;
$diff_time = $cur_time - $time_lock;
if ($diff_time >= 3600)
{
open(USAGE, ">/etc/virtual/usage/$name");
close(USAGE);
chmod (0660, "/etc/virtual/usage/$name");
open(TIMELOCK, ">/etc/virtual/usage/$name.time");
close(TIMELOCK);
}

$count = (stat("/etc/virtual/usage/$name"))[7];

if ($count eq "")
{
$count = 0;
}

if ($count > $email_limit)
{
die("You ($name) have reach your daily email limit of $email_limit emails\n");
}

open(USAGE, ">>/etc/virtual/usage/$name");
print USAGE "1";
close(USAGE);
chmod (0660, "/etc/virtual/usage/$name");
}

my $sender_address = Exim::expand_string('$sender_address');
my $mid = Exim::expand_string('$message_id');

log_bandwidth($uid,"type=email&email=$sender_address&method=outgoing&id=$mid");

return "yes"
}

Сохраняем файл и перезапускаем exim. Заходим в директорию /etc/virtual/ , создаем файл с названием limit_имяпользователя и вписуем в него цифрами количество писем в час, например 200. Далее идем в директорию /etc/virtual/usage/ и ищем файлы с именем пользователя. При отправке сообщения пользователем, например user, с домена, в директории появятся файлы:

user – в файле калькулируются количество писем, одно письмо = 1 в файле

user.bytes – логируются данные писем (пользователь, исходящее письмо или входящее и т.д.)

user.time – файл является точкой отсчета для проверки ограничения писем в час

Вот и все. Cтавьте, проверяйте и пользуйтеcь на здоровье.

Архив файла exim.pl можно скачать тут — ссылка

Не будем вдаваться в подробности, что такое MPM и с чем его едят, кому интересно –это сокращение от Multi-Processing Module. mpm-itk базируется на традиционном prefork MPM + добавлены некоторые функции, например возможность ограничения количества соединений на виртуальный хост, задание имени пользователя и группы от которой будет работать Apache на определенном виртуальном хосте и последнее свойство – задание приоритета работы в системе для виртуального хоста.

Итак, зачем нам нужно устанавливать этот MPM? Например:

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

2) исчезает головная боль у системного администратора с квотированием места для веб сайтов. Теперь файлы закачанные на сервер через веб интерфейс имеют владельца и группу пользователя, соответственно попадают в подсчет квоты.

3) приоритет процессов в системе. Очень удобно “душить” очень сильно грузящие сервер сайты

4) задание количества соединений на виртуальный хост – уходит сюрприз когда один сайт съедает максимальное количество соединений выставленных для всего сервера.

5) так как виртуальный сервер (домен пользователя) работает с правами пользователя, то возможно установить ограничение на процессорное время в системе.

Спросите почему не использовать тот же suphp? Причины: 1) у suphp есть куча ситуаций когда php код написанный под mod_php не работает. 2) suphp не работает с php кэшерами (eaccelerator, xcache и т.д.) 3) большая нагрузка на сервер

Итак, с плюсами разобрались, начнем установку. Первое это обновляем  apache и php в DirectAdmin до последней стабильной версии. Далее копируем архив apache с /usr/local/directadmin/custombuild , например в /usr/local/src, разархивируем его. Заходим на сайт разработчика mpm-itk: http://mpm-itk.sesse.net/ находим там diff файл и закачиваем его в директорию распакованного архива apache.

Запускаем patch, который внесет изменения в код:

#patch –p1 <apache2.2-mpm-itk-20090414-00.patch

Смотрим вывод и если ошибок нету то запускаем buildconf, он должен пройти без ошибок, если ошибки есть то смотрим что не хватает, например expat или autoconf, их нужно будет установить и повторить запуск buildconf. После этого архивируем директорию пропатченного apache:

#tar czf httpd-2.2.16.tar.gz httpd-2.2.16/

И копируем архив в директорию custombuild

#cp –f httpd-2.2.16.tar.gz /usr/local/directadmin/custombuild/

Переходим в директорию custombuild, снимаем md5 сумму с архива httpd-2.2.16.tar.gz и заменяем ею текущую md5 сумму в versions.txt

Приступаем к редактированию новых темплейтов для виртуальных хостов:

1) в директории /usr/local/directadmin/data/templates создаем поддиректорию custom и копируем в нее все virtual_host* конфигурационные файлы.

2) редактируем эти конфигурационные файлы, находи в них строку SuexecUserGroup и заменяем ее на AssignUserID.  Если планируете использовать директивы MaxClientsVHost и NiceValue, то добавляете их.

Теперь переходим к процессу установки нового Apache. Создаем в директории /usr/local/directadmin/custombuild директорию custom. Копируем в нее с директории configure директорию ap2. Редактируем скопированный configure.apache и добавляем в конец ключ «—with-mpm=itk», приступаем к сборке:

#/usr/local/directadmin/custombuild> ./build apache

Все, Apache пересобран, конфигурационные файлы изменены. Если у вас до этого были уже созданы пользователи и домены, то не забываем сбросить владельцев на файлах и директориях, и добавить секюрности:

# chown -R user1:group1 public_html
# cd public_html
# find . -type d -exec chmod 750 {} \;
# find . -type f -exec chmod 640 {} \;

Далее проверяем свою работу, создаем в директории любого домена php скрипт следующего содержания:

<?php system("id"); ?>

Смотрим результат через веб, при работе обычного Apache будет такой результат:

uid=1004(apache) gid=1004(apache) groups=1004(apache)

При правильной работе Apache с mpm-itk результат будет такой:

uid=1500(user1) gid=1500(group1) groups=1500(group1)

Удачи

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

cd /usr/local/directadmin/scripts
./move_domain.sh domain.com olduser newuser

вместо domain.com olduser newuser ставим свои значения, а то есть домен, старый владелец, новый владелец.

После переноса не забываем сменить владельца на файлы и директории перенесенного домена.

Язык php имеет бурное развитие и новые версии выходят довольно часто, поэтому вебмастера стараются держать свои программные продукты в актуальном виде. Не так давно свет увидела новая версия php 5.3. На сегодняшний день вышло уже 2 (два) обновления и версия php имеет номер 5.3.2.

Внимание: на данный момент Zend Optimizer не поддерживает версию php 5.3, поэтому если вы используете Zend на вашем сервере, то вы не должны обновлять php до версии 5.3, так как это приведет к неработоспособности ваших сайтов.

Итак, приступаем к настройке в DirectAdmin. Переходим в каталог: /usr/local/directadmin/custombuild . Забираем последние обновления софта с DirectAdmin: ./build update . Меняем версию php на 5.3 в файле options.conf переменная php5_ver или через интерактивную конфигурацию запустив команду: ./build options

После изменений можно приступать к пересборке php запустив команду: ./build php n

Стандартные сборки софта конечно же не каждому подойдут, поэтому после установки DirectAdmin или в дальнейшем нам потребуется сделать пересборку софта на свой вкус. Вы скажете что это очень просто, заходишь в директорию /usr/local/directadmin/custombuild/configure , далее переходишь в поддиректорию требуемого ПО, например php и правишь на свой вкус конфигурационный файл.

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

Начнем на примере пересборки php. Итак нам нужно чтобы в php была поддержка SOAP (php будет работать через suphp). Идем в директорию /usr/local/directadmin/custombuild, создаем там директорию custom, в нее копируем директорию suphp c данными с директории configure. И уже в скопированной вновь директории правим файлик configure.php5 (для php версии 5) или configure.php4 (для php версии 4). После добавления нужных опций пересобираем php средствами DirectAdmin.

А теперь все тоже самое, но в командах:

cd /usr/local/directadmin/custombuild

mkdir custom

cd custom

cp –R /usr/local/directadmin/custombuild/configure/suphp /usr/local/directadmin/custombuild/custom

cd /usr/local/directadmin/custombuild/custom/suphp

vi configure.php5

добавляем предпоследней строчкой «—enable-soap» \ и приступаем к пересборке php

cd /usr/local/directadmin/custombuild

./build php5-cgi n

Столкнулся с проблемой при снятии данных курса обмена через xml запрос. На машинке где все (apache, php, libxml и т.д.) собрано с портов все отлично работает, а на машинке где DirectAdmin, вместо данных получаю или пустую страницу или ругань о не возможности получить данные. Поковырявшись в скриптах сборки увидел, что libxml собирается по умолчанию без поддержки iconv.

Лечим так:

1) переходим в /usr/local/directadmin/custombuild, открываем на редактирование файл build, находим функцию doLibxml2() и меняем:

./configure —prefix=/usr/local —without-python

на

./configure —prefix=/usr/local —without-python –with-iconv

2) делаем пересборку libxml2: ./build libxml2 n

3) делаем пересборку php: ./build php5-cli n или ./build php5-cgi n, в зависимости от режима работы вашего php

Перезапускаем apache и проверяем работу скрипта.

Итого: так как разработчики DirectAdmin не знают другого языка как английский, то ничего удивительного нет в том, что iconv им не нужен.

Для смены пароля на почту используйте URL такого типа:

http://mydomain:2222/CMD_CHANGE_EMAIL_PASSWORD

где mydomain смените на название вашего доменного имени или IP адрес сервера, ну и протокол http или https.

В открывшемся окне указываете свой email адрес, текущий пароль и новый пароль два раза. На этом можно считать ваше задание выполнено :)

Если вы на этой странице, то вы уже столкнулись с вопросом настройки SSL для DirectAdmin. Эта статья никоим образом не относится к настройки SSL для apache.

Итак как же это сделать? Все элементарно и просто, генерируем само подписанный SSL если у вас его нету:

/usr/bin/openssl req -x509 -newkey rsa:1024 -keyout /usr/local/directadmin/conf/cakey.pem -out /usr/local/directadmin/conf/cacert.pem -days 9999 -nodes

настраиваем права на файлы:

chown diradmin:diradmin /usr/local/directadmin/conf/cakey.pem
chmod 400 /usr/local/directadmin/conf/cakey.pem

Если у вас уже есть SSL сертификат и ключ, то скопируйте их так:

сертификат:   /usr/local/directadmin/conf/cacert.pem

ключ: /usr/local/directadmin/conf/cakey.pem

Если есть CA Root Certificate, то копируем его в: /usr/local/directadmin/conf/carootcert.pem

Далее прописываем в конфигурационном файле DirectAdmin:

SSL=1

и если есть подписанный сертификат и ключ и CA Root, то добавляем еще и

carootcert=/usr/local/directadmin/conf/carootcert.pem

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