Рубрики
Наследие

Восстановление сервера после взлома

Итак, рассмотрим на примере сервера, который был взломан путем закачки эксплоита через ошибку в php скрипте, запуск через него же и получение доступа к shell с правами веб-сервера. Об этом красноречиво свидетельствуют «следы» в директориях, доступных на запись для всех: /tmp, /var/tmp, /dev/shm.
Взлома можно было бы избежать на этом этапе, примонтировав разделы для временных файлов без права запуска, отключением опасных функций php и просто более тщательным кодом в php. Однако ничего этого сделано не было.
Хакер не терял времени даром. Он закачал разнообразные эксплоиты, скомпилировал их и после запуска получил права суперпользователя root, воспользовавшись одной из уязвимостей.
И на этом моменте можно было бы его остановить, отключив wget и компиляторы для непривилегированных пользователей и поставив патч, запрещающий выполнение кода в стеке или libsafe. Но, увы, и это не было сделано.
Ситуация была неоднозначной. С одной стороны — очень важные данные, потеря которых критична, с другой стороны — проблема backdor, когда хакер мог бы зайти с помощью какого-то пользователя или выслав определенный набор пакетов демону, слушающему порт. Было принято решение о восстановлении сервера и дальнейшем тщательным наблюдении за ним.
Отключив ряд процессов, которые явно носили в себе нечто чуждое системе, первым делом был установлен, обновлен и запущен rkhunter — утилита для отлова троянов.
Вывод rkhunter был неутешительный — минимум два руткита, масса измененных бинарников.
В такой ситуации поможет только одно — замена зараженного руткитом бинарника на чистый. Однако необходимо знать, какие именно бинарники заменять. Но тут немного повезло. Хакер поставил на измененные файлы атрибуты, запрещающие изменение, удаление или замену файла при помощи команды chatter. Для неофитов, знакомых только с chmod, это создало бы эффект контроля над системой со стороны хакера — зараженные бинарники не переписываются, хотя права на запись стоят.
Создав список зараженных бинарников, все атрибуты удалось восстановить командами

