LINUX.ORG.RU
ФорумAdmin

Конфиг nginx для mvc + phpmyadmin

 , ,


0

1

Добрый день, всё никак немогу разобраться с nginx. Практики не хватает. Суть такова. Есть легаси проект на php, он в mvc архитектуре, без фреймворков. Крутился раньше на апаче, нужно его перебросить на nginx+php-fpm. Наковырял конфиг, вроде работает mvc приложуха, но не уверен что он правильно настроен в плане реврайтинга. В апаче там через .htaccess реврайт прописывался, тут как я понял try_files $uri $uri/ /index.php; и далее маршрутизация управляется приложением (ну всё через index.php). Обратите внимание на location / и ниже, правильно ли вообще написаны директивы для mvc ? . Немогу утверждать важная или нет инфа - но запросы в приложении маршрутизируются с помощью переменных, примерно вот так cabinet/epu/([A-Za-z]+)/edit/(write-item-extant)/([0-9]+) и далее контроллеры обрабатывают, а вот классический подход типа ?uri=$uri&$args не используется. Ну и собственно вторая часть вопроса.

Скачал свежий phpmyadmin архив, распаковал в директорию /usr/share/phpMyAdmin, cделал владельцем этой директории www-data и дал права на выполнение (от него же и nginx работает и php-fpm), чтото-там [ключ] добавил в blowfish_secret, импортровал/создал таблицы для phpMyAdmin в мускуле и также добавил для него location в конфиге nginx. Ничего не завелось. Вопрос - где неправильно описана обработка location (ведь он же уже не как mvc сущность считается ) ? Может стоит в отдельный блок server запихать phpMyAdmin ? на выходе хотелось бы на том же порту [пока 80й] остаться и приложением mvc и phpmyadmiНОМ. В логах ошибок нет, в браузере пустая страница выводится белая как снег, аксес лог вот такой:

[21/Apr/2024:18:43:31 +0300] 192.168.3.77 -> test.local "GET /phpmyadmin/ HTTP/1.1" 200 31 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0" "-"rt=0.000 ut=0.000 cs=-

На выходе хотелось бы иметь схему на одном порту без поддоменов. Т.е. test.local - открывает mvc приложение, а test.local/phpmyadmin панель phpMyAdmin.

Стоит добавить что если написать в браузере непонятные символы http://test.local/asdasdqwe то в логе то же самое (ну за исключением GET - он с непонятыми символами). Забегая вперед также еще вопрос - можно ли как-то встречать 404й или ещё какой-то ошибкой такой юзерский ввод ? Если допустим юзер уже в приложении авторизовался с куками и сессиями и такой ввод делает, то там уже приложение перебрасывает на еррорпэйджи, а вот до авторизации как «встретить» кракозябры от юзера nginx-ом?

сам конфиг

server {
     listen   192.168.3.10:80;
     server_name  www.test.local;
     return 301 http://test.local$request_uri;
}
server {
     listen   192.168.3.10:80;
    server_name  192.168.3.10;
     return 301 http://test.local$request_uri;
}

server {
    #listen 443 ssl http2;
     listen 192.168.3.10:80;
     server_name test.local;
	 
		##phpMyAdmin config###
		location /phpmyadmin {
		alias /usr/share/phpMyAdmin/;
		#root /usr/share/phpMyAdmin/;
		    location /phpmyadmin {
                   try_files $uri $uri/ =404;
			}
			
		    location ~ \.php$ {
		    # fastcgi_pass 127.0.0.1:9000;
			fastcgi_pass   unix:/run/php-fpm/www.sock;
			fastcgi_index index.php;
			fastcgi_param SCRIPT_FILENAME /usr/share/phpMyAdmin$request_filename;
			include fastcgi_params;
			fastcgi_ignore_client_abort off;
		    }
			
		    location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
			access_log    off;
			log_not_found    off;
			expires 1M;
			}
		}

    root /var/www/legacy-project/;
    index index.php index.html index.htm;
    access_log /var/www/legacy-project/log/access.log main;
    error_log /var/www/legacy-project/log/error.log;
	charset utf-8;

	if (!-e $request_filename)
	{
		rewrite ^/(.*)$ /index.php last;
		break;
	}

    location / {
	index  index.php;
	    try_files $uri $uri/ /index.php;
    }

    location ~* ^.+.(js|css|png|jpg|jpeg|gif|ico|woff|woff2)$ {
    access_log off;
    expires max;
    }

    location ~ \.php$ {
    try_files  $uri =404;
    fastcgi_pass   unix:/run/php-fpm/www.sock;
    fastcgi_index index.php;
    fastcgi_param DOCUMENT_ROOT  /var/www/legacy-project/;
    fastcgi_param SCRIPT_FILENAME /var/www/legacy-project$fastcgi_script_name;
    fastcgi_param PATH_TRANSLATED /var/www/legacy-project$fastcgi_script_name;
    include fastcgi_params;
    fastcgi_param QUERY_STRING $query_string;
    fastcgi_param REQUEST_METHOD $request_method;
    fastcgi_param CONTENT_TYPE $content_type;
    fastcgi_param CONTENT_LENGTH $content_length;
    fastcgi_param HTTPS on;
    fastcgi_intercept_errors on;
    fastcgi_ignore_client_abort off;
    fastcgi_connect_timeout 60;
    fastcgi_send_timeout 180;
    fastcgi_read_timeout 180;
    fastcgi_buffer_size 128k;
    fastcgi_buffers 4 256k;
    fastcgi_busy_buffers_size 256k;
    fastcgi_temp_file_write_size 256k;
    }

    location = /favicon.ico {
    log_not_found off;
    access_log off;
    }


    location ~ /\.ht {
    deny all;
    }
}

