Redmine: Instalar plugin “Close Issue button”

Redmine is a flexible project management web application written using Ruby on Rails framework.

Llevo 1 mes utilizando Redmine en mi empresa en reemplazo de un viejo Jira y es un total éxito, tiene todo lo que una empresa de desarrollo puede necesitar integrando fácilmente Wiki, Foros, Repositorios, etc.

Sobre la instalación standard en Debian siempre es necesario potenciar nuestro entorno con los plugins que la comunidad pone a nuestra disposición.

Necesité instalar el plugin “Close Issue button“, lo hice según las instrucciones pero no funcionó; Resultó ser que la documentación no aclara 2 cosas.

  • Es preciso ser miembro de un proyecto para ver la opción “Close” en un Issue.
  • Hay que hacer un refresh de los plugins en el entorno “production” de Redmine mediante el comando rake.

Manos a la obra, a continuación el proceso de instalación detallado.

Asumiremos que ya tenemos instalado y funcionando Redmine.

1
2
3
4
root@mveeze:~# cd /var/lib/redmine
root@mveeze:/var/lib/redmine# git clone git://github.com/Undev/redmine_close_button.git vendor/plugins/redmine_close_button
root@mveeze:/var/lib/redmine# rake db:migrate_plugins RAILS_ENV=production
root@mveeze:/var/lib/redmine# /etc/init.d/apache2 restart
root@mveeze:~# cd /var/lib/redmine
root@mveeze:/var/lib/redmine# git clone git://github.com/Undev/redmine_close_button.git vendor/plugins/redmine_close_button
root@mveeze:/var/lib/redmine# rake db:migrate_plugins RAILS_ENV=production
root@mveeze:/var/lib/redmine# /etc/init.d/apache2 restart

Eso es todo, se entiende por supuesto que deben tener git instalado en su servidor Debian.

1
root@mveeze:~# aptitude install git -y
root@mveeze:~# aptitude install git -y

Lo único que le falta a este plugin es que cuando hacemos click en “Close” lo que hace es cerrar el actual Issue en forma directa, se echa en falta el normal comportamiento que existe en Trac, Bugzilla, etc; Que cuando cerramos un issue/ticket podemos agregar un comentario.

Click para agrandar

Tips: Friendly urls en WordPress +nginx

Como un simple ayudamemoria, la configuración que estoy utilizando en mi wordpress + nginx es la siguiente.
En vez de las urls por defecto que utiliza WordPress ej: http://ngen.com.ar/blog/?p=23 podemos utilizar las mas utilizadas hoy en dia con el nombre completo del post en la url.

Para eso deben activar dentro del panel de WordPress en la sección “Permalinks” utilizo la variable /%postname%.

Sólo queda modificar el VirtualHost del nginx para que funcione.
Reiniciar nginx y verificar que los posts ahora se navegan desde urls que incluyen el nombre del post.

1
2
3
4
5
6
7
8
        location /blog {
                root   /var/www/ngen.com.ar;
                index  index.php;
                if (!-e $request_filename) {
                       rewrite ^/(.*)$ /blog/index.php?q=$1 last;
                       break;
                       }
                }
        location /blog {
                root   /var/www/ngen.com.ar;
                index  index.php;
                if (!-e $request_filename) {
                       rewrite ^/(.*)$ /blog/index.php?q=$1 last;
                       break;
                       }
                }

Me gustan las pelis

Las pelirrojas… Si es pelirroja tetona y con pecas = Nirvana :D

Tips: Múltiples IPs utilizando iproute en Debian

En el ámbito de administración de servidores GNU/Linux, cuando se necesita especificar más de una IP en una interface se recurre generalmente los alias de interface, los conocidos ethx:x.
Aunque funciona perfectamente bien y la administración de las reglas iptables asociadas es relativamente fácil estamos dejando de lado una suma de funciones poderosas a utilizar en un servidor GNU/Linux.
Nunca me gustó utilizar alias, pocas veces lo he necesitado; Ahora justamente tengo en mi empresa un server con Debian “Squeeze” cumpliendo las funciones de gateway, tenemos un enlace dedicado con un pool de 14 IPs públicas y necesito dejar todo listo para un próximo enlace dedicado a la par del actual, utilizar alias realmente me limita en comparación con los beneficios a futuro si utilizo iproute [0].

Tengo hasta el momento 4 interfaces físicas en mi server (eth0=ISP1, eth1=ISP2, eth2=lan, eth3=dmz)

Como por el momento tengo solamente 1 ISP, y estoy utilizando al menos 3 IPs públicas del pool disponible y en el futuro inmediato necesito:

  • balanceo de carga
  • Wan failover
  • traffic shapping
  • múltilples rutas entre la (dmz, openvpn, lan, internet, etc)

La solución es integrar iproute con la estructura de networking en Debian.

Debian utiliza el archivo /etc/network/interfaces para definir el estado de las interfaces y sus IPs, en este caso en particular definimos las IPs utilizando iproute, debemos cambiar entonces el comportamiento modificando algunos valores.

He aqui un ejemplo típico (las IPs son ficticias)

1
2
3
4
5
6
7
auto eth0
iface eth0 inet static
        address 190.139.257.1
        netmask 255.255.255.240
        network 190.139.257.0
        broadcast 190.139.257.15
        gateway 190.139.257.14
auto eth0
iface eth0 inet static
        address 190.139.257.1
        netmask 255.255.255.240
        network 190.139.257.0
        broadcast 190.139.257.15
        gateway 190.139.257.14

Utilizando iproute cambiamos el valor inet a “manual” quedando como el ejemplo que sigue.

1
2
3
4
5
6
auto eth0
iface eth0 inet manual
        pre-up ip link set eth0 up
        post-up ip addr add 190.139.257.1/28 dev eth0
        post-up ip addr add 190.139.257.2/28 dev eth0
        post-up ip route add default via 190.139.257.14 dev eth0
auto eth0
iface eth0 inet manual
        pre-up ip link set eth0 up
        post-up ip addr add 190.139.257.1/28 dev eth0
        post-up ip addr add 190.139.257.2/28 dev eth0
        post-up ip route add default via 190.139.257.14 dev eth0

Para confirmar que las IPs esta correctamente configuradas, iproute nos provee con el comando “ip” para verificarlo

12
3
4
5
6
7
root@cerberus:~# ip addr show eth02: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:e0:7d:ea:f6:00 brd ff:ff:ff:ff:ff:ff
    inet 190.139.257.1/28 scope global eth0
    inet 190.139.257.2/28 scope global secondary eth0
    inet6 fe80::2e0:7dff:feea:f600/64 scope link
       valid_lft forever preferred_lft forever
root@cerberus:~# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:e0:7d:ea:f6:00 brd ff:ff:ff:ff:ff:ff
    inet 190.139.257.1/28 scope global eth0
    inet 190.139.257.2/28 scope global secondary eth0
    inet6 fe80::2e0:7dff:feea:f600/64 scope link
       valid_lft forever preferred_lft forever

Eso es todo, posteriormente se puede agregar a las lineas de /etc/network/interfaces todo lo que necesitemos aplicar con iproute (rutas extras, traffic shapping, etc)

[0] http://lartc.org

Online + reinstalación con Debian Squeeze

Despues de haber estado 3 semanas sin el servidor (por baja del servicio donde estaba alojado) me armé un nuevo server en el cual instalé el flamante y recién estrenado Debian GNU/Linux “Squeeze”.
Me falta poner en linea de mi qmail y listo! (estimo hacerlo este fin de semana)