Integración contínua (CI)

En un entorno donde las páginas web son modificadas constantemente e involucra a programadores, es necesario llevar un control de la calidad del software. Es aquí donde entra el Continous Integration.

Para entender un poco mejor esto, hay que conocer la teoría de la ventana rota: Si tienes un carro en buen estado y lo dejas un par de semanas en un mismo lugar donde hay cierto índice de vandalismo es probable que al regresar encuentres el carro en el mismo estado que lo dejaste --ya lo sé, esto no aplica en México. Pero que pasa si dejas el mismo carro con una ventan rota en el mismo lugar... al regresar es probable que lo encuentres sin motor, o sin llantas o de cualquier manera vandalizado. Si algo está mal, la tendencia es que empeorará.

Aplicado esto al desarrollo de aplicaciones con varios programadores, si Juanito Programador envía una porción de código y no pasa las pruebas de calidad se espera que Juantio Programador lo resuelva antes de continuar al siguiente paso del proyecto. Si por el contrario Juanito Programador lo ignora y continúa, los demás programadores tenderán a hacer lo mismo. Para esto es muy práctico contar con un mecánismo (o un bot) que ejecute una serie de pruebas en cuanto Juanito Programador añada su código al proyecto y nos notifique en caso de no pasar alguna de las pruebas.

Nosotros como administradores de sistema debemos de estar al tanto cuando un deploy pueda poner en riesgo la estabilidad del servidor o simplemente muestre una página en blanco o con errores fatales en el caso de servidores web. Para eso nos valemos de herramientas como Jenkins o CI Joe.

Nombres de interfaces de red en Fedora 15 y adelante

Un desarrollador de Fedora, Matt Domsch, menciona que las interfaces de red en Fedora a partir de la versión 15 ya no serán ethX.

