BatU's Stack

Cuando tenemos una máquina que no funciona correctamente es posible que los procesos estén en estado zombi. Para poder ver los procesos en este estado usamos el comando siguiente:

ps -el | grep 'Z'

Con el comando ps -el se puede obtener una salida en la que la segunda columna indica el estado del proceso. Existen varios estados:

S : sleeping
R : running
D : waiting
T : gestopt (suspended)
Z : zombie (defunct)

Un ejemplo podría ser el siguiente:

# ps -el | grep 'Z'
F S   UID   PID  PPID  C PRI  NI ADDR    SZ WCHAN  TTY   TIME CMD
1 Z     0  1213   589  0  75   0    -     0 funct> ?    00:00:00 find

Donde vemos que el proceso dovecot-auth está en estado zombi.

Hoy he descubierto un programa bastante interesante para generar paquetes para las distribuciones más usadas, entre ellas como no Debian. El programa en cuestión es Checkinstall. Nos permite generarnos debs a partir del código fuente de forma tan fácil como:

./configure
make
checkinstall

Al ejecutar el checkinstall este nos pregunta acerca de la descripción que queremos poner al paquete, el tipo de paquete(RPM, DEB o SLACKWARE TGZ), así como el maintainer, version, licencia… Y después de indicárselo tendremos en el directorio nuestro programa en forma de paquete deb/rpm/tgz. Además el programa nos permite poner documentación que luego se instalará en /usr/share/doc, también podemos ejecutar scripts preinstall/postinstall y preremove/postremove y puede que más cosas que no he mirado.

Existe una forma cómoda, fácil y rápida de tener java (ya sea jre o jsdk) en un deb, mediante el paquete java-package de debian. Los pasos son los siguientes:

1. Instalar java-package (apt-get install java-package)
2. Bajar de la web de sun el jsdk por ejemplo el jdk 5.0
3. Ejecutar make-jpkg jdk-1_5_0-linux-i586.bin (lo que nos generará el .deb)

Ahora ya podremos hacer dpkg -i sun-j2sdk1.5_1.5.0_i386.deb , lo que nos instalará el entorno en /usr/lib/j2sdk1.5-sun.

Lo que voy a explicar es una forma de hacer que una máquina (servidor) actúe como pasarela a internet, es decir compartir la conexión a internet entre varios equipos. Para ello nuestro servidor deberá constar de dos tarjetas de red. Una de ellas conectada a “internet” (modem) y la otra a otro equipo ya sea otro pc o un switch.

Bueno pues lo primero que necesitaremos que nuestro kernel debe soportar iptables (versiones 2.4 en adelante) así como realizar nat mediante este. Para ello tenemos que tener activados los modulos ip_tables e iptable_nat.

Una vez nos aseguramos de ello deberemos ejecutar lo siguiente:

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE

Donde 192.168.0.0/24 indica que redireccionaremos a toda la subred 192.168.0.0 (con máscara 255.255.255.0) y eth0 es la interfaz de red conectada a internet.

Después debemos activar el ip forwarding de la ejecutando lo siguiente:

echo "1" > /proc/sys/net/ipv4/ip_forward

Con esto ya tenemos a nuestra máquina haciendo funciones de pasarela. Pero en este punto si reiniciamos el ordenador se perderá la configuración y tendremos que volver a ejecutar los dos comandos anteriores. Para solucionar esto los metemos en un script, algo así como:

#! /bin/sh
echo -n "Iniciando Gateway... "
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE

echo "1" > /proc/sys/net/ipv4/ip_forward
echo "Iniciado."

Guardamos este script como /etc/init.d/gateway, por ejemplo, le damos permisos de ejecución y creamos enlaces simbólicos a él para los runlevels que nos interesen, p. ej para el 2, como sigue:

ln -s /etc/init.d/gateway /etc/rc2.d/S99gateway

Solo resta configurar los clientes, utilizando como puerta de enlace la ip de nuestro servidor (p. ej. 192.168.0.1 en caso de que hayamos configurado esa ip en la segunda tarjeta de red de nuestro servidor) y para las DNS tenemos dos posibilidades:

• Poner directamente las DNS de nuestro proveedor de servicios.
• Instalar bind en nuestra máquina servidor (lo que se escapa de esta explicación).

He estado trasteando un poco (bastante poco la verdad) con el tan resonado software de control de versiones Subversion y la verdad, creía que no me serviría hasta que fuera a hacer algo serio y tal, pero es muy útil y fácil de utilizar.

Según he entendido, básicamente es un sistema de ficheros (o algo parecido) que guarda información en una base de datos acerca de todos los cambios que se realizan sobre los ficheros añadidos a los diferentes repositorios. Un repositorio (se pueden tener todos los que se quiera) no es más, a mi entender, que un contenedor de directorios y ficheros, en el que los usuarios van guardando archivos nuevos, actualizando existentes, eliminando… dando para cada una de estas acciones comentarios sobre lo que y porque lo hacen. De esta manera el sistema subversion guarda un historial de todos esos cambios referentes a cada acción, teniendo así un alto control del proyecto. Todos estos cambios se pueden extraer en un ChangeLog.

Bueno esa es la visión global que he tenido en un ratito. Dejo aquí algunos comandos para ilustrar la facilidad de este sistema:

• Crear un repositorio:

  svnadmin create /directorio/directorio

• Importar un proyecto ya existente en un repositorio:

  svn import /directorio/dir http://server/dir -m "Comentario"

  Los repositorios se indican con URLs (file://, http://...)

• Añadir un fichero al proyecto:

  svn add fichero
svn commit fichero -m "comentario"

  Con add indicamos a subversion que vamos a controlar ese fichero y con commit subimos los cambios (la primera vez pues subimos el original)

• Actualizar nuestra copia local de trabajo:

  svn update

  Desde el directorio que queremos actualizar.

Y bueno muchas más cosas interesantes. Será cuestión de intentar darle uso durante este curso, de hecho un amigo y yo ya hemos pensado usarlo para pasar a LaTeX los apuntes de matemáticas. Todo se andará.

Salu2