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:
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:
Jan 16

Después de los más de tres meses de espera desde la primera beta de la release 6.2 por fin ya tenemos disponible la versión final (ver la noticia). Proporciona mejoras en el rendimiento y estabilidad a parte de incluir numerosas novedades y actualizaciones tanto de aplicaciones como de drivers.

Algunas de las novedades incluidas:

  • FreeBSD Update: Utilidad para actualizaciones binarias del sistema base. Si no te gusta compilar y prefieres trabajar con la versión binaria del sistema base esto es perfecto para ti. La idea es trabajar con la versión binaria del sistema base distribuida en el CD oficial e ir actualizándote con esta herramienta, aunque también permite trabajar con sistemas recompilados localmente.
  • OpenBSM: Añadido OpenBSM (Open Source Basic Security Module). Es una implementación opensource del BSM de Sun, un sistema muy potente para realizar auditorías de seguridad al SO.
  • KDE: Incluida la versión 3.5.4 del KDE.
  • Csup: Incluido csup al sistema base. Csup es una reimplementación de CVSup escrita en C.
  • IPFW: Nuevas reglas de configuración para el firewall. Ahora podemos ponerle tags a los paquetes para identificarlos más tarde (sólo dentro del kernel, no por la red).
  • Linsysfs: Añadido soporte para la emulación del sys filesystem del Linux necesario para correr algunos binarios de Linux sobre FreeBSD.

Puedes ver la lista completa de novedades y cambios en las notas de la release y descargar las imágenes ISO desde la sección de downloads de www.freebsd.org.

Tagged with:
Nov 26

Como culminación a la serie de post dedicados a instalaciones y actualizaciones de software en FreeBSD voy a explicar como montar un servidor de paquetes de software compilado en FreeBSD 6.1. Este procedimiento describe como mantener actualizadas un grupo de máquinas con los mismos programas instalados, como por ejemplo un clúster de servidores Apache con PHP.

A la serie de artículos acerca de cvsup, portsnap, buildworld, sólo le faltaba uno explicando como usar portupgrade. En este post se mostrará un poco su uso, aunque es una herramienta muy potente y con la que vas a tener que trabajar bastante (como rpm para RedHat o apt para Debian), es obligatorio un “man portupgrade”.

El objetivo del invento es sencillo, la idea es que una máquina se encargue de descargar el código fuente, compilarlo y generar paquetes binarios de los programas para que las demás máquinas lo instalen directamente. De esta forma invirtiendo el mínimo tiempo podemos trabajar controlando el código fuente con todas las ventajas que esto conlleva (añadir opciones extra en un Makefile del PHP o Apache, etc.), a parte de que en FreeBSD es necesario pasar por la compilación de los ports para estar realmente a la última (en rapidez en sacar las últimas versiones de software ganamos a la mayoría de distros linux :)

Se asume que todas las máquinas que queremos mantener actualizadas son clones, es decir, tienen el mismo software instalado. Si tienes varios tipos de máquina una posible solución es tener instalado todo el software en la que actúa de master, aunque el sistema es suficientemente flexible como para tener varios servidores de paquetes o servidores de determinados tipos de paquetes. Al mismo tiempo si se muere el master cualquier otro clon del clúster puede continuar su función.

Es cierto que con FreeBSD para disponer de un clúster de servidores con exactamente las mismas versiones de ports instaladas podemos tirar por compartir /usr/local por NFS pero con /usr/local/etc en local en cada máquina vía softlink. Con esto sólo será necesario administrar el software en una máquina. El problema es la dependencia que crea con el servidor de archivos (ya podemos tener un buen failover) a parte de que el NFS tiene un límite y veremos que con unas cuantas decenas de máquinas con el /usr/local compartido y con más directorios compartidos (p.e. el document root del apache, caches de disco, etc.), se empiezan a bloquear procesos por acceso a NFS…. entonces tendrás que empezar a pensar en un clúster de servidores de archivos. Es una opción viable y aplicada en muchos casos pero en general es recomendable reducir al mínimo los servicios extra entre las máquinas de un clúster.. ya tenemos ocupados los recursos con su función principal (web, mail, etc.).

