Archivo de la categoría: Servidor Web

Mod_deflate en Htaccess – Comprimir páginas.

Apache

Sencillo código sin tener que editar la configuración de apache:

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/css text/x-component application/x-javascript application/javascript text/javascript text/x-js text/html text/richtext image/svg+xml text/plain text/xsd text/xsl text/xml image/x-icon application/json
</IfModule>

Otra variante:

<IfModule mod_deflate.c>
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/atom_xml
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE application/x-httpd-fastphp
AddOutputFilterByType DEFLATE application/x-httpd-eruby
AddOutputFilterByType DEFLATE text/html
</IfModule>

Si da error 500 lo quitan, seguramente sea por que mod_deflate no este habilitado.

Con eso comprimimos todo el contenido, mod page speed de google nos nos dará el error, aceleramos la carga y reducimos el consumo de ancho de banda.

Dejar Hotlink a Minituras – Thumbnails – Nginx y Apache

Servidor Web

Protección hotlink

He estado migrando unos servidores con imágenes y pasando el servidor web de apache a NGINX y así queda la parte de hotlink:

En Apache:

RewriteEngine on

RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{REQUEST_URI} !_thumb
RewriteCond %{HTTP_REFERER} !^http://(www\.)?skamasle.com(/)?.*$ [NC]
RewriteRule \.(jpg|jpeg|gif|png|bmp|ico)$ url-imagen.jpg [NC,R,L]

Lo mismo pero en NGINX:

#Dejamos los thumbs
location ~* (.*)(_thumb)\.(gif|txt|json|jpg|png|bmp|swf|css|js|swf|pdf|ico)$ {
expires max;
access_log off;
root /dir;
}

# Bloqueamos lo demás, estees el mismo código hotlink si quieren bloquear todo el hotlink copien de aquí hacia abajo
location ~* \.(gif|jpg|png|bmp|swf|css|js|swf|json|pdf|ico|txt)$ {
valid_referers none blocked server_names ~(skamasle.com|www.skamasle.com);
if ($invalid_referer) {
# return 403;
rewrite (.*)\.(jpg|jpeg|png|gif)$ imagen.jpg last;
}
access_log off;
expires max;
root /dir;
}

Como dice el comentario de NGINX si no tienen pensado dejar copiar ninguna imagen pueden copiar del comentario hacia abajo y les servirá para prevenir todo el hotlink.

URLS Amigables de WordPress con NGINX

Nginx, Wordpress

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

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

Nginx,

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

Nginx

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».

Limitar velocidad de bajada en apache con libapache2-mod-bw

Apache

Bueno como dice el titulo vamos a limitar la velocidad de bajada de cada conexión a apache.

Primero instalamos

libapache2-mod-bw

apt-get install libapache2-mod-bw

Habilitamos el modulo:

a2enmod bw

Este paso casi nunca hace falta ya que si lo instalamos con apt-get se auto habilita.

Ahora bien, en el virtual host de cada web o de la web que queremos limitar la bajada añadimos estas lineas al final:

BandwidthModule On
ForceBandWidthModule On
# Limitamos a 200KB por segundo ( los valores en bits )
Bandwidth all 1638400
# Podemos limitar por ciertas extensiones ( 100KBps
LargeFileLimit .avi 1 819200
LargeFileLimit .mpg 1 819200

Reiniciamos apache:

service apache2 restart

Eso es todo.

mod_fcgid: process /usr/local/cpanel/cgi-sys/php5 exit(communication error), get unexpected signal 7

cPanel, PHP, Servidor Web, ,

Administro varios servidores con una configuración muy similar, 8 vps en la misma empresa todos con APC pero solo en uno tengo ese error

Error en cPanel mod_fcgid: exit(communication error), get unexpected signal 7

La configuración en la mayoría de VPS:

PHP 5.3.25 o php 5.4 algunos con IONcube y otros sin el, algunos con ZEND y otros sin el, todos con fcgi y APC.

El caso curioso es que solo un servidor tienen el error descrito anteriormente, el cual he deducido que pasa por tener APC, al quitar APC el error desaparece.

El error no es solo un get unexpected signal 7 en el error log si no que también provoca un error 500 en las páginas web del servidor.

Bien según las pruebas que hecho el error desaparece al quitar APC, al cambiar a PHP 5.4 y poner xcache persiste el error pero aparece en ocasiones muy raras.

Así que viendo el error: mod_fcgid: exit(communication error), get unexpected signal 7 puedo ver que pasa con cualquier optcode: apc o xcache.

cPanel
PHP 5.4 ( muy de vez en cuando )
PHP 5.3.25
Con o sin ZEND o ION
Pasa en un solo VPS con cpanel con unas 25 webs.
Pasa en un VPS de 8 en la misma empresa:

4 gigas de RAM
CPU 4x Xeon(R) CPU E5-2660 0 @ 2.20GHz
SSD raid10
Loadaverage entre 0.80 y 2 según la hora y cantidad de tráfico.
Ram consumida no sobre pasa los 3 gigas.

En fin, con esto digo que con php 5.4 y xcache se reduce la cantidad de veces que sucede, aunque es pronto decirlo los cambios en el server los he hecho hace varias horas y aún no llegamos a hora pico, pero lo que si puedo decir es que si tienen el mismo problema, el mismo mensaje en los logs y errores 500 en la web desabiliten APC o xCache.

Yo volveré a escribir cuando pase la hora pico hoy por la noche que es cuando más se ve el error y veremos si PHP 5.4 y xcache lo solucionan si es así probaré con APC y si tampoco recae en el error atribuiré el fallo a php 5.3.25, algún modulo dañado o algo por el estilo que ya me a pasado en otras ocasiones y reinstalandolo me a solucionado otros fallos similares y cargas altas sin motivo aparente.

Lo otro sería que el VPS este en un nodo con algún problemilla con la RAM, se quede sin RAM o algo parecido, aunque la empresa en la que están los VPS siempre tienen mucha RAM libre y no hay overselling en los nodos.

Error en Apache: Could not reliably determine the server’s fully qualified domain name

Apache

Hay veces que nos topamos con este error en apache:

Could not reliably determine the server’s fully qualified domain name, using 127.0.0.1 for ServerName

waiting apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.0.1 for ServerName

Bien es por que no tenemos definido nada como servidor, o sea en los vhost usamos :80 solamente y apache no encuentra nada o bien por que no tenemos definido un hostname, así que para solucionar el error podemos editar el httpd.conf ( en debian o centos aunque debian usa apache2.conf también tiene un httpd.conf.

Lo editamos: nano /etc/apache2/httpd.conf y agregamos esta linea:

ServerName localhost

O bien agregamos el hostname que tenemos:

ServerName server.skamasle.com

Ojo que el hostname tiene que resolver / apuntar al servidor si no seguirá dando error.

Reiniciamos y listo.