Archivo de la categoría: Apache

Configurar ServerLimit en WHM/cPanel Usando MPM_Event [Error]

Apache, cPanel

Bueno hace poco habla de configurar mpm_event y las directivas ServerLimit cosa que pueden ver en este enlace: MPM_Event – MPM_Prefork – Configuración de ServerLimit y MaxClients

Resulta que en cPanel da errores al definir un valor en ServerLimit menor que MaxClients, he reportado el problema en cpanel, que parece que ya han tenido ese problema y lo están investigando, según la respuesta del soporte:

WHM/cPanel MPM_Event Configuración

We are currently tracking the issues with the apache configuration in WHM where certain directives and combinations of values are not possible due to the interface being designed with prefork in mind. For your reference, the case number is 52321. Our developers are already pursuing a resolution. While there is no set timeline for when this issue will be fixed, please note that new patches are advertised in our changelog as soon as they are implemented.

El error es que no se le puede asignar a ServerLimit un valor menor que MaxClients o MaxRequestWorkers ( apache 2.4 ) ya que el sistema esta diseñado para trabajar con Prefork, al intentar cambiarlo nos devuelve el siguiente error:

The following settings are invalid and were rejected:

maxclients: 100

Bien la solución temporal a sido definir el ServerLimit editando el fichero /var/cpanel/conf/apache/local

nano /var/cpanel/conf/apache/local

Definiendo ahí la directiva ServerLimit:

  "serverlimit":
    "item":
      "serverlimit": 40

También podemos editar la directiva MaxClients, luego solo tenemos que actualizarlo:

Con:

/scripts/rebuildhttpdconf

El resultado de que todo a ido bien:

Built /usr/local/apache/conf/httpd.conf OK

Listo ya no nos dará error en WHM al cambiar esa directiva si usamos MPM_Event.

Edito: para configurar otras directivas podemos editar este otro archivo:

/usr/local/apache/conf/includes/pre_main_global.conf

Eso para las directivas que no se pueden editar desde whm.

MPM_Event – MPM_Prefork – Configuración de ServerLimit y MaxClients

Apache,

Este es solo un pequeño resumen de las directivas de apache, ya que he visto que muchos no saben la diferencia que hay en la configuración del ServerLimit, según el MPM que usamos, ya sea Event o Prefork, así que lo daré con algunos ejemplos:
En Prefork

ServerLimit         256
    MaxClients          150

En event

ServerLimit 40
MaxRequestWorkers 400

Ahí tienen las dos configuraciones normalmente por defecto siempre viene prefork como mpm, por ejemplo en cpanel, la config por defecto es algo así:

 ServerLimit 256
 MaxClients 150

Ahora bien, el punto es que en prefork si subimos el maxclients por encima del ServerLimit no nos dejará iniciar con ese valor y lo dejará igual que ServerLimit.

Esto por que Prefork abre una procesos por conexión.

En Event es diferente, el ServerLimit es la cantidad de servidores que tendremos, puede ser por ejemplo 40 y el MaxRequestWorkers es el número de peticiones que se le podrán hacer a cada uno de esos servidores.

Bien, el problema es cuando en servidores como cpanel cambiamos el mpm_prefork por mpm_worker y dejamos la configuración tal cual estaba, o sea el serverlimit tan alto, por ejemplo que lo tuviéramos en 500, en ese caso apache podrá abrir 500 procesos, esto no es nada bueno, es un consumo de RAM innecesario y si nos hacen muchas peticiones el servidor puede colapsar ya que abrirá muchos procesos en este caso hasta 500 y cada uno podrá aceptar el número de conexiones definido en MaxRequestWorkers.

Bajo ataque o en un pico alto de tráfico será un caos, ya que abrirá todos los procesos que le dejemos.

Event viene siendo como una copia de nginx para que se entienda mejor, en nginx tenemos estas dos directivas que funcionan exactamente igual: 

worker_processes 1;
worker_connections 600;

( bueno igual no, por que si lo pones en apache 1 -> 600 no va a funcionar pero en apache ajustas otros valores para compensar, es solo que funciona muy similar )

En ese caso es igual que en event, nginx abrirá un proceso solo y simultáneamente aceptará hasta 600 conexiones ese proceso, si subimos el worker_processes a 2 y dejamos las conexiones a 600 cada procesos aceptara 600 conexiones simultaneas, lo cual nos dará como resultado que en total podremos recibir hasta 1200 peticiones a la vez, de manera similar funciona mpm_event en apache 2.4 ( en los anteriores también pero en esta versión se lanzo event estable )

Aunque en nginx es mucho más sencillo, tiene menos parámetros que definir a diferencia de apache que todo interviene, pero la idea de este tema era explicar esto, ya que es importante explicar lo del cambio a event y las consecuencias que se pueden tener si se dejan los valores iguales a prefork. Pero también cabe mencionar que los demás valores también son importantes y hay que tener cuidado con ellos.

En lo personal me gusta mucho más NGINX para configurar bajo mucho tráfico, hablamos de 5 mil a más peticiones, es mucho más fácil de controlar, con apache hay que trabajar más rato para lograr que este igual de estable que nginx, como dije antes más valores que ajustar en apache.

Por lo demás si buscan una configuración para event usen la default y ajustenla sus necesidades, no copien la primera que vean en internet.

Evitar el cacheo en el navegador con htaccess.