According the Matt Domsch, the new naming scheme is as follows:
em[1-N] for on-board (embedded) NICs (# matches chassis labels)
pci<slot>#<port> for cards in PCI slots, port 1..N
NPAR & SR-IOV devices add a suffix of _<vf>, from 0..N depending on the number of Partitions or Virtual Functions exposed on each port.
Other Linux conventions, such as .<vlan> and :<alias> suffixes remain unchanged and are still applicable.

Lo que quiere decir que las interfaces de tarjetas integradas a la tarjeta madre seran em1, em2... y las interfaces de tarjetas PCI seran pc1, pc2....

Otra peculiaridad que se maneja en el archivo de configuración de las tarjetas en /etc/sysconfig/network-scripts/ifcfg-nombre es que se usa el UUID de la tarjeta de red y ya no se especifica el nombre del dispositivo como antes se hacia.

Antes:

DEVICE="eth0"

 Ahora:

UUID=0e0e0e0e-1234-1234-a1a1-1234567890ab

Curiosidades NFS

Problema
Equipo que monta un directorio NFS y le asigna propiedad a los archivos como el usuario nobody

ls -ld /home/usuario/.ssh
drwx------ 2 nobody nobody 4096 Nov 25 23:44 .ssh

Solucion
revisar la configuracion de idmapd.conf . Esto se puede deber a que el cliente NFS no sabe como mapear el id del propietario remoto de los archivos a un id de usuario local. Se puede especificar explicitamente que use el mapeo de nssswitch, agregando la siguiente linea en el archivo  idmapd.conf

Method = nsswitch

también hay que revisar en el mismo archivo de configuración que el dominio tanto del cliente como del servidor sean el mismo

Domain = midominio.net

Problemas con Google Chrome

• El navegador inicia en modo de pantalla completa y no sale del modo incluso presionando F11:
  
  Borrar archivo de Preferencias en:
   $HOME/.config/google-chrome/Default/Preferences

XForwarding en CentOS

Por lo general los servidores se instalan sin ambiente grafico para obtener lo que se pueda de RAM libre, pero en ocasiones resulta muy practico (o a veces necesario) ingresar a una aplicacion en modo grafico.

Para ello podemos hacer uso del XForwarding en SSH, pero si no se cuenta con ciertos paquetes instalados en el servidor, podremos tener dificultades como el molesto mensaje Cannot open display y si bien nos va, se abre una ventana donde cada casilla de texto se muestra con rectangulos.

Hay que asegurarse que se tengan los siguientes paquetes si por ejemplo se quiere ejecutar virt-manager

• PackageKit-gtk-module
• PackageKit-glib
• PackageKit
• xorg-x11-fonts-misc
• ttmkfdir
• xorg-x11-fonts-Type1
• xorg-x11-fonts-100dpi
• xorg-x11-fonts-75dpi
• libcanberra
• libcanberra-gtk2
• xorg-x11-xauth

Esto aplica para CentOS 6

svn + ssh

Servidor SVN accesible mediante SSH

¿Porque?
El usar conexiones SSH para manejar repositorios de subversion, nos da seguridad al manejar la capa cifrada del SSH, ademas de que podremos hacer uso de los usuarios en el S.O. para el acceso a los repositorios en lugar de estar creando usuarios y contrasenias individuales solo para acceder a los repos.

Como se hace

1. Instalar subversion
   yum install subverison
2. Crear un grupo de usuarios para subversion
   groupadd -g 800 svn
3. Crear el directorio donde estaran los repositorios
   mkdir -p /usr/local/svn/repos
4. Dar pertenencia de grupo al directorio para que los usuarios puedan escribir en el
   chown -R :svn  /usr/local/svn
   chmod -R 775 /usr/local/svn/repos
5. Crear un repositorio con svnadmin
   svnadmin create /usr/local/svn/repos/mi_repo
6. Agregar al grupo a los usuarios que modificaran los repos
   usermod -G svn fulanito
7. Crear un wrapper para evitar problemas de permisos al acceder por ssh.
   Cuando se esta ejecutando el servidor de subversion y es accedido por ssh, el demonio crea una instancia de si mismo con nuestro propio usuario (por ejemplo svnserve ejecutado por fulanito) y por default los permisos de archivos creados seran de solo lectura y escritura para el usuario que los creo. Para evitar esto hay que colocar un script que sirva de wrapper, como el siguiente:
   
   #!/bin/sh
   # permite escritura al grupo
   umask 002
   
   # invocamos a svnserve, pasando como argumentos el directorio de los repos
   exec /usr/bin/svnserve "$@" -r /usr/local/svn/repos
8. Guardamos este script como /usr/local/bin/svn
9. Lanzamos svnserve como demonio
   /usr/bin/svnserve -d -r /usr/local/svn/repos
10. Ahora los clientes se podran conectar a servidor/mi_repo
    svn list svn+ssh://servidor/mi_repo

Troubleshooting

• Revisar que la creacion del repositorio y el directorio root de svnserve sea coherente, por ejemplo si se uso como root directory /usr/local/svn/ y se hizo svnadmin create /usr/local/svn/puppet entonces los clientes haran el checkout con svn co svn+ssh://noc2/puppet

Varnish

¿Que es?

Es un acelerador de aplicaciones web. Se instala en el webserver donde el contenido sera almacenado, resultando en un incremento del desempeño.

Si tu sitio consta de un par de servidores web o mas con contenido que no cambia muy frecuentemente, varnish puede alojar en su cache el contenido mas consultado, evitando que se le hagan peticiones a los servidores web. Es mas rpadio entregar contenido que esta en memoria acontenido que tiene que ser extraido de un archivo y transmitido a traves de la red local antes de ser transmitido a la Internet.

Tips

• Como averiguar el archivo de configuración que esta usando el demonio en ejecución
  ps -fea | grep varnishd
• Para ver en que puerto esta escuchando el demonio de varnish
  lsof -i | grep varnish

Si el demonio no levanta:

• Verificar que el puerto no se encuentre en uso (por ejemplo un servidor web apache en el puerto 80)