Erudeando con Duker
Tecnologías de la Información, de las Otras y la cosas de la vida…
septiembre 3, 2011 at 12:52 am · Clasificados en Uncategorized
Aquí les dejo una crónica de la instalación de Jenkins en CentIOS 5.5 por si les interesa empezar a utilizarlo para sus soluciones de CI.
Acá pueden encontrar las instrucciones oficiales, yo decidí instalarlo standalone, es decir sin tener un Tomcat corriendo.
El primer paso es agregar los repositorios de Jenkins y su firma a nuestro yum, para ello ejecutamos los siguientes comandos como root:
# wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
# rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key
# yum update && yum install jenkins
El siguiente paso es configurar el servicio en caso de que no nos sirva alguno de los parámetros por defecto del mismo, para eso necesitamos editar el archivo/etc/sysconfig/jenkins
En mi caso cambie el puerto por defecto de 8080 a 5353 ya que tengo el 8080 ocupado por otros servicios. Esto lo hice modificando la variable JENKINS_PORT de la siguiente manera:
JENKINS_PORT="5353"
El siguiente paso es arrancar el servicio, para ello como root corremos
# /etc/init.d/jenkis start
Es muy común que en este paso se produzca una excepción similar a la siguiente:
Starting Jenkins Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at Main._main(Main.java:127)
at Main.main(Main.java:96)
Caused by: java.lang.UnsatisfiedLinkError: /tmp/jna/jna7112420072244666734.tmp: /tmp/jna/jna7112420072244666734.tmp: failed to map segment from shared object: Operation not permitted
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1750)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1646)
at java.lang.Runtime.load0(Runtime.java:787)
at java.lang.System.load(System.java:1022)
at com.sun.jna.Native.loadNativeLibraryFromJar(Native.java:745)
at com.sun.jna.Native.loadNativeLibrary(Native.java:674)http://blog.mibanez.com.ar/wp-admin/post.php?post=193&action=edit
at com.sun.jna.Native.<clinit>(Native.java:115)
El problema se debe a que jenkins crea una librería en el directorio temporal /tmp y trata de ejecutarla, pero generalmente dicha partición esta montada con el bit noexec por seguridad.
La solución es muy simple, lo que tenemos que hacer es instruir a la maquina virtual de java para que use un directorio temporal diferente, en mi caso decidí usar
/usr/local/java/tmp
Para crearlo y darle los permisos adecuados ejecutamos:
# mkdir -p /usr/local/java/tmp
# chmod 777 /usr/local/java/tmp
Y luego modificamos el script que arranca Jenkins para que use esta nuevo directorio como temporal. Para ello editamos el script /etc/init.d/jenkins y modificamos la variable JENKINS_JAVA_CMD para que quede de la siguiente forma:
JENKINS_JAVA_CMD="$candidate -Djava.io.tmpdir=/usr/local/java/tmp"
Con esto ya deberíamos poder arrancar el servicio y configurarlo yendo con el navegador a http://miserver.com:5353
Una ver que hacemo esto Jenkins se va a autoconfigurar. Noten que en ningun momento configuramos usuarios o privilegios, para crear un usuario y que solamente ese usuario se pueda loguear vamos a Manage Jenkins, luego a Configure System. Una vez en esa pantalla elegimos Enable Security luego en Security Realm pueden elegir el sistema que prefieran, en mi caso elegi Jenkin’s own user database. Una vez hecho esto, guardamos los cambios con el boton Save.
En ese momento tendremos que crear un usuario, y recien ahi tenemos seguridad habilitada para nuestro Jenkins.
En proximos posts, vamos a ir configurando la pequeña bestia que es este sistema de Continuous Integration.
noviembre 12, 2009 at 12:32 pm · Clasificados en Uncategorized
Les dejo un link a una de las tantas versiones del Pringao HowTo. Es un texto humorístico que anda dando vueltas por la red hace mucho tiempo, pero nunca pierde su vigencia.
Espero que les haga largar un lagrimón de la risa.
Pringao HowTo visto en sromero.org
septiembre 6, 2009 at 10:19 pm · Clasificados en Uncategorized
Hace ya un par de meses tuve que adquirir una nueva laptop ya que el bug de la bios finalmente aniquiló a la vieja y querida Compaq v3000.
Compré una HP DV6 con la esperanza de poder seguir usando la batería de larga duración que tenía en la Compaq y el cargador universal, pero obviamente los muchachos de HP cambiaron de lugar la ficha de la batería cosa de vender toda una nueva serie. Bien por ellos, pero mal para mí.
Si lo hubiera sabido me compraba una Dell.
El caso es que nunca pude hacer funcionar el sonido en mi Sabayon 4.2 y por lo que pude investigar había que pasarse a alsa 1.0.20. Luego de un par de instalaciones inútiles, y ahora que encontré la solución innecesarias, finalmente hace breves momentos di con la solución.
No hacía falta instalar nada, bastaba con agregar la siguiente línea al final del archivo /etc/modprobe.d/alsa:
options snd-hda-intel model=hp-dv5
Luego corremos un update-modules, reiniciamos y voliá! Sonido para todo el mundo.
Hay un pequeño glitch que hace un ruido punzante como si se encendieran los parlates cada un par de minutos si no se está usando la placa de sonido, ahora bien si estamos mirando una peli o reproduciendo música, desaparece el bugcito.
Supongo que eso si se solucionará para la nueva actualización de alsa.
Saludos!
agosto 26, 2009 at 5:43 pm · Clasificados en Uncategorized
Para los que suelen usar la shell como herramienta de trabajo, existe una terminal open sorce muy buena para la plataforma Windows llamada Poderosa. Se las recomiendo ya que es una leve mejora sobre Putty al permitir el uso de pestañas, dividir la pantalla en diferentes partes y demás goodies que irán conociendo a medida que la usen.
El problema viene cuando nos logueamos a un servidor y descubrimos horrorizados que las teclas Inicio y Fin no funcionan como deben, sino que insertan extraños caracteres.
La solución por suerte es muy simple. En el home de sus usuarios en el servidor remoto, agreguen las siguientes lineas al archivo .initrc, en caso de que no exista, creenlo:
# poderosa/xterm
"\e[7~": beginning-of-line
"\e[8~": end-of-line
"\e[D": backward-word
"\e[C": forward-word
Y ready the chicken. No solo ahora funcionan las teclas de Inicio y Fin, sino que además las teclas de cursor izquierda y derecha saltan palabras completas!
enero 15, 2009 at 1:35 pm · Clasificados en Uncategorized
Generalmente cuando uno actualiza el kernel del sistema una muy buena idea es probar que el nuevo kernel tiene todos los modulos necesarios, y sobre todo, funciona como esperamos que lo haga.
Para ello instalamos la nueva versión del kernel, la seteamos como opción por defecto y reiniciamos la máquina. En caso de que algo no funcione como debe, reiniciamos y elegimos manualmente la versión anterior desde el gestor de arranque.
Todo muy lindo si tenemos la maquina a nuestros pies, pero cuando la actualización se llevo a cabo en un servidor remoto no es tan sencillo, ya que no tenemos acceso al gestor de arranque para elegir otra opción.
En esos casos lo mejor que podemos hacer es dejar configurado como opción por defecto algún kernel que sepamos funciona bien y configuramos el GRUB para que se inicie solo una vez con el kernel nuevo. En caso de que todo funcione bien podemos configurar el gestor para hacer permanente nuestra elección del nuevo kernel, pero si falla basta con llamar al nuestro proveedor de servicios para solicitar un reinicio del servidor y acto seguido estamos nuevamente corriendo con el kernel que sabemos funciona bien.
En grub esto se hace con las opciones default saved en la sección general, savedefault en la sección del kernel probado y savedefault #kernelprobado en la sección del kernel nuevo.
Por ejemplo, si nuestro grub luego de la actualización se ve así:
lo modificamos de la siguiente manera:
La clave es que el kernel probado tenga savedefault y el kernel nuevo tenga savedefault 1 siendo 1 el numero del kernel probado.
El efecto de esto es que se iniciará solo una vez el kernel nuevo y podamos volver al viejo con solo pedir un reinicio del servidor. Si luego de que arrancó y se ha probado a discreción el nuevo kernel estamos conformes, simplemente eliminamos el 1 en la sección del kernel nuevo, con lo que cuando arranque quedara como opción por defecto.
Ah, me olvidaba, pero como estamos hablando de servidores remotos, los más atentos dirán: muy lindo, muy lindo, pero ¿como le digo a grub que arranque la próxima vez con el kernel nuevo?
Fácil:
grub-set-default 0
Siendo 0 el kernel a probar.
Update:
En algunos sistemas el comando grub-set-default no se encuentra disponible, en esos casos tenemos que acceder a la consola de grub y usar el comando
savedefault –default=0 –once
y despues
reboot
esto logra el mismo resultado. Después ya estamos listos para el reinicio del servidor.