Requisitos para los clones y el servidor

[1] Instalar portupgrade

Podemos instalarlo de binario:

# pkg_add -r portupgrade

o compilando:

# cd /usr/ports/sysutils/portupgrade
# make install clean

Es recomendable conseguir instalar la misma versión del portupgrade tanto en el servidor como en los clones. No es mala idea tirar del binario al principio para ganar tiempo ya que igualmente si pretendemos estar al día de versiones lo acabaremos compilando no muy tarde (es un paquete que se actualiza con bastante frecuencia).

[2] Preparar el entorno

Fijar las siguientes variables de entorno en tu .bash_profile (asumiendo trabajas con bash):

PACKAGES=/var/portupgrade/packages; export PACKAGES
PKG_PATH=/var/portupgrade/packages/All; export PKG_PATH
PKG_TMPDIR=/var/portupgrade/temp; export PKG_TMPDIR
PKG_FETCH=/usr/bin/false ; export PKG_FETCH

Requisitos sólo para el servidor

[1] Crear el directorio para los paquetes

Crear un directorio con suficiente espacio para los paquetes, backups, y archivos temporales. Dependiendo de la cantidad de paquetes pueden ser centenares de megas.

# mkdir -p /var/portupgrade/packages /var/portupgrade/temp

Servidor de paquetes

[1] Iniciar el árbol de ports

Si no lo tienes ya seguir el post Actualiza tu FreeBSD a toda pastilla con portsnap para tener /usr/ports bajo control y al día con portsnap

[2] Instalación de software

Para instalar ports y que portupgrade nos genere el binario en el directorio anteriormente creado:

# portinstal -p [port]

[3] Actualización de todo lo instalado

Para actualizar todos los ports instalados generando el paquete binario y guardando backup.

– Actualizamos el árbol de ports con portsnap:

# portsnap fetch update

– Solucionamos posibles problemas con la BD de paquetes instalados antes de empezar (opcional pero recomendado):

# pkgdb -F

– Descargamos todo lo que vamos a necesitar para no interrumpir el proceso de actualización por un fallo de red (opcional pero recomendado):

# portupgrade -aRF

– Actualizamos todo generando paquetes binarios y guardando backup de las versiones actualmente instaladas:

# portupgrade -abRp

[4] Distribución de software

Ahora sólo falta disponer de los directorios /usr/ports y /var/portupgrade en los clones. Para conseguir esto existen varias alternativas y no es objetivo de este post su detalle, pero básicamente tenemos dos métodos:

  • copiamos el contenido a los clones con algo como rsync o cualquier otra utilidad.
  • compartimos los directorios, por ejemplo con NFS.

Compartir el directorio es lo más cómodo y recomendado, lo ideal es contar con un sistema redundante (algo como DRBD p.e.) aunque si perdemos estos directorios o al propio servidor que actúa como master cualquiera de las máquinas puede pasar a ser master, sólo tiene que iniciar el árbol de ports como se ha descrito anteriormente y crear los directorios en /var/portupgrade.

Clones

A continuación describo como instalar software en los clones. Es recomendable no instalar y/o actualizar software en todas las máquinas a la vez, primero deberiamos probar el proceso en un sólo clon o idealmente en una máquina dedicada a test. En ocasiones desgraciadamente existen bugs y la instalación del port desde el código fuente no tiene el mismo resultado que la desde el paquete binario.

[1] Instalación de software

Para instalar ports y que portupgrade utilice el binario generado por el master:

# portinstal -PP [port]

[2] Actualización de todo lo instalado

Para actualizar todo lo instalado en uno de los clones:

# portupgrade -aPPR

El procedimiento aquí descrito ha sido probado con éxito en varias instalaciones realizadas por el autor.

Tagged with:
preload preload preload