Archivo de la categoría: Nginx

FreeBSD: PHP-FPM y NGINX Página en Blanco | White Page

PHP-FPM Página en Blanco | White Page

He estado montado unos servidores con FreeBSD con NGINX y PHP-FPM y me he encontrado que no funcionaba el PHP con la configuración habitual, tampoco salia nada en los logs, el único síntoma era una página en blanco al acceder a cualquier archivo PHP.

La solución al problema, añadir el PATH_TRASLATED que no esta definido a la configuración de fcgi:

fastcgi_param PATH_TRANSLATED $document_root$fastcgi_script_name;

Esto se tiene que añadir o bien al vhost de la web o directamente en fastcgi_params para que tome efecto en todas las páginas, luego reiniciamos nginx y listo ( no hace falta reiniciar php-fpm)

Nginx config para xenforo y phpbb

Nginx vhost para xenforo

server {
    listen   [::]:80;
    server_name  example.com www.example.com;
    root   /var/www/example.com;
    index  index.html index.htm index.php;
    access_log  /var/www/logs/example.com.access.log;  

    location / {
        try_files $uri $uri/ /index.php?$uri&$args;
    }

    location ~ /(internal_data|library) {
         internal;
    }

    location ~ \.php$ {
        fastcgi_pass   unix:/tmp/php.socket;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include fastcgi_params;
    }   
}

Nginx vhots para phpbb

server {
    listen   [::]:80;
    server_name  www.domain.com parkeddomain.com *.parkeddomain.com;
    rewrite ^    http://domain.com$request_uri? permanent;
}

