Generación de una clave

Simplemente hemos de ejecutar el siguiente comando:

gpg --gen-key

Nos hará una serie de preguntas, entre ellas nos pedira un passphrase, que sera la clave privada.

Más adelante necesitaremos importar la clave pública para usar el repositorio, la exportamos con el siguiente comando:

gpg -a --export > clave_publica.gpg

Firma de los Release

Ahora que ya poseemos una clave para firmar el repositorio tenemos que firmar todos los Release en cada uno de los directorios:

gpg -bao Release.gpg Release

Esto nos pide el passphrase que introdujimos al generar la clave, y nos genera un fichero Release.gpg. Pues bien una vez hemos firmado todos los ficheros Release ya tenemos firmado el repositorio.

Importando la clave pública

Ahora lo único que nos falta es importar la clave pública exportada anteriormente en cada una de las máquinas que utilizan el repositorio:

apt-key add clave_publica.gpg

Si no hacemos este último paso el apt de cada máquina no reconocerá como firmados los Release

Preparando el repositorio

Antes que nada deberemos crear un directorio raíz donde se hallará el resto de directorios y ficheros. Por ejemplo creamos el directorio /var/repo.

Una vez creado el raíz habrá que crear dentro de el la estructura de directorios, por ejemplo para la distribución sarge creamos la siguiente estructura:


/dists
/dists/sarge
/dists/sarge/contrib
/dists/sarge/contrib/binary-i386
/dists/sarge/contrib/source
/dists/sarge/main
/dists/sarge/main/binary-i386
/dists/sarge/main/source
/dists/sarge/non-free
/dists/sarge/non-free/binary-i386
/dists/sarge/non-free/source


Donde vemos que primero se crea el directorio dists, donde luego habrá un directorio por cada distribución (en nuestro caso solo sarge). Dentro de la distribución (sarge) tendremos las diferentes secciones, main para paquetes libres, non-free para paquetes no libres, y contrib para paquetes libres que dependen de otros paquetes que no lo son.

Una vez creadas las secciones creamos un directorio para los binarios, binary-<arquitectura> en este caso como serán exclusivamente para arquitectura i386 solo necesitaremos binary-i386, y un directorio para los fuentes, source.

Llenando el repositorio

Una vez creada la estructura ya podemos alojar nuestros paquetes. Para ello tenemos que copiar los .deb correspondientes a paquetes binarios en los directorios binary-i386 de cada sección. Si además queremos distribuir los fuentes copiaremos los ficheros .dsc -diff.tar.gz .orig.tar.bz en los directorios source.

En cada directorio binary-i386 y source necesitamos un fichero Release cuyo contenido sería el siguiente:


Archive: stable
Component: main
Origin: <Tu nombre u organizacion>
Label: <Una etiqueta descriptiva>
Architecture: <Arquitectura de tu procesador o "source" para los directorios de fuentes>


Ficheros de configuración

Necesitamos dos ficheros de configuración:

• apt-sarge-release.conf
• apt-ftparchive.conf

Ambos ficheros los pondremos en el directorio raíz del repositorio. Y su contenido sería el siguiente:

apt-sarge-release.conf


APT::FTPArchive::Release::Origin "Tu nombre u organizacion";
APT::FTPArchive::Release::Label "Etiqueta descriptiva";
APT::FTPArchive::Release::Suite "stable";
APT::FTPArchive::Release::Codename "sarge";
APT::FTPArchive::Release::Architectures "i386 source";
APT::FTPArchive::Release::Components "main contrib non-free";
APT::FTPArchive::Release::Description "Descripcion detallada";


apt-ftparchive.conf

Dir {
  ArchiveDir \".\";
  CacheDir \".\";
};
	
Default {
  Packages::Compress \"gzip bzip2\";
  Sources::Compress \"gzip bzip2\";
  Contents::Compress \"gzip bzip2\";
};
	
BinDirectory \"dists/sarge/main/binary-i386\" {
  Packages \"dists/sarge/main/binary-i386/Packages\";
  Contents \"dists/sarge/Contents-i386\";
  SrcPackages \"dists/sarge/main/source/Sources\";
};
	
BinDirectory \"dists/sarge/contrib/binary-i386\" {
  Packages \"dists/sarge/contrib/binary-i386/Packages\";
  Contents \"dists/sarge/Contents-i386\";
  SrcPackages \"dists/sarge/contrib/source/Sources\";
};
	
BinDirectory \"dists/sarge/non-free/binary-i386\" {
  Packages \"dists/sarge/non-free/binary-i386/Packages\";
  Contents \"dists/sarge/Contents-i386\";
  SrcPackages \"dists/sarge/non-free/source/Sources\";
};
	
Tree \"dists/sarge\" {
  Sections \"main contrib non-free\";
  Architectures \"i386 source\";
};
	
Default {
  Packages {
    Extensions \".deb\";
  };
};

Una vez tenemos los ficheros de configuración adecuados a nuestras necesidades hemos de ejecutar un par de comandos, los cuales podemos meter en un script llamado por ejemplo update-archive.sh:


#!/bin/sh
apt-ftparchive generate apt-ftparchive.conf
apt-ftparchive -c apt-dapper-release.conf release dists/dapper/ >dists/dapper/Release


Actualizando el repositorio

Una vez hemos puesto los paquetes dentro de los directorios correspondientes de su sección ejecutamos el script update-archive.sh, obteniendo una salida como la siguiente:

$ ./update-archive.sh
 dists/sarge/main/binary-i386: 21 files 42.7MB 2s
 dists/sarge/contrib/binary-i386: 0 files 0B 0s
 dists/sarge/non-free/binary-i386: 4 files 114MB 5s
 dists/sarge/main/binary-i386/: 21 files 42.7MB 0s
 dists/sarge/contrib/binary-i386/: 0 files 0B 0s
 dists/sarge/non-free/binary-i386/: 4 files 114MB 0s
 dists/sarge/main/source/: 2 pkgs in 0s
 dists/sarge/contrib/source/: 0 pkgs in 0s
 dists/sarge/non-free/source/: 0 pkgs in 0s
Done Packages, Starting contents.
Done. 314MB in 50 archives. Took 7s

Usando el repositorio

Después de los pasos anteriores ya podemos utilizar el repositorio modificando el fichero /etc/apt/sources.list:

• Para acceso local

  deb file:///var/repo sarge main contrib non-free

• Para acceso remoto (si por ejemplo hacemos un enlace simbólico a /var/svn dentro del direcorio de un servidor http):

  deb http://nuestro.servidor/repositorio sarge main contrib non-free

Nota

Este post es prácticamente una traducción de un howto cuyo link es este

En un próximo post pondré como añadir nuestra firma al repositorio con gpg.

Como curiosidad, lleva como buscador por defecto Yahoo! en lugar de Google.

technorati tags:Flock, Browser, Firefox, Mozilla

Blogged with Flock

En concreto usando JDBC con el driver de mysql. Tiene muchos fallos y no funciona demasiado bien, pero ahi esta.

Código fuente

Empecé poniendole una Ubuntu Breezy, pero la tarjeta inalámbrica me daba muchos fallos (kernel panic), despues probé una fedora core 5 y más de lo mismo. Compilando el driver a mano, con ndiswrapper y nada. Al final he puesto una Ubuntu Dapper y va a las mil maravillas.

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 dovecot-auth 

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

./configure

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.

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.

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).

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