Certificados SSL en Tomcat

Lidiando recientemente con las solicitudes del área de desarrollo, hubo que actualizar un certificado vencido en uno de sus maravillosos portales desarrollados en Java y servidos con Tomcat. La experiencia vivida con eso fue terrible, pues no tienen ni la más mínima idea de como hacer un sitio seguro. Solo se cercioran de descomentar los items relacionados con SSL en el archivo server.xml y colocar allí un archivo de certificados que tampoco saben como está hecho, ni por mera curiosidad relacionada a la herramienta de desarrollo que utilizan.

Por otro lado, no había documentación oficial en la organización de como se hizo el proceso, ni donde guardaron los archivos de solicitud de firma y la clave privada (CSR y Key file), mucho menos el equipo estrella de desarrollo.

Aunado a esto, el certificado firmado del dominio fue proporcionado por Godaddy, cuyos certificados no son reconocidos por Java (al menos no como lo dice la documentación de Tomcat) y de paso, el procedimiento explicado por ellos para colocarlos en servidores Tomcat NO FUNCIONA.

La raíz del problema

Las aplicaciones web desarrolladas en Java requieren un almacén de certificados para este tipo de lenguaje (Java Keystore). Este contenedor puede ser creado con Keytool, una herramienta similar a OpenSSL pero es propia de Java, bastante práctica pero con ciertas limitaciones. Con Keytool se pueden hacer:

  • El contenedor de claves (JKS)
  • La solicitud de firma de Certificado (archivo CSR)

El procedimiento para hacer un Keystore y la solicitud de firma es bastante simple:

1.- Crear el archivo de llaves:

keytool -genkey -alias midominio -keyalg RSA -keystore keystore.jks -keysize 2048

2.- Generar el archivo de solicitud de firma (CSR) basado en el nuevo keystore:

keytool -certreq -alias midominio -keystore keystore.jks -file midominio.csr

3.- El proceso siguiente es el que corresponde a responder las preguntas del certificado (que omitiré por mera practicidad), que al final debe confirmar afirmativamente para crear el archivo.

Ya con el archivo CSR creado, se hace la solicitud de firma ante cualquier Autoridad de Certificación (GlobalSign, Verisign, Norton, Godaddy). Una vez hecho eso, la empresa que firma le entregará el certificado firmado (CRT) junto a dos archivos: el Certificado Raíz (root) y el Certificado Intermedio, ambos necesarios, sin eso no es posible validar la autenticidad del certificado ya firmado.

4.- Importar los certificados obtenidos de manera ordenada dentro del almacén de claves (Keystore)

keytool -import -trustcacerts -alias root -file root.crt -keystore keystore.jks
keytool -import -trustcacerts -alias intermediate -file intermediate.crt -keystore keystore.jks
keytool -import -trustcacerts -alias midominio -file midominio.crt -keystore keystore.jks

(Importante: desde el proceso de creación del almacén se requiere una contraseña que no debe olvidarse, ojo)

Y voilá! Tiene un archivo keystore listo para ser usado en sus servidores web con Java.

Se verifica el contenido del almacen de certificados, y el Keytool deberá mostrar algo como esto:

keystore -list -keystore keystore.jks -storepass password

Tipo de Almacén de Claves: JKS
Proveedor de Almacén de Claves: SUN

Su almacén de claves contiene 3 entradas

root, 17/02/2016, trustedCertEntry,
Huella Digital de Certificado (SHA1): 27:AC:93:69:FA:F2:52:07:BB:26:27:CE:FA:CC:BE:4E:F9:C3:19:B8
midominio, 20/01/2017, trustedCertEntry,
Huella Digital de Certificado (SHA1): 35:A3:AB:6A:EA:11:4F:E4:1C:8D:4C:51:F4:82:3F:4E:31:B5:97:CA
intermediate, 17/02/2016, trustedCertEntry,
Huella Digital de Certificado (SHA1): 27:AC:93:69:FA:F2:52:07:BB:26:27:CE:FA:CC:BE:4E:F9:C3:19:B8

Hasta ahora parece sencillo, termina configurando su servidor Tomcat agregando en el archivo de configuración server.xml lo relacionado a la conexión por HTTPS:

<Connector port=”8443″ maxThreads=”200″ scheme=”https” secure=”true” SSLEnabled=”true”
keystoreFile=”/la/ruta/al/archivo/keystore.jks”
keystorePass=”contraseñadelarchivokeystore” clientAuth=”false” sslProtocol=”TLS”/>

