Mar 16

Hace poco más de dos semanas se liberó la versión 5.2.9 del PHP. La que probablemente será la última release de la rama 5.2.x… o al menos eso esperamos muchos como yo que andamos impacientes por la llegada de la 5.3 estable con todas sus novedades.

Como siempre se corrigen un buen número de bugs de seguridad (algunos relacionados con las extensiones libxml y XML) y se añaden algunas mejoras menores… por ejemplo, como curiosidad, ahora a la función array_unique le podemos pasar el tipo de comparación a realizar para descartar ítems. En el changelog están detallados todos los cambios.

En mi opinión siempre es muy recomendable actualizar los servidores a la última versión, si queremos podemos esperar unas semanas para ver como reacciona internet a una nueva release pero se ha de tener en cuenta que lleva meses de test por parte de la comunidad (algo en lo que, por cierto, cualquiera puede participar). Me parece sorprendente todavía encontrar sistemas/proyectos corriendo PHP 4.x o incluso 5.0.x / 5.1.x. (aunque PHP 5 sigue sonando a nuevo se ha de pensar que la versión 5.0 salió el Julio del 2004 y la 5.1 el Noviembre del 2005).

A pesar de que muchas distribuciones Linux (no tanto los *BSD) incluyen como estables versiones desfasadas del PHP si uno tiene un servidor web (LAMP) creo que es recomendable conseguir tener la combinación Apache+MySQL+PHP lo más actualizada posible. Es la forma de aprovechar las nuevas funcionalidades existentes (sobretodo en el caso del PHP dado que es un lenguaje de programación :) y también es la forma de encontrar bugs y hacer que estos proyectos open source evolucionen correctamente.

PS: Por suerte HostGator hace tiempo que se pusieron las pilas y nos mantienen bastante actualizados (este blog corre sobre PHP 5.2.8).

Tagged with:
Feb 22

Desde hace muchos años y por mucho que evolucione el desarrollo web e internet el SSH, al igual que el CVS/SVN, sigue siendo una de las herramientas más usada para administrar aplicaciones web y sus respectivos servidores.

Una de las funciones que para mi resulta más útil del SSH a parte de lo evidente que es poder iniciar sesión en nuestro servidor, es poder ejecutar comandos remotamente y así fácilmente poder escribir scripts (PHP y/o de shell) que interactúen entre máquinas. Por ejemplo para subir la última release de nuestra web a producción, borrar cachés de disco, reiniciar algún que otro Apache que se ha quedado tonto, etc.

Algo que resulta muy útil en estos casos es poder usar SSH entre distintas máquinas sin necesidad de ir introduciendo la contraseña. Para conseguirlo, y entendiendo bien el riesgo de seguridad que puede suponer, hemos de seguir los siguientes pasos:

[1] Iniciamos sesión en el servidor A con el usuario que queremos dejar libre de contraseña y ejecutamos:

$ ssh-keygen -t rsa

[2] Añadimos la clave publica generada (.ssh/id_rsa.pub) al archivo de claves aceptadas del servidor B, por ejemplo vía SCP:

$ scp .ssh/id_rsa.pub usuario@B:.ssh/authorized_keys

Se ha de tener en cuenta que el anterior comando sobreescribe el archivo y podemos tener más de una clave aceptada en authorized_keys.

[3] Listos! Desde el servidor A ya podemos entrar en B sin contraseña. Si estamos logueados con el usuario correcto sólo será necesario ejecutar:

$ ssh B

Al programar en PHP por supuesto que siempre tienes la alternativa de realizarlo todo vía peticiones HTTP aunque para determinadas tareas y situaciones los scripts CLI son una gran alternativa (y los puedes hacer muy chulos usando ncurses).

Tagged with:
Jun 17

Para los nostálgicos como yo que os gusta seguir con una slackware por algún rincón, hace poco que está disponible la primera candidata a release de la futura Slackware 12.0.

Entre muchas novedades tenemos kernel 2.6.21.5, KDE 3.5.7, Apache 2.2.4 con PHP 5.2.3, etc.

A mi personalmente es una distribución que me sigue encantando… si no tengo más remedio que usar un Linux por que ninguno de los BSD es apropiado, no lo dudo ni un momento, Slackware o Debian si quiero ir rápido y Gentoo si tengo más tiempo.

Vía Tod-OS.com

Tagged with:
Apr 26

Como prometía en el post dedicado a la optimización de ADOdb voy a explicar como instalar el sistema de cache APC sobre un servidor FreeBSD 6.x. El APC (Alternative PHP Cache) es un sistema de cache de opcode para PHP, sirve para cachear el código intermedio del PHP y así no tener que interpretar todos los scripts en cada ejecución. Para almacenar este código “compilado” se usa la memoria compartida del sistema. A parte el APC nos ofrece funciones para poder almacenar y recuperar datos de cache.

El APC es una extensión PECL que no viene incluida por defecto con el PHP (esto cambiará con la futura versión 6). A continuación describo como instalar y configurar el APC sobre FreeBSD.

[1] Instalar el port

Suponiendo que tenemos instalado y funcionando un servidor web (Apache+PHP) sólo nos falta añadirle la extensión PECL con:

# portinstall pecl-APC

Si no trabajas con portupgrade:

# cd /usr/ports/www/pecl-APC/
# make install clean

Con esto compilamos e instalamos el APC. Si todo va bien acabará el proceso y podremos ver esta nueva linea en el archivo /usr/local/etc/php/extensions.ini:

extension=apc.so

Cuando lo compilas se dan a escoger tres opciones: MMAP, SEMAPHORES y PHP4_OPT. Es aconsejable seleccionar sólo MMAP y si trabajas con PHP4 la última también. La opción de SEMAPHORES dependiendo de tu sistema puede provocar cierta inestabilidad y no ofrece muchas mejoras en rendimiento.

La última versión del APC (pecl-APC-3.0.14) se compila siempre con soporte mmap aunque desactives la opción (o esto es lo que me pasa a mi en los servidores bajo FreeBSD).

Ahora sólo falta configurar correctamente las directivas apropiadas en el php.ini y un restart (o reload) del Apache.

[2] Configurando el APC

La configuración por defecto del APC es apropiada en muchas situaciones aunque bajo FreeBSD deberíamos configurar correctamente el tamaño de memoria compartida. Esto se consigue con las siguientes directivas:

apc.shm_segments=1
apc.shm_size=32

En FreeBSD el tamaño de memoria compartida por defecto es de 32MB. Puedes optar por aumentarlo o por dejarlo igual y usar varios segmentos configurando la directiva apc.shm_segments. Para aumentar el tamaño de la memoria compartida a 128MB en FreeBSD:

# sysctl kern.ipc.shmmax=134217728
# sysctl kern.ipc.shmall=32768

Si quieres conservar estos valores después de reiniciar el sistema debes añadirlos en /etc/sysctl.conf.

Se debe fijar SHMALL (kern.ipc.shmall) a SHMMAX/PAGE_SIZE. Este valor en el ejemplo descrito de 128MB de memoria compartida nos queda como: 134217728/4096 = 32768. Puedes ejecutar el comando pagesize para conocer el tamaño de una página de memoria (PAGE_SIZE) en tu sistema y ipcs -M para verificar la configuración de la memoria compartida.

También hacer notar en este punto que con la última versión del APC bajo FreeBSD no permite usar varios segmentos de memoria compartida y estás obligado a sólo usar un segmento, si necesitas más memoria debes aumentar el tamaño de memoria compartida del sistema.

El resto de directivas de configuración dependen mucho del tipo de aplicación PHP. Dependiendo del número de visitas, cantidad de archivos a cachear, frecuencia de cambio de los archivos, etc. Una configuración de ejemplo con pequeñas notas acerca del significado de las directivas usadas (en el archivo /usr/local/share/doc/APC/INSTALL tienes todas las directivas disponibles detalladas):

; Activa el APC
apc.enabled=1
; Número de segmentos de memoria compartida
apc.shm_segments=1
; Tamaño de la memoria compartida
apc.shm_size=128
; Un número aproximado de archivos fuente a cachear
apc.num_files_hint=6000
; Un número aproximado de variables a cachear
apc.user_entries_hint=100
; Segundos que dejamos en cache una entrada que ya no se usa
apc.ttl=600
; Idem al anterior pero para las variables de usuario
apc.user_ttl=600
; Segundos que dejamos una entrada cacheada en el recolector de basura
apc.gc_ttl=0
; Indica si se cachea por defecto.
apc.cache_by_default=On
; Expresiones regulares para saber que archivos cacheamos
; Resulta útil si se usa en combinación con la directiva anterior
apc.filters=""
; Indica si se activa el APC para el modo CLI del PHP
apc.enable_cli=0
; Indica el tamaño máximo de archivos a cachear
apc.max_file_size=1M
; Indica si el APC ha de verificar si los archivos han sido modificados
; para actualizar la cache
apc.stat=1

De todos los cacheadores de código que he usado APC es con diferencia el más estable aunque no es perfecto. En situaciones de mucho tráfico y si constantemente estás cambiando los archivos al final consigues un fantástico segfault del Apache. Una gran opción si dispones de una aplicación que no está en constante desarrollo es usar la directiva apc.stat a 0, con este parámetro consigues mucha más estabilidad.

Es un gran invento y es muy recomendable su uso, puedes llegar a ver loads de CPU reducidos al 50% y ganar un 20% de memoria. Pero como todo tiene bugs y al menos yo en el escenario donde lo uso (decenas de millones de páginas vistas por mes + clúster de decenas de servidores BSD) es un tanto inestable en ciertas situaciones… pero mucho más estable que algo como EAccelerator el cual en el anterior escenario no aguanta ni 5 minutos.

Si usas APC sobre FreeBSD en webs con mucho tráfico y no tienes ni un segfault nunca… no te cortes y comenta que directivas/opciones estás usando.

En un siguiente post explicaré como usar las funciones que proporciona el APC para almacenar datos de aplicación en cache.

Tagged with:
Jan 29

Desde hoy PHPBSD.net pasa a formar parte de Planeta BSD. Planeta BSD es un planeta que recopila escritos en español relacionados con los sistemas BSD. Es un blog que funciona de forma automática alimentándose de las feeds de blogs relacionados.

Para poder formar parte de este planeta necesitamos poder sindicar sólo temas relacionados con BSD, si tu blog sólo se dedica a BSD perfecto, ya lo tienes (a q esperas :), pero si no has de poder conseguir generar un feed sólo acerca de este tema específico.

Con WordPress dispones de dos formas fáciles de conseguirlo: usando las categorías incluidas por defecto o el plugin UTW para disponer de tags. Sólo se trata de categorizar o etiquetar todo lo relacionado con BSD y añadiendo feed/ (o &feed=rss2) a la URL de la categoría o etiqueta dispondremos de la feed deseada.

Como InKiLiNo me comenta que ya estoy añadido en el sistema este post también debería aparecer en PlanetaBSD.

Tagged with:
preload preload preload