Internal server error ubuntu apache2

Apache2 500 internal error

clop1000

New member

Установил апач и php при попытки зайти на 127.0.0.1 пишет Internal Server Error 500

в логе /var/log/error.log

[client 127.0.0.1:38930] AH00027: No authentication done but request not allowed without authentication for /. AstraMode requires authentication.

Как это победить
1) Правильным способом. Как использовать эту пресловутую Astra аунтификацию. Что эт такое вообще?
2) как это выключить в «хакерском режиме»? Пологаю что нужно выключть какой то PAM модуль или в конфиге апача.

New member

JohnRambo

New member

clop1000

New member

clop1000

New member

А кто нибудь успешно настраивал Kerberos авторизацию?)
А то как то сложно выглядит? Есть у кого опыт?

clop1000

New member

Сюдаже что бы не плодить новую тему:

Как включить поддержку .htaccess?

Options Indexes FollowSymLinks
AllowOverride All
Require all granted

mod_auth_kerb/5.4
И после чего caught SIGTERM, shutting down

JohnRambo

New member

clop1000

New member

А можете рассказать в кратце как это работает в пактическом смысле?
Это желательно только в рамках домена ALD? (Иначе придется на сервере для каждого юзера заводить аккаунт)?
Т.е. разрешения будут на каждый файл в отдельности?
А если это PHP скрипт. он же выполняется от пользователя apache2?
Работает ли apache2 в такой конфигурации в режиме целостности отличной от нуля? (т.е. когда другие сетевые службы не очень работают?)

А вы пробовали Postgres аунтификацию настраивать? Как она работает? Для каждой строки мандатная метка?

Источник

Apache CGI — ошибка 500

ЛОР — последее, куда обращаюсь за советом. Только если уже другие ресурсы бессильны. Виртуальный хост сервера Apache на Ubuntu выдает ошибку 500 при исполнении CGI скриптов. На localhost все скрипты работают.Вот лог ошибки:

ЛОР — последее, куда обращаюсь за советом.

Права на все файлы и папки стоят 777

Кто владелец /media/data/HTML/www/cgi/? Выложи конфиг куда-нибудь.

Premature end of script headers

Означает, что скрипт запустился, но либо упал с сегфолтом, либо вернул какую-то фигню.

Так что, копайте, что там у вас в этом CGI.

ЛОР — последее, куда обращаюсь за советом.

Это чтобы не задавать тут «хэлловорлдные» вопросы, которые, как правило, возникают у всех, кто только начинает что-то осваивать.

Так что, копайте, что там у вас в этом CGI.

скрипт рабочий 100%. Он работает в localhost, ели вы об этом

О, там же у тебя логи пишутся, посмотри в них 😉

А кто будет разрешать запуск CGI, Пушкин?

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

это я тоже пробовал — не помогает. может я куда то не туда пихаю этот код?

tail -f /var/log/httpd/*

Запускаем CGI и смотрим, что пишут логи.

это я тоже пробовал — не помогает. может я куда то не туда пихаю этот код?

Запросто. Кстати, доступ 777 с владельцем-рутом — нехорошо.

На каком ЯП CGI-то?

логи я приводил ведь.

Почему 777 под рутом не хорошо? на локальной машине вроде не страшно

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

куда надо прописать?

в логах пишет одно и тоже, нет смысла приводить

Ну, например, у меня так работает (/etc/httpd/conf/httpd.conf):

Кстати, а html-ки то виртуальный хост отдает?

эти же директивы будут аналогично работать в sites-available? хтмлки хост отдает и даже пхпшки, а вот cgi не хочет

755 на каталог и cgi-скрипты

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

Значит все-таки права криво раздал в апаче

Или /media/data подмонтирован с noexec =)

// в общем, телепаты вовсю работают!

ТС! Ну объясни же ты: зачем пихать корень веб-сервера в /media ?

Ты не в курсе, для чего эта директория?

Да нет, дело не в апаче совсем, как выяснилось. На диске запрещается исполнение файлов всем не только через апач или ещё что-то не так , я пока не разобрался. наверно что-то с монтированием

🙂 Опять мой libastral.so не подвел

/media/data монтируется через файл fstab вот так

Для сменных накопителей: флешек, USB-HDD и т.п.

Оно еще и на ntfs! Вот это жесть.

А что, есть принципиальная разница , куда кидать корень локального сервера для тестирования страничек? На нтфс он только, чтобы к файлам был доступ и через винду тоже. А куда тогда правильно монтировать жесткие диски? Где же тогда параметры прав при монтировании? rw? Буковка x к ним ничего не дает

Это ntfs! Так что можно забыть о нормальных правах доступа.

Как вариант, если уж так хочется «черезжопия», можно создать образ ext2-раздела на этом ntfs-разделе и держать файлы там (монтировать его через loop-device).

да нет, не хочется черезжопия. на корень сервака в нтфс я забил уже.

Источник

Ошибка 500 internal server error Nginx

При разработке веб-сайтов и веб-приложений можно столкнуться с ошибкой 500 internal server error. Сначала она может испугать и ввести в заблуждение, поскольку обычно веб-сервер выдает более конкретные ошибки, в которых указана точная причина проблемы, например, превышено время ожидания, неверный запрос или файл не найден, а тут просто сказано что, обнаружена внутренняя ошибка.

Но не все так страшно и в большинстве случаев проблема вполне решаема и очень быстро. В этой статье мы разберем как исправить ошибку Internal server error в Nginx.

Как исправить 500 internal server error Nginx

Дословно Internal server error означает внутренняя ошибка сервера. И вызвать её могут несколько проблем. Вот основные из них:

• Ошибки в скрипте на PHP — одна из самых частых причин;
• Превышено время выполнения PHP скрипта или лимит памяти;
• Неправильные права на файлы сайта;
• Неверная конфигурация Nginx.

А теперь рассмотрим каждую из причин более подробно и разберем варианты решения.

1. Ошибка в скрипте PHP

Мы привыкли к тому, что если в PHP скрипте есть ошибки, то сразу же видим их в браузере. Однако на производственных серверах отображение сообщений об ошибках в PHP отключено, чтобы предотвратить распространение информации о конфигурации сервера для посторонних. Nginx не может отобразить реальную причину ошибки, потому что не знает что за ошибка произошла, а поэтому выдает универсальное сообщение 500 internal server error.

Чтобы исправить эту ошибку, нужно сначала понять где именно проблема. Вы можете включить отображение ошибок в конфигурационном файле php изменив значение строки display_errors с off на on. Рассмотрим на примере Ubuntu и PHP 7.2:

sudo systemctl restart php-fpm

Затем обновите страницу и вы увидите сообщение об ошибке, из-за которого возникла проблема. Далее его можно исправить и отключить отображение ошибок, тогда все будет работать. Ещё можно посмотреть сообщения об ошибках PHP в логе ошибок Nginx. Обычно он находится по пути /var/log/nginx/error.log, но для виртуальных доменов может настраиваться отдельно. Например, смотрим последние 100 строк в логе:

tail -n 100 -f /var/log/nginx/error.log

Теперь аналогично, исправьте ошибку и страница будет загружаться нормально, без ошибки 500.

2. Превышено время выполнения или лимит памяти

Это продолжение предыдущего пункта, так тоже относится к ошибкам PHP, но так, как проблема встречается довольно часто я решил вынести её в отдельный пункт. В файле php.ini установлены ограничения на время выполнения скрипта и количество оперативной памяти, которую он может потребить. Если скрипт потребляет больше, интерпретатор PHP его убивает и возвращает сообщение об ошибке.

Также подобная ошибка может возникать, если на сервере закончилась свободная оперативная память.

Если же отображение ошибок отключено, мы получаем error 500. Обратите внимание, что если время ожидания было ограничено в конфигурационном файле Nginx, то вы получите ошибку 504, а не HTTP ERROR 500, так что проблема именно в php.ini.

Чтобы решить проблему увеличьте значения параметров max_execution_time и memory_limit в php.ini:

sudo vi /etc/php/7.2/php.ini

max_execution_time 300
memory_limit 512M

Также проблема может быть вызвана превышением других лимитов установленных для скрипта php. Смотрите ошибки php, как описано в первом пункте. После внесения изменений в файл перезапустите php-fpm:

sudo systemctl restart php-fpm

3. Неверные права на файлы

Такая ошибка может возникать, если права на файлы, к которым обращается Nginx установлены на правильно. Сервисы Nginx и php-fpm должны быть запущены от имени одного и того же пользователя, а все файлы сайтов должны принадлежать этому же пользователю. Посмотреть от имени какого пользователя запущен Nginx можно командой:

nginx -T | grep user

Чтобы узнать от какого пользователя запущен php-fpm посмотрите содержимое конфигурационного файла используемого пула, например www.conf:

sudo vi /etc/php-fpm.d/www.conf

В моем случае это пользователь nginx. Теперь надо убедится, что файлы сайта, к которым вы пытаетесь обратиться принадлежат именно этому пользователю. Для этого используйте команду namei:

namei -l /var/www/site

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

sudo chown nginx:nginx -R /var/www/site

Этой командой мы меняем владельца и группу всех файлов в папке на nginx:nginx. Добавить права на чтение для всех пользователей для каталога можно командой chmod. Например:

sudo chmod o+r /var/www/

Далее все должно работать. Также, проблемы с правами может вызывать SELinux. Настройте его правильно или отключите:

Выводы

В этой статье мы разобрали что делать если на вашем сайте встретилась ошибка 500 internal server error nginx. Как видите проблема вполне решаема и в большинстве случаев вам помогут действия описанные в статье. А если не помогут, напишите свое решение в комментариях!

Похожие записи

Нет похожих записей.

Оцените статью

Об авторе

Основатель и администратор сайта losst.ru, увлекаюсь открытым программным обеспечением и операционной системой Linux. В качестве основной ОС сейчас использую Ubuntu. Кроме Linux, интересуюсь всем, что связано с информационными технологиями и современной наукой.

2 комментария к “Ошибка 500 internal server error Nginx”

Чушь.
1. header(«http/1.1 500 Internal Server Error») ;
И логи не помогут.
2. Если скрипт превышает лимиты, то, вероятнее всего, в коде что-то не так. Бесконечный цикл, например. С ним, кстати, и увеличение этих лимитов не спасёт.

статья однобока. проблема к nginx вряд ли имеет отношение, зря в заголовок вынесено название этого великолепного сервера. nginx может работать, и работает, в связке не только с PHP. а на PHP свет клином не сошёлся. если уж пишете о PHP то и выносите в заголовок PHP, а не nginx.

инициировать такую ошибку можно элементарно. например, отключаем сервис PostgreSQL и вуаля. Welcome home, dear!

Источник