chattr -iacsuASDd /bin/*
chattr -iacsuASDd /sin/*
chattr -iacsuASDd /sbin/*
chattr -iacsuASDd /usr/sbin/*
chattr -iacsuASDd /usr/bin/*
chattr -iacsuASDd /usr/local/bin/*
chattr -iacsuASDd /usr/local/sbin/*

Однако ряд бинарников, которые не были защищены от изменения, все-таки были заражены. Это показал rkhunter. Таким образом, стало ясно, что это неординарный взломщик, который специально оставил взломанные файлы с целью их восстановления. Соответственно, в системе установлен backdor.
Также не работал ряд команд, хотя rkhunter этого не показал. Например, top не выводил ряд присутствующих в системе процессов. По всей видимости, заражение было на уровне модуля ядра, что обеспечивало стелс-защиту зараженных бинарников.
Однако хакер не предусмотрел, что в rpm-based дистрибутивах Linux есть возможность узнать, был ли изменен файл или нет при помощи rpm.
Методика достаточно проста — сначала узнаем, где расположен подозрительный бинарник, например:

which top

Эта команда выдаст полный путь к утилите top — /usr/bin/top. Теперь с помощью rpm узнаем, к какому пакету относится данный файл:

rpm -qf /usr/bin/top

Эта команда сообщит, что утилита top входит в пакет procps. Переустановим его с помощью менеджера apt командой:

apt-get --reinstall install procps

Во время установки было сообщение, что предыдущий top был слинкован с библиотекой /lib/libext-2.so.7. Возможно, это и есть часть стелс-механизма. Запросив с помощью rpm информацию об библиотеке

rpm -qf /lib/libext-2.so.7

была получена информация, что данный файл не является частью системы. Естественно, что он был удален:

chattr -iacsuASDd /lib/*
rm /lib/libext-2.so.7

Далее обнаружилось несколько скрытых процессов, которые были убиты с помощью утилиты killall.
Естественно, что переустановить пришлось не только procps, но и ряд других пакетов, подозреваемых во взломе: util-linux, psmisc, net-tools, kernel, dev, initscripts и многие другие.
После замены ядра сервер был перезагружен и была проведена проверка изменения всех файлов с помощью команды

rpm -Va

Были замечены косвенные признаки наличия в системе backdor. После небольшого исследования системы бэкдор был обнаружен. Также было обнаружено, что у всех системных пользователей сменена оболочка на /bin/sh. Таким образом, это позволяло обратиться к backdor от имени любого пользователя. Для избегания такой ситуации был отключен ряд нежелательных сервисов и создан новый пользователь, который может заходить по сети в оболочку через ssh. Все остальные были отключены.
В настоящее время не замечено никаких попыток несанкционированного доступа, что свидетельствует о весьма высоком уровне взломщика и нежелании его засветиться.

Данная история описана с согласия владельца взломанного сервера. По его словам, все что он сделал, это добавил поддержку php в apache. О том, к каким последствиям это может привести, он даже и не подозревал.

Будьте бдительны! Во время летних каникул происходит очень много взломов. Защищайте свой выделенный сервер до того, как его взломают. Предотвращайте взлом на разных уровнях. И главное — периодически проверяйте содержимое каталогов для временных файлов. Возможно, что там уже что-то есть.
Особенно остерегайтесь файлов, начинающихся с точки или состоящих из одних пробелов, — это прямое свидетельство успешного взлома.

Рубрики
Наследие

Борьба со спамом от nobody — sendmail warper.

Очень важно знать, кто и сколько отсылает почты, так как держать спамера у себя на сервере опасно, так как дата-центры запросто закрывают такие серверы. Особенно важно контролировать отправку с сервера с помощью sendmail различными скриптами.
Обычный лог MTA не может помочь, так как не показывает, откуда было обращение к sendmail.

Для начала необходимо остановить MTA, затем переименовать и переместить бинарник sendmail, например, в /bin/xyz.
После этого создать скрипт вместо sendmail:

#!/usr/local/bin/perl

# use strict;
use Env;
my $date = `date`;
chomp $date;
open (INFO, ">>/var/log/spam_log") || die "Failed to open file ::$!";
my $uid = $>;
my @info = getpwuid($uid);
if($REMOTE_ADDR) {
print INFO "$date - $REMOTE_ADDR ran $SCRIPT_NAME at $SERVER_NAME n";
}
else {
print INFO "$date - $PWD - @infon/n/n";
}
my $mailprog = '/bin/xyz';
foreach (@ARGV) {
$arg="$arg" . " $_";
}

open (MAIL,"|$mailprog $arg") || die "cannot open $mailprog: $!n";
while ( ) {
print MAIL;
}
close (INFO);
close (MAIL);

Затем создать лог-файл, который будет содержать историю обращения к sendmail:

touch /var/log/spam_log
chmod 0777 /var/log/spam_log

Step 7)

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

Рубрики
Наследие

Брендинг хостинга

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

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

Ваш бренд должен быть нечто большим чем простым логотипом на сайте или на визитке. Это некоторый уникальный идентификатор, которы позволит выделить Вас среди множества других хостингов.
Бренд хостинга понятие не материальное. Это совокупность уникальности услуг, которые хостинг предоставляет клиентам. Чем больше довольных клиентов, тем более ценным становится бренд.
А ценный бренд предоставляет множество преимуществ. Что толкает потребителя на покупку одежды в фирменных магазинах? Только ценный бренд, который компенсирует высокую стоимость.
Таким образом, доход от хостинга может существовать только за счет синергии продвижения брендинга и качественных услуг.

Почему нужно создавать свой бренд.

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

Маркетинг, маркетинг и еще раз маркетинг.

Еще одной хорошей причиной создания собственного бренда является сила продажи, и эта сила работает на Вас более эффективно благодаря бренду.
Представьте себе, что вы бы не могли тратить первую половину своего времени на раскрутку и рекламные компании, на создание пресс-релизов и пиара. Почему бы не предоставить развитие коммуникационной силы за счет брендинга хостинга. Ценный бренд у всех на слуху и одно его упоминание ассоциируется у клиентов с ответами на их вопросы.
Еще одно преимущество брендинга это возможность раширения спектра сервисов, косвенно связанных с хостингом. Это может быть студия дизайна, системы управления сайтами и многое другое.
Все это, выпущенное под брендом хостинга автоматически переносит все положительные качества, всю ценность в глазах потенциального клиента на новую продукцию и услуги. Таким образом, собственный бренд — это путь к расширению спектра продукции и услуг.

Как создать свой бренд

Итак, бренд необходим. Но что нужно для его создания?
Следует исходить из того что бренд должен говорить кто Вы, что Вы делаете и как. Это необходимо для создания всех тех факторов, которые установят доверительные отношения между хостингом и клиентами. Не требуется говорить что отношения — это наиболее важный аспект, и создавая свой бренд Вы создаете эти отношения. Второй аспект создания бренда — это точнее соответствие всем требованиям потенциальных клиентов. Если Вы чувствуете что не можете предоставить требуемые услуги клиентам, то следует пересмотреть целевую группу или собственную стратегию.
Залог успешного бренда — это доверие клиентов и способность удовлетворить требованием потенциальных клиентов.

Миссия невыполнима

Опишите свою миссию — основные ценности своего хостинга. Какие они? Для понимания этого попробуйте почувствовать себя в качестве своего потенциального клиента. Поставьте себя на место целевой аудитории. Вам нужен вебхостинг. Вы готовы купить хостинг, но какие преимущества может предоставить именно этот, Ваш хостинг?
Не следует в первую очередь смотреть на цены. Они могут быть высокими благодаря расходам на организацию многоканальной телефонной поддержки клиентов 24 часа в сутки или внедрением ноу-хау, не имеющего аналогов у конкурентов.
Как на счет разнообразных дополнительных преимуществ хостинга? Нужна ли Вам, как клиенту возможность создания неограниченного числа почтовых ящиков или больше вожна возможность запуска cgi-скриптов на самом низкобюджетном тарифном плане? Или больше важны такие вещи как русскоязычная панель управления? Возможность использования SSL или организации своих листов рассылки?
Одни вещи важны для разных целевых групп и менее важны для других. Таким образом необходимо сфокусировать все свои приемущества, которые максимально соответствуют Вашей целевой группе. Так же присмотритесь к ценовой политике, времени отклика и информативности службы поддержки.

Вас, как потенциального клиента может привлечь сообщение вроде гарантируется аптайм 99%, 24-х часовая поддержа и возврат денег в 15-ти дневный срок.
Однако это лишь общее описание. Удалите из него все, что Вы не сможете обеспечить и добавьте свое, то что отличает Ваш хостинг от других. Сфокусируйте описание своей мисси так, чтоб максимально соответствовать выбранной целевой группе.

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

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

А кто наши клиенты?

После создания бренда самое время начать повышать его ценность среди определенного круга людей. Но как узнать кто именно является потенциальным клиентом?
Персонализаця — это путь с помощью которого можно наиболее эффективно продвигать бренд. Узнайте о своих клиентах все. Выясните к какой социальной группе они принадлежат, какие у них общие увлечения, проблемы. Найдя определенный сегмент, который соответствует целевой группе необходимо продвигать его именно в этом сегменте. Не стесняйте себя в способах выражения!
Ваш сегмент — это любители экстремальных видов сорта? Бренд размещенный на парашюте способен привлечь множество клиентов, а для любителей дайвинга приятным сюрпризом будет бренд, выложенный цветными ракушками на песчаном дне.
Нестандартный подход может быть очень эффективный.

А вот мне друг сказал…

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

Отличайтесь от других. Не пытайтесь охватить все. Будьте целеустремленны. И у Вас все получится. Удачи!

Рубрики
Наследие

Как создать свой хостинг

Первая статья из цикла свой хостинг.

Вопросов при создании собственного хостинга больше чем ответов. Но мы постораемся упорядочить их и ответить на самые важные.
Каждый, кто хочет создать свой хостинг должен понимать, что веб хостинг не принесет прибыль сразу после основания. Наоброт, потребуется запастись финансами, терпением, знанием англиского языка. Это потребуется для изучения документации к панелям управления.
Изучив все приемущества и недостатки каждой, можно приступать к наиболее простому этапу — получение сервера с предустановленной панельью. Однако это не означает что сама задача проста. Наоборот, это самый ответственный этап. Грамотный выбор сервера и площадки для его размещения и понимание того, что панели управления хоть и позволяют начать создание хостинга однако накладывают свои ограничение — все это надо понимать до начала создания своего хостинга

Время — это самый ценный ресурс

Сколько времени планируется уделить хостингу? День за днем, клиенты будут приходить и требовать поддержку. Требовать ее 24 часа в сутки, 7 дней в неделю, по телефонам, ICQ и почте.
Готовы ли Вы сами не спать и заменять собой службу поддержки и менеджеров? Поддержка — это очень важный ключевой аспект для старта собственного хостинга. Так как хостинг — это не место на сервере а прежде всего информационная услуга.
Первый вопрос, на который надо дать себе ответ — смогу ли я оказать поддержку клиентам?

Знания приходят со временем

Насколько Вы знакомы с программной и аппаратной частью?
Очень важно быть знакомым с ПО, установленном на дедике, которое используется для хостинга клиентских сайтов. Например, для вебсервера IIS под управлением MS Windows необходимо не просто его установить, а прочитать несколько книг по настройкам как Windows так и IIS. Так же необходимо быть в курсе возможностей, уязвимостей и всегда следить за установкой последних обновлений.
Для создания хостинга на Unix/Linux платформе необходимо уметь управлять системой с помощью консоли и иметь базовые представления о том как работает система.
Конечно, каждая панель управления имеет свой собственнный набор средств для облегчения управлением хостингом, однако это не отменяет требования к знаниям об аппаратной и программной части хостинга.

Время помноженное на знанание приносит доход

Для того, что бы что-то заработать сначала необходимо вложить свои деньги, время и знания. Вы готовы вкладывать начальный капитал в долгий путь хостинга? Множество разнообразных вещей потребуют серьезный финансовых вливаний на начальном этапе создания собственного хостинга.
Следует очень хорошо понимать, что аренда сервера хорошего сервера и удобная панель не могут быть дешевыми. А следвательно клиенты хостинга размещение сайтов обойдется не дешево. Множество хостинг компаний размещают сайты клиентов на серьезных серверах вроде Dual Opteron с 16Gb RAM. Для конкуренции с ними потребуется более-менее серьезный выделенный сервер. И Celeron’а с 512Mb RAM будет явно недостаточно.
Другой, недорогой путь — это стать партнером (ресселером) уже известной хостинг компании, взяв у них часть сервера. Это более простой путь для старта своего хостинга и многие известные сейчас хостинг-провайдеры начинали свой путь имено с ресселерства. Это требует минимальных начальных вложений, однако имеет свои недостатки.
Это полное отсутсвие контроля за сервером, невозможность поставить ПО, которое требуют клиенты, риск сбоя, и невозможность перезагрузить сервер или рестартовать упавший сервис. Таким образом под угрозой стоит репутация, самое ценное что есть хостинга.

Нанимаем сотрудников?

Вы собираетесь нанимать сотрудников в начале или будете в одиночку поддерживать свой хостинг? Путь одиночки — хорошее решение с финансовой стороны, но требует значительных временных затрат. А время стоит дороже денег.
Отсутствие сотрудников означает что придется решать как технические так и организационные проблемы, и вообще со всеми трудностями придется сражаться в одиночку. Иногда такая битва может положить конец хостингу, и Вы будете проигавшей стороной.

Не страшно?

Ну тогда продолжим.

Регистрация Имени хостинга

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

Заказ выделенного сервера

Вы можете заказать свой сервер и поставить его на площадку провайдера (коло). В этом случае месячная оплата будет ниже чем в случае аренды выделенного сервера, однако следует учесть что сервер — это не персональный компьютер и стоит достаточно дорого, особенно если это бренд.
Каждый Дата Центр, который предоставляет выделенные сервера в аренду или коло так-же предоставляет соеденение с сетью и определенный лимит траффика, пропускную способность или определенное соотношение входящего/исходящего траффика.
У начинающих хостингов сайтов мало и они могут объявить что траффик «неограничен», однако всегда может найтись тот кто сможеть его использовать для перекачки медиа-файлов и исчерпать его полностью.

ДатаЦентр

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

Это только первые шаги создания своего хостинга. Маркетинг хостинга это более сложная часть, онако к выделенным серверам она отношения не имеет. Так же мы не рассматривали аутсорсинг, когда часть работы осуществляется специальными компаниями за определенную оплату — телефонные операторы, удаленные администраторы и многое другое.
Конкурениця большая и потребуется немало дополнительных оригинальных сервисов для привлечения клиентов.

Хостинг — это крепкий орешек, разрызть который под силу не каждому.

Рубрики
Наследие

Оптимизация трафикогенерирующих серверов

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

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

Проблемы, с которыми сталкиваются владельцы трафикогонных серверов, достаточно типизированы.
Это прежде всего проблема активного свопа, когда жесткий диск используется процессами, требующими слишком много оперативной памяти.
Это загрузка CPU, которая возникает из-за плохо оптимизированных скриптов и баз данных.
И, наконец, сетевые проблемы — ограничения, накладываемые железом, и разного рода атаки.

Для проверки сервера можно использовать такие утилиты, как vmstat, top, ps, netstat. Они позволяют выявить причины низкого КПД сервера — утилизация CPU, памяти, системы ввода/вывода или сеть.

Типичная проблема — это активное использование оперативной памяти веб-сервером apache. При запуске команд ps ax или top сразу можно увидеть, как процессы apache отнимают память. Эта, на первый взгляд, незначительная проблема может стать значительной, после того как apache вытеснит все процессы в своп и в результате сервер будет настолько загружен, что придется его перезапускать.

Если веб-сервер служит для отдачи статической информации, то каждый процесс apache занимает 2-3 Mb памяти.
Если же сервер содержит 99% статической и информации и 1% динамической, то каждый процесс занимает 3-20 Mb, комплексно завися от наиболее частовызываемых динамических страниц.
Это происходит, потому при выполнении скриптов память увеличивается и не возвращается к изначальному состоянию, когда скрипт отработал. Если сервер генерирует много трафика и содержит в себе большинство динамических страниц, стоит подумать о замене их предгенеренными статическими страницами, производством которых будет заниматься отдельный процесс (демон).

Также следует обратить внимание на опцию KeepAlive. Это неоднозначный параметр. С одной стороны, он позволяет обработать одному процессу несколько запросов, а с другой стороны, за считанные секунды разрастается и занимает очень много памяти. Однако KeepAlive позволяет ускорить загрузку страниц, особенно когда они содержат много статических файлов вроде картинок.
Разумным решением в этом случае будет включить KeepAlive и ограничить время 1-2 секундами (с помощью параметра KeepAliveTimeout).

Лимит одновременных подключений к apache MaxClients.
Если apache используется для отдачи динамического контента, то число одновременных подключений следует увеличивать крайне осторожно, так как может произойти активный своп, резкое падение скорости и, в конце концов, apache упадет.
Для предотвращения такой ситуации необходимо выполнить ряд мер.
Сначала нужно выставить максимально возможное число подключений к apache, а также опытным путем с помощью бенчмаркинга ab выставить StartServers, MinSpareServers и MaxSpareServers. Затем определить убийство процесса при превышении одновременных подключений с помощью MaxRequestsPerChild. Это уменьшит вероятность того, что скрипт исчерпает всю память. Последний параметр наиболее неоднозначный, так как с его помощью можно значительно уменьшить расход памяти, но в то же время неправильные настройки способны вызвать активный своп.

Обычно ограничение одновременных подключений в 20 дает неплохой результат, однако оно не фиксировано и зависит от состояния сервера. Необходимо самостоятельно определить оптимальное значение, изучая вывод команды ps axu --sort:rss.
Результаты могут быть ошеломляющие, но, к сожалению, непостоянные. Необходимо следить за сервером и помнить, что перед тем, как увеличить MaxRequestsPerChild, стоит увеличить MaxClients.

При размещении нескольких трафикогенерирующих сайтов вроде галерей, сайтов для загрузки файлов и т.п. можно расширить за счет параллельной обработки сайта несколькими веб-серверами, а также за счет кэширования.
Путь параллельной обработки заключен в использовании более легких веб-серверов для отдачи статического контента – картинок, html страниц и т.п., в то время как apache будет обрабатывать динамические страницы и php скрипты.
Неплохим выбором легкого веб-сервера будет:

К недостаткам такого метода следует отнести невозможность обработки файлов .htaccess со всеми вытекающими последствиями: паролированием, правилами для mod_rewrite и т.п.
Для решения этой проблемы придется отказаться от .htaccess и все директивы прописывать в виртуальном хосте Apache.

Оптимальный путь – это генерация статических страниц и замена apache на более легкий веб-сервер.
Для реализации этого механизма необходимо использовать Apache только внутри сервера, периодически обновляя динамические страницы, например, с помощью wget . Отдачу же следует производить веб-серверами, которые не используют блокировку операций ввода-вывода и обрабатывают все запросы в одном процессе:

Решением для оптимизации PHP скриптов может служить любой php-акселератор, например, Turck MMCache, который, кстати, используется на этом сервере. Кроме него существуют также и другие php-акселераторы: APC, Zend и пр. Использование акселераторов даст возможность увеличить скорость отдачи php-скриптов, уменьшение загрузки CPU, однако это потребует расхода памяти для хранения кэшированых скриптов.
Для оптимизации базы данных прежде всего необходимо выяснить, что же приводит к замедлению – неправильная конфигурация или отдельные неоптимизированные запросы. Следует учесть, что один такой запрос, отнимающий 5% CPU и 5% памяти, может привести к катастрофическим последствиям в случае одновременного вызова сотни-другой таких запросов. Для поиска медленных запросов поможет опция log-slow-queries=/var/log/slow.log, которую необходимо добавить в файл настроек mysql — /etc/my.cnf, и перезапустить mysql.
После чего необходимо проанализировать медленные запросы и оптимизировать их.

Производительность можно повысить только комплексным методом. В руководстве уделено внимание именно такому подходу. Если Вы не знаете некоторых нюансов, не стесняйтесь спрашивать.

Рубрики
Наследие

Восстановление прав на пользовательские директории

Очень часто после восстановления из бэкапов «теряются» владельцы файлов. Особенно этим страдает cPanel. Симптомы — не работают запароленные .htaccess, не подходят пароли к ftp и т.п.

Для быстрого восстановления необходимо выполнить следующие команды под суперпользователем в оболочке bash:

cd /home
for i in `ls`; do chown -R $i $i; done

Рубрики
Наследие

Экстренный бэкап всех аккаунтов

Если выделенному серверу грозит отключение или выход из строя, самое главное — не паниковать. Необходимо создать ftp-аккаунт где-то на резервном сервере и скопировать туда все аккаунты.

Приступаем к созданию резервных копий:
for i in `ls /home/`; do [ -d "/home/$i" ] && /scripts/pkgacct `basename $i /`; done
А теперь быстро закачиваем их на резервный сервер:
ncftpput -u логин -p пароль хости ./ /home/*.gz.

Рубрики
Наследие

Перенос аккаунтов из Direct Admin в WHM/cPanel

Скрипт для переноса учетных записей из DirectAdmin в cPanel, написаный SkyHorse.

На данный момент не существует готовых надежных решений по переносу сайтов из Directadmin в cPanel, скрипт служит только частичным решением.
Скрипт работает с файлами в каталогах backup и domains.
После обработки скриптом файл tar.gz необходимо развернуть, только на новом аккаунте в cPanel.
Скрипт позволяет перенести:

  • квоты;
  • почту IMAP;
  • настройки squirrelmail;
  • все каталоги сайтов из стиля DirecAdmin в стиль cPanel.

Скрипт не переносит:

  • FTP;
  • субдомены;
  • DNS записи;
  • все остальное.

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

Сам скрипт:

# bash
# Copyleft (C) SkyHorse 2004
# for each account:
# put passwd as passwd + shadow
# quota (if != 0)
# into ~/etc/%domain%
GENDOMAIN=domain.com
GENUSERNAME=accuser
NEWACCPASS=accpass
MYFILESPATH=/home/skyhorse/temp_sites

mkdir result
mkdir result/mail
mkdir result/mail/$GENDOMAIN
mkdir result/etc
mkdir result/etc/$GENDOMAIN

cp $MYFILESPATH/$GENUSERNAME/backup/$GENDOMAIN/email/quota result/etc/quota
chmod 644 result/etc/quota

touch result/etc/shadow
chmod 640 result/etc/shadow

touch result/etc/passwd
chmod 644 result/etc/passwd

chmod 660 $MYFILESPATH/$GENUSERNAME/backup/email_data/imap/*
cp $MYFILESPATH/$GENUSERNAME/backup/email_data/imap/* result/mail
cp $MYFILESPATH/$GENUSERNAME/backup/email_data/pop/$GENUSERNAME result/mail/inbox
chmod 660 result/mail/inbox

mkdir result/.sqmaildata
cp $MYFILESPATH/$GENUSERNAME/backup/email_data/squirrelmail/* result/.sqmaildata

ENTRY=`cat $MYFILESPATH/$GENUSERNAME/backup/$GENDOMAIN/email/passwd`
for line in $ENTRY
do
login=`echo $line | sed s/[:].*//`
pass=`echo $line | sed s/.*[:]//`
mkdir result/mail/$GENDOMAIN/$login
mkdir result/mail/$login