Apache

Hace tiempo hablamos de como cachear en el navegador o forzar el cacheo del contenido estático por medio de htaccess, podemos verlo aquí: Forzar cacheo de imágenes en el navegador

Si queremos hacer lo contrario podemos usar este otro código:

<FilesMatch "\.(html|htm|js|css)$">
FileETag None
<ifModule mod_headers.c>
Header unset ETag
Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires "Wed, 1 han 2000 05:00:00 GMT"
</ifModule>
</FilesMatch>

Con eso evitamos que se cachee el contenido, aunque en el ejemplo solo se previene el cacheo del css, js y los html, esto por ser los archivos más propensos a cambiar y a la vez los que menos ancho de banda gastan, aunque el primer motivo es mas influyente para evitar que se cacheen estos archivos.

Cargar un subdirectorio en el index / con htaccess

Apache

Instalar web en subdirectorio pero cargarla en el index

Aveces por ciertas razones necesitamos tener nuestra página web en un subdirectorio y no en el public_html, pero necesitamos que el contenido se vea en el index, ejemplo:

/home/skamasle/public_html -> este es el index skamasle.com

Pero por algún motivo queremos que nuestra web este en:

/home/skamasle/public_html/blog , pero que al entrar a skamasle.com se cargue el contenido de blog sin que aparezca la url skamasle.com/blog.

Pues bien, podemos hacerlo con htaccess de esta manera:

RewriteCond %{HTTP_HOST} ^skamasle.com$ [NC,OR]
RewriteCond %{HTTP_HOST} ^www.pruebas.skamasle.com$
RewriteCond %{REQUEST_URI} !blog/
RewriteRule (.*) /blog/$1 [L]

Otras soluciones

Por la web encontramos otras soluciones como esta:

RewriteEngine On

# Map http://www.example.com to /site.
RewriteRule ^$ /site/ [L]

# Map http://www.example.com/x to /site/x unless there is a x in the web root.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/site/
RewriteRule ^(.*)$ /site/$1

# Add trailing slash to directories within /site
# This does not expose the internal URL.
RewriteCond %{SCRIPT_FILENAME} -d
RewriteRule ^site/(.*[^/])$ http://www.example.com/$1/ [R=301]

Y una larga discusión sobre el tema en este enlace: http://www.webmasterworld.com/apache/4095623.htm

Otra variante en que encontramos en serverfault:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^(www.)?site.com$
RewriteCond %{REQUEST_URI} !^/subdir/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /subdir/$1
RewriteCond %{HTTP_HOST} ^(www.)?site.com$
RewriteRule ^(/)?$ subdir/index.php [L]

En este enlace: http://stackoverflow.com/questions/990392/htaccess-rewrite-to-redirect-root-url-to-subdirectory

También en el foro de drupal se habla del asunto:

Drupal instalado en subdirectorio pero cargando en el index

https://drupal.org/node/144643
Options -Indexes
RewriteEngine on
Options +FollowSymLinks
RewriteCond %{HTTP_HOST} !^www\.mysite\.com$ [NC]
RewriteRule .* http://www.mysite.com/	[L,R=301]
RewriteRule ^$ drupal/index.php [L]
RewriteCond %{DOCUMENT_ROOT}/drupal%{REQUEST_URI} -f
RewriteRule .* drupal/$0 [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* drupal/index.php?q=$0 [QSA]

Htaccess – Redirección y Hotlink

Apache,

Un post rápido..

Prevenir hotlink y enviar una imagen cualquier en vez de la original:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?dominio\.com/.*$ [NC]
RewriteRule .*\.(gif|jpe?g|png)$ http://www.EnlaceANuevaImagenParaQueAparezcaEnvezDeLaQueEnlazan/no.jpg [R,NC,L]

Redirrección 301 de dominio (cambio de dominio)

RewriteEngine on
RewriteRule (.*) http://www.dominio.com/$1 [R=301,L]

Solución a: Leverage browser caching – Cachear las imágenes en el navegador

Apache

Si usan el gmetrix o usan el page speed de google, puede que se tomen con un error como este

Leverage browser caching

Esto lo que nos dice es que nuestra web no le dice al navegador que guarde el contenido estático, o sea cada vez que una visita vuelve a entrar a nuestra web carga las imágenes, al menos que le navegador tenga la opción de cachear activada por defecto.

Si tenemos mod_expires activado en nuestro servidor podemos usar este código:

<IfModule mod_expires.c>
  ExpiresActive on

# Your document html
  ExpiresByType text/html "access plus 0 seconds"

# Media: images, video, audio
  ExpiresByType audio/ogg "access plus 1 month"
  ExpiresByType image/gif "access plus 1 month"
  ExpiresByType image/jpeg "access plus 1 month"
  ExpiresByType image/png "access plus 1 month"
  ExpiresByType video/mp4 "access plus 1 month"
  ExpiresByType video/ogg "access plus 1 month"
  ExpiresByType video/webm "access plus 1 month"

# CSS and JavaScript
  ExpiresByType application/javascript "access plus 1 year"
  ExpiresByType text/css "access plus 3 month"
</IfModule>

Con esto forzamos al navegador a cachear nuestro contenido estático y dejarlo guardado por un mes, así que si una visita entra seguido a nuestra web no tendrá que descargar todo el contenido cada vez que entra y así navegará más rápido.

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.

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.

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.