Решение проблемы "Forbidden You don't have permission to access / on this server."

Forbidden  You don't have permission to access / on this server.

Forbidden

You don't have permission to access / on this server.

Обычно возникает данная ошибка при переносе сайта, с локальной машины на «боевой» сервер. Не стоит впадать в отчаянье. Ошибка означает, что доступ к твоему php файлу запрещен.

Что бы исправить ошибку, внимательно проверьте:

  1. Права на папки и файлы
  2. Чаще всего данная ошибка связана с не проставленными правами chmod на папки и файлы. Внимательно перепроверьте.
  3. Запрет на все файлы
  4. В .htaccess указана деректва: deny from all. Попробуйте убрать.

504 Gateway Time-out (nginx и в связке nginx+apache) - что можно сделать?

504 — значит скрипт (бэкенд) слишком долго отвечал или скрипт завершается раньше, чем получен ответ.

Сразу предупрежу, если вы получаете такое сообщение на обычном shared хостинге – то проблема скорее в том, что исполняемый скрипт не укладывается во временные рамки (30 или 60 секунд – в зависимости от настройки).

Это может быть по разным причинам:
  • объем данных, обрабатываемых скриптом существенно вырос
  • скрипт ображается к другим сайтам или сервисам, которые долго фомрируют ответ
  • скрипт слишком тяжелый

504 Gateway Timeout (time out) на чистом nginx

В случае с выделеными серверами:
в php.ini увеличить значение параметра
PHP max_execution_time

в конфиге nginx увеличить время ожидания исполнения скрипта:

proxy_read_timeout 120;
        proxy_connect_timeout 120;


увеличить оперативной памяти
Файл конфигурации nginx.conf находиться в каталоге /etc/nginx/

syntax: proxy_connect_timeout время
default: proxy_connect_timeout 60
context: http, server, location
Директива задаёт таймаут для соединения с проксированным сервером. Необходимо иметь в виду, что этот таймаут __не может быть больше 75 секунд__.


504 Gateway Timeout (time out) в связке nginx+apache


Если возникла ошибка 504 Gateway Timeout (time out) в связке nginx+apache то увеличим на сервере допустимое время выполнения скриптов и ожидания ответа:
php.ini:
max_execution_time = 900


nginx.conf:
proxy_read_timeout  900;
client_header_timeout  10m;
client_body_timeout    10m;
send_timeout           10m;


Теперь есть 900 секунд (15 минут) на выполнение скриптов.

Также:
worker_processes 2; количество worker-ов, обычно один.
keepalive_timeout 400; (было 100)

Как определить количество рабочих процессов, задаваемых параметром worker_processes?

Ответ автора nginx Игоря Сысоева:

Если весь сайт помещается в память сервера, к диску обращений нет, и это выделенный сервер для nginx, то 1. Не будет лишних переключений контекста. Если нужно ходить на диск, то 5-10 — это позволит обрабатывать соединения процессами, незаблокироваными на диске.

Кроме этого необходимо понаблюдать за состоянием процессов nginx в работе в часы пик. Командой ps посмотреть состояние рабочих процессов (worker process):

# ps ax -o %cpu,vsz,wchan,command | grep "nginx\|PID"

%CPU   VSZ WCHAN  COMMAND
0,0  1428 pause  nginx: master process /usr/local/nginx/sbin/nginx
0,0  2284 -      nginx: worker process (nginx)
0,0  2128 kqread nginx: worker process (nginx)

Если один из рабочих процессов находится в состоянии ожидания «kqread» в колонке «WCHAN», то значит их количество достаточно. Ну а если уж все они постоянно находятся в этом состоянии, то их количество можно сократить до одного.

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

Безопасность: Ограничение методов TRACK, TRACE в apache

С помощью использования методов TRACK и TRACE в протоколе HTTP возможно выполнение атаки межсайтовый скриптинг. Для отключения метода TRACE в конфиге апача надо указать (начиная с версии 2.0.55):
TraceEnable off

Директивой Limit этот метод ограничить нельзя!

Для отключения TRACK надо поместить в .htaccess:
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]

Перенос WordPress с Apache на Nginx