echo $login:x:32120:622::/home/$GENUSERNAME/mail/$GENDOMAIN/$login:/usr/local/cpanel/bin/noshell >> result/etc/passwd
echo $login:$pass::::::: >> result/etc/shadow

chmod 750 result/mail/$GENDOMAIN/$login
cp $MYFILESPATH/$GENUSERNAME/backup/$GENDOMAIN/email/data/pop/$login result/mail/$GENDOMAIN/$login/inbox
chmod 660 result/mail/$GENDOMAIN/$login/inbox

cp $MYFILESPATH/$GENUSERNAME/backup/$GENDOMAIN/email/data/imap/$login/.mailboxlist result/mail/$GENDOMAIN/$login/
cp $MYFILESPATH/$GENUSERNAME/backup/$GENDOMAIN/email/data/imap/$login/mail/* result/mail/$GENDOMAIN/$login/

touch result/mail/$login/inbox
chmod 660 result/mail/$login/inbox
done

cp result/etc/* result/etc/$GENDOMAIN/

#domain files
cd domains/$GENDOMAIN
#update file references - this one liner deletes domains/domain.net in every file of the tree.
# efectively changes:
#/home/username/domains/domain.net/public_html into
#/home/username/public_html
find ./ -type f -exec sed -i 's/domains\/$GENDOMAIN\///' {} \;

cp -R * ../../result
cd ../../result

tar --owner=$GENUSERNAME --group=$GENUSERNAME -czf ../$GENUSERNAME-$GENDOMAIN.tar.gz *
cd ..

#upload tar.gz
#I have ncftpput installed, but because most people don't, I've commented it out
#ncftpput -u $GENUSERNAME -p $NEWACCPASS localhost / $GENUSERNAME-$GENDOMAIN.tar.gz

#database:

#mysql

#subdomains

#ftp

Рубрики
Наследие

Перенос аккаунтов из WHM/cPanel в Direct Admin

Для переноса аккаунтов есть специальный скрипт, написаный Phil‘ом. Этот скрипт позволяет конвертировать резервную копию аккаунта cPanel в аккаунт Direct Admin.

Резервная копия аккаунта может быть выполнена как из командной строки: /scripts/pkgacct, так и с помощью веб-интерфейса WHM.
Скрипт может быть запущен как на сервере с DirectAdmin так и на сервере с cPanel.
Когда скрипт запускается на сервере с cPanel, то может дополнительно перенести новый архив в формате DirectAdmin на сервер в домашний (реселлерский) каталог на сервере (/home/{reseller}/user_backups) DA server directory.

Установка:

wget http://www.l0rdphi1.com/tools/da.cpanel.import.tar.gz
tar zxf da.cpanel.import.tar.gz
mkdir import export

Необходимо изменить конфигурационный файл defaults.conf, иначе скрипт работать не будет. Далее perl da.cpanel.import.pl и следовать инструкциям в диалоговом режиме.

Скрипт, по словам разработчика, способен перенести: сам аккаунт, субдомены, ftp-аккаунты, pop3-ящики, дополнительные домены и их файлы, базы mysql, паркованные домены и задачи crontab.

Рубрики
Наследие

Детектируем попытки спама через php/cgi скрипты.

Среди проблем, связанных со спамом, самой важной является своевременное отключение скриптов/учетных записей, которые рассылают скрипт.

Определить такие скрипты поможет собственный лог апача, который анализирует попытки частого обращения к скриптам, носящим провокационные названия вроде spam.cgi, sent.php и т.п.

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

LogFormat "%h %l %u %t \"%v %r\" %>s %b" spamlog
SetEnvIf Request_URI "[S,s][E,e][N,n][T,t]" spam
SetEnvIf Request_URI "[S,s][P,p][A,a][M,m]" spam
CustomLog logs/spam.log spamlog env=spam

Это даст возможность протоколировать обращения к ссылкам, где встречаются слова sent или spam (без учета регистра).
Следует обратить внимание на %v в описании LogFormat, так как это дает возможность записать в лог информацию о виртуальном хосте.
Таким образом, несложно написать парсер, который при превышении лимита к такой ссылке — например, 10 обращений в секунду, — блокировал бы ее.