Nov 11 2009

Hudson, Sventon y conexiones SSH con llaves (bajo Tomcat y Windows)

Categoría: Integración ContinuaJuan @ 1:59 pm

¡Demonios!, esto debe ser una tontería y seguramente que soy el único pardillo que no sabía como configurar Hudson y Sventon juntos (un navegador de repositorios para el que no lo conozca) bajo Tomcat y en Windows para que funcionen usando svn+ssh con llaves. Si no es así, y ya que me ha costado sangre, sudor y lágrimas, ahí os dejo la solución (que aunque simple, me ha costado mucho encontrar).

Basta con añadir los siguientes parámetros al final del archivo catalina.properties que normalmente se encuentra en C:\Program Files\Apache Software Foundation\Tomcat 6.0\conf:

svnkit.ssh2.key=_llave_
(por ejemplo: “D:/ssh_keys/userkeys/llave”)
svnkit.ssh2.username=_nombre_de_usuario_

Seguro que esta ni es la mejor solución, ni la más elegante pero al menos funciona (que con el tiempo que me ha llevado es, al menos por ahora, más que suficiente).

Si alguien conoce una manera mejor o más apropiada, le estaría muy agradecido si la compartiese.

Etiquetas: , , , ,


Ene 26 2009

Hudson (en Windows y como servicio) y CVS

Categoría: Integración ContinuaJuan @ 12:51 pm

Cómo es el sistema, lo primero: un Windows con CVSNT para acceder al repositorio y Hudson en Tomcat configurado como un servicio.

El problema viene cuando Hudson intenta acceder al repositorio por primera vez y la huella del repositorio no está en la caché. Como Hudson lo ejecuta no interactivamente no podemos escribir “yes” y darle al intro al ver el siguiente mensaje:

The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is. The server's key fingerprint is:
ssh-dss 1024 4f:8...
If you trust this host, hit Yes to add the key to
PuTTY's cache and carry on connecting.
If you want to carry on connecting just once, without
adding the key to the cache, hit No.
If you do not trust this host, hit Cancel to abandon the
connection.SCM check out aborted

Bueno, no hay problema, podemos hacerlo desde la consola y añadir la huella a la cache manualmente… Pues no, ahora el problema es que Hudson es un servicio y ejecuta bajo la cuanta de usuario Local Service Account y yo, personalmente, no sé como puedo entrar al sistema con ese usuario (lo siento, no tengo tanta experiencia con Windows) Supongo (quizá erróneamente) que esta cuenta no se puede usar para entrar al sistema ya que es una cuenta especial y hacerlo con otro usuario no arreglaría nada ya que la caché es dependiente del usuario.

El siguiente paso es añadir la huella manualmente a la caché (un fichero) ya que sé que se puede hacer en Linux. Mal otra vez, Windows no tiene esta caché como un fichero sino que utiliza el registro. Buscando en el registro encontré una entrada para mi usuario (ya que previamente había accedido al repositorio y añadido la huella a la caché) donde estaba la huella guardada y la copié a HKEY_USERS para que cualquier usuario pueda acceder a ella. La entrada es algo así:

Key Name: HKEY_USERS\.DEFAULT\Software\SimonTatham\PuTTY\SshHostKeys
Class Name: NO CLASS
Last Write Time: 23.01.2009 - 18:35
Value 0
Name: dss@22:bla_bla.com
Type: REG_SZ
Data: 0xb477b...

Desde la línea de comandos, se puede añadir la huella fácilmente como sigue:

reg add HKEY_USERS\.DEFAULT\Software\SimonTatham\PuTTY\SshHostKeys /v dss@22:bla_bla.com /d 0xb477b...

Ahora Hudson, ejecutado como un servicio, accede felizmente y sin problemas al repositorio donde está el código.

Etiquetas: , ,


Ago 19 2008

Interacción con el escritorio, JSUnit y Hudson

Categoría: Integración ContinuaJuan @ 10:35 am

Hace unas cuantas semanas trabajando con un equipo en Kuala Lumpur me encontré con un problema al utilizar JSUnit junto con Hudson (en Windows). Para quien no lo conozca, Hudson, es un motor de integración continua similar a CruiseControl que, quizá, sea el más conocido (nota mental: escribir una entrada en exclusiva para Hudson en el futuro).

JSUnit, el entorno de test unitarios para JavaScript, utiliza un navegador (Explorer, FireFox, Opera, etc.) para ejecutar las pruebas. Cuando lanzaba las pruebas desde la consola (usando ant), estas eran ejecutadas sin problemas (abriendo el navegador pertinente y cerrándolo al terminar), sin embargo, cuando la misma operación era efectuada por Hudson, el navegador no era lanzado aunque el proceso era ejecutado (el proceso aparecía en ejecución en la lista de procesos).

Hudson normalmente es ejecutado por Apache Tomcat, el cual suele ser un servicio, y, por defecto, Tomcat tiene deshabilitada la opción de “interacción con el escritorio”. Esta era la razón por la cual el navegador no era ejecutado correctamente.

La manera de corregir este problema es yendo a las propiedades del servicio de Tomcat (accesibles desde Tomcat o desde las propiedades de servicios de Windows) y desde allí a la pestaña “Log on”. En esta pestaña hay que habilitar la opción “Allow service to interact with desktop” (ver la siguiente imagen) y una vez hecho esto reiniciar el servicio. Ahora Hudson debería ser capaz de lanzar cualquier navegador (o programa en ventana) sin problemas.

Integración de JSUnit y Hudson

Etiquetas: , , , , , ,