server {
    listen   [::]:80;
    server_name  domain.com;
    root   /var/www/domain.com;
    index  index.php index.html index.htm;
    access_log  /var/logs/domain.com.access.log;

    location ~ /(config\.php|common\.php|cache|files|images/avatars/upload|includes|store) {
        deny all;
        return 403;
    }

    location ~* \.(gif|jpe?g|png|css)$ {
        expires   30d;
    }

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_pass   unix:/tmp/php.socket;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

Los vhost gracias a nginxlibrary.com

Aunque no es muy distinto de los demás, es más que todos los vhost son similares lo que cambia es que nginx no tiene htaccess y se tienen que integrar la reescritura de urls en el vhost directamente, aparte de las rutas de algunos directorios a los que tal vez queremos denegar el acceso, redirigir, pero el principio es el mismo 🙂

Forzar las WWW con NGINX

Para forzar que nuestro dominio cargue directamente con las www y evitar algunos errores de “este dominio no esta redirigiendo correctamente” en el caso de wordpress y otros cms en los que en la configuración ponemos que cargue con www pero que aún así a veces deja acceder sin las www, en nginx basta con una redirección:

Con este código lo solucionamos:

Redirigir a WWW con NGINX

server {
    listen       80;
    server_name  skamasle.com;
    return       301 http://www.skamasle.com$request_uri;
}

Pero es importante tener dos directivas server, un ejemplo, una directiva normal puede ser:

server {
        listen *:80;
        server_name skamasle.com www.skamasle.com;
        root   /var/www/web;
        index index.html index.htm....................... etc
}

O sea en server_name definidos los dos dominios, así que tenemos que separar a una directiva aparte, skamasle.com en una sección server para hacer la redirección y www.skamasle.com en la directiva server principal si no, no funciona.

NOTA para versiones viejas de nginx se usaba rewrite:

server {
    server_name  skamasle.com;
    rewrite ^(.*) http://www.skamasle.com$1 permanent;
}

Usar rewrite es menos eficiente, aunque ya nadie usa versiones viejas de nginx y con el return no tendremos problemas en ninguna versión.

Quitar las WWW con nginx

server {
    server_name www.skamasle.com;
    return 301 $scheme://skamasle.com$request_uri;
}

URLS Amigables de WordPress con NGINX

Solo hay que añadir este código al VHOST:

URLS Amigables con NGINX

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

Si WordPress esta en un subdirectorio basta con añadir el subdirectorio al index.php: ej:

location / {
try_files $uri $uri/ /blog/index.php?$args;
}

También podemos usar este si tenemos problemas con el wp-admin.

rewrite /wp-admin$ $scheme://$host$uri/ permanent;

location ~* \.(jpg|jpeg|png|gif|css|js|ico)$ {
expires max;
log_not_found off;
}

Estos dos códigos se pueden usar en ISPCONFIG ( por eso los dejo por aquí para tenerlos a mano )

Si usamos ISPCONFIG corriendo bajo debian tenemos que añadirlos en la sección de opciones del dominio, en NGINX settings y con eso tendremos las pretty urls o urls amigables.

Edito

Nginx WordPress not Found

Algunas veces he visto que no funciona este método con un not found, así que aquí una variante:

try_files $uri $uri/ /index.php?q=$uri&$args; 

VbSEO con NGINX

Las reglas de reescritura de VBSEO para nginx o en ingles rewrite rules, aquí las dejo:

Vbseo con NGINX

location /forums/ {

rewrite ^/forums/((urllist|sitemap_).*\.(xml|txt)(\.gz)?)$ /forums/vbseo_sitemap/vbseo_getsitemap.php?sitemap=$1 last;

if ($request_filename ~ “\.php$” ) {
rewrite ^(.*)$ /forums/vbseo.php last;
}

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

}

Gracias a Oleg Ignatiuk de vbseo.com las vi hace tiempo en un post suyo y quedaron en mis apuntes.

Nginx y PHP con Usuarios, Grupos y configuración individual: /etc/php5/fpm/pool.d

Un ejemplo de lo que puede ir en /etc/php5/fpm/pool.d/sitioweb con nginx y PHP, con esto podemos usar usuarios y grupos, mayor seguridad y rendimiento, también podemos definir la cantidad de procesos de PHP y todas las opciones de php-fpm

[web1]

listen = 127.0.0.1:9020
listen.allowed_clients = 127.0.0.1

user = skamasle
group = skamasle

pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 5
pm.max_requests = 0

chdir = /

php_admin_value[open_basedir] = /aquí lo suyo
php_admin_value[session.save_path] = /aquí alguna ruta para el tmp, normalmente /tpm pero si queremos otra la ponemos
php_admin_value[upload_tmp_dir] = /mas de lo mismo si queremos otro upload dir lo ponemos aqui

NOTA:

Podemos usar sockets, yo prefiero los sockets y siempre los uso, pero la gente usa puerto, en ese caso ponemos un puerto distinto para cada web:

listen = 127.0.0.1:9020
listen = 127.0.0.1:9030
etc

El puerto tiene que coincidir en el vhost y el socket también ( si lo usaramos;

location @php {
include /etc/nginx/fastcgi_params;
fastcgi_pass 127.0.0.1:9020;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

Si usamos socket queda algo así:

[web1]

listen = /var/lib/php5-fpm/web1.sock <- UN socket para cada web listen.owner = skamasle listen.group = skamasle listen.mode = 0660 user = skamasle group = skamasle etc

Y el vhost igual pero con el socket:

location @php {
include /etc/nginx/fastcgi_params;
fastcgi_pass unix:/var/lib/php5-fpm/web1.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

Bueno más o menos así, no espero que lo entiendan bien, es solo una base y lo dejo aquí para recordarme

Nginx: 24: Too Many Open Files Error : Solución

Aveces nos podemos encontrar con este error en nginx: Nginx: 24: Too Many Open Files sea cual sea el uso de NGINX, ya sea como proxy, proxy inverso, web server principal ejecutando PHP.

El error es que superamos el limite de archivos abierto ( valla novedad eso ya lo dice el error )

Aveces es culpa del sistema tiene limites, esos limites los podemos ver en /etc/sysctl.conf

Aunque casi nunca es cosa del sistema, no si es nuestro servidor y no le hemos puesto limites, por defecto casi nunca tiene ningún limite al menos que se lo hayamos puesto o algún otro sys admin.

Es problema de nginx casi siempre, la solución muy sencilla, editamos el nginx.conf y añadimos esta linea:

worker_rlimit_nofile 45000;

Reiniciamos y eso es todo, puede que necesitemos aumentar el valor, si tenemos muchas peticiones o estamos sufriendo un DDOS muy potente 45 000 no será suficiente aunque subir mucho el valor tampoco nos ayudará ya que el server puede colapsar, así que ustedes verán que les sirve, solo hay que analizar la situación, ver el tipo de servidor que tenemos etc etc

NOTA: Puede salir error cuando tenemos pocas conexiones asignadas, si es así aumentamos los workers_conections y los workers.

Con 30 mil o 35 mil es más que suficiente para un servidor y una web “normal”.