Otras veces ya hemos visto como realizar una instalación de Apache con PHP y eAccelerator, una vez instalado los ficheros ejecutables importantes son:

• apachectl: Mediante este script podremos:
  • Gestionar el arranque y parada del daemon (start/stop)
  • Comprobar la configuración (configtest):

    # /usr/local/apache22/bin/apachectl configtest
    Syntax OK

  • Recargar la configuración en caliente, sin apagar el daemon (graceful)
• httpd: Binario del daemon, con dicho fichero podemos:
  • Indicar que fichero de configuración cargar (opción -f)
  • Ver el listado de módulos que carga (opción -M):

    # /usr/local/apache22/bin/httpd -M
    Loaded Modules:
     core_module (static)
    (...)
     jrun_module (shared)

  • Al igual que con apachectl, comprobar la configuración con la opción -t:

    # /usr/local/apache22/bin/httpd -t
    Syntax OK

  • Ver el resumen de configuración de los VirtualHosts con la opción -S:

    # /usr/local/apache22/bin/httpd -S
    VirtualHost configuration:
    wildcard NameVirtualHosts and _default_ servers:
    *:80                   is a NameVirtualHost
             default server shuvak.systemadmin.es (/usr/local/apache22/conf/extra/httpd-vhosts.conf:7)
             port 80 namevhost shuvak.systemadmin.es (/usr/local/apache22/conf/extra/httpd-vhosts.conf:7)
             port 80 namevhost systemadmin.es (/usr/local/apache22/conf/extra/vhosts/systemadmin.es.conf:1)
             port 80 namevhost foro.systemadmin.es (/usr/local/apache22/conf/extra/vhosts/foro.systemadmin.es.conf:1)
    Syntax OK

Un ejemplo de configuración típica de un VirtualHost sería la siguiente:

<VirtualHost *:80>
        DocumentRoot "/var/www/systemadmin.es/htdocs"
        DirectoryIndex index.php
        ServerName systemadmin.es
        ServerAlias foro.systemadmin.es

        <Directory /var/www/systemadmin.es/htdocs>
            Options FollowSymLinks
            AllowOverride all
            Order deny,allow
            Allow from all
        </Directory>

        ErrorLog  "| /usr/local/sbin/cronolog -S /var/www/systemadmin.es/logs/current.error.log /var/www/systemadmin.es/logs/%Y/%m/%d/error.log"
        CustomLog "| /usr/local/sbin/cronolog -S /var/www/systemadmin.es/logs/current.custom.log /var/www/systemadmin.es/logs/%Y/%m/%d/custom.log" combined

</VirtualHost>

Las directivas importantes son:

• DocumentRoot: Directorio base desde el cual serviremos el contenido. Deberemos acompañarlo de la directiva Directory para establecer si se puede servir o no su contenido
• DirectoryIndex: Cuando se intente servir la raíz o cualquier directorio (sin especificar fichero), cual se debería servir. Típicamente se usa index.algo, pero podría ser cualquier fichero. Esta directiva indica que fichero servir y en que orden de prioridad. Por ejemplo:

  DirectoryIndex index.php index.html index.htm

  Primero miraría si existe un fichero index.php, en caso que no exista buscaría el siguiente (index.html) y así el listado que indiquemos. En caso que no exista ninguno, se serviría un 404

• ServerName y ServerAlias: Nombres a los que responde según el header Host. Se pueden especificar wildcards tanto pode delante (*.systemadmin.es) como por detrás (webmail.*). La diferencia entre ServerName y ServerAlias a la practica tiene poca importancia.

En cuanto a la gestión de logs, personalmente uso cronolog ya que una vez configurado cómo queremos almacenar los logs no deberemos hacer mantenimiento a no se que queramos eliminar los antiguos. Para ello suelo emplear un simple script que haga limpieza:

#!/bin/bash
for i in $(find /var/www/ -maxdepth 2 -iname logs);
do

        #eliminacion de los mas antiguos de 10 dias
        find $i -mtime +10 -type f -exec rm {} \;

        #eliminacion de directios vacios
        find $i -empty -type d -exec rmdir {} \; 2>/dev/null

        #compresión de logs ya rotados
        find $i -type f -iname \*\.log -mtime +2 -exec gzip {} \;

done

Deberemos adaptar el find del for para que encuentre los directorios raíz dónde tenemos los logs.

Para conocer el estado del Apache existe el modulo mod_status, que nos indica que esta haciendo dicho daemon. Generalmente se instala en /server-staus con acceso limitado por IP de origen.

En el scoreboard veremos los estado del los apachitos (procesos apache) y podremos ver si existe algún problema con algún VirtualHost. Típicamente podremos ver:

• Se nos llena el scoreboard de W: Cuando un slot esta en estado W significa que esta contestando, pero si vemos que se nos acumulan W posiblemente esta contestando muy lentamente por algún motivo o bien simplemente se queda colgado. Generalmente indica problemas en la base de datos.Si habilitamos la opción

  ExtendedStatus On

  Tendremos un listado de todas las peticiones y su estado, para cuanto tiempo lleva un slot en el estado actual deberemos fijarnos en la columna SS. Por lo tanto, las peticiones en estado W que tenga el SS alto son las primeras que deberemos investigar. Evidentemente, si servimos contenido estático (un mp3) es lógico que tarde en ser entregado y por lo tanto que su SS sea alto.

• Se nos llena el scoreboard de K: Tendremos que ver si nos interesa reducir el tiempo de KeepAlive de las conexiones. Por defecto lo tenemos a 5 segundos, pero lo podemos dejar en 1 o 2 segundos según la aplicación.

En otra ocasión ya hablamos de en que debemos fijarnos para entender el problema que tenga un entorno LAMP

Otra cosa a tener en cuenta es la diferencia entre ServerLimit y MaxClients: ServerLimit es el límite fijo que no puede ser modificado mediante una recarga de configuración (graceful) mientras que MaxClients es el límite actual.

Actualmente mod_status no muestra los slots de Apache que quedan deshabilitados por la directiva MaxClients, por lo que nos puede dar pie a error al suponerlos libres. En su momento hice un patch para evitar esto y será incluido en la próxima release de Apache (2.4), actualmente ya se encuentra disponible en la versión beta desde la versión 2.3.11.

Nuestra fuente: Systemadmin

RewriteCond %{HTTP_USER_AGENT} ^.*iPhone.*$
RewriteRule ^(.*)$ http://mobile.yourdomain.com [R=301]
RewriteCond %{HTTP_USER_AGENT} ^.*BlackBerry.*$
RewriteRule ^(.*)$ http://mobile.yourdomain.com [R=301]
RewriteCond %{HTTP_USER_AGENT} ^.*Palm.*$
RewriteRule ^(.*)$ http://mobile.yourdomain.com [R=301]

Redirect iPhone, Blackberry, & Palm Requests With .htaccess

Nuestra fuente: Sentidoweb

El servidor web Apache distribuye incontables bytes de datos cada segundo. Según la propia ASF, también está al servicio de empresas, universidades, instituciones financieras, militares y aeroespaciales. Es más, lo podemos encontrar incrustado en software propiedad de Oracle, IBM, Apple y Borland, por ejemplo.

Ahora les presento algunos datos alrededor de Apache:

• Hay dos tesis sobre el origen del nombre: 1) En honor a una tribu de nativos americanos, 2) Dado que nació del resultado de combinar pedazos de código del proyecto padre (NCSA httpd), entonces fue “A patchy server”.
• Llegó a convertirse en el servidor web más popular del mundo a tan solo seis meses de su creación.
• Actualmente ofrece sus servicios a cerca de 112 millones de sitios web: un 70% del total de ellos.
• Apache v.1.0 fue liberado en diciembre de 1995; siete años después, surge la versión 2.0, reestructurada desde sus cimientos para ofrecer mayor modularidad y portabilidad entre plataformas.
• En febrero de 2009, el servidor Apache se convirtió en el primero de su tipo en rebasar la barrera de los 100 millones de sitios web.
• El modelo de colaboración entre la comunidad Apache, conocido como “The Apache Way”, es meritocrático. Dicha comunidad la conforman más de 2.000 personas, oficialmente.
• ApacheCon es la conferencia anual dedicada a Apache que se lleva a cabo en EE. UU., Asia y Europa.
• La ASF es financiada gracias a aportaciones tanto individuales como corporativas: Entre ellas, Google, HP, Microsoft (sic), Yahoo! y recientemente, Facebook.

Algunos ya habrán notado que el año de inicio es 1994 y han pasado 16 años desde entonces. Así que ¿por qué festejar 15 años? Porque la versión 1.0 de Apache llegó en diciembre de 1995. Es una contabilidad extraña la del anunció de la ASF, ¿no lo creen? (¿alguien ve una mejor explicación?).

Sin más, despido este artículo agradeciendo a Apache la oportunidad de llegar hasta ustedes vía HTTP (lo sé, hay muchos otros intermediarios, pero no terminaría de listarlos).

Nuestra fuente: bitelia.com

Independientemente que el fichero que tengamos en el /etc/init.d, por ejemplo /etc/init.d/httpd, permita esta comprobación de sintaxis, el fichero apachectl permite realizar esta comprobación. En instalaciones desde repositorios lo podremos encontrar típicamente en /usr/sbin/apachectl y desde código fuente dependerá de las opciones de compilación, por ejemplo, /usr/local/apache22/bin/apachectl

Para comprobar la sintaxis simplemente deberemos indicar la opción configtest:

# /usr/local/apache22/bin/apachectl configtest
Syntax OK

En caso de algún problema nos indicará la linea donde podemos empezar a mirar:

# /usr/local/apache22/bin/apachectl configtest
Syntax error on line 425 of /usr/local/apache22/conf/httpd.conf:
Invalid command ‘Frak’, perhaps misspelled or defined by a module not included in the server configuration

Nuestra Fuente: SystemAdmin.es

Para el código que se ejecuta con el servidor web suele ser útil deshabilitar funciones de PHP que no queremos usar. El problema es que seguramente la parte de la aplicación que ejecutamos periódicamente (con el cron por ejemplo) tendrá unos requerimientos diferentes.

Para poder ejecutar los procesos (mailings, calculos varios…) podemos indicar que se use un php.ini diferente mediante el parámetro -c:

php -c /etc/php.procesos.ini proceso.cualquiera.php

Mediante este comando indicamos a php que ejecute el scriptproceso.cualquiera.php usando la configuración presente en el fichero/etc/php.procesos.ini. En este fichero podremos ser más permisivos sin afectar a lasrestricciones del servidor web.

Nuestra Fuente: SystemAdmin.es