Иногда бывает нужно сделать так, чтобы апач и скрипты запускаемые кроном имели разные php.ini. К примеру, для того чтобы ограничить скрипты апача разными disable_functions.
Просто создаем копию php.ini в любом месте, допустим, это будет версия для Apache. Добавляем в нее:
Памяти никогда много не бывает. И по мере роста трафика сервер может начать свопиться, а это очень плохо. Посмотрим что же можно сделать:
Во-первых, сначала надо убедиться, что перед апачем установлен nginx (ну или лайти) и он отдает напрямую всю статику: графику, видео, js, css, какие-либо архивы и прочее. Для контроля очень удобно воспользоваться встроенными возможностями апача просмотра статуса:
<Location /server-status>
SetHandler server-status
</Location>
ExtendedStatus On
Обязательно нужно внимательно пройтись по конфигу апача и закомментировать загрузку неиспользуемых модулей
Так же нужно проконтролировать, чтобы максимальное одновременное количество клиентов апача не превышало объема установленной на сервере памяти. Просто делим общее количество памяти на количество занимаемое одним процессом апача за минусом памяти под mysql и прочее. Иначе система уйдет в своп и катастрофически деградирует.
Так же можно поставить MaxRequestsPerChild поменьше (~500) чтобы форки апача почаще перезапускались и освобождали память.
Если используется Eaccelerator, то надо проверить что eaccelerator.shm_size не очень большое, = “64″ вполне подойдет
Если ничего не помогает, то нужно попытаться определить какой из виртуалхостов самый прожорливый. Можно просто по очереди тестировать сайты на сервере при помощи и наблюдать за нагрузкой. Скорее всего найдется код создающий максимальную нагрузку по памяти. Далее можно пойти путем оптимизации кода либо попрбовать перенести именно этот виртуалхост на php в режиме fast cgi.
Так же нужно не забывать про возможность просто взять более мощный сервер. Благо, например, у Hetzner за смешные деньги можно арендовать сервер с 8 и более ГБ памяти. Часто это может оказаться самым “дешовым” решением.
Иногда бывают такие ситуации, когда несколько глюков наложившись один на другой составляют проблему весьма и весьма загадочную на первый взгляд.
Ситуация была такая:
Проводился перенос сайтов с ВПС-а (на LAMP платформе) на дедик с таким же LAMP только еще с DirectAdmin-ом. Контент сайтов и базы данных были перенесены на новый хост. На одном из сайтов был установлен WordPress и в подпапке /st/ некий скрипт доступ к которому был ограничен в файле .htaccess лежащем в той же папке. Вот содержимое того .htaccess
Order allow,deny
Allow from all
AuthType Basic
AuthName "admin"
AuthUserFile /home/username/domains/domain.com/public_html/st/.htpasswd
Require valid-user
Вроде все очень просто и правильно. Но, при попытке доступа к domain.com/st/ мы стабильно получаем ошибку “404 – File Not Found” и отсутствие какого либо запроса на авторизацию. В логах этого виртуалхоста никаких ошибок, только 404 ответы. Все пути проверены и перепроверены. Авторизационные модули апача точно присутствуют:
В конфигах апача точно разрешено переопределение директив для этой папки AllowOverride All.
Расследование вывело на .htaccess лежащий в корне этого сайта и строки от вордпресса:
Комментируя последнюю строчку мы получали работающую авторизацию. Но при чем тут она?! =)
Пытался отключать наследование работы mod_rewrite прописывая в “нижний” .htaccess директив RewriteEngine Off – не помогало. Да и на старом ВПС-е все работало. Очень странно.
Для уточнения работы правил реврайта пришлось в виртуалхост добавить директивы:
Оказалось, что при открытии проблемного УРЛ mod_rewrite пытался преобразовать адрес uri ’401.shtml’. Что и указало на суть проблемы. А проблема на самом деле была в том, что при переносе сайта из ДиректАдминовского каталога /public_html были удалены дефолтные файлы – обработчики ошибок:
400.shtml, 401.shtml, 403.shtml … которые были назначены в конфиге апача обработчиками соответствующих ошибок. И происходило следующее: при запросе проблемного урла апач отвечал 401 – как и должен был, и пытался отдать страницу 401.shtml, но так как она была удалена .htaccess из корня сайта преобразовывал запрос на вордпрессовый index.php отдавая 404 из-за отсутствующего 401.shtml.
Возвращение на место *.shtml файлов вернуло все в работающее состояние.
Мораль: изменять дефолтные настройки всяких сложных панелей нужно очень аккуратно.
Иногда бывает, что ДиректАдмин по каким-то причинам не считает статистику по доменам. Вот несколько пунктов по которым это может происходить:
отсутствует библиотека GD. Симптом: “ebalizer: error while loading shared libraries: libgd.so.2: cannot open shared object file: No such file or directory”. Чтобы починить:
yum install gd
Не установлен или не работает crond. Чтобы починить:
yum -y install vixie-cron
service crond start
chkconfig crond on
Не прописан создатель домена. Например, в общем случае, в /usr/local/directadmin/data/users/admin/users.list должны быть прописаны все пользователи DirectAdmin-а
Сам webalizer не корректно собран. Для проверки просто запускаем webalizer и смотрим не появятся ли ошибки.
Анализ логов отключен в directadmin.conf. Чтобы починить ищем и исправляем в directadmin.conf строки:
webalizer=0
rotation=0
Какие либо проблемы в самом webalizer. Чтобы проверить это запускаем обсчет статистики вручную для конкретного домена:
и смотрим /var/log/directadmin/system.log & /var/log/directadmin/error.log
Еще фишка с настройками вебалайзера. По дефолту, используются умолчальные настройки и они забиты в бинарник ДиректАдмина.
Чтобы кастомизировать настройки webalizer надо создать конфиг в /usr/local/directadmin/data/templates/custom/webalizer.conf и поместить туда директивы, которые должны отличаться от дефолтных, например:
Если по простому,то это штука, которая позволяет выполнять PHP-скрипты под Apache с правами их владельца, а не с правами веб-сервера. Это бывает необходимо если на сервере несколько пользователей (например, фтп), они активно меняют контент сайтов, но веб-серверу тоже нужен доступ к этим файлам. Тут то и происходит конфликт владельцев.
suPHP есть и в портах для FreeBSD:
Для активации надо прописать либо в глобальной секции httpd.conf, либо в конкретном виртуал-хосте:
suPHP_Engine on
suPHP_AddHandler application/x-httpd-php
Не путать с модулем для апача !
Замечен такой косяк: если надо запускать что-то через exec и по относительному пути исполняемый файл не находится, то надо убедится, что в suphp.conf прописано с кавычками!
Сертификаты бывают на один домен (будет работать только для mydomain.com или только для www.mydomain.com) и мультидоменные (*.mydomain.com). Мультидоменные стоят много дороже. В нашем случае рассматриваются сертификаты на один домен.
Генерим закрытый ключ и запрос на сертификат:
Самое важное это указать Common name = mydomain.com. Остальные поля не так важны. Всякие Optional-поля лучше вообще не указывать.
На данном этапе если хотим подписать сертификат доверенным центром сертификации то отправляем им mydomain.com.csr. А если будем подписывать сами, то:
Когда генерим CSR то не надо указывать e-mail, challenge password и дополнительные опции.
Если мы хотим подписать сертификат доверенным центром сертификации, то отправляем им mydomain.com.csr. Если же будем подписывать сами то:
Иногда бывает необходимо поставить nginx перед апачем на сервере с уже установленным DirectAdmin-ом. И тут есть несколько варинтов:
Перевесить апач на 127.0.0.1, а nginx на все внешние адреса. Но для этого прийдется править конфиги всех сайтов + темплейты для создания новых хостов в ДиректАдмине (шаблоны лежат тут $DIRECTADMIN_HOME/data/templates/). Так же этот вариант опасен тем, что если что-то пойдет не так, то сайты будут не доступны некоторое время.
Перевесить апач на другой порт, а nginx на 80. В этом варианте тоже прийдется править шаблоны.
Ну и самый удобный вариант это просто добавить новый ip на сервер, но не добавлять его в ДиректАдмин. Повесить на этот ип nginx и уже на него перевести днс-ы тех доменов, которые больше всего грузят сервер. После добавления ип-а и
SSLv2 уже давно не обеспечивает приемлемого уровня безопасности и поэтому желательно отключить его в mod_ssl. Для этого в виртуалхосте апача надо прописать:
С помощью использования методов TRACK и TRACE в протоколе HTTP возможно выполнение атаки межсайтовый скриптинг. Для отключения метода TRACE в конфиге апача надо указать (начиная с версии 2.0.55):
TraceEnable off
Директивой Limit этот метод ограничить нельзя!
Для отключения TRACK надо поместить в .htaccess:
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
чтобы пробросить ip пользователя к apache, то некоторые скрипты, работающие под apache из-за заголовка X-Forwarded-For могут считать, что пользователь пришел через прокси. А это не желательно. В таком случае в nginx те два заголовка надо заменить на:
proxy_set_header Test $remote_addr;
а в конфиге mod_rpaf сделать так:
RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1 внешние ип-ы
RPAFheader Test
cd /usr/local/src
wget http://stderr.net/apache/rpaf/download/mod_rpaf-0.6.tar.gz
tar xzf mod_rpaf-0.6.tar.gz
cd mod_rpaf-0.6
apxs -i -c -n mod_rpaf-2.0.so mod_rpaf-2.0.c
3. Далее нужно создать файл конфигурации mod_rpaf – /etc/httpd/conf.d/rpaf.conf
и добавить в него следующие строки:
LoadModule rpaf_module modules/mod_rpaf-2.0.so
RPAFenable On
RPAFproxy_ips 127.0.0.1 xx.xx.xx.xx yy.yy.yy.yy
где xx.xx.xx.xx и yy.yy.yy.yy – IP адреса вашего сервера.