¿Y donde está el problema?

Todo esto funciona muy bien cuando la CA que firma los certificados es cualquiera, menos Godaddy. Mi compadre y colega @eu53 en su amplia experiencia me explica que estos certificados por Godaddy son emitidos para servidores web como Apache2 (httpd), y servidores como Tomcat les da un tratamiento como tales. No son certificados que una app web hecha en Java reconocerá de manera inmediata.

La solución consiste en convertir los certificados en un formato que sea reconocido por las apps java (desde Tomcat 6 en adelante), como PKCS12.

Para esto se requiere en el mejor de los casos:

  • El certificado firmado por la Autoridad Certificadora (el archivo midominio.crt)
  • El certificado Raíz de la Autoridad Certificadora (root.crt)
  • El certificado Intermedio de la CA (supuestamente se requiere para Godaddy)
  • El archivo de clave privada con el que se generó la solicitud de firma originalmente (archivo .key)

Pero, keytool NO genera un archivo de clave privada (archivo.key) con el que originalmente se puede generar el archivo CSR (midominio.csr). Volvemos al problema: y entonces cómo?

La Solución: hacer las cosas bien desde el principio

Mi recomendación es hacer el proceso de generación de claves con OpenSSL.

1.- Crear los certificados de clave privada y requerimiento de firma:

openssl req -new -newkey rsa:2048 -nodes -out midominio.csr -keyout midominio.ke

(se responden las preguntas de la organización de origen, y se coloca la contraseña de la clave privada, que no debe olvidarse)

El resultado del proceso son los archivos midominio.key y midominio.csr

2.- Ya con el archivo CSR creado, se hace la solicitud de firma ante cualquier Autoridad de Certificación asi como se explicara en este documento. Para el caso en particular, Godaddy.

Una vez hecho eso, la empresa que firma le entregará el certificado firmado (CRT) junto a dos archivos: el Certificado Raíz (root) y el Certificado Intermedio empaquetados en un archivo ZIP que se descarga desde el portal de Godaddy.

3.- Crear el almacen de certificados (Keystore) con Keytool:

keytool -genkey -alias midominio -keyalg RSA -keystore tomcat.jks

(en este paso, responda las preguntas con los mismos datos proporcionados al ejecutar el paso 1 con openssl)

4.- Exportar el certificado firmado y la clave privada al formato PKCS12

openssl pkcs12 -export -in midominio.crt -inkey midominio.key -out midominio.p12 -name midominio -CAfile ca.crt -caname root

5.- Finalmente, importar el archivo PKCS12 en el almacen de certificados usando Keytool:

keytool -importkeystore -deststorepass <elpassworddelarchivoJKS> -destkeypass <elpassworddelarchivoKey> -destkeystore tomcat.jks -srckeystore midominio.p12 -srcstoretype PKCS12 -srcstorepass <elpassworddelarchivoJKS> -alias midominio

(para propósitos prácticos, use el mismo password utilizado en el archivo key para su keystore)

El contenido del almacen de certificados se verá de esta forma:

Tipo de Almacén de Claves: JKS
Proveedor de Almacén de Claves: SUN

Su almacén de claves contiene 1 entrada

midominio, 17/02/2016, PrivateKeyEntry,
Huella Digital de Certificado (SHA1): B3:6B:2B:D6:00:43:4E:B4:BF:03:53:F2:DE:FE:FE:2C:F2:F9:5D:53

Ahora si, el certificado se encuentra listo para ser usado en el servidor Tomcat, para es se modifica el archivo server.xml:

<Connector port=”8443″ maxThreads=”200″ scheme=”https” secure=”true” SSLEnabled=”true” keystoreFile=”/la/ruta/del/archivo/tomcat.jks”
keystorePass=”elpassworddelarchivoJKS” clientAuth=”false” sslProtocol=”TLS”/>

Para mantener un orden debido en las configuraciones de un servidor, ubique el archivo de certificados en un lugar especifico. Se puede crear un directorio adicional en /usr/local para guardar los certificados agregados.

Un problema (des)conocido

El equipo de desarrollo no está feliz: a pesar que ya el portal tiene un certificado que funciona en su sitio, en la ejecución de tan maravillosa obra de arte desplegado en el servidor muestra un error luego de autenticar y hacer llamadas a unos subprogramas dentro del mismo servidor:

2017-01-26 16:56:06,274 [ CommonUtils.java:http-bio-443-exec-3:getResponseFromServer:327] – sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Alegato del desarrollador: el certificado no sirve.

Luego de consultar foros y nuevamente acudir a la sabia experiencia de mi compadre @eu53 en materia de Tomcat, me explica lo siguiente:

“Básicamente el problema que tienes es confianza con el certificado raíz que firmó tu certificado público, posiblemente sea que el certificado de la entidad verificadora haya sido recientemente actualizado y no esté esa versión incluida en el cacert de tu version de Java. La solución es agregar el certificado al cacert y asi cualquier app java o servidor que levantes usando ese JRE tenga ya el certificado entre su truststore, pero de todas todas el certificado no esta malo, simplemente hay que actualizar el listado de certificados”.

Y en efecto, lo recomendado es actualizar el certificado raíz de la CA con que se firmó el certificado del sitio en el almacén de claves de Java, en este caso de la versión que estará usando Tomcat. Para eso entonces nuevamente se hace uso de keytool:

keytool -importcert -file gd_bundle-g2-g1.crt -alias godaddy -keystore $JAVA_HOME/jre/lib/security/cacerts

(el password del almacén es “changeit”)

Problema resuelto.

Todo lo mencionado aquí funciona con las versiones de Tomcat 6, 7 y 8.

 

Referencias:
https://support.globalsign.com/customer/en/portal/articles/2121490-java-keytool—create-keystore
https://picodotdev.github.io/blog-bitix/2014/02/generar-y-convertir-claves-y-certificados-con-openssl/
http://robblake.net/post/18945733710/using-a-pem-private-key-and-ssl-certificate-with
https://raiolanetworks.es/blog/instalar-tomcat-e-importar-certificado-ssl-existente/

Configuración de Cobbler en CentOS 7

Mis actividades recientes consisten en la preparación de un laboratorio de computación para las pruebas que realizan las distintas unidades que tiene la empresa.  Algunos servicios requieren ser migrados pero otros ya hemos decidido empezar de cero.  Uno de los servicios necesarios es el de Aprovisionamiento para la instalación de sistemas operativos a través de la red.  Aqui la opción ha sido desde siempre utilizar una herramienta llamada Cobbler.

¿Qué es Cobbler?

La mejor explicación es la que se define en la Wikipedia*:

Cobbler es un servidor del aprovisionamiento Linux que centraliza y simplifica el control de servicios incluyendo DHCP, TFTP, y DNS con propósito de realizar instalaciones basadas en red de sistemas operativos.  Puede ser configurado para PXE, reinstalaciones, y huéspedes virtualizados usando Xen, KVM o VMware. Cobbler interactúa con un programa llamado Koan para el soporte de la reinstalación y la virtualización. Koan y Cobbler usan libvirt para integrarse con diferentes softwares de virtualización.

Cobbler está hecho sobre el mecanismo de Kickstart y ofrece perfiles de instalación que pueden ser aplicados a una o muchas máquinas. También ofrece la integración con Yum para ayudar en instalaciones de máquinas.

Aunque Cobbler está enfocado en instalaciones basadas en RPM vía Kickstart y el Anaconda, puede ser usado para configurar un servidor PXE para cargar varias imágenes tales como Knoppix y otros sabores de Debian.

Se decidió hacer la instalación en el servidor con CentOS 7 donde previamente configuramos los repositorios CentOS y Debian, así que ya algunos servicios fueron previamente configurados.

Requerimientos previos para la instalación y configuración:

  • Servidor con CentOS 7
  • Servicio dhcpd instalado
  • Servicio httpd instalado

Pasos a seguir

1.- deshabilitar SELINUX
2.- bajar iptables
3.- instalar repositorio EPEL (el link de descarga puede estar actualizado, se requiere verificar primero si el archivo existe)

[root@cobbler ~]# rpm -Uvh https://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm

Retrieving https://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch&#8230;
warning: /var/tmp/rpm-tmp.Cisj7E: Header V3 RSA/SHA256 Signature, key ID 352c64e5: NOKEY
Preparing… ################################# [100%]
Updating / installing…
1:epel-release-7-5 ################################# [100%]

4.- Instalar Kickstart, cobbler y dependencias:

[root@cobbler ~]# yum -y install cobbler cobbler-web pykickstart dhcp tftp xinetd

5.- habilitar tftp y rsync en xinetd, luego reiniciar xinetd y habilitarlo como inicio por defecto en el sistema:

[root@cobbler ~]# systemctl enable xinetd