Самая приятная новость последних дней это мой переезд на новый сервер. На этот раз он не виртуальный, а физический. Преимуществ и удобств после расставания со старым хостером просто масса. Но обо всем по порядку. Раз уж я начал заниматься переносом, то подумал почему бы не провести оптимизацию и программной составляющей. Я давно собирался уйти от монструозного Apache2 на какой-нибудь более легкий веб сервер, но первое правило администратора гласит — если работает, не трогай. А когда появился вроде как официальный повод тронуть, то я тут же им воспользовался.

Все мои сервера в Сети управляются операционной системой Debian. О совсем очевидных тонкостях настройки системы и установки программного обеспечения я рассказывать не буду. Эта статья для тех кто имеет доступ на свой сервер с правами root, а значит он должен знать что делает.
Читать дальше →

GoAccess – realtime парсер логов Apache (ncurses)



Совершенно случайно натолкнулся на эту чудную вещь!
Это консольный realtime-парсер логов Apache с графическим режимом. Об этой штуке я давно мечтал – и вот, свершилось!

Что умеет GoAccess?


На лету собирает и анализирует такие показатели как:
* Пропускная способность
* Уникальные посетители,
* Браузеры,
* Приходящие веб-роботы(пауки),
* Хосты,
* IP geolocation,
* Ключевые фразы с поисковиков,
* Сайты-реффереры,

* Коды ответов сервера
* и многое другое.
Читать дальше →

Простейшая реализация Watchdog для apache

Что такое watch dog? Watch Dog — это системный демон, который при определенных условиях, к примеру подвисания или падения службы перезапускает её в автоматическом режиме.

Вот его то мы с вами сейчас и напишем.

Давайте начнем с проверки, запущенно ли приложение. Сделать это довольно просто и существует несколько разных способов. К примеру практически все приложения создают pid файл, если приложение «сдохло» то пид файла нет. А так же в пид файл пишется номер процесса, который можно использовать для поиска приложения в списке запущеных программ. Но в моём случае такой вариант не сильно подходит, да и считаю я его не надежным.

Наш вачдог:
#!/bin/bash
ps ax | grep apache2 | grep -v grep -q || /etc/init.d/apache2 restart > /dev/null
otvet=`curl -s -L --head -w "%{http_code}\n" <a href="http://www.%D1%81%D0%B0%D0%B9%D1%82.net" onclick="javascript:_gaq.push(['_trackEvent','outbound-article','http://www.сайт.net']);" rel="nofollow" class="external" target="_blank">http://www.сайт.net</a> | tail -n1`
if [ $otvet -ne "200" ]
then
echo "`date +%d-%m-%Y`  `date +%H:%M:%S%t` Server podvis" >> /var/log/vault_daemons.log
/etc/init.d/apache2 restart
fi
exit 0


Сохраним скрипт, поставим права на запуск и добавим в крон.

Защита Web-сервера, что нужно знать про MySQL и Apache

Давайте рассмотрим пример защиты MySQL и Apache в операционной сис­теме Linux. Мы опустим защиту самой ОС, потому что это отдельная и очень большая тема, да и весь Apache мы трогать не будем, пусть живет. Итак, за­щита начинается с установки и предварительного конфигурирования. В слу­чае с MySQL необходимо выполнить следующие действия:
  1. СУБД устанавливается с настройками по умолчанию, при которых адми­нистраторский доступ разрешен пользователю root с пустым паролем. Это не хорошо. Необходимо как минимум установить сложный пароль, а луч­ше переименовать учетную запись root. Если вы работали с ОС Linux, то должны знать, что в этой системе администратором тоже является root. Имя администратора в ОС и в СУБД никак не связаны;
  2. необходимо заблокировать анонимный доступ к СУБД. Подключения должны осуществляться только авторизованными пользователями;

Читать дальше →

Установка apache, php, mysql в Ubuntu 10.10

В связи с установкой себе новой версии убунты 10.10 решил написать новое руководство по установке и настройки веб-сервера.
Мы будем использовать такие программы:

* Apache
* Php
* MySql
* PhpMyAdmin
* Mod_rewrite


Читать дальше →