П.С. Все тестовые манипуляции были с чистым кэшем браузера (каждый тест - новое окно инкогнито)



Последнее исправление: Sv00p (всего исправлений: 4)

Ты не привёл старый .htaccess, поэтому непонятно насколько ты правильно его перевёл в nginx-конфиг.

И сделай нормальные отступы в конфиге, читать же неудобно. Каждый вложенный блок +4 или +8 пробелов.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)

Вопрос - где неправильно описана обработка location (ведь он же уже не как mvc сущность считается ) ? Может стоит в отдельный блок server запихать phpMyAdmin ? на выходе хотелось бы на том же порту [пока 80й] остаться и приложением mvc и phpmyadmiНОМ. В логах ошибок нет, в браузере пустая страница выводится белая как снег, аксес лог вот такой

Не знаю что за mvc сущность, но это явно понятие не вебсерверное и ни при чём тут.

Причина скорее всего вот в чём: если ты ставишь location с просто префиксом урла, без ^~, то у этого location-а будут отнимать запросы все регэксповые location-ы, в том числе те которые прописаны ниже. Так что первое location /phpmyadmin следует заменить на location ^~ /phpmyadmin. А сейчас у тебя все урлы .php, включая те что начинаются с /phpmyadmin/, попадают в локацию для приложения т.к. у неё приоритет больше. Не забудь так же продублировать внутрь неё запрет на обращение к /.ht

$request_filename - это путь к файлу уже включая root/alias, а ты его соединяешь с базовой директорией phpmyadmin - путь получится неверный и работать оно не будет, лучше заменить на $fastcgi_script_name как в приложении.

Вот этот код

	if (!-e $request_filename)
	{
		rewrite ^/(.*)$ /index.php last;
		break;
	}

    location / {
	index  index.php;
	    try_files $uri $uri/ /index.php;
    }
Делает два раза одно и то же - заменяет урлы к несуществующим файлам на /index.php. И, кстати, первый if опять действует и на phpmyadmin и скорее всего будет там что-то портить. Лучше if убрать, вроде и без него try_files сделает всё что надо.

Два отдельных server {} в одинаковым редиректом не нужны - можно оставить один и перечислить домены через пробел в server_name.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 3)

Суть задачи не особо ясна из поста. Возможно лучше/проще будет настроить apache2 слушать локалхост порт, и nginx поставить в качестве прокси между пользователем и apache2. Статику при этом можно оставить nginx, таким образом совместить лучшее из двух серверов, это относительно распространенное решение.

MOPKOBKA ★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

Нет, он всё правильно сделал что выкинул это легаси. Выкидывать надо до конца а не подкостыливать.

таким образом совместить лучшее из двух серверов

Лучшее из двух серверов - это nginx.

это относительно распространенное решение.

Было 15-20 лет назад, когда с nginx-ом ещё до конца не освоились и php-fpm ещё не появился а потом был бетой.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

Да, если у тебя есть апач то лучше перед ним поставить nginx - он будет его хорошо проксировать. Но ещё лучше выкинуть апач и поставить вместо него что-то более специализированное, в данном случае это php-fpm. nginx будет проксировать и его ничуть не хуже.