6.- iniciar los servicios de cobbler

[root@cobbler ~]# systemctl enable cobblerd
ln -s ‘/usr/lib/systemd/system/cobblerd.service’ ‘/etc/systemd/system/multi-user.target.wants/cobblerd.service’
[root@cobbler ~]# systemctl start cobblerd

7.- Instalar cobbler loaders

[root@cobbler ~]# cobbler get-loaders

El resultado será algo similar a esto:

[root@mirror ~]# cobbler get-loaders
task started: 2016-01-27_142230_get_loaders
task started (id=Download Bootloader Content, time=Wed Jan 27 14:22:30 2016)
downloading http://cobbler.github.com/loaders/README to /var/lib/cobbler/loaders/README
downloading http://cobbler.github.com/loaders/COPYING.elilo to /var/lib/cobbler/loaders/COPYING.elilo
downloading http://cobbler.github.com/loaders/COPYING.yaboot to /var/lib/cobbler/loaders/COPYING.yaboot
downloading http://cobbler.github.com/loaders/COPYING.syslinux to /var/lib/cobbler/loaders/COPYING.syslinux
downloading http://cobbler.github.com/loaders/elilo-3.8-ia64.efi to /var/lib/cobbler/loaders/elilo-ia64.efi
downloading http://cobbler.github.com/loaders/yaboot-1.3.17 to /var/lib/cobbler/loaders/yaboot
downloading http://cobbler.github.com/loaders/pxelinux.0-3.86 to /var/lib/cobbler/loaders/pxelinux.0
downloading http://cobbler.github.com/loaders/menu.c32-3.86 to /var/lib/cobbler/loaders/menu.c32
downloading http://cobbler.github.com/loaders/grub-0.97-x86.efi to /var/lib/cobbler/loaders/grub-x86.efi
downloading http://cobbler.github.com/loaders/grub-0.97-x86_64.efi to /var/lib/cobbler/loaders/grub-x86_64.efi
* TASK COMPLETE *

8.- generar el hash del password que utilizará cobbler, el hash obtenido será definido en el archivo de configuración del servicio cobbler:

[root@cobbler ~]# openssl passwd -1 -salt ‘laboratorio.gs’ ‘Abcd1234’ | la salida es esta → $1$laborato$wzEZkT4MdOYVxA6L0UMKp1

9.- Configurar cobbler implica la modificación del archivo de configuración, que se encuentra en /etc/cobbler/settings. Este archivo tiene formato de datos YAML. las opciones a modificar en el archivo son las siguientes:

next_server: colocar la dirección IP del servidor siendo configurado
server: igual que en el item anterior
default_password_crypted: <aqui se coloca el hash generado con anterioridad>
manage_dhcp: cambiar de valor 0 y colocar 1
pxe_just_once: cambiar de valor 0 a 1

10.- Teniendo instalado previamente el servicio dhcp, al modificar el parámetro manage_dhcp en 1 le estamos indicando al servicio que la plantilla de configuración dhcpd.conf será la que le suministre cobbler. Esto sucederá cuando posteriormente se ejecute el comando cobbler sync. El contenido de la plantilla del archivo dhcpd.conf será por este estilo, y debe modificarse para indicarle las subredes que serán atendidas:

/etc/cobbler/dhcp.template

subnet 192.168.1.0 netmask 255.255.255.0 {

option routers 192.168.1.5;
option domain-name-servers 192.168.1.1;
option subnet-mask 255.255.255.0;
range dynamic-bootp 192.168.0.4 192.168.0.25;
default-lease-time 21600;
max-lease-time 43200;
next-server $next_server;
class “pxeclients” {
match if substring (option vendor-class-identifier, 0, 9) = “PXEClient”;
if option pxe-system-type = 00:02 {
filename “ia64/elilo.efi”;
} else if option pxe-system-type = 00:06 {
filename “grub/grub-x86.efi”;
} else if option pxe-system-type = 00:07 {
filename “grub/grub-x86_64.efi”;
} else {
filename “pxelinux.0”;
}
}

}

11.- Ejecutar cobbler sync. Teniendo en cuenta que todo está configurado debidamente, esta sería la salida esperada:

[root@mirror ~]# cobbler sync
task started: 2016-01-27_145553_sync
task started (id=Sync, time=Wed Jan 27 14:55:53 2016)
running pre-sync triggers
cleaning trees
removing: /var/lib/tftpboot/pxelinux.cfg/default
removing: /var/lib/tftpboot/grub/grub-x86.efi
removing: /var/lib/tftpboot/grub/images
removing: /var/lib/tftpboot/grub/grub-x86_64.efi
removing: /var/lib/tftpboot/grub/efidefault
removing: /var/lib/tftpboot/s390x/profile_list
copying bootloaders
trying hardlink /var/lib/cobbler/loaders/grub-x86.efi -> /var/lib/tftpboot/grub/grub-x86.efi
trying hardlink /var/lib/cobbler/loaders/grub-x86_64.efi -> /var/lib/tftpboot/grub/grub-x86_64.efi
copying distros to tftpboot
copying images
generating PXE configuration files
generating PXE menu structure
rendering DHCP files
generating /etc/dhcp/dhcpd.conf
rendering TFTPD files
generating /etc/xinetd.d/tftp
cleaning link caches
running post-sync triggers
running python triggers from /var/lib/cobbler/triggers/sync/post/*
running python trigger cobbler.modules.sync_post_restart_services
running: dhcpd -t -q
received on stdout:
received on stderr:
running: service dhcpd restart
received on stdout:
received on stderr: Redirecting to /bin/systemctl restart dhcpd.service

running shell triggers from /var/lib/cobbler/triggers/sync/post/*
running python triggers from /var/lib/cobbler/triggers/change/*
running python trigger cobbler.modules.scm_track
running shell triggers from /var/lib/cobbler/triggers/change/*
* TASK COMPLETE *

Con esto ya se tiene configurado el servicio cobbler. Para acceder a la interfaz web se coloca la url https://<direccionip>/cobbler_web/

Previo, con el comando cobbler check se puede verificar la lista de cosas que deben ser resueltas a fin de tener el servicio sin problemas. La salida puede mostrar algo como esto:

[root@mirror ~]# cobbler check
The following are potential configuration items that you may want to fix:

1 : reposync is not installed, need for cobbler reposync, install/upgrade yum-utils?
2 : fencing tools were not found, and are required to use the (optional) power management features. install cman or fence-agents to use them

Restart cobblerd and then run ‘cobbler sync’ to apply changes.

En el caso de este servidor, el resultado del chequeo indicó por ejemplo que reposync no se encuentra en el servidor (aunque si se encuentre instalado yum-utils). Esta herramienta sirve para sincronizar los mirrors de las distribuciones de las que cobbler hará uso si fuese necesario. Es una opción, no es obligatorio el uso de reposync.

Con esto ya se tiene entonces instalado y listo el servidor Cobbler en CentOS 7.

 

Creación de un repositorio Debian en CentOS 7

Hace poco tuve la necesidad de crear el repositorio de paquetes para los servidores de nuestro laboratorio, la gran mayoría de ellos instalados en CentOS y Red Hat.  Para esto mi compañero @alberkman y yo instalamos un servidor con CentOS 7 usando  rsync a través de sencillos scripts que hacen el trabajo.

La preparación de este servidor de mirrors va más allá de atender sólo los sistemas operativos antes mencionados (por la facilidad de su sistema de paquetes gestionados a través de YUM), así que nos vimos en la necesidad de crear un repositorio de paquetes para Debian estable.  Ahora, ¿cómo se hace para sincronizar un mirror de paquetes DEB en un servidor que sólo gestiona paquetes RPM?

Los pasos a seguir fueron los siguientes [1]:

En primer lugar, instale los siguientes paquetes del repositorio de CentOS.

[root@mirror ~]# yum install bzip2 perl-Digest-SHA1 perl-Compress-Zlib rsync ed

Se instalan dos paquetes adicionales desde el repositorio de EPEL (el servidor debe tener añadido previamente el repositorio de EPEL)

[root@mirror ~]# yum install perl-LockFile-Simple perl-libwww-perl

A continuación, vaya al directorio /usr/src

Desde allí descargue el paquete perl-Digest-MD5-M4p y lo instala en el sistema. Preste atención a la arquitectura correcta de su sistema. Si utiliza un sistema de 64 bits como es el caso del servidor que estoy usando, debe descargar e instalar el archivo correspondiente:

[root@mirror src]# wget http://pkgs.repoforge.org/perl-Digest-MD5-M4p/perl-Digest-MD5-M4p-0.01-1.2.el6.rf.x86_64.rpm
[root@mirror src]# rpm -i perl-Digest-MD5-M4p-0.01-1.2.el6.rf.x86_64.rpm

Ahora necesita el módulo de Perl —> Net :: INET6Glue y para eso debe abrir el shell de CPAN:

[root@mirror src]# perl -MCPAN -e shell

Se instala el módulo Net :: Perl INET6Glue con el siguiente comando:

cpan[1]> install Net::INET6Glue

Después de instalar el módulo de cpan, salga de nuevo a la shell del sistema:

cpan[2]> exit

Después de haber completado todos los preparativos, descargue desde el repositorio de Ubuntu el paquete debmirror y descomprima el archivo empaquetado en el directorio:

[root@mirror src]# wget http://archive.ubuntu.com/ubuntu/pool/universe/d/debmirror/debmirror_2.16ubuntu1.tar.gz
[root@mirror src]# tar xvzf debmirror_2.16ubuntu1.tar.gz

Luego, copie el script debmirror en el directorio /usr/bin

[root@mirror src]# cp debmirror-2.16ubuntu1/debmirror /usr/bin/

Si ejecuta ahora debmirror, debe recibir la siguiente salida:

[root@mirror scripts]# debmirror
mirrordir not specified

Usage: /usr/bin/debmirror [options] <mirrordir>

For details, see man page.

Con esto ya tenemos instalado debmirror en nuestro sistema con CentOS.

Lo que viene ahora requiere que previamente tenga el archivo de llaves que verifica debmirror para crear el espejo en nuestro servidor. Estos pasos se llevan a cabo en un equipo con Debian preferiblemente.

Descargue las llaves más recientes de Debian, para el caso de este espejo a crear, se descarga el debian-archive-keyring desde el repositorio de testing:

ellanos@Friday:~/scripts$ wget http://ftp.us.debian.org/debian/pool/main/d/debian-archive-keyring/debian-archive-keyring_2014.3_all.deb

Luego, desempaquete el contenido del archivo en un directorio del equipo donde se va a generar el archivo de llaves (para este caso, fue creado un directorio debian dentro de mi equipo):

ellanos@Friday:~/scripts$ dpkg-deb -x debian-archive-keyring_2014.3_all.deb debian/

Se importan los llaveros en el archivo que se indica:

ellanos@Friday:~/scripts$ gpg –no-default-keyring –keyring ~/scripts/trustedkeys.gpg –import debian/usr/share/keyrings/debian-archive-keyring.gpg

Ya creado el archivo trustedkeys.gpg, se copia en el servidor CentOS en el directorio destinado para tal fin.  Para esta copia use el método de su preferencia (con un flashdrive usb, vía scp, smb, etc).

Ya de nuevo en el servidor CentOS, previamente debe tener un script para debmirror donde defina en sus parámetros la ruta donde se encuentra el archivo de llaves

(El script utilizado fue tomado del blog del amigo Luis Gallardo [2] :D )

#!/bin/sh

# Don’t touch the user’s keyring, have our own instead
export GNUPGHOME=/root/scripts/keyrings/debian

# Architecture (i386, powerpc, amd64, etc.)
arch=i386,amd64

# Section (main,contrib,non-free)
section=main,contrib,non-free

# Release of the system (squeeze,lenny,stable,testing,etc)
release=jessie

# Server name, minus the protocol and the path at the end
server=ftp.us.debian.org

# Path from the main server, so http://my.web.server/$dir, Server dependant
inPath=/debian

# Protocol to use for transfer (http, ftp, hftp, rsync)
proto=http

# Directory to store the mirror in
outPath=/srv/mirror/debian

# Start script

debmirror -a $arch \

–no-source \
–md5sums \
–progress \
–passive \
–verbose \
-s $section \
-h $server \
-d $release \
-r $inPath \
-e $proto \
$outPath

 

Es importante destacar que se debe previamente verificar si se tiene conexión rsync con el servidor desde el cual se desea hacer mirror.

Como último paso, agregue el script a una tarea programada del servidor para que se ejecute a la hora señalada:

[root@mirror ~]# crontab -e
0 22 * * 1 sh /root/scripts/repocentos-update.sh
0 0 * * 1 sh /root/scripts/repo-epel-update.sh
0 0 * * * sh /root/scripts/repo-debian.sh

Suponiendo que ya este proceso se llevó a cabo con éxito, publique vía web el contenido del repositorio creado. En nuestro caso instalaremos apache.

Instale el paquete httpd:

[root@mirror ~]# yum install httpd

Por defecto en CentOS/RedHat, Apache usa /var/www/html como directorio raíz. entonces para indicarle al apache el directorio del repositorio sólo se crea el enlace simbólico a ese directorio:

[root@mirror ~]# ln -s /srv/mirror/debian /var/www/html

Listo. Con esto tenemos creado un repositorio Debian en un servidor CentOS 6/7

 

 


Referencias:
[1] http://www.gtkdb.de/index_33_1669.html
[2] http://lgallardo.com/en/2012/12/06/como-crear-un-mirror-de-debian-y-ubuntu-con-debmirror/

Los números de 2013

Los duendes de las estadísticas de WordPress.com prepararon un informe sobre el año 2013 de este blog.  Espero este año si escribir más.

Aquí hay un extracto:

Un teleférico de San Francisco puede contener 60 personas. Este blog fue visto por 3.100 veces en 2013. Si el blog fue un teleférico, se necesitarían alrededor de 52 viajes para llevar tantas personas.

Haz click para ver el reporte completo.

Instalación de cliente Websphere MQ 7.0 en Debian Squeeze

Una buena oportunidad para desempolvar el blog y dedicarme a escribir las nuevas experiencias adquiridas en este nuevo camino profesional.

Por solicitud de un proveedor hubo la necesidad de instalar el cliente de MQ para manejo de mensajes hacia servidores Websphere MQ dedicados para un proyecto relacionado con recarga de saldos en una empresa de telefonía celular a través de banca electrónica. Evidentemente, como todo producto IBM se requiere que el producto se instale en sistemas basados en RPM (Red Hat, Suse, Fedora) por su soporte, sin embargo era necesario instalar el cliente en un servidor con Debian.

En realidad el proceso es sencillo (siguiendo los mismos pasos documentados para instalar MQ en un cliente linux):

Se empieza todo este proceso teniendo como premisa los paquetes necesarios para la instalación de Websphere MQ versión 7.0 para la arquitectura de 32 bits, usando los permisos del superusuario. Ejemplo de los archivos a utilizar:

-r–r–r– 1 root root 261 feb 24 2012 copyright
-r–r–r– 1 root root 4277977 feb 24 2012 gsk7bas-7.0-4.38.i386.rpm
-r–r–r– 1 root root 1372281 feb 24 2012 gskcrypt32-8.0.14.14.linux.x86.rpm
-r–r–r– 1 root root 7546233 feb 24 2012 gskssl32-8.0.14.14.linux.x86.rpm
drwxrwxr-x 4 root root 4096 feb 24 2012 lap
drwxrwxr-x 2 root root 4096 feb 24 2012 licenses
-rwxr-xr-x 1 root root 5076 feb 24 2012 mqlicense.sh
-rw-rw-r– 1 root root 1476951 feb 24 2012 MQSeriesClient-7.0.1-8.i386.rpm
-rw-rw-r– 1 root root 26247200 feb 24 2012 MQSeriesJava-7.0.1-8.i386.rpm
-rw-rw-r– 1 root root 45110879 feb 24 2012 MQSeriesKeyMan-7.0.1-8.i386.rpm
-rw-rw-r– 1 root root 6544861 feb 24 2012 MQSeriesRuntime-7.0.1-8.i386.rpm
-rw-rw-r– 1 root root 731985 feb 24 2012 MQSeriesSamples-7.0.1-8.i386.rpm
-rw-rw-r– 1 root root 226944 feb 24 2012 MQSeriesSDK-7.0.1-8.i386.rpm
-rw-rw-r– 1 root root 126230 feb 24 2012 MQSeriesMsg_cs-7.0.1-8.i386.rpm
-rw-rw-r– 1 root root 131277 feb 24 2012 MQSeriesMsg_de-7.0.1-8.i386.rpm
-rw-rw-r– 1 root root 124699 feb 24 2012 MQSeriesMsg_es-7.0.1-8.i386.rpm
-rw-rw-r– 1 root root 124753 feb 24 2012 MQSeriesMsg_fr-7.0.1-8.i386.rpm
-rw-rw-r– 1 root root 128386 feb 24 2012 MQSeriesMsg_hu-7.0.1-8.i386.rpm
-rw-rw-r– 1 root root 126540 feb 24 2012 MQSeriesMsg_it-7.0.1-8.i386.rpm
-rw-rw-r– 1 root root 117243 feb 24 2012 MQSeriesMsg_ja-7.0.1-8.i386.rpm
-rw-rw-r– 1 root root 111408 feb 24 2012 MQSeriesMsg_ko-7.0.1-8.i386.rpm
-rw-rw-r– 1 root root 126910 feb 24 2012 MQSeriesMsg_pl-7.0.1-8.i386.rpm
-rw-rw-r– 1 root root 125998 feb 24 2012 MQSeriesMsg_pt-7.0.1-8.i386.rpm
-rw-rw-r– 1 root root 119143 feb 24 2012 MQSeriesMsg_ru-7.0.1-8.i386.rpm
-rw-rw-r– 1 root root 116313 feb 24 2012 MQSeriesMsg_Zh_CN-7.0.1-8.i386.rpm
-rw-rw-r– 1 root root 118736 feb 24 2012 MQSeriesMsg_Zh_TW-7.0.1-8.i386.rpm
drwxrwxr-x 3 root root 4096 feb 24 2012 PreReqs
-r–r–r– 1 root root 6410 feb 24 2012 readadd.txt

Pueden obviarse los archivos de mensajes, a menos que sea necesario (MQSeriesMsg_*)

Se crea el usuario mqm, que tenga como carpeta origen /var/mqm. Adicionalmente el grupo mqm también debe ser creado:

adduser –home mqm –group mqm –disabled-password mqm

Se instala el paquete rpm para la gestión de paquetes rpm en Debian:

aptitude install rpm

Acepte el acuerdo de licencia usando el método normal (puede ejecutarse en otro modo, claro) ejecutando el script correspondiente:

./mqlicense.sh

Luego de esto, ya se puede hacer la instalación de los paquetes necesarios para el cliente MQ:

rpm -ivh –nodeps –force-debian MQSeriesClient-7.0.1-8.i386.rpm MQSeriesJava-7.0.1-8.i386.rpm MQSeriesRuntime-7.0.1-8.i386.rpm MQSeriesSamples-7.0.1-8.i386.rpm MQSeriesSDK-7.0.1-8.i386.rpm gsk7bas-7.0-4.38.i386.rpm MQSeriesMsg_es-7.0.1-8.i386.rpm

La aplicación principal crea la carpeta que la contendrá en /opt/mqm con los permisos del usuario mqm previamente creado. El resto de los archivos de configuración y ajuste se almacenan en el proceso de instalación en el directorio del usuario mqm, quedando algo como lo que se muestra a continuación:

hostname00:~# ls -l /opt/mqm/
total 32
dr-xr-xr-x 2 mqm mqm 4096 feb 22 20:15 bin
dr-xr-xr-x 4 mqm mqm 4096 feb 22 20:15 inc
dr-xr-xr-x 7 mqm mqm 4096 feb 22 20:15 java
dr-xr-xr-x 6 mqm mqm 4096 feb 22 20:15 lib
dr-xr-xr-x 2 mqm mqm 4096 feb 22 20:15 licenses
dr-xr-xr-x 3 mqm mqm 4096 feb 22 20:15 properties
dr-xr-xr-x 18 mqm mqm 4096 feb 22 20:15 READMES
dr-xr-xr-x 10 mqm mqm 4096 feb 22 20:15 samp

hostname00:~# ls -l /var/mqm
total 52
drwxrwsr-x 2 mqm mqm 4096 feb 22 20:15 config
drwxrwsr-x 3 mqm mqm 4096 feb 22 20:15 conv
drwxrwsrwx 2 mqm mqm 4096 feb 22 20:15 errors
drwxrwsr-x 2 mqm mqm 4096 feb 22 20:15 exits
drwxrwsr-x 2 mqm mqm 4096 feb 22 20:15 exits64
drwxrwsr-x 2 mqm mqm 4096 feb 22 20:15 log
-rw-rw-r– 1 mqm mqm 637 feb 22 20:15 mqclient.ini
-rw-rw-r– 1 mqm mqm 1907 feb 22 20:15 mqs.ini
drwxrwsr-x 3 mqm mqm 4096 feb 22 20:15 qmgrs
-rw-rw-r– 1 mqm mqm 1373 feb 22 20:15 service.env
drwxrwsr-x 3 mqm mqm 4096 feb 22 20:15 sockets
drwxrwsrwx 2 mqm mqm 4096 feb 22 20:15 trace

Listo. Con esto ya quedó instalado el cliente Websphere MQ. El mismo procedimiento se aplica para instalar el servidor MQ.

Espero sea de utilidad.

Links de referencia:

http://bit.ly/YiOG1o
http://bit.ly/cFKM8y