Время на прочтение
8 мин
Количество просмотров 60K
Nginx — это веб-сервер, на котором работает треть всех сайтов в мире. Но если забыть или проигнорировать некоторые ошибки в настройках, можно стать отличной мишенью для злоумышленников. Detectify Crowdsource подготовил список наиболее часто встречающихся ошибок, делающих сайт уязвимым для атак.
Nginx — один из наиболее часто используемых веб-серверов в Интернете, поскольку он модульный, отзывчивый под нагрузкой и может масштабироваться на минимальном железе. Компания Detectify регулярно сканирует Nginx на предмет неправильных настроек и уязвимостей, из-за которых могут пострадать пользователи. Найденные уязвимости потом внедряются в качестве теста безопасности в сканер веб-приложений.
Мы проанализировали почти 50 000 уникальных файлов конфигурации Nginx, загруженных с GitHub с помощью Google BigQuery. С помощью собранных данных удалось выяснить, какие ошибки в конфигурациях встречаются чаще всего. Эта статья прольёт свет на следующие неправильные настройки Nginx:
-
Отсутствует корневой каталог
-
Небезопасное использование переменных
-
Чтение необработанного ответа сервера
-
merge_slashes отключены
Отсутствует корневой каталог
server {
root /etc/nginx;
location /hello.txt {
try_files $uri $uri/ =404;
proxy_pass http://127.0.0.1:8080/;
}
}Root-директива указывает корневую папку для Nginx. В приведённом выше примере корневая папка /etc/nginx, что означает, что мы можем получить доступ к файлам в этой папке. В приведенной выше конфигурации нет места для / (location / {...}), только для /hello.txt. Из-за этого root-директива будет установлена глобально, а это означает, что запросы к / перенаправят вас на локальный путь /etc/nginx.
Такой простой запрос, как GET /nginx.conf, откроет содержимое файла конфигурации Nginx, хранящегося в /etc/nginx/nginx.conf. Если корень установлен в /etc, запрос GET на /nginx/nginx.conf покажет файл конфигурации. В некоторых случаях можно получить доступ к другим файлам конфигурации, журналам доступа и даже зашифрованным учётным данным для базовой аутентификации HTTP.
Из почти 50 000 файлов конфигурации Nginx, которые мы проанализировали, наиболее распространёнными корневыми путями были следующие:
Потерявшийся слеш
server {
listen 80 default_server;
server_name _;
location /static {
alias /usr/share/nginx/static/;
}
location /api {
proxy_pass http://apiserver/v1/;
}
}При неправильной настройке off-by-slash можно перейти на один шаг вверх по пути из-за отсутствующей косой черты. Orange Tsai поделился информацией об этом в своём выступлении на Blackhat «Нарушение логики парсера!». Он показал, как отсутствие завершающей косой черты в location директиве в сочетании с alias директивой позволяет читать исходный код веб-приложения. Менее известно то, что это также работает с другими директивами, такими как proxy_pass. Давайте разберёмся, что происходит и почему это работает.
location /api {
proxy_pass http://apiserver/v1/;
}Если на Nginx запущена следующая конфигурация, доступная на сервере, можно предположить, что доступны только пути в http://apiserver/v1/.
http://server/api/user -> http://apiserver/v1//userКогда запрашивается http://server/api/user, Nginx сначала нормализует URL. Затем он проверяет, соответствует ли префикс /api URL-адресу, что он и делает в данном случае. Затем префикс удаляется из URL-адреса, поэтому остаётся путь /user. Затем этот путь добавляется к URL-адресу proxy_pass, в результате чего получается конечный URL-адрес http://apiserver/v1//user.
Обратите внимание, что в URL-адресе есть двойная косая черта, поскольку директива местоположения не заканчивается косой чертой, а путь URL-адреса proxy_pass заканчивается косой чертой. Большинство веб-серверов нормализуют http://apiserver/v1//user до http://apiserver/v1/user, что означает, что даже с этой неправильной конфигурацией всё будет работать так, как ожидалось, и это может остаться незамеченным.
Эта неправильная конфигурация может быть использована путём запроса http://server/api../, из-за чего Nginx запросит URL-адрес http://apiserver/v1/../, который нормализован до http://apiserver/. Уровень вреда от такой ошибки определяется тем, чего можно достичь, если использовать эту неправильную конфигурацию. Например, это может привести к тому, что статус сервера Apache будет отображаться с URL-адресом http://server/api../server-status, или он может сделать доступными пути, которые не должны быть общедоступными.
Одним из признаков того, что сервер Nginx имеет неправильную конфигурацию, является возврат сервером одинакового же ответа при удалении косой черты в URL-адресе. То есть, если http://server/api/user и http://server/apiuser возвращают один и тот же ответ, сервер может быть уязвимым. Он позволяет отправлять следующие запросы:
http://server/api/user -> http://apiserver/v1//user
http://server/apiuser -> http://apiserver/v1/userНебезопасное использование переменных
Некоторые фреймворки, скрипты и конфигурации Nginx небезопасно используют переменные, хранящиеся в Nginx. Это может привести к таким проблемам, как XSS, обход HttpOnly-защиты, раскрытие информации и в некоторых случаях даже RCE.
SCRIPT_NAME
С такой конфигурацией, как эта:
location ~ \.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass 127.0.0.1:9000;
}основная проблема будет заключаться в том, что Nginx отправит интерпретатору PHP любой URL-адрес, заканчивающийся на .php, даже если файл не существует на диске. Это распространённая ошибка во многих конфигурациях Nginx, и об этом говорится в документе «Ловушки и распространенные ошибки», созданном Nginx.
XSS возможен, если PHP-скрипт попытается определить базовый URL на основе SCRIPT_NAME;
<?php
if(basename($_SERVER['SCRIPT_NAME']) ==
basename($_SERVER['SCRIPT_FILENAME']))
echo dirname($_SERVER['SCRIPT_NAME']);
?>
GET /index.php/<script>alert(1)</script>/index.php
SCRIPT_NAME = /index.php/<script>alert(1)</script>/index.phpИспользование $uri может привести к CRLF-инъекции
Другая неправильная конфигурация, связанная с переменными Nginx, заключается в использовании $uri или $document_uri вместо $request_uri.
$uri и $document_uri содержат нормализованный URI, тогда как нормализация в Nginx включает URL-декодирование URI. В блоге Volema рассказывалось, что $uri обычно используется при создании перенаправлений в конфигурации Nginx, что приводит к внедрению CRLF.
Пример уязвимой конфигурации Nginx:
location / {
return 302 https://example.com$uri;
}Символами новой строки для HTTP-запросов являются \r (возврат каретки) и \n (перевод строки). URL-кодирование символов новой строки приводит к следующему представлению символов %0d%0a. Когда эти символы включены в запрос типа http://localhost/%0d%0aDetectify:%20clrf на сервер с неправильной конфигурацией, сервер ответит новым заголовком с именем Detectify, поскольку переменная $uri содержит новые URL-декодированные строчные символы.
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.19.3
Content-Type: text/html
Content-Length: 145
Connection: keep-alive
Location: https://example.com/
Detectify: clrfПроизвольные переменные
В некоторых случаях данные, предоставленные пользователем, можно рассматривать как переменную Nginx. Непонятно, почему это происходит, но это встречается не так уж редко, а проверяется довольно-таки сложным путём, как видно из этого отчёта. Если мы поищем сообщение об ошибке, то увидим, что оно находится в модуле фильтра SSI, то есть это связано с SSI.
Одним из способов проверки является установка значения заголовка referer:
$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’Мы просканировали эту неправильную конфигурацию и обнаружили несколько случаев, когда пользователь мог получить значение переменных Nginx. Количество обнаруженных уязвимых экземпляров уменьшилось, что может указывать на то, что уязвимость исправлена.
Чтение необработанного ответа сервера
С proxy_pass Nginx есть возможность перехватывать ошибки и заголовки HTTP, созданные бэкендом (серверной частью). Это очень полезно, если вы хотите скрыть внутренние сообщения об ошибках и заголовки, чтобы они обрабатывались Nginx. Nginx автоматически предоставит страницу пользовательской ошибки, если серверная часть ответит ей. А что происходит, когда Nginx не понимает, что это HTTP-ответ?
Если клиент отправляет недопустимый HTTP-запрос в Nginx, этот запрос будет перенаправлен на серверную часть как есть, и она ответит своим необработанным содержимым. Тогда Nginx не распознает недопустимый HTTP-ответ и просто отправит его клиенту. Представьте себе приложение uWSGI, подобное этому:
def application(environ, start_response):
start_response('500 Error', [('Content-Type',
'text/html'),('Secret-Header','secret-info')])
return [b"Secret info, should not be visible!"]И со следующими директивами в Nginx:
http {
error_page 500 /html/error.html;
proxy_intercept_errors on;
proxy_hide_header Secret-Header;
}proxy_intercept_errors будет обслуживать пользовательский ответ, если бэкенд имеет код ответа больше 300. В нашем приложении uWSGI выше мы отправим ошибку 500, которая будет перехвачена Nginx.
proxy_hide_header почти не требует пояснений; он скроет любой указанный HTTP-заголовок от клиента.
Если мы отправим обычный GET-запрос, Nginx вернёт:
HTTP/1.1 500 Internal Server Error
Server: nginx/1.10.3
Content-Type: text/html
Content-Length: 34
Connection: closeНо если мы отправим неверный HTTP-запрос, например:
GET /? XTTP/1.1
Host: 127.0.0.1
Connection: closeТо получим такой ответ:
XTTP/1.1 500 Error
Content-Type: text/html
Secret-Header: secret-info
Secret info, should not be visible!merge_slashes отключены
Для директивы merge_slashes по умолчанию установлено значение «on», что является механизмом сжатия двух или более слешей в один, поэтому/// станет /. Если Nginx используется в качестве обратного прокси и проксируемое приложение уязвимо для включения локального файла, использование дополнительных слешей в запросе может оставить место для его использования. Об этом подробно рассказывают Дэнни Робинсон и Ротем Бар.
Мы нашли 33 Nginx-файла, в которых для параметра merge_slashes установлено значение «off».
Попробуйте сами
Мы создали репозиторий GitHub, где вы можете использовать Docker для настройки своего собственного уязвимого тестового сервера Nginx с некоторыми ошибками конфигурации, обсуждаемыми в этой статье, и попробуйте найти их самостоятельно!
Вывод
Nginx — это очень мощная платформа веб-серверов, и легко понять, почему она широко используется. Но с помощью гибкой настройки вы даёте возможность совершать ошибки, которые могут повлиять на безопасность. Не позволяйте злоумышленнику взломать ваш сайт слишком легко, не проверяя эти распространённые ошибки конфигурации.
Вторая часть будет позднее.
Что ещё интересного есть в блоге Cloud4Y
→ Пароль как крестраж: ещё один способ защитить свои учётные данные
→ Тим Бернерс-Ли предлагает хранить персональные данные в подах
→ Подготовка шаблона vApp тестовой среды VMware vCenter + ESXi
→ Создание группы доступности AlwaysON на основе кластера Failover
→ Как настроить SSH-Jump Server
Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.
IIS supports sharing the configuration across multiple web servers. In some cases, you may come across “Configuration file is not well-formed XML” or “Cannot read configuration file” errors in Event Viewer.
These error messages indicate that IIS shared config environment is having difficulties syncing the data. This may stop the application pool which means an outage for your application.
Check both System and Application containers in Event Viewer to have more details about issue:
5172: The Windows Process Activation Service encountered an error trying to read configuration data from file applicationHost.config line number 0. The error message is: ‘Cannot read configuration file’. The data field contains the error number.
2307: The worker process for application pool abc.com encountered an error ‘Configuration file is not well-formed XML’ trying to read configuration data from file abc.config, line number 3. The data field contains the error code.
“Cannot read configuration file”
“Configuration file is not well-formed XML”
Solution
As this article mentions, DFS deletes the current configuration file and creates every time there is a change in the IIS shared environment. During this process, a member server may retrieve an incomplete config file.
Solution 1
The fastest solution is that changing the value of the ConfigPollMilliSeconds parameter to 600000 so that IIS doesn’t rely on file system change notifications. It automatically checks the last modified date of the configuration file every 600000 milliseconds (10 minutes) with this setting. More details: Microsoft Support
The registry key: HKLM\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds (REG_DWORD). Restart the server after changing the value of this registry key.
Solution 2
You can try using Offline Files for the IIS shared folder. If it is production environment, please implement this change after business hours and monitor the system. The changes should be synced and websites are served without any issues.
- In Control Panel, open “Offline Files”
- Click “Enable Offline Files”
- Run the following command in Command Prompt to set the cache Read Only
REG ADD "HKLM\System\CurrentControlSet\Services\CSC\Parameters" /v ReadOnlyCache /t REG_DWORD /d 1 /f - Restart the web server
- Go to the file share folder. Right click and select “Always Available Offline”
- Go to “Control Panel > Offline Files”. Select “Schedule”
- Schedule offline file sync
2 декабря, 2022 12:20 пп
877 views
| Комментариев нет
LEMP Stack
Nginx — это популярный веб-сервер, на котором размещаются многие крупные сайты. При настройке веб-сервера Nginx обычно создается domain block с деталями конфигурации, чтобы сайт мог обрабатывать входящие запросы. Часто при настройке Nginx в файле конфигурации допускают ошибки. Мы разберем самые распространенные синтаксические ошибки, а также подумаем, как их проверить и как исправить.
Примеры в этом мануале были протестированы на сервере Ubuntu, но они будут работать на большинстве установок Nginx, так как они в основном связаны со стандартным файлом конфигурации. Каталоги и пути могут немного отличаться.
Проверка лога ошибок Nginx
В этом мануале мы рассмотрим самые распространенные ошибки и способы их устранения. Синтаксические ошибки нарушают структуру, которую Nginx распознает как допустимую. Часто одна ошибка переходит в другую и становится причиной более серьезной или отдельной проблемы. Поэтому конкретные обстоятельства и настройки в реальной среде могут отличаться от тех, что приведены в данном мануале.
Помните, что вы всегда можете обратиться к логу ошибок Nginx, чтобы просмотреть текущий список:
sudo cat /var/log/nginx/error.log
В этом мануале позже будет рассказано, как разобрать и понять сообщения об ошибках Nginx.
Проверка файла конфигурации на наличие ошибок
Давайте посмотрим на пример domain block в Nginx с разными ошибками в файле конфигурации. Эти ошибки сделаны намеренно, чтобы показать вам, как их можно исправить. Чтобы проверить, есть ли в настройке какие-либо синтаксические ошибки, запустите следующую команду:
sudo nginx -t
Если ошибок нет, вывод будет следующим:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
Если команда обнаружит ошибки, вы получите сообщение, в котором будет указан точный файл и строка кода, а также конкретная проблема с синтаксисом, которую нужно решить.
Выявление структурных синтаксических ошибок
Одна из распространенных ошибок при работе с Nginx – отсутствие необходимых символов или неправильная структура синтаксиса. Конфигурационный файл Nginx ориентирован на директивы, и эти директивы должны быть объявлены определенным образом. В противном случае конфигурационный файл будет структурно некорректным.
Директивы можно разделить на два типа, каждый из которых имеет свой синтаксис: простые директивы (которые содержат имя и параметры, заканчивающиеся точкой с запятой) и блочные директивы (разделяются фигурными скобками { } и могут содержать другие блоки внутри себя).
Если директива структурирована неправильно, Nginx не сможет распознать ее, что может привести к следующим ошибкам.
Ошибка Invalid parameter
Файл конфигурации Nginx очень требователен к структуре и синтаксису. Одна из самых частых проблем с синтаксисом связана с точкой с запятой. Например, рассмотрим такое сообщение об ошибке:
[emerg] invalid parameter "root" in /etc/nginx/sites-enabled/your_domain:5 nginx: configuration file /etc/nginx/nginx.conf test failed
Прежде чем решать эту проблему, нужно понять сообщение об ошибке Nginx. В нем есть подсказки, которые помогают определить причину ошибки. В этом случае [emerg] означает “emergency” — это связано с нестабильностью системы. Значит, Nginx столкнулся с проблемой, которая не позволяет ему работать.
Это сообщение об ошибке дополнительно указывает место, где обнаружена ошибка. Имейте в виду, что в настройках Nginx у вас будет свой файл конфигурации, связанный симликом с /etc/nginx/nginx.conf. Если вы следовали мануалу Установка Nginx в Ubuntu 20.04, то в пункте 5 вы видели, как это делается. Указана точная строка в конфигурационном файле с ошибкой: /etc/nginx/sites-enabled/your_domain:5. Также в этом файле есть invalid parameter “root”.
Теперь, когда у вас есть информация, где искать ошибку, вы можете открыть файл в любом текстовом редакторе. Мы будем работать с nano:
sudo nano /etc/nginx/sites-available/your_domain
Примечание: Все конфигурационные файлы можно найти в каталоге /etc/nginx/.
Внутри файла найдите строку 5, на которую ссылается сообщение об ошибке:
server { listen 80; listen [::]:80; root /var/www/your_domain/html index index.html index.htm index.nginx-debian.html; server_name your_domain www.your_domain; location / { try_files $uri $uri/ =404; } }
Ошибка может быть не совсем очевидна. Напоминаем, из сообщения об ошибке следует, что проблема заключается в invalid parameter. Параметры — это аргументы, которые предоставляются директивам Nginx. В этом сценарии /var/www/your_domain/html – и есть это недействительный параметр. Он не работает потому, что в синтаксической структуре отсутствует символ, в данном случае – точка с запятой в конце строки.
Многие строки в этом файле также заканчиваются точкой с запятой. Точка с запятой должна стоять в конце каждой строки, которая содержит директиву. В этом примере у нас присутствует директива root, которая указывает на root каталог, который будет использоваться при поиске файла. Наличие root необходимо для того, чтобы Nginx мог найти определенный URL. Разберем важность директив в следующем разделе.
Если вкратце, исправить эту ошибку можно, добавив точку с запятой в конец этой строки, чтобы директива стала действительна. Это будет выглядеть следующим образом:
… root /var/www/your_domain/html; index index.html index.htm index.nginx-debian.html; …
После исправления сохраните и закройте файл.
Чтобы убедиться, что синтаксическая ошибка исправлена, выполните команду sudo nginx -t.
Неправильно поставленные фигурные скобки
Еще одна распространенная ошибка, которая может возникнуть в синтаксической структуре Nginx, связана с фигурными скобками { }. В отличие от предыдущей ошибки, в которой не было указано, как исправить недопустимый параметр, это сообщение указывает на ее причину:
nginx: [emerg] unexpected "}" in /etc/nginx/sites-enabled/your_domain:15 nginx: configuration file /etc/nginx/nginx.conf test failed
Сообщение об ошибке указывает на строку 15, в которой содержится лишняя фигурная скобка в том же файле конфигурации, что и раньше. Откройте этот файл через текстовый редактор:
server { listen 80; listen [::]:80; root /var/www/your_domain/html; index index.html index.htm index.nginx-debian.html; server_name your_domain www.your_domain; location / { try_files $uri $uri/ =404; }
Внизу файла вы найдете фигурную скобку }. Сначала суть проблемы может быть непонятна, поскольку фигурная скобка вроде бы присутствует на своем месте. Однако при детальном разборе оказывается, что после этой фигурной скобки не хватает еще одной скобки. Правильное количество фигурных скобок в файле конфигурации Nginx очень важно, поскольку они указывают на открытие и закрытие определенного блока. Фигурная скобка в конце файла является закрывающей скобкой для следующего вложенного блока location:
… location / { try_files $uri $uri/ =404; } …
Если просмотреть файл конфигурации еще дальше, то окажется, что в server block также отсутствует закрывающая фигурная скобка. Server block в Nginx важен, поскольку он предоставляет детали конфигурации, необходимые Nginx для определения того, какой виртуальный сервер будет обрабатывать получаемые запросы. Важно отметить, что location blocks вложены в server block, поскольку он имеет приоритет при обработке входящих запросов. Учитывая все это, для завершения server block в конце файла нужно добавить закрывающую фигурную скобку. Теперь содержимое этого файла будет выглядеть следующим образом:
server { listen 80; listen [::]:80; root /var/www/your_domain/html; index index.html index.htm index.nginx-debian.html; server_name your_domain www.your_domain; location / { try_files $uri $uri/ =404; } }
После редактирования не забудьте сохранить и закрыть файл. Чтобы убедиться, что синтаксическая ошибка устранена, запустите sudo nginx -t.
Ошибка invalid host
Эта ошибка возникает из-за неверно сформированного параметра, заданного в директиве. Если завершение строк точкой с запятой и закрытие каждой фигурной скобки относится к общей структуре конфигурационного файла, то параметры – это пользовательские данные, которые могут варьироваться в зависимости от потребностей установки.
Отметим, что в этом сценарии действует директива host, но при недопустимых параметрах любая директива может быть подвержена этой ошибке. Соответственно, изменится и сообщение об ошибке:
[emerg] invalid host in "[::]80" of the "listen" directive in /etc/nginx/sites-enabled/your_domain:3 nginx: configuration file /etc/nginx/nginx.conf test failed
Сообщение объясняет, что установленная директива порта 80 недействительна. Сообщение об ошибке дополнительно указывает место обнаружения ошибки и точную строку в файле конфигурации: /etc/nginx/sites-enabled/your_domain:3. Обладая информацией о том, где найти ошибку, можно открыть файл в текстовом редакторе. Найдите строку 3, на которую ссылается сообщение:
server { listen 80; listen [::]80; root /var/www/your_domain/html; index index.html index.htm index.nginx-debian.html; server_name your_domain www.your_domain; location / { try_files $uri $uri/ =404; } }
Два двоеточия в скобках представляют собой обозначение IPv6 или 0.0.0.0; без дополнительного двоеточия после скобки он не сможет привязаться к порту 80. В результате директива listen не будет работать, поскольку без двоеточия неясно, какой порт должен прослушивать сервер.
В общем, конкретная синтаксическая ошибка здесь заключается в том, что после скобки [::] не хватает двоеточия, а это делает параметр недействительным. После добавления пропущенного двоеточия, фрагмент кода в файле будет выглядеть следующим образом:
server { listen 80; listen [::]:80; …
После обновления этой строки обязательно сохраните и закройте файл и убедитесь, что синтаксическая ошибка исправлена, выполнив команду sudo nginx -t.
В целом, при получении подобных синтаксических ошибок, связанных с параметрами, точками с запятой ; или фигурными скобками { }, рекомендуем обратить особое внимание на точное местоположение и детали в сообщении [emerg].
Выявление неправильных директив – ключевые слова в конфигурационном файле Nginx
Помимо предыдущих синтаксических ошибок, вы можете неправильно написать ключевые слова, связанные с директивой в конфигурационном файле. Мы кратко упоминали директивы в предыдущем разделе, но давайте вернемся к ним подробнее.
Ошибка unknown directive
Как упоминалось ранее, в основе файла конфигурации Nginx лежат директивы. У Nginx большой выбор директив, но есть несколько основных, необходимых практически в каждом в файле конфигурации. Однако существуют ошибки, которые могут возникнуть в самой директиве. Например, ключевое слово написано не совсем так, как должно быть. Вот пример такого сообщения об ошибке:
nginx: [emerg] unknown directive "serve_name" in /etc/nginx/sites-enabled/your_domain:8 nginx: configuration file /etc/nginx/nginx.conf test failed
Эта ошибка указывает на unknown directive “serve_name” в строке 8 файла конфигурации. Откройте файл с помощью текстового редактора:
server { listen 80; listen [::]:80; root /var/www/your_domain/html; index index.html index.htm index.nginx-debian.html; serve_name your_domain www.your_domain; location / { try_files $uri $uri/ =404; } }
В данном примере ошибка — это неправильно написанное слово “server” в имени директивы server_name. В нем пропущена буква “r” и по этой причине директива не распознается. Это серьезная ошибка, поскольку в директиве server_name хранятся конкретные названия серверов, к которым будет обращаться server block при получении запроса. Без корректной работы этой директивы запрос не будет выполнен. Казалось бы, незначительная опечатка, но она нарушает синтаксис и вызывает ошибку. Обновите фрагмент кода в файле конфигурации следующим образом:
… server_name your_domain www.your_domain; …
Сохраните и закройте файл. Проверьте его с помощью команды sudo nginx -t.
Ошибка directive is not allowed here
Теперь предположим, что возникла ошибка с той же директивой, но на этот раз сообщение выглядит так:
nginx: [emerg] "server" directive is not allowed here in /etc/nginx/sites-enabled/your_domain:8 nginx: configuration file /etc/nginx/nginx.conf test failed
Ошибка возникает в том же месте, что и предыдущая, причина проблемы подробно описана в этом сообщении. Поэтому важно понимать, на что указывает сообщение об ошибке. Эта ошибка указывает, что directive is not allowed here. Откройте файл конфигурации в текстовом редакторе:
server { listen 80; listen [::]:80; root /var/www/your_domain/html; index index.html index.htm index.nginx-debian.html; server name your_domain www.your_domain; location / { try_files $uri $uri/ =404; } }
Здесь слово “server” написано правильно, но теперь тут отсутствует символ подчеркивания. Поэтому server воспринимается как дубликат, что недопустимо, о чем и говорит сообщение об ошибке. Это связано с различием между простыми и блочными директивами, о котором мы говорили ранее.
Эта ошибка связана с тем, что без подчеркивания server name читается просто как server и таким образом конфликтует с первой директивой server block в начале файла. Это сложная синтаксическая ошибка, которая может возникнуть из-за иерархической структуры Nginx в файле конфигурации среди блочных директив и вложенных простых директив. Исправить эту ошибку можно, добавив знак подчеркивания:
… server_name your_domain www.your_domain; …
После внесения исправлений сохраните и закройте файл. Затем проверьте правильность синтаксиса с помощью команды sudo nginx -t. Если в файле конфигурации нет ошибок, должно появиться сообщение syntax is ok.
Примечание: В конфигурационных файлах Nginx есть определенная гибкость в отношении интервалов или разделения строк, что не приведет к возникновению ошибок. Однако все, что явно связано с директивами, приведет к ошибке, поскольку для правильной работы необходимы точная формулировка или синтаксическая структура.
Последнее, что нужно рассказать: если файл конфигурации содержит несколько ошибок, сообщения об ошибках будут появляться по одному в последовательном порядке. Это означает, что если вы получили сообщение об одной ошибке и исправили ее, а затем снова запустили команду проверки синтаксиса, то в выводе появится следующая ошибка (если таковая встречается в файле). Так будет продолжаться, пока все ошибки не будут исправлены.
Здесь вы узнали о самых распространенных синтаксических ошибках, которые могут возникнуть с определенными директивами в файле конфигурации веб-сервера. Важно отметить, что все эти примеры представлены в среде терминала. Вы также можете использовать редактор кода, например Visual Studio Code, который может проверять и выделять ошибки в коде, не отправляя многочисленных уведомлений, что позволит исправить их все сразу или даже избежать их на ранней стадии.
Читайте также: Установка командной строки Visual Studio Code
Подводим итоги
В этом мануале мы разобрали распространенные синтаксические ошибки Nginx и поговорили о том, как их исправить. Несмотря на то, что вы можете столкнуться с разными синтаксическими ошибками Nginx, эти примеры дают представление о решениях наиболее частых из них.
Читайте также: Структура и контексты конфигурационного файла Nginx
Tags: NGINX
Оглавление
1. Где смотреть ошибки веб-сервера и как правильно задать вопрос
2. Ошибки Apache в Windows
3. Ошибки PHP в Windows
4. Ошибки MySQL/MariaDB в Windows
5. Ошибки phpMyAdmin в Windows
6. Вопросы и ответы по веб-серверу в Windows
Где смотреть ошибки веб-сервера и как правильно задать вопрос
Некоторые ошибки выводятся при открытии сайтов на локальном хостинге или при тестировании своих скриптов. Такие ошибки обычно сразу показываются в веб-браузере.
Некоторые ошибки не дают нормально установиться и запустится веб-серверу. Такие ошибки могут выводиться в командную строку (правда, не всегда в читаемом виде). Также может возникнуть ситуация, что показываться пустая веб-страница или какой-то компонент веб-сервера просто не запускается без видимых проблем.
В любом случае, самую полную информацию об ошибках Apache и PHP вы найдёте в файле журналов Apache (по ссылке подробности о содержимом и настройке этого файла). Если у вас веб-сервер установлен по этой инструкции, то путь до этого файла такой: C:\Server\bin\Apache24\logs\error.log. В любом случае, файл журнала находится по умолчанию в папке веб-сервера в подпапке logs, либо может быть в другом месте в соответствии с директивой ErrorLog. Также очень важные сообщения, в том числе и ошибки содержаться в файле C:\Server\bin\Apache24\logs\access.log.
Журнал ошибок MySQL и MariaDB находится в файле в C:\Server\data\DB\data\*.err (конкретное имя файла зависит от имени компьютера). Опять же, если вы устанавливали по другой инструкции или у вас другие настройки СУБД, то ищите этот файл в соответствии с вашими установками — по умолчанию он расположен в папке data и имеет расширение *.err.
Если ваша ошибка связана с установкой веб-сервера, то крайне желательно привести логи полностью, поскольку причина проблемы может быть в самых первых действиях.
Если ошибка возникла позже и связана с неправильной работой вашего скрипта или нового тестового сайта, то к этому моменту журналы могут быть переполнены информацией, которые не имеют отношение к этому вопросы. В этом случае, идеально было бы сделать так:
Остановите веб-сервер (иначе невозможно отредактировать файлы журналов):
c:\Server\bin\Apache24\bin\httpd.exe -k stop net stop mysql
Очистите содержимое журналов:
C:\Server\bin\Apache24\logs\error.log C:\Server\data\DB\data\*.err
Вновь запустите веб-сервер:
c:\Server\bin\Apache24\bin\httpd.exe -k start net start mysql
Сразу после этого выполните действие, которое приводит к ошибке. И опять же, сразу после этого скопируйте содержимое журналов ошибок и выложите здесь в комментариях.
При любой ошибке, если вы планируете попросить помощи, ваша задача как можно полнее собрать и предоставить информацию: какие действия приводят к ошибке, какой текст ошибки, что в журналах веб-сервера, устанавливали по инструкции ссылка на которую дана выше или нет (если нет, то как именно), желательно сделать скриншот. Помните, что вам помогают на добровольных началах и «выдавливать» из вас по каплям информацию никому не интересно. Если вы непонятно/неполно изложили свою ситуацию, то, извините, никто из кожи лезть не будет, чтобы во что бы то ни стало вам помочь — по возможности сразу излагайте проблему полно и ясно.
Ошибки Apache в Windows
Ошибка:
Когда я кликаю на httpd.exe, мелькает чёрное окно, а затем исчезает
Решение:
Решение смотрите здесь: Окно Apache появляется и сразу пропадает (РЕШЕНО)
Ошибка:
Никак не могу установить apache, выдаёт ошибку:
AH00558: httpd.exe: Could not reliably determine the server's fully qualified domain name, using fe80::7978:6c40:7af5:6ea5. Set the 'ServerName' directive globally to suppress this message
Решение:
Это предупреждение, а не ошибка. По идее, Apache должен всё равно работать. У вас http://localhost/ открывается?
Чтобы это предупреждение не выводилось (цитата из инструкции):
меняем
#ServerName www.example.com:80
на
ServerName localhost
Ошибка:
При запуске httpd я получаю следующее сообщение:
(OS 10048)Обычно разрешается только одно использование адреса сокета (протокол/сетевой адрес/порт). : AH00072: make_sock: could not bind to address 0.0.0.0:80
AH00451: no listening sockets available, shutting down
AH00015: Unable to open logs
В качестве ОС использую Windows 8.1
Решение:
Данная ошибка вызвана тем, что какая-то программа прослушивает порт 80, при этом Apache пытается использовать этот же порт. Но две программы не могут это делать одновременно – отсюда и ошибка.
Для того, чтобы узнать, какая программа занимает этот порт:
1) нажмите сочетание клавиш WIN + x
2) из открывшегося списка выберете «Командная строка (администратор)»
3) скопируйте туда:
netstat -ano
4) Найдите строку, содержащую «0.0.0.0:80», в этой строчке нас интересует PID, например, в моём случае это 2168
Теперь нам нужно сопоставить идентификатор процесса с конкретной программой. Чтобы сопоставить идентификатор процесса программы, выполните следующие действия:
5) Нажмите сочетание клавиш WIN + x (или CTRL + ALT + DELETE) и нажмите кнопку «Диспетчер задач».
6) Перейдите на вкладку «Процессы».
7) Если не имеется столбец PID, щелкните «Просмотр», «Выбрать столбцы» и установите флажок «PID» (в русской версии – «ИД процесса»).
Щелкните заголовок столбца, под названием «PID» сортировка процесс по PID. Вы сможете легко найти идентификатор процесса, и он соответствует программе, которая отображается в диспетчере задач.
После того, как найдёте программу, которая занимает этот порт, в зависимости от нужности этой программы и от возможности её настройки, можно:
а) удалить эту программу;
или
б) настроить её на использование другого порта;
или
в) настроить Apache на использование другого порта
п.с. на самом деле, могут быть другие причины данной ошибки (кроме занятости порта) – например, неправильная конфигурация сервера Apache, либо запрет в политиках безопасности ОС на использование этого порта. Но если Вы не вносили изменений «от себя» в конфигурацию сервера и в конфигурацию Windows, то дело, почти наверняка, в занятости порта другой программой.
Ответ пользователя с ошибкой: Проблема решена — порт занимал Скайп (есть у него такая бяка в настройках соединения — использовать порты 80 и 443 в качестве альтернативных, после того, как я отключил эту опцию, всё заработало).
Ошибка:
Сервер замедляется, перестаёт отвечать на запросы, хотя причин для этого нет — он не перегружен.
В логах появляется ошибка AH00341: winnt_accept: Asynchronous AcceptEx failed:
[Thu Jun 05 07:24:55.747090 2014] [mpm_winnt:notice] [pid 1784:tid 444] AH00455: Apache/2.4.9 (Win64) PHP/5.5.13 configured — resuming normal operations [Thu Jun 05 07:24:55.747090 2014] [mpm_winnt:notice] [pid 1784:tid 444] AH00456: Apache Lounge VC11 Server built: Mar 16 2014 12:42:59 [Thu Jun 05 07:24:55.747090 2014] [core:notice] [pid 1784:tid 444] AH00094: Command line: 'c:\\Server\\bin\\Apache24\\bin\\httpd.exe -d C:/Server/bin/Apache24' [Thu Jun 05 07:24:55.748090 2014] [mpm_winnt:notice] [pid 1784:tid 444] AH00418: Parent: Created child process 4952 [Thu Jun 05 07:24:55.957978 2014] [mpm_winnt:notice] [pid 4952:tid 388] AH00354: Child: Starting 64 worker threads. [Thu Jun 05 07:26:16.695036 2014] [mpm_winnt:warn] [pid 4952:tid 1112] (OS 64)Указанное сетевое имя более недоступно. : AH00341: winnt_accept: Asynchronous AcceptEx failed. [Thu Jun 05 07:26:16.695036 2014] [mpm_winnt:warn] [pid 4952:tid 1112] (OS 64)Указанное сетевое имя более недоступно. : AH00341: winnt_accept: Asynchronous AcceptEx failed. [Thu Jun 05 07:26:48.250710 2014] [mpm_winnt:warn] [pid 4952:tid 1112] (OS 64)Указанное сетевое имя более недоступно. : AH00341: winnt_accept: Asynchronous AcceptEx failed. [Thu Jun 05 07:26:48.250710 2014] [mpm_winnt:warn] [pid 4952:tid 1112] (OS 64)Указанное сетевое имя более недоступно. : AH00341: winnt_accept: Asynchronous AcceptEx failed. [Thu Jun 05 07:29:27.137784 2014] [mpm_winnt:warn] [pid 4952:tid 1112] (OS 64)Указанное сетевое имя более недоступно. : AH00341: winnt_accept: Asynchronous AcceptEx failed. [Thu Jun 05 07:29:27.137784 2014] [mpm_winnt:warn] [pid 4952:tid 1112] (OS 64)Указанное сетевое имя более недоступно. : AH00341: winnt_accept: Asynchronous AcceptEx failed.
Решение:
В файл httpd.conf нужно добавить следующие строки:
Для 2.2:
Win32DisableAcceptEx EnableSendfile off EnableMMAP off
Для 2.4:
AcceptFilter http none AcceptFilter https none EnableSendfile off EnableMMAP off
Ошибка:
работать с сервером не могу пока не запущу Apache Monitor.exe, сам Apache в службах значится -как запущенная служба, но через браузер (localhost и т.д.) никакой реакции, пока не произведу вышеуказанное действие, получается запускать апач монитор надо каждый раз для работы c сервером?
сделал чтоб консоль не закрывалась вот что пишет
C:\Server\bin\Apache24\bin>httpd.exe
AH00526: Syntax error on line 241 of C:/Server/bin/Apache24/conf/httpd.conf:
DocumentRoot must be a directory
Решение:
наиболее вероятная причина в том, что Вы ставите не на диск C, либо поменяли пути, названия папок, либо не создали папки, о которых говорится в статье. Суть в том, что Apache не видит каталога c:/Server/data/htdocs/
Оказалось, что: нашёл решение проблемы по запарке каталог data создал в bin действительно на свежую голову думается лучше а то после работы ничего не мог понять))
Ошибка:
Появилась проблема: до момента добавления строк
PHPIniDir "C:/Server/bin/PHP" AddHandler application/x-httpd-php .php LoadModule php5_module "C:/Server/bin/PHP/php5apache2_4.dll"
все работает, как надо. Но как только вставляю их в конец файла httpd.conf. выдает ошибку «the requested operation has failed». В логах
Restarting the server. httpd.exe: Syntax error on line 532 of C:/Server/bin/Apache24/conf/httpd.conf: Cannot load C:/Server/bin/PHP/php5apache2_4.dll into server: \xcd\xe5 \xed\xe0\xe9\xe4\xe5\xed \xf3\xea\xe0\xe7\xe0\xed\xed\xfb\xe9 \xec\xee\xe4\xf3\xeb\xfc. [Mon Jul 06 02:38:24.688572 2015] [mpm_winnt:notice] [pid 2916:tid 392] AH00364: Child: All worker threads have exited.
Решение:
Необходимо установить Visual C++ Redistributable for Visual Studio 2017 (или любой другой более поздний).
Ошибки PHP в Windows
Ошибка:
При запуске команды «c:Server\bin\Apache24\bin\httpd.exe -k restart» машина выдала следующее:
httpd.exe: Syntax error on line 537 of C:/Server/Bin/Apache24/conf/httpd.conf: Cannot load C:/Server/bin/PHP/php7apache2_4.dll into server: \xed\xe5 \xed\xe0\xe9\xe4\xe5\xed\xf3\xea \xe0\xe7\xe0\xed\xed\xfb\xe9\xec\xee\xe4\xf3\xeb\xfc.
В папке PHP отсутствует файл php7apache2_4.dll, но имеются файлы php7.dll и php7phpdbg.dll.
Решение:
Вы скачали архив с версией для отладки. Посмотрите здесь, как правильно выбрать нужный файл.
Ошибка:
Вчера настроил всё, всё работает, но вот перенёс сайт и выдало ошибку:
Parse error: syntax error, unexpected 'new' (T_NEW) in C:\Server\data\htdocs\includes\joomla.php on line 840.
Решение:
Дело в версии PHP. Обновите движок вашего сайта. Если обновлений нет, то нужно править исходный код, подробности смотрите в статье «Решение проблемы на PHP 7: Parse error: syntax error, unexpected T_NEW».
Ошибка:
Fatal error: Uncaught Error: Call to undefined function mysql_connect() in C:\Server\data\htdocs\test.php:2 Stack trace: #0 {main} thrown in C:\Server\data\htdocs\test.php on line 2
вот что написано на test.php
<?php
$resource = mysql_connect('localhost','root', 'NFSmostwanted22');
if (!$resource) {
die('Ошибка при подключении: ' . mysql_error());
}
echo 'Подключено успешно!';
mysql_close($resource);
?>
Ещё один вариант ошибки:
Создал в папке C:\Server\data\htdocs файл_test0000.html следующего содержания:
<html><head>
<link href="../css/phpMM.css" rel="stylesheet" type="text/css" />
</head><body>
<?php
$link1 = mysql_connect('localhost', 'root');
?>
</body></html>
и получаю сообщение:
Fatal error: Uncaught Error: Call to undefined function mysql_connect() in C:\Server\data\htdocs\_test0000.html:7 Stack trace: #0 {main} thrown in C:\Server\data\htdocs\_test0000.html on line 5
Решение:
Данное расширение — mysql_connect() — устарело, начиная с версии PHP 5.5.0, и удалено начиная с PHP 7.0.0. Используйте вместо него MySQLi или PDO_MySQL. Альтернативы для данной функции:
- mysqli_connect()
- PDO::__construct()
Ошибка:
Fatal error: Call to undefined function mb_detect_encoding() in C:\server\data\htdocs\phpmyadmin\libraries\php-gettext\gettext.inc on line 177
Решение:
Данная ошибка вызвана тем, что не подключено расширение mbstring. За это расширение в php.ini отвечает строчка
extension=php_mbstring.dll
Понятно, что для исправления ошибки нужно подключить расширение и перезапустить сервер (если не хотите ставить все расширения, как это описано в инструкции, то прежде чем выбрать, что Вам действительно нужно, лучше изучить описание каждого из них).
Тем не менее, теоретически, ошибка может быть вызвана тем, что из-за неправильной конфигурации Apache, файл php.ini вообще не «подхватывается» и PHP работает на дефолтных настройках, т.е. вообще без всех расширений. Но если это было бы так, то phpMyAdmin, в первую очередь пожаловался на то, что не определена другая функция (из-за отсутствия расширения отвечающего за связь с MySQL).
Ошибка:
phpMyAdmin выдаёт ошибку http 500.
Ставлю сервер на Windows 7. Apache и MySQL встали нормально по Вашей инструкции. Дошёл до PHP. Скачал архив php-7.2.3-Win32-VC15-x64.zip. Добавил в конец файла httpd.conf строки по инструкции. Перезапускаю Apache.
C:\Users\Администратор>c:\Server\bin\Apache24\bin\httpd.exe -k restart
Получаю в командной строке сообщение:
httpd.exe: Syntax error on line 537 of C:/Server/Bin/Apache24/conf/httpd.conf: Cannot load C:/Server/bin/PHP/php7apache2_4.dll into server: %1 \xed\xe5 \xff\xe2 \xeb\xff\xe5\xf2\xf1\xff \xef\xf0\xe8\xeb\xee\xe6\xe5\xed\xe8\xe5\xec Win32.
В файле error.log появились строчки:
[Sun Mar 25 10:22:52.208678 2018] [mpm_winnt:notice] [pid 2608:tid 292] AH00455: Apache/2.4.33 (Win64) configured -- resuming normal operations [Sun Mar 25 10:22:52.224278 2018] [mpm_winnt:notice] [pid 2608:tid 292] AH00456: Apache Lounge VC15 Server built: Mar 18 2018 12:58:47 [Sun Mar 25 10:22:52.224278 2018] [core:notice] [pid 2608:tid 292] AH00094: Command line: 'c:\\Server\\bin\\Apache24\\bin\\httpd.exe -d C:/Server/Bin/Apache24' [Sun Mar 25 10:22:52.224278 2018] [mpm_winnt:notice] [pid 2608:tid 292] AH00418: Parent: Created child process 2696 [Sun Mar 25 10:22:52.583079 2018] [mpm_winnt:notice] [pid 2696:tid 180] AH00354: Child: Starting 64 worker threads. "Syntax error in 524 line Cannont load "C:/Server/bin/PHP/php7apache2_4.dll" to server"
Решение
То был другой архив: php-7.2.3-Win32-VC15-x86.zip.
Скачал х64 и все заработало!
Ошибка:
возникла странная ошибка, причин которой понять не могу.
Стоит только добавить в каталог к PHP файл php.ini с любыми настройками, перестают выполняться php-скрипты. Убираю файл, перезапускаю Apache — работает (естественно до момента работы с базами данных например, тогда начинает просить расширения)
Решение:
Ответил сам пользователь: Оказалось, что в конфиге php по умолчанию выключена поддержка коротких тегов . Стоило ее включить и сразу все заработало 🙂
Ошибка:
В логах веб-сервера при каждом запуске Apache появляются ошибки:
PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\Server\\bin\\PHP\\ext\\php_curl.dll' - \xef\xbf\xbd\xef\xbf\xbd \xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd \xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd \xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\Server\\bin\\PHP\\ext\\php_intl.dll' - \xef\xbf\xbd\xef\xbf\xbd \xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd \xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd \xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\Server\\bin\\PHP\\ext\\php_ldap.dll' - \xef\xbf\xbd\xef\xbf\xbd \xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd \xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd \xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\Server\\bin\\PHP\\ext\\php_pdo_pgsql.dll' - \xef\xbf\xbd\xef\xbf\xbd \xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd \xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd \xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\Server\\bin\\PHP\\ext\\php_pgsql.dll' - \xef\xbf\xbd\xef\xbf\xbd \xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd \xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd \xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd.\r\n in Unknown on line 0
Как их исправить?
Решение:
Вам нужно добавить путь до PHP в переменную окружения PATH в Windows.
Ошибка:
При использовании некоторых скриптов и CMS возникает ошибки:
Fatal error: Call to undefined function curl_multi_init() in …
Или:
Ошибка curl: SSL certificate problem: unable to get local issuer certificate
Решение:
Причина ошибки в том, что cURL настроена неправильно.
Чтобы cURL работала в Apache на Windows вам нужно:
1) Обязательно добавить PHP директорию в PATH (системные переменные среды). Как это сделать сказано чуть выше или здесь https://hackware.ru/?p=21#11
2) В файле C:\Server\bin\PHP\php.ini должна быть раскомментирована строка extension=curl
3) Необходимо скачать файл https://curl.haxx.se/ca/cacert.pem, затем в папке C:\Server\ создать новую папку с именем certs и в эту новую папку (C:\Server\certs\) переместите скаченный файл.
4) В файле C:\Server\bin\PHP\php.ini найдите строку
;curl.cainfo =
И замените её на
curl.cainfo = C:\Server\certs\cacert.pem
5) Перезапустите сервер.
Ошибка:
Выполнила 1-6 и также увидела
Fatal error: Uncaught Error: Call to undefined function mb_detect_encoding() in C:\Server\data\htdocs\phpmyadmin\libraries\php-gettext\gettext.inc:177 Stack trace: #0 C:\Server\data\htdocs\phpmyadmin\libraries\php-gettext\gettext.inc(282): _encode('The %s extensio…')
#1 C:\Server\data\htdocs\phpmyadmin\libraries\php-gettext\gettext.inc(289): _gettext('The %s extensio…')
#2 C:\Server\data\htdocs\phpmyadmin\libraries\core.lib.php(306): __('The %s extensio…')
#3 C:\Server\data\htdocs\phpmyadmin\libraries\core.lib.php(961): PMA_warnMissingExtension('mbstring', true)
#4 C:\Server\data\htdocs\phpmyadmin\libraries\common.inc.php(102): PMA_checkExtensions()
#5 C:\Server\data\htdocs\phpmyadmin\index.php(13): require_once('C:\\Server\\data\\…')
#6 {main} thrown inC:\Server\data\htdocs\phpmyadmin\libraries\php-gettext\gettext.inc on line 177
При этом extension_dir = «C:\Server\bin\PHP\ext\» прописано именно так.
На других форумах пишут, что должно быть активно mbstring. Но мы его раскомментировали. Либо надо ещё что-то сделать ?
Решение:
После внесения изменений в файлы настроек нужно перезапустить сервер.
Если сервер перезапустили, а ошибка осталась, то одним из случаев может быть когда файл php.ini не подхватывается сервером. У меня получается так сделать, если при настройке Apache я добавляю строки
AddHandler application/x-httpd-php .php LoadModule php7_module "C:/Server/bin/PHP/php7apache2_4.dll"
А строку
PHPIniDir "C:/Server/bin/PHP"
не добавляю или пишу её с ошибкой.
Чтобы убедиться, что дело именно в том, что не подхватывается файл php.ini, выполните phpinfo (); (в статье описано, как это сделать) и найдите там Loaded Configuration File. Если запись такая:
То дело именно в этом.
Правильно должно быть так:
Loaded Configuration File C:\Server\bin\PHP\php.ini
Ответ пользователя: Оказалось, что php.ini-development надо было переименовать в просто php.
Ошибка:
Что-то у меня проблема с кодировкой. Если utf-8, то нормально. А 1251 странно глючит.
Все вроде нормально. Упростил код до безобразия
<html> <head> <META http-equiv="Content-Type" content="text/html; charset=windows-1251"> <title>Проверка кодировки</title> </head> <body> <h1>Тестовый файл для проверки кодировки</h1> </body> </html>
Если файлу дать расширение html то в норме, а рсширение php — не работает, кракозябры идут, сам автоматом в utf перебрасывает.
AddDefaultCharset off AddDefaultCharset WINDOWS-1251
не помогает
Решение:
Не нужно забывать о таком варианте, когда ваши действия по установке кодировки работают, но крякозяблы появляются от того, что сам файл в неправильной кодировке.
Установка кодировки в коде файла или в файле .htaccess влияет только на то, как браузер будет трактовать этот файл, но не конвертирует его в другую кодировку.
То есть, допустим, ваш файл реально сохранён в кодировке utf-8. Вы указываете в качестве кодировки windows-1251. И это работает: браузер трактует ваш файл как windows-1251, но показывает крякозяблы, поскольку на самом-то деле это utf-8.
Поэтому начните с того, что проверьте кодировку файла и при необходимости пересохраните в нужной кодировке.
Если кодировка правильная, то для PHP файла безотказно работает
header('Content-Type: text/html; charset=utf-8');
Эта функция отправляет нужную кодировку в заголовке. Она должна идти до любого вывода текста на экран. Кодировку поменяйте на свою.
У меня есть целая статья про кодировку «Решение проблем неправильной кодировкой веб-страницы». Там в конце показано, как проверить HTTP заголовки с помощью cURL, которые отправляются сервером.
Программа curl есть и в Windows, поэтому если у вас прям ничего не получится, то напишите, что выводит curl.
Ошибки MySQL/MariaDB в Windows
Ошибка:
Found option without preceding group in config file
mysqld: [ERROR] Found option without preceding group in config file C:\Server\bin\mysql-8.0\my.ini mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
Решение:
Ошибка в конфигурационном файле my.ini — пропущена секция [mysqld] или что-то подобное.
Ошибка:
MySQL сервер не запускается
Если MySQL не запускается, а в журнале ошибок вы видите строки Column count of mysql.user is wrong. Expected 51, found 49. The table is probably corrupted (количество колонок не соответствует ожидаемому, возможно таблица повреждена), а также Cannot load from mysql.tables_priv. The table is probably corrupted! (не получается прочитать из таблицы, возможно таблица повреждена), например:
2019-09-04T16:26:31.008436Z 0 [Warning] [MY-013143] [Server] Column count of mysql.user is wrong. Expected 51, found 49. The table is probably corrupted 2019-09-04T16:26:31.008449Z 0 [Warning] [MY-013139] [Server] Cannot load from mysql.db. The table is probably corrupted! 2019-09-04T16:26:31.008465Z 0 [Warning] [MY-013139] [Server] Cannot load from mysql.tables_priv. The table is probably corrupted! 2019-09-04T16:26:31.008482Z 0 [Warning] [MY-013139] [Server] Cannot load from mysql.tables_priv. The table is probably corrupted! 2019-09-04T16:26:31.008501Z 0 [Warning] [MY-013139] [Server] Cannot load from mysql.columns_priv. The table is probably corrupted! 2019-09-04T16:26:31.008509Z 0 [Warning] [MY-013139] [Server] Cannot load from mysql.procs_priv. The table is probably corrupted! 2019-09-04T16:26:31.008517Z 0 [Warning] [MY-013139] [Server] Cannot load from mysql.procs_priv. The table is probably corrupted! 2019-09-04T16:26:31.008525Z 0 [Warning] [MY-013139] [Server] Cannot load from mysql.proxies_priv. The table is probably corrupted! 2019-09-04T16:26:31.008532Z 0 [Warning] [MY-013139] [Server] Cannot load from mysql.proxies_priv. The table is probably corrupted! 2019-09-04T16:26:31.008539Z 0 [Warning] [MY-013139] [Server] Cannot load from mysql.proxies_priv. The table is probably corrupted! 2019-09-04T16:26:31.008547Z 0 [Warning] [MY-013139] [Server] Cannot load from mysql.role_edges. The table is probably corrupted! 2019-09-04T16:26:31.008554Z 0 [Warning] [MY-013139] [Server] Cannot load from mysql.role_edges. The table is probably corrupted! 2019-09-04T16:26:31.008562Z 0 [Warning] [MY-013139] [Server] Cannot load from mysql.default_roles. The table is probably corrupted! 2019-09-04T16:26:31.008569Z 0 [Warning] [MY-013139] [Server] Cannot load from mysql.default_roles. The table is probably corrupted! 2019-09-04T16:26:31.008577Z 0 [Warning] [MY-013139] [Server] Cannot load from mysql.global_grants. The table is probably corrupted! 2019-09-04T16:26:31.008584Z 0 [Warning] [MY-013139] [Server] Cannot load from mysql.password_history. The table is probably corrupted! 2019-09-04T16:26:31.008845Z 0 [ERROR] [MY-013139] [Server] Cannot load from mysql.global_grants. The table is probably corrupted! 2019-09-04T16:26:31.008938Z 0 [ERROR] [MY-010952] [Server] The privilege system failed to initialize correctly. For complete instructions on how to upgrade MySQL to a new version please see the 'Upgrading MySQL' section from the MySQL manual. 2019-09-04T16:26:31.017728Z 0 [ERROR] [MY-010119] [Server] Aborting 2019-09-04T16:26:32.072392Z 0 [System] [MY-010910] [Server] C:\Server\bin\mysql-8.0\bin\mysqld: Shutdown complete (mysqld 8.0.17) MySQL Community Server - GPL.
Решение:
Если у вас что-то подобное, то попробуйте выполнить обновление.
Для этого переходим в папку с установленной СУБД (у вас путь может быть другим):
cd C:\Server\bin\mysql-8.0\bin\
Я запустил программу для обновления баз данных при переходе на новую версию MySQL:
./mysql_upgrade.exe -uroot
Но она мне сообщила:
>> The mysql_upgrade client is now deprecated. The actions executed by the upgrade client are now done by the server. To upgrade, please start the new MySQL binary with the older data directory. Repairing user tables is done automatically. Restart is not required after upgrade. The upgrade process automatically starts on running a new MySQL binary with an older data directory. To avoid accidental upgrades, please use the --upgrade=NONE option with the MySQL binary. The option --upgrade=FORCE is also provided to run the server upgrade sequence on demand. It may be possible that the server upgrade fails due to a number of reasons. In that case, the upgrade sequence will run again during the next MySQL server start. If the server upgrade fails repeatedly, the server can be started with the --upgrade=MINIMAL option to start the server without executing the upgrade sequence, thus allowing users to manually rectify the problem.
В этом сообщении сказано, что клиент mysql_upgrade теперь устарел. Его функции по обновлению выполняет сам сервер автоматически. Чтобы запретить обновление, нужно запустить с опцией —upgrade=NONE. Для запроса обновления, нужно запустить с опцией —upgrade=FORCE.
Я запустил следующим образом:
.\mysqld.exe --upgrade=FORCE
и проблема с чтением таблиц была решена.
Ошибка:
Системная ошибка 1067.
При попытке запуске MySQL или MariaDB может возникнуть ошибка:
Служба "MySQL" запускается.. Не удалось запустить службу "MySQL". Системная ошибка. Системная ошибка 1067. Процесс был неожиданно завершен.
Решение:
Ошибка связана с тем, что не была выполнена инициализация базы данных — это необходимо сделать один раз после установке. В процессе инициализации создаётся необходимая для работы СУБД база данных, в которой храниться техническая информация (например, созданные пользователи, информация о таблицах и так далее).
Если у вас указанная выше ошибка возникла в MySQL, то выполните команды:
C:\Server\bin\mysql-8.0\bin\mysqld --initialize-insecure --user=root C:\Server\bin\mysql-8.0\bin\mysqld --install net start mysql
В этих командах исполнимые файлы MySQL расположены в папке C:\Server\bin\mysql-8.0\, расположение базы данных взято из файла my.cnf (переменная datadir).
а база данных должна быть создана в C:\Server\data\DB\data\. Если у вас другое расположение файлов, то отредактируйте предыдущие команды под ваши условия.
Если у вас указанная выше ошибка возникла в MariaDB, то выполните команды:
C:\Server\bin\mariadb\bin\mysql_install_db.exe --datadir=C:\Server\data\DB\data\ C:\Server\bin\mariadb\bin\mysqld --install net start mysql
В этих командах исполнимые файлы MariaDB расположены в папке C:\Server\bin\mariadb, а база данных должна быть создана в C:\Server\data\DB\data\. Если у вас другое расположение файлов, то отредактируйте предыдущие команды под ваши условия.
Подробности смотрите в статье «Как установить MariaDB 7.4 в Windows».
Ошибка:
Ошибки «Can’t create test file c:\Server\data\DB\data\MiAl-PC.lower-test» и «Can’t change dir to ‘c:\Server\data\DB\data\’ (Errcode: 2 «No such file or directory»)»
Если во время инициализации или при запуске службы СУБД у вас возникли примерно следующие ошибки:
2019-07-07 5:40:58 0 [Note] C:\Server\bin\mariadb\bin\mysqld.exe (mysqld 10.4.6-MariaDB) starting as process 12084 ... 2019-07-07 5:40:58 0 [Warning] Can't create test file c:\Server\data\DB\data\MiAl-PC.lower-test C:\Server\bin\mariadb\bin\mysqld.exe: Can't change dir to 'c:\Server\data\DB\data\' (Errcode: 2 "No such file or directory") 2019-07-07 5:40:58 0 [ERROR] Aborting
Решение:
Они означают, что отсутствует папка, в которой должны храниться базы данных. Для исправления достаточно создать необходимую папку.
Ошибка:
Ошибки InnoDB: Operating system error number 87 in a file operation и File .\ib_logfile101: ‘aio write’ return OS error 187.
Решение:
Если инициализация завершилась неудачей и в папке C:\Server\data\DB\data\ недостаёт файлов, а в логе ошибок C:\Server\data\DB\data\*.err вы видите примерно следующие записи:
[ERROR] InnoDB: Operating system error number 87 in a file operation [ERROR] InnoDB: File .\ib_logfile101: 'aio write' return OS error 187. [ERROR] InnoDB: Cannot continue operation
То для решения этой проблемы удалите всё содержимое папки C:\Server\data\DB\data\ и в файл my.ini добавьте ещё одну строчку:
innodb_flush_method=normal
Теперь инициализируйте MySQL ещё раз:
C:\Server\bin\mysql-8.0\bin\mysqld --initialize-insecure --user=root C:\Server\bin\mysql-8.0\bin\mysqld --install net start mysql
Ошибка:
Исправление MySQL после неудачной инициализации
Если вы что-то сделали не так при инициализации (например, указали не все рекомендуемые опции), то при последующей инициализации у вас тоже ничего не получится и в журнале ошибок будет примерно следующее:
[ERROR] [MY-010457] [Server] --initialize specified but the data directory has files in it. Aborting. [ERROR] [MY-013236] [Server] Newly created data directory c:\Server\data\DB\data\ is unusable. You can safely remove it. [ERROR] [MY-010119] [Server] Aborting
Решение:
В этом случае нужно остановить MySQL сервер:
net stop mysql c:\Server\bin\mysql-8.0\bin\mysqld --remove
Очистите содержимое папки C:\Server\data\DB\data\ (удалите всё из неё).
Теперь инициализируйте MySQL ещё раз:
C:\Server\bin\mysql-8.0\bin\mysqld --initialize-insecure --user=root C:\Server\bin\mysql-8.0\bin\mysqld --install net start mysql
Ошибка:
Подскажите, пожалуйста, почему при инициализации MySQL 8.0.13 в каталоге C:\Server\data\DB\data\ ничего не появляется. Все файлы появляются в каталоге C:\Server\bin\mysql-8.0\data. В файле ошибок SVO5195.err (находится в C:\Server\bin\mysql-8.0\data) следующая информация:
2019-01-04T10:01:56.830374Z 0 [System] [MY-013169] [Server] C:\Server\bin\mysql-8.0\bin\mysqld.exe (mysqld 8.0.13) initializing of server in progress as process 8860 2019-01-04T10:02:02.311887Z 5 [Warning] [MY-010453] [Server] root@localhost is created with an empty password ! Please consider switching off the --initialize-insecure option. 2019-01-04T10:02:05.511185Z 0 [System] [MY-013170] [Server] C:\Server\bin\mysql-8.0\bin\mysqld.exe (mysqld 8.0.13) initializing of server has completed
Решение:
Папка C:\Server\data\DB\data\ прописана в файле my.ini.
Получается причина ошибки только одна: вы или не создали файл my.ini, или создали его неправильно, или создали его не в том месте, или не записали туда директиву с C:\Server\data\DB\data\ — то есть что-то такое.
Ответ пользователя: Разобрался. Причина была в том, что я создавал файл my.ini.txt вместо my.ini. Не обратил внимания на отображение расширений в Проводники. Ошибка — глупая, но, думаю, сократит многим новоначальным время, если её указать.
Ошибка:
Я устанавливал себе MariaDB по вашей статье и возникла ошибка 1067. Что мне делать?
Решение:
Внимание: этот ответ подходит только для MariaDB 7.3 и более ранних версий!
Любые ошибки возникают только если хоть в чём-то отойти от мануала. Вы пропустили это:
Переместите папку C:\Server\bin\mariadb\data\ в папку C:\Server\data\DB\.
Ошибка:
Захожу http://localhost/phpmyadmin/index.php ввожу лог root а мне пишет ошибка — Невозможно подключиться к серверу MySQL.
Решение:
Такая ошибка возникает если не установлен или не запущен сервер MySQL. Внимательнее изучите инструкции https://hackware.ru/?p=21 и https://hackware.ru/?p=7033
Ошибка:
При установке Mysql когда я набираю в консоль mysql -u root, выдается ошибка ERROR 2003, can’t connect to mysql (10061), добавлю что открыл порт 3306 в брандмауре
Решение:
Это точно такая же ситуация как и в предыдущей ошибке: она возникает если не установлен или не запущен сервер MySQL. Внимательнее изучите инструкции https://hackware.ru/?p=21 и https://hackware.ru/?p=7033
Ошибка:
Эта версия mysqld.exe не совместима с Windows, работающей на этом компьютере
При попытке установить MySQL, либо при любой попытке запустить какой-либо исполнимый файл MySQL может возникнуть ошибка:
Эта версия mysqld.exe не совместима с Windows, работающей на этом компьютере. Проверьте сведения о системе, а затем обратитесь к издателю программного обеспечения.
Решение:
Причина ошибки в том, что делается попытка установить MySQL на 32-битный Windows. Архив «Windows (x86, 64-bit), ZIP Archive» содержит в себе только версию для 64-битных систем (хотя название файла название может сбить с толку).
В виде отдельного портативного архива MySQL больше недоступна для 32-битных систем.
Из этой ситуации есть два выхода:
- воспользоваться установщиком MySQL Installer (он на той же странице, где вы скачивали MySQL — большой такой банер). Как сказано в описании, там «все продукты MySQL» — что нужно и что не нужно, в том числе 32-битная версия. Установка проходит в графическом интерфейсе, настройка тоже выполняется из графического интерфейса и, как бы это не было странно, занимает больше времени, чем установка из портативного архива. Но, в принципе, ничего сложного;
- перейти на MariaDB. Это улучшенная версия MySQL, которая является бесплатной, но в ней собраны функции платных вариантов MySQL. Портативный архив с версией для 32-битных систем имеется. Сейчас много кто перешёл с MariaDB на MySQL (в том числе хостинги). У меня на компьютере тоже установлена именно MariaDB вместо MySQL. Инструкция по установке всего веб-сервера здесь: https://hackware.ru/?p=7033 (там точно такая же инструкция как и здесь, но вместо MySQL показана установка MariaDB). Что касается работы сайтов, то для них MySQL и MariaDB абсолютно равнозначны.
Ошибка:
После выполнения команд :
C:\Server\bin\mysql-8.0\bin\mysqld --initialize-insecure --user=root C:\Server\bin\mysql-8.0\bin\mysqld --install net start mysql
база данных в C:\Server\data\DB\data\ не создаётся.
Решение:
Выяснилось, что файл my.ini был создан как my.ini.txt. Также причинами может быть то, что файл my.ini не был создан вовсе или в него неправильно скопировали настройки.
Ошибка:
я попыталась выполнить «инициализацию и установку» через командную строку от имени администратора. Введя первую строку (C:\Server\bin\mysql-8.0\bin\mysqld —initialize-insecure —user=root) я получила ответ, что системе не удается найти путь.
Решение:
Неверно названы папки, либо при сооздании папок для сервера что-то сделано неправильно.
Ошибка:
Также попробовала из самой папки C:\Server\bin\mysql-8.0\bin\ открыть файл mysqld.exe (подумала,что именно его я открываю в командной строке), тут появилась системная ошибка, что «Не удается продолжить выполнение кода, поскольку система не обнаружила VCRUNTIME140_1.dll. Для устранения этой проблемы попробуйте переустановить программу.»
Решение:
Файл VCRUNTIME140_1.dll не найден потому что не установили Visual C++ Redistributable for Visual Studio 2015-2019.
Ошибка:
При попытке запустить MySQL данная служба не запускаются и появляются ошибки:
Служба "MySQL" запускается…….. Не удалось запустить службу "MySQL". Для вызова дополнительной справки наберите NET HELPMSG 3523. ошибка источник PHP-8.1.1 php[13708]
А также:
Не удалось запустить службу "MySQL". Для вызова дополнительной справки наберите NET HELPMSG 3534.
Подроности причины ошибки:
PHP Warning: PHP Startup: Unable to load dynamic library 'PDO_OCI' PHP Warning: PHP Startup: Unable to load dynamic library 'PDO_OCI' (tried: C:\Server\bin\PHP\ext\PDO_OCI (Не найден указанный модуль), C:\Server\bin\PHP\ext\php_PDO_OCI.dll (Не найден указанный модуль)) (C:\Server\bin\Apache24\bin\httpd.exe -d C:/Server/bin/Apache24)
Решение:
Причина ошибки в том, что активировано расширение pdo_oci. Отключите его в файле php.ini:
;extension=pdo_oci
Ошибка:
Deprecation Notice in .\vendor\twig\twig\src\Loader\FilesystemLoader.php#40 realpath(): Passing null to parameter #1 ($path) of type string is deprecated Backtrace .\vendor\twig\twig\src\Loader\FilesystemLoader.php#40: realpath(NULL) .\libraries\classes\Template.php#57: Twig\Loader\FilesystemLoader->__construct(string 'C:\\Server\\data\\htdocs\\-phpmyadmin\\\\templates\\') .\libraries\classes\Theme.php#101: PhpMyAdmin\Template->__construct() .\libraries\classes\Theme.php#174: PhpMyAdmin\Theme->__construct() .\libraries\classes\ThemeManager.php#307: PhpMyAdmin\Theme::load( string './themes/metro', string 'C:\\Server\\data\\htdocs\\-phpmyadmin\\./themes/metro/', ) .\libraries\classes\ThemeManager.php#79: PhpMyAdmin\ThemeManager->loadThemes() .\libraries\classes\ThemeManager.php#121: PhpMyAdmin\ThemeManager->__construct() .\libraries\classes\ThemeManager.php#385: PhpMyAdmin\ThemeManager::getInstance() .\libraries\common.inc.php#240: PhpMyAdmin\ThemeManager::initializeTheme() .\index.php#15: require_once(.\libraries\common.inc.php) Deprecation Notice in .\vendor\twig\twig\src\Markup.php#35 Return type of Twig\Markup::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice Backtrace .\vendor\composer\ClassLoader.php#444: include(.\vendor\twig\twig\src\Markup.php) .\vendor\composer\ClassLoader.php#322: Composer\Autoload\includeFile(string 'C:\\Server\\data\\htdocs\\-phpmyadmin\\vendor\\composer/../twig/twig/src/Markup.php') .\tmp\twig\46\46f1bfbf4328d3d22fddffb9178fdeb9868d0740e4cc8b5bbd6f2fcfb8e4523e.php#59: Composer\Autoload\ClassLoader->loadClass(string 'Twig\\Markup') .\vendor\twig\twig\src\Template.php#405: __TwigTemplate_034511bee5325c368ee003e3d97d6cb47c3e1c94ebb527bcf0b76ba7818d1ac6->doDisplay( array, array, ) .\vendor\twig\twig\src\Template.php#378: Twig\Template->displayWithErrorHandling( array, array, ) .\vendor\twig\twig\src\Template.php#390: Twig\Template->display(array) .\vendor\twig\twig\src\TemplateWrapper.php#45: Twig\Template->render( array, array, ) .\libraries\classes\Template.php#132: Twig\TemplateWrapper->render(array) .\libraries\classes\Header.php#714: PhpMyAdmin\Template->render( string 'javascript/variables', array, ) .\libraries\classes\Header.php#193: PhpMyAdmin\Header->getVariablesForJavaScript() .\libraries\classes\Header.php#142: PhpMyAdmin\Header->addDefaultScripts() .\libraries\classes\Response.php#184: PhpMyAdmin\Header->__construct() .\libraries\classes\Response.php#215: PhpMyAdmin\Response->__construct() .\libraries\classes\Plugins\Auth\AuthenticationCookie.php#102: PhpMyAdmin\Response::getInstance() .\libraries\classes\Plugins\AuthenticationPlugin.php#275: PhpMyAdmin\Plugins\Auth\AuthenticationCookie->showLoginForm() .\libraries\common.inc.php#263: PhpMyAdmin\Plugins\AuthenticationPlugin->authenticate() .\index.php#15: require_once(.\libraries\common.inc.php) Deprecation Notice in .\vendor\twig\twig\src\Markup.php#40 Return type of Twig\Markup::jsonSerialize() should either be compatible with JsonSerializable::jsonSerialize(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice Backtrace .\vendor\composer\ClassLoader.php#444: include(.\vendor\twig\twig\src\Markup.php) .\vendor\composer\ClassLoader.php#322: Composer\Autoload\includeFile(string 'C:\\Server\\data\\htdocs\\-phpmyadmin\\vendor\\composer/../twig/twig/src/Markup.php') .\tmp\twig\46\46f1bfbf4328d3d22fddffb9178fdeb9868d0740e4cc8b5bbd6f2fcfb8e4523e.php#59: Composer\Autoload\ClassLoader->loadClass(string 'Twig\\Markup') .\vendor\twig\twig\src\Template.php#405: __TwigTemplate_034511bee5325c368ee003e3d97d6cb47c3e1c94ebb527bcf0b76ba7818d1ac6->doDisplay( array, array, ) .\vendor\twig\twig\src\Template.php#378: Twig\Template->displayWithErrorHandling( array, array, ) .\vendor\twig\twig\src\Template.php#390: Twig\Template->display(array) .\vendor\twig\twig\src\TemplateWrapper.php#45: Twig\Template->render( array, array, ) .\libraries\classes\Template.php#132: Twig\TemplateWrapper->render(array) .\libraries\classes\Header.php#714: PhpMyAdmin\Template->render( string 'javascript/variables', array, ) .\libraries\classes\Header.php#193: PhpMyAdmin\Header->getVariablesForJavaScript() .\libraries\classes\Header.php#142: PhpMyAdmin\Header->addDefaultScripts() .\libraries\classes\Response.php#184: PhpMyAdmin\Header->__construct() .\libraries\classes\Response.php#215: PhpMyAdmin\Response->__construct() .\libraries\classes\Plugins\Auth\AuthenticationCookie.php#102: PhpMyAdmin\Response::getInstance() .\libraries\classes\Plugins\AuthenticationPlugin.php#275: PhpMyAdmin\Plugins\Auth\AuthenticationCookie->showLoginForm() .\libraries\common.inc.php#263: PhpMyAdmin\Plugins\AuthenticationPlugin->authenticate() .\index.php#15: require_once(.\libraries\common.inc.php)
Решение:
О причинах и исправление ошибки смотрите в статье «Ошибка phpMyAdmin «Deprecation Notice in .\vendor\twig\twig\src\Loader\FilesystemLoader.php#40 realpath(): Passing null to parameter #1 ($path) of type string is deprecated» (РЕШЕНО)».
Ошибки phpMyAdmin в Windows
Ошибка:
1.
попытался установить пшагово по Вашей инструкции все программы для запуска phpMyAdminно выходит ошибка :
"Расширение mysqli не найдено. Пожалуйста, проверьте ваши настройки PHP. Смотрите [a@doc/html/faq.html#faqmysql@documentation]our documentation для дополнительной информации."
2.
При первоначальном запуске phpMyAdmin получила ошибку
The mysqli extension is missing. Please check your PHP configuration. See our documentation for more information.
Решение:
Возможные причины ошибки:
1.
В файле php.ini не раскомментирована строка:
extension=mysqli
2.
В файл httpd.conf не добавлена или записана с ошибкой строка:
PHPIniDir "C:/Server/bin/PHP"
3.
Файл php.ini имеет неверное имя, например, вы забыли его переименовать из php.ini-development.
В последних двух случаях настройки из файла php.ini вообще не используются, поскольку сам файл не может быть найден сервером. Чтобы это проверить, откройте файл i.php с функцией:
phpinfo ();
Найдите поле Loaded Configuration File, там должны быть перечислены загруженные конфигурационные файлы, например:
Loaded Configuration File C:\Server\bin\PHP\php.ini
Если у вас так, как показано выше, значит файл php.ini используется, но расширение mysqli не активировано (см. 1й пункт выше).
Ошибка:
Добавляю http://localhost/phpmyadmin/setup/
вместо панели управления вижу код:
<?php
/* vim: set expandtab sw=4 ts=4 sts=4: */
/**
* Front controller for setup script
*
* @package PhpMyAdmin-Setup
* @license http://www.gnu.org/licenses/gpl.html GNU GPL 2.0
*/
/**
* Core libraries.
*/
require './lib/common.inc.php';
$page = filter_input(INPUT_GET, 'page');
$page = preg_replace('/[^a-z]/', '', $page);
if ($page === '') {
$page = 'index';
}
if (!file_exists("./setup/frames/$page.inc.php")) {
// it will happen only when entering URL by hand, we don't care for these cases
PMA_fatalError(__('Wrong GET file attribute value'));
}
и т. д.
Решение:
Сервер Apache работает без PHP
Ответ пользователя: Перезапустил и обновил браузер все получилось
Ошибка:
Столкнулся вот с какой проблемой — после расширения возможностей phpmyadmin и попытке войти под пользователем pma, выскакивает ошибка: #1045 Невозможно подключиться к серверу MySQL. Под root всё в порядке. Если знаете в чем проблема, подскажите пожалуйста как её исправить?! Хочется взглянуть на эти дополнительные возможности phpmyadmin)
Решение:
Вам не нужно заходить в phpMyAdmin от имени пользователя pma. Когда Вы всё настроили и зашли под рутом, то всё уже работает. Просто, на самом деле, в phpMyAdmin мало что меняется. Чтобы убедиться, что доп. возможности работают, кликните по какой-нибудь базе данных и посмотрите, есть ли у Вас в верхнем меню Дизайнер и Слежение. Если есть, значить всё работает.
Ошибка:
Apache, PHP и MySQL установились без проблем, но когда я дошла до 6-го пункта (phpMyAdmin), получила сообщение об ошибке:
Fatal error: Call to undefined function mb_detect_encoding() in C:\Server\data\htdocs\phpmyadmin\libraries\php-gettext\gettext.inc on line 177.
Я читала комментарий выше об этой же ошибке, но у меня все нужные строки в php.ini раскомментированы, все делала четко по инструкции. Но все равно ошибка.
С чем это может быть связано и как исправить?
Решение:
перезагрузила — все работает)))
Ошибка:
У меня при установке phpMyAdmin возникла проблема:
Добавить новый сервер Warning: Illegal string offset 'Servers/1/auth_type' in C:\Server\data\htdocs\pma\libraries\configWalidator.class.php on line 312 Warning: Illegal string offset 'Servers/1/auth_type' in C:\Server\data\htdocs\pma\libraries\configWalidator.class.php on line 319 Warning: Illegal string offset 'Servers/1/auth_type' in C:\Server\data\htdocs\pma\libraries\configWalidator.class.php on line 328 Warning: Illegal string offset 'Servers/1/auth_type' in C:\Server\data\htdocs\pma\libraries\configWalidator.class.php on line 336 Warning: Illegal string offset 'Servers/1/pmadb' in C:\Server\data\htdocs\pma\libraries\configWalidator.class.php on line 371 Warning: Illegal string offset 'Servers/1/controluser' in C:\Server\data\htdocs\pma\libraries\configWalidator.class.php on line 376 Warning: Illegal string offset 'Servers/1/controlpass' in C:\Server\data\htdocs\pma\libraries\configWalidator.class.php on line 381 Warning: Illegal string offset 'Servers/1/connect_type' in C:\Server\data\htdocs\pma\libraries\configWalidator.class.php on line 388 Warning: Illegal string offset 'Servers/1/hosf in C:\Server\data\htdocs\pma\libraries\configWalidator.class.php on line 389 Warning: Illegal string offset 'Servers/1/port' in C:\Server\data\htdocs\pma\libraries\configWalidator.class.php on line 389 Warning: Illegal string offset 'Servers/1/socket' in C:\Server\data\htdocs\pma\libraries\configWalidator.class.php on line 390 Warning: Illegal string offset 'Servers/1/controluser' in C:\Server\data\htdocs\pma\libraries\configWalidator.class.php on line 390 Warning: Illegal string offset 'Servers/1/controlpass' in C:\Server\data\htdocs\pma\libraries\configWalidator.class.php on line 391 (&) Предупреждение_______________________________________________________________________________________________________ Данные формы содержат ошибки Проверка данных на соответствие и возвращение в изначальное значение при наличии ошибки Хранение конфигурации ► Не удалось соединиться с сервером базы данных! - mysqli_connect() expects parameter 5 to be long, string given Игнорировать ошибки Показать форму
Решение:
Если так, то это ошика исключительно версии phpMyAdmin 4.3.2. Тикет ошибки: http://sourceforge.net/p/phpmyadmin/bugs/4653/
Очевидные решения:
1) пользоваться phpMyAdmin из ветки 4.2,
2) подождать пока починят.
Ошибка:
Добрый день. Сделала все по инструкции, но при вводе http://localhost/phpmyadmin/ выдает такой текст «Composer detected issues in your platform: Your Composer dependencies require the following PHP extensions to be installed: mysqli, openssl«.
Решение:
Возможные причины ошибки и способ решения смотрите в статье: Ошибка «Composer detected issues in your platform: Your Composer dependencies require the following PHP extensions to be installed: mysqli, openssl» (РЕШЕНО)
Вопросы и ответы по веб-серверу в Windows
Вопрос:
Я хочу потренироваться в администрировании сайта на WordPress или Я изучаю программирование PHP для WordPress, как мне установить эту CMS на свой локальный сервер в Windows?
Ответ:
Смотрите статью «Как установить WordPress в Windows».
Вопрос:
Могут ли мой веб-сервер взломать?
Ответ:
Да, по умолчанию безопасности веб-сервера не уделено никакого внимания — задача минимум, заставить его работать на Windows. Сразу после успешной установки и проверки, настоятельно рекомендуется перейти ко второй стадии: «Как защитить веб-сервер Apache от взлома в Windows».
Вопрос:
У меня есть уже готовый сайт всё настроил.как сделать чтоб его стало видно из интернета?
Ответ:
Здесь подробная инструкция: «Как веб-сервер на своём компьютере сделать доступным для других».
Вопрос:
Как настроить поддомены и виртуальные хосты?
Ответ:
Подробная инструкция «Настройка Apache в Windows» в разделе Подключение виртуальных хостов Apache в Windows.
Вопрос:
Скажите пожалуйста где вы взяли файл C:/Server/bin/PHP/php5apache2_4.dll
А то у меня ругается апач на его отсутствие
Ответ:
Этот файл с самого начала есть в архиве php-5.5.9-Win32-VC11-x64.zip , который скачиваю с официального сайта.
Если в Вашем архиве нет этого файла, скорее всего, Вы скачали или старую версию (5.4.*, 5.3.*) или Non-Thread Safe (NTS) версию.
Если файл C:/Server/bin/PHP/php5apache2_4.dll присутствует, но Apache выдаёт ошибку, значит проблема в настройке Apache.
Ссылки на «правильный» PHP:
64-бит: http://windows.php.net/downloads/releases/php-5.5.9-Win32-VC11-x64.zip
32-бит: http://windows.php.net/downloads/releases/php-5.5.9-Win32-VC11-x86.zip
(ссылки устарели)
Вопрос:
А что, если после установки MySQL 5.4.16 не появилось окошко настроек «MySQL Server Instance Configuration Wizard»?
Что делать? Как настраивать?
Ответ:
Значит вы скачали не установщик, а zip-архив. Лично мне ручная установка MySQL кажется более простой и гибкой. Как это сделать описано здесь.
Вопрос:
Как поменять пароль для MySQL?
Ответ:
Для задания нового пароля MySQL в командной строке:
c:\Server\bin\mysql-5.6\bin\mysql -u root mysql
mysql> update user set Password=PASSWORD('новый пароль') WHERE User='root';
mysql> exit
net stop mysql
net start mysql
Вопрос:
Как прописать переменные среды для MySQL в Windows?
Ответ:
Откройте «Мой компьютер» (у меня называется «Этот компьютер» — не суть). Там выберите «Свойства системы». Дальше выберите «Дополнительные параметры системы». В открывшемся окне на вкладке «Дополнительно» нажмите «Переменные среды». Там два окошечка, смотрите на то, которое называется «Системные переменные». Находите переменную «Path». Кликаете два раза на ней. В «Значение переменной» уже много-много чего понаписано. Добавляете туда (например, вставьте в самое начало) строку (если у вас MySQL):
C:\Server\bin\mysql-8.0\
Или (если у вас MariaDB):
C:\Server\bin\mariadb\
Нажмите везде ОК, чтобы закрылись все окна. Сразу, даже без перезагрузки можно работать в командной строке и вызывать MySQL как mysql — полный путь прописывать до бинарника не нужно.
Вопрос:
Посоветуйте хостинг
Ответ:
Хостинг, которым пользуется автор этих инструкций на протяжении 10 лет и где размещены этот и другие сайты с инструкциями: здесь. Для получения бесплатного месяца и других бонусов, указывайте промокод b33e0e2f
Совет:
Хотите навсегда забыть о всех проблемах с сервером? Хотите просто радоваться развитию вашего сайта и не думать ни о каких технических проблемах? Хотите получить надёжных друзей в виде высококвалифицированной и быстрой технической поддержки? Лучший хостинг от лидеров рынка по доступным ценам. Тарифы. Чтобы получить бесплатный месяц веб-хостинга, другие бонусы и подарки, указывайте промокод b33e0e2f
Связанные статьи:
- Как установить веб-сервер Apache с PHP, MySQL и phpMyAdmin на Windows (94.2%)
- Ошибка «Composer detected issues in your platform: Your Composer dependencies require the following PHP extensions to be installed: mysqli, openssl» (РЕШЕНО) (61.6%)
- Установка Apache, PHP, MySQL и phpMyAdmin на Windows XP (59.5%)
- Готовая сборка Apache для Windows XP (59.5%)
- Как исправить «Configuration File (php.ini) Path» no value (57.7%)
- Виртуальный хост Apache по умолчанию. _default_ и catch-all в Apache (RANDOM — 50.9%)
This is driving the whole team crazy. There must be some simple mis-configured part of IIS or our Web Server, but every time we try to run out ASP.NET Web Application on IIS 7.5 we get the following error…
Here’s the error in full:
HTTP Error 500.19 - Internal Server Error
The requested page cannot be accessed because the related configuration
data for the page is invalid.
`Detailed Error Information`
Module IIS Web Core
Notification Unknown
Handler Not yet determined
Error Code 0x8007000d
Config Error
Config File \\?\E:\wwwroot\web.config
Requested URL http://localhost:80/Default.aspx
Physical Path
Logon Method Not yet determined
Logon User Not yet determined
Config Source
-1:
0:
The machine is running Windows Server 2008 R2. We’re developing our Web Application using Visual Studio 2008.
According to Microsoft the code 8007000d means there’s a syntax error in our web.config — except the project builds and runs fine locally. Looking at the web.config in XML Notepad doesn’t bring up any syntax errors, either. I’m assuming it must be some sort of poor configuration on my part…?
Does anyone know where I might find further information about the error? Nothing is showing in EventViewer, either 
Not sure what else would be helpful to mention…
Assistance is greatly appreciated. Thanks!
UPDATES! — POSTED WEB.CONFIG BELOW
Ok, since I posted the original question above, I’ve tracked down the precise lines in the web.config that were causing the error.
Here are the lines (they appear between <System.webServer> tags)…
<httpHandlers>
<remove verb="*" path="*.asmx"/>
<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
</httpHandlers>
Note: If I delete the lines between the <httpHandlers> I STILL get the error. I literally have to delete <httpHandlers> (and the lines inbetween) to stop getting the above error.
Once I’ve done this I get a new 500.19 error, however. Thankfully, this time IIS actually tells me which bit of the web.config is causing a problem…
<handlers>
<remove name="WebServiceHandlerFactory-Integrated"/>
<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory,System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
<add name="ScriptHandlerFactoryAppServices" verb="*" path="*_AppService.axd" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
<add name="ScriptResource" preCondition="integratedMode" verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
</handlers>
Looking at these lines it’s clear the problem has migrated further within the same <system.webServer> tag to the <handlers> tag.
The new error is also more explicit and specifically complains that it doesn’t recognize the attribute «validate» (as seen on the third line above). Removing this attribute then makes it complain that the same line doesn’t have the required «name» attribute. Adding this attribute then brings up ASP.NET error…
Could not load file or assembly
‘System.web.Extensions,
Version=1.0.61025.0, Culture=neutral,
PublicKeyToken=f2cb5667dc123a56’ or
one of its dependencies. The system
cannot find the file specified.
Obviously I think these new errors have just arisen from me deleting the <httpHandlers> tags in the first place — they’re obviously needed by the application — so the question remains: Why would these tags kick up an error in IIS in the first place???
Do I need to install something to IIS to make it work with them?
Thanks again for any help.
WEB.CONFIG
Here’s the troublesome bits of our web.Config…
<system.Web>
<!-- stuff cut out -->
<httpHandlers>
<remove verb="*" path="*.asmx"/>
<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
<add verb="*" path="*_AppService.axd" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
<add verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56" validate="false"/>
</httpHandlers>
<httpModules>
<add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
</httpModules>
</system.web>
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<modules>
<add name="ScriptModule" preCondition="integratedMode" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
</modules>
<remove verb="*" path="*.asmx"/>
<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
<handlers>
<remove name="WebServiceHandlerFactory-Integrated"/>
<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory,System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
<add name="ScriptHandlerFactoryAppServices" verb="*" path="*_AppService.axd" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
<add name="ScriptResource" preCondition="integratedMode" verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
</handlers>
</system.webServer>