firkax ★★★★★
()
Ответ на: комментарий от firkax

первый location в phpmyadmin поправил на location ^~ /phpmyadmin, if совсем убрал, теперь на 404 кидает когда пишу http://test.local/phpmyadmin

А по аксес логу видно, что GETится /phpmyadmin и 404

на 404 кидает когда прописан root /usr/share/phpMyAdmin/;

а если написать alias /usr/share/phpMyAdmin/; , то file not found и еррор [error] 3134#3134: *9 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream

Sv00p
() автор топика
Последнее исправление: Sv00p (всего исправлений: 4)
Ответ на: комментарий от Sv00p

теперь на 404 кидает

на 404 кидает когда прописан root /usr/share/phpMyAdmin/;

а если написать alias

Так у тебя в первом сообщении и написан alias, откуда root взялся? alias - правильно.

Primary script unknown значит что в php-fpm пришёл неправильный путь к скрипту. Ты $request_filename поменял? Хотя с alias наверно fastcgi_script_name удет бесполезным, ведь урл теперь отличается от конца пути. Надо тогда request_filename оставить без префикса перед ним.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Вот так заработало, даже без try_files, и $request_filename сработал. Может что-то еще нужно подкрутить?

server {
     listen   192.168.3.10:80;
    server_name  192.168.3.10 www.test.local;
     return 301 http://test.local$request_uri;
}

server {
    #listen 443 ssl http2;
     listen 192.168.3.10:80;
     server_name test.local;
	 
		##phpMyAdmin config###
		location /phpmyadmin {
		alias /usr/share/phpMyAdmin/;
		#root /usr/share/phpMyAdmin/;
		    #location /phpmyadmin {
                   #try_files $uri $uri/ =404;
			#}
			
		    location ~ \.php$ {
		    # fastcgi_pass 127.0.0.1:9000;
			fastcgi_pass   unix:/run/php-fpm/www.sock;
			fastcgi_index index.php;
			fastcgi_param SCRIPT_FILENAME $request_filename;
			include fastcgi_params;
			fastcgi_ignore_client_abort off;
		    }
			
		    location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
			access_log    off;
			log_not_found    off;
			expires 1M;
			}
			 location ~ /\.ht {
				deny all;
			}
		}

    root /var/www/legacy-project/;
    index index.php index.html index.htm;
    access_log /var/www/legacy-project/log/access.log main;
    error_log /var/www/legacy-project/log/error.log;
	charset utf-8;


    location / {
	index  index.php;
	    try_files $uri $uri/ /index.php;
    }

    location ~* ^.+.(js|css|png|jpg|jpeg|gif|ico|woff|woff2)$ {
    access_log off;
    expires max;
    }

    location ~ \.php$ {
    try_files  $uri =404;
    fastcgi_pass   unix:/run/php-fpm/www.sock;
    fastcgi_index index.php;
    fastcgi_param DOCUMENT_ROOT  /var/www/legacy-project/;
    fastcgi_param SCRIPT_FILENAME /var/www/legacy-project$fastcgi_script_name;
    fastcgi_param PATH_TRANSLATED /var/www/legacy-project$fastcgi_script_name;
    include fastcgi_params;
    fastcgi_param QUERY_STRING $query_string;
    fastcgi_param REQUEST_METHOD $request_method;
    fastcgi_param CONTENT_TYPE $content_type;
    fastcgi_param CONTENT_LENGTH $content_length;
    fastcgi_param HTTPS on;
    fastcgi_intercept_errors on;
    fastcgi_ignore_client_abort off;
    fastcgi_connect_timeout 60;
    fastcgi_send_timeout 180;
    fastcgi_read_timeout 180;
    fastcgi_buffer_size 128k;
    fastcgi_buffers 4 256k;
    fastcgi_busy_buffers_size 256k;
    fastcgi_temp_file_write_size 256k;
    }

    location = /favicon.ico {
    log_not_found off;
    access_log off;
    }

    location ~ /\.ht {
    deny all;
    }
}

п.с. заметил забавную вещь в браузере firefox - в приватном режиме он долго думает прежде чем отправить запрос. В обычном режиме норм отрабатывает. Остальные браузеры во всех режимах норм. А сначала думал с днс какая-то беда, выяснил что браузер firefox так себя ведет в приватном режиме. Даже tcpdump показывает что не сразу соединяется (уже даже в виндовом hosts прописал локальный домен)

Sv00p
() автор топика
Последнее исправление: Sv00p (всего исправлений: 1)