Category: GNU/Linux


skype logoHace poco tiempo se libero la versión 4.1 del famoso cliente de videollamadas/chat Skype en versión Linux, ahora propiedad de Microsoft. Esta versión incorpora como novedad la posibilidad de iniciar sesión con nuestra cuenta de MSN Messenger y enlazarla con una cuenta Skype.

Particularmente he tenido algunos inconvenientes a la hora de instalarla ya que en la web oficial no hay disponible un paquete amd64 para la versión deb de skype

skype.linux

skype.linux

Nos bajamos la versión etiquetada como multiarch y vamos al directorio de descarga, deberíamos tener un archivo como este:

skype-debian_4.1.0.20-1_i386.deb

Si tratamos de instalarlo probablemente obtengamos algo como esto:

# dpkg -i skype-debian_4.1.0.20-1_i386.deb

dpkg: error al procesar skype-debian_4.1.0.20-1_i386.deb (–install):

la arquitectura del paquete (i386) no corresponde con la del sistema (amd64)

Se encontraron errores al procesar:

skype-debian_4.1.0.20-1_i386.deb

Una forma que encontré de solucionar esto es añadiendo a nuestra distribución amd64 soporte para multiples arquitectura, e incorporar la arquitectura  i386 a nuestra distribución amd64, esto lo hacemos ejecutando como root:

 # dpkg –add-architecture i386

(por desgracia este ultimo comando funcionara en debian si tenemos dpkg a partir de la versión 1.16.2 en adelante, en Wheezy si funciona, en Squeeze en la versión de dpkg que viene es la 1.15.8.13 )

Luego de hecho esto actualizamos nuestra lista de paquetes disponibles:

# apt-get update

y procedemos a instalar nuevamente skype:

# dpkg -i skype-debian_4.1.0.20-1_i386.deb

hecho esto el páquete no se instalara, pero  el mensaje sera distinto , esta vez alertandonos que no tenemos las dependencias necesarias instaladas lo cual solucionamos con:

# apt-get -f install

y Listo! Skype 4.1 en linux

Saludos

Links:

 

Envio algunos tips útiles para consola después de un tiempo de no tirarle un hueso a mi blog, espero que les sean de utilidad.

Recientemente tuve la necesidad de utilizar unos archivos de gran tamaño a fin de realizar testings de transferencias de velocidad. Con el comando dd podemos realizar esto entre otras posibilidades que nos permite.

A continuación crearemos el archivo llamado imagen2gb.txt de 2Gb en nuestro directorio /tmp:

# dd if=/dev/zero of=/tmp/imagen2gb.txt bs=1024 count=2048000

Otro uso interesante que podemos darle a dd es hacer backups de nuestro MBR del disco rígido en caso que necesitemos jugar un poco con particiones y las cosas no salgan tan bien como esperábamos:

# dd if=/dev/sda of=/dev/backup_mbr_wester500gb.mbr bs=512 count=1

Con el parametro bs le indicamos que tome bloques de 512 bytes de tamaño y con count=1 que sea el primer bloque y luego lo escriba en el archivo backup_mbr_wester500gb.mbr. Para restaurar dicho backup la orden es muy simple:

# dd if=/dev/backup_mbr_wester500gb.mbr of=/dev/sda bs=512 count=1

Otro uso practico en caso que se nos halla acabado la memoria swap y necesitemos un poco mas:

# dd if=/dev/zero of=/archivo_swap2 bs=1024 count=4096000

# mkswap /archivo_swap2

# swapon /archivo_swap2

En la linea anterior creamos un archivo de 4Gb en el directorio raiz, se formatea para dejarlo como swap y lo activamos como tal.

Y ya que estamos dejo una muy conocida también  y bastante practica linea para hacer imágenes iso  de nuestros dvd o cds:

# dd if=/dev/cdrom of=/dir/debian-6.0.5-amd64.iso

Espero que les sean de utilidad, saludos

Cito a continuación un excelente articulo extraido del sitio PineHead, interesante lectura para los sysadmin de Linux:

“You’re fired!” yells a red-headed, more or less bald guy in a suit. You’ll probably recognize this from any of a dozen comedy series. Would you like to play the role of the employee in such a scene, in real life? If you happen to be a Linux sysadmin, it’s your lucky day! We’ve got just the right tips for you. Read on for a comprehensive list of ways to make your boss hit the roof and bounce back again.

1. Write undocumented scripts

This one always works wonders. Be sure to do this with scripts that are 1) important for others to be able to work and 2) likely to need an update in about 6 months, but no earlier. Those 6 months will help your memory to forget the tricky parts of the script, so you’re actually treating yourself to a nice challenge in the future! And if somebody else might ever try to replace you, he will have a ball figuring out what all your scripts are supposed to do. Even better: do not remove or mark old versions and unused scripts, and force him to examine them all!

2. Do not keep any back-ups, or only local ones

Back-ups are cumbersome. There is a good reason that many people intend to set them up but don’t actually do it, and the reason is that they’re cumbersome. Did I say that back-ups are cumbersome? Anyway, some bosses may actually keep nagging you about back-ups until you have them configured, so if you really can’t get away without setting them up, be sure to only make back-ups within a server. Why go through all the hassle of setting up remote authentication if you can just add a simple line of cp to your personal crontab? Problem solved! Nowadays hard disks don’t fail much, right?

3. Install updates on live systems

Installing software updates is easy, right? Just whack “sudo apt-get update” and then “sudo apt-get upgrade” into the server terminal, press enter without looking, now run the command again and press “y” before enter without looking because some blundering fool made “no” the default answer, and you’re done. What’s that? The company website is down? Well, it can’t have been the update you just installed, because newer versions are always better. Go check the power cables or something. Even better: blame the employee who was just editing the site using the CMS back-end. You never trusted that software anyway.

4. Install no updates at all

So, installing updates on a live system almost got you fired for bringing the company website down. Fine, let them experience life without updates! Be sure to expose the exact version string of the web server software in the site’s HTML, then wait until the next useful exploit is found for that version. And if the script kiddies don’t find the vulnerable server fast enough, post a challenge on some obscure hacker forum offering a list of all the company’s active e-mail addresses to the first person able to deface the company website. That’ll teach ‘em!

5. Put your personal settings in global configuration files

Have you ever had to work on somebody else’s account for a short while? Having to miss all your useful aliases, color settings, vi-style hotkeys and 60 characters long PS1 is just unbearable, right? So why not put those settings in the server’s /etc/profile? That way, you can enjoy your favorite terminal settings on everyone’s account! Doesn’t life just smile at you now?

6. Do not implement redundancy

Redundancy is lame. The very word suggests what’s wrong with it: you’re wasting hardware that could be used for something awesome, like powering your BitTorrent downloads so you can watch Star Trek tonight. And what about RAID? All RAID configurations are lame, except RAID 0, because it actually makes your I/O faster. So don’t do failover configurations, versioned back-ups, mirroring disks or UPS power supplies. Say it’s against your religion or something. Bloody waste.

7. Run a different distro on every server you manage

Let’s do some simple math. Every distro has its strengths and weaknesses, and every server is used for something different. So, install a different distro on every server, to match distro strengths with function requirements. Brilliant! Make sure to complete your collection of different package managers, so that every time you need to install or update software, you get confused between apt/dpkg, apt/rpm, apt/tgz, yum/rpm, pacman, emerge and even pisi. Also, make sure to “accidentally” include a distro that barely receives any updates and delight in the mess of incompatibility that ensues. And of course, enjoy the thrill of solving a single problem in 9 different ways!

8. Eat above your keyboard

Not only does it personalize your keyboard by making it feel extra greasy and causing it to smell after a while, but also it helps you to avoid boring conversations with colleagues who do not understand your ravings about the advantages of emacs over vim. Moreover, you don’t have to hear their complaints about the current IT situation, which are only caused by their own lack of computer skills. Besides, if they really want to talk to you, they can always join you on IRC in your favorite Freenode channel, right?

9. Don’t mind file permissions

File permissions are overprotective. And cumbersome. If people can read each others’ files, there is more social control, resulting in a better working climate. Besides, nobody is stupid enough to store a password in a file. If you can remember your own 40-random-character password, they should be able to remember their variations on abc123 and qwertyuiop. Also, nobody ever stores private files on work network shares, or sensitive files for that matter. No sense in fencing things off.

10. Always keep the default configuration on software

Especially if the comment says “DO NOT LEAVE THIS ON IN A PRODUCTION ENVIRONMENT”. Default settings are always good, because if you have a problem with the software and you Google for it, people’s answers are assuming that you’re running the default settings. Makes find a solution just that little bit easier. And if you have to change a setting, do it at the bottom of the configuration file without commenting the original default setting. Much easier than having to find where that particular setting is already listed.

11. Make all servers depend on a single one to function

Single points of failure are cool. Every sysadmin needs to experience a total breakdown of the IT setup of his/her company at least once, and the more single points of failure there are, the faster that experience will come. So, by all means, make a single login server that is contacted on every login, let servers use their configuration files from a network share directly, and put critical servers in a subnet protected by some outdated version of a firewall distro. In the meanwhile, make sure allinternet traffic is routed through a proxy server that blocks traffic based on some 4 kilobyte regex you once conjured up.

12. Do not monitor your servers and certainly don’t set alerts

An appropriate supplement to the previous point! Once your carefully designed single point of failure has done its job, the lack of monitoring and alerts ensures that it takes much longer before things are back up again. Make sure to save your dullest face for the moment the first colleague walks in asking why he hasn’t been able to get anything done for over an hour. Then start (slowly) walking through the default checklist of “have you tried turning it off and on again”, “is the power cord plugged in” and “did you recently see a living unicorn”. Then, when you’re finally fixing the actual problem, the lack of monitoring and alerts ensures you won’t notice it if you break something else in the process. Good times!

13. Give your friend ssh access to the server

So, your friend would also like to do nightly BitTorrent downloads over your company’s huge internet connection. Sure thing! Just give him an ssh account, preferably without double-checking the permissions it has, and let him download away! Nobody’s bothered, right? What could possibly go wrong?

14. Do not use a firewall

Firewalls are nasty. They always get in the way when you want to do something cool, like mounting the server’s “/” directory to your phone using sshfs, or playing EVE Online at work, or streaming the webcam in the company kitchen to livestream.com. Linux is secure by definition, so firewalls are redundant, and we already established that redundancy is lame. Also, don’t do port scans, as they might advise you to change the default configuration, which is against tip #10.

15. Copy huge files over the company internet connection without bandwidth limits

Sometimes, you have to copy a large amount of data to some machine outside the company. It could be a back-up, but that would violate tip #2, so let’s say your external hard drive is full and you want to copy the latest 1080p uncompressed Doctor Who episode to your home computer over the internet. Well, doesn’t that seem like an excellent moment to test the upload bandwidth of the company internet connection? Not only is this a useful statistic to know, but it will also get your 300 gigabytes of sci-fi goodness home that much sooner! Perhaps it will make Reddit load a bit slow on your pc, but fortunately, there’s an app for that!

16. Take home confidential files on an unencrypted usb pendrive

And by tip #2, don’t have a back-up of them either. You won’t be as stupid as those people who lost important pendrives in public transport or things like that. Also, pendrives never fail. And encryption just wastes space and CPU cycles.

17. Always leave the physical terminal of every server logged in

It’ll save you a few keystrokes and some racking your brain for the password. No one else will ever even think of touching the server’s physical terminal, right? No colleagues, cleaners, janitors and certainly no hackers, who always play by the rules and hack over the internet. Completely safe, this.

18. Find the cheapest hosting for the company website

And put the company personnel database on the same hosting account. How could a dollar a month ever be wrong? Besides, shared hosting makes the company website feel less lonely. And if it loads slow (if at all) or suddenly gets hacked, you have the hosting provider to point at instead of taking the blame yourself. Think about it! No need to apply updates, no configuration files to crack your brains over, easy phpMyAdmin access (preferably without SSL) and a fancy control panel to click around in. Oh, and “99% uptime guaranteed” means the website isn’t down for more than 7.44 hours a month, or you’ll get your dollar back!

19. Use the same password on every server

And preferably a password that you also use in your private life. Look at how fast you can type this password because you type it all day! Share this achievement with all your Facebook friends and be considered the most awesome geek they know!

20. Enable root login in sshd_config

Having to su or type sudo all the time is cumbersome bothersome (back-ups are cumbersome, remember?). Therefore, enable root login for ssh, keep it running on the default port (saves typing -pevery time) and use a short root password for convenience. Now, when you see strange failed authentication warnings for the root account in the sshd logs (presuming you actually check those at all), comfort yourself by saying that they will never guess that your short root password is l3tm31n instead of letmein.

21. Change the server network configuration over ssh

And don’t add a timed reversal script or anything like that. Locking yourself out won’t happen to you like it happened to so many others, because of your secret years of ninja training. Or whatever. Bonus points if you don’t have physical access to the server.

22. Don’t invest in your Linux knowledge

Stay away from the other articles on this site, and especially from linuxacademy.com. Block it in your firewall! Wait, you don’t have one because of tip #14. Ahem! Change the ip to 127.0.0.1 in /etc/hosts! This site is insolent enough to presume that you could possibly learn anything about Linux. The arrogance! Your vast knowledge is unparalleled! Besides, copy-pasting solutions from Google always works, so there’s no need to understand anything about them.

Fuente: http://tuts.pinehead.tv/2012/10/10/how-to-make-your-boss-angry-bad-linux-sysadmin-practices/

Después de un tiempo de dar  soporte y mantenimiento remoto a servidores , tras repetitivas veces de tipear una y otra vez los mismos comandos, me puse en la tarea de buscar una herramienta de software que me permitiera gestionar estas conexiones de forma centralizada y me brindara mas posibilidades, particularmente busque alguna alternativa a mRemote (que solo corre en Windows).

En Pac Manager encontre la solucion que buscaba, esta herramienta es la que mas uso en el día a día tanto en el trabajo como desde casa, tiene un amplio soporte de protocolos  con opciones de personalización en las conexiones a terminales remotas o en las conexiones a desktops remotos, soporte de diferentes tipo de encoding, definición de comandos a ejecutar pre inicio y post finalizacion de la conexión, ejecución automatizada de comandos en base a una determinada respuesta desde la terminal, caracteristicas de wake on lan para reactivar equipos en forma remota, definiciones de macros,  y una de las  opciones que mas uso, gestión de cluster de equipos para enviar mismos comandos a un grupo de terminales.

Los protocolos soportados  en su ultima version 4.2 son:

  • Conexiones seriales via cu,  remote-tty
  • Accesos RDP, via rdesktop
  • Accesos VNC, via vncviewer
  • Conexiones via sftp/ssh/telnet

PAC Manager screenshot

En lo que respecta a mis actividades como sysadmin, uno trata de acelerar siempre los tiempos automatizando, en la medida de lo posible, la mayor parte de los procesos repetitivos, mas aun cuando el deber llama y las papas queman.

Antes de toparme con Pac Manager estuve usando mucho  clusterssh, una buena opción programada en tcl/tk  y que me permitía agrupar un conjunto de equipos para conectarme en paralelo a múltiples grupos de servidores y ejecutar comandos en conjunto, pero solo podia usarlo para conexiones por protocolo ssh, al igual que sshmenu, un applet para escritorios gnome que use durante poco tiempo tambien y me permitia de manera mas agil ejecutar los accesos remotos desde un menu desplegable  ubicado en la barra de tareas.

Otras buenas  alternativas multiprotocolos en la misma categoria de Pac Manager  son:

MonoCaffe: Gestor de conexiones, multiprotocolos, y escrito en GTK – Web: http://sourceforge.net/projects/monocaffecm/

Remmina: Web: http://remmina.sourceforge.net/ – Web: https://sites.google.com/site/davidtv/

Que titulo Tete! Bueno, mas allá de lo largo del titulo de este post, hoy me encontraba un poco con ganas de repasar programacion en Shell Scripts de bash asi que tome un viejo script  que encontré en internet hace un tiempo. En aquel momento  lo habia modificado un poco para que anduviese asi que me decidi mejorarlo mas aun porque la verdad cada vez que añadia una nueva maquina virtual tenia que cambiar muchisimas lineas de código.

La gente de VirtualBox provee en sus paquete una herramienta llamada VBoxManage que es para aquellos que empleamos  virtualbox como gestor de maquinas virtuales y necesitamos ejecutarlas  en un servidor sin necesidad de hacer uso del modo gráfico e interactivo donde tenemos que arrancar los host virtualizados a mano.  Este ejecutable nos permite gestionar completamente la administracion de host virtualizados desde linea de comandos con la posibilidad de ejecutarlas de fondo sin activacion del entorno grafico al que todos estamos acostumbrados.

El script gestiona VBoxManage para permitir iniciar/detener/ver el estado de cuantas  maquinas virtuales tengamos, lo anexan al directorio  /etc/init.d/ y como enlace al /etc/rcX.d de su preferencia, en mi caso que uso debian en el /etc/rc2.d/  y  ya podemos empezar a usarlo luego de adecuarlo a nuestras necesidades solo modificando unas pocas variables con nuestro editor de textos favorito.  En las variables a modificar especificaremos datos como nombre de las maquinas virtuales, usuario con el que se ejecuta Virtualbox, tiempo máximo de espera para el apagado de una maquina virtual.

A continuación mi script, tada!!!

#!/bin/bash

##
## virtualbox-daemon-mcy.sh
##
## Version : 0.2 27.01.2012 03:05:43
##
## Descripcion: Demonio de inicio de Maquinas virtuales de VirtualBox
## El objetivo es automatizar el inicio de maquinas virtuales de
## Virtualbox en modo headless ( que es cuando nose ejecutan en modo
## interactivo, sin interfaz grafica, sino en background ). Se soportan
## el inicio de clientes windows como Linux y se mantiene un log por
## fechas de cuando se arranco/detuvo/guardo una sesion. Los logs se
## almacenan en el $HOME/.VBoxLogs del usuario que tiene las VM.
##
## Copyright 2012 Cesar Yanez <emanceyan@gmail.com>
##
## This program is free software; you can redistribute it and/or modify
## it under the terms of the GNU General Public License as published by
## the Free Software Foundation; either version 2 of the License, or
## (at your option) any later version.
##
## This program is distributed in the hope that it will be useful,
## but WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
## GNU General Public License for more details.
##
## You should have received a copy of the GNU General Public License
## along with this program; if not, write to the Free Software
## Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
## MA 02110-1301, USA.
### MODIFICABLE POR USUARIO ### MODIFICABLE POR USUARIO #######
##
## Info: VMs Windows ###
##
## Ayuda:
## VBX_WIN_TOTAL : cantidad de Maquinas Virtuales con Win
##
## VBX_WIN_NAMEX : nombre de la maquina virtual X con Win
## VBX_WIN_USERX : usuario admin de la maquina virtual X
## VBX_WIN_PASSX : password admin de la maquina virtual X
## VBX_WIN_NUMIPX : numero ip de la maquina virtual X
##
## Si hay mas de 4 maquinas virtuales con windows copiar
## y repetir secciones sin repetir numeros
##
VBX_WIN_TOTAL=1

VBX_WIN_NAME1="Windows XP"
VBX_WIN_USER1="cesar"
VBX_WIN_PASS1="cesar"
VBX_WIN_NUMIP1="192.168.1.140"

VBX_WIN_NAME2=""
VBX_WIN_USER2=""
VBX_WIN_PASS2=""
VBX_WIN_NUMIP2=""

VBX_WIN_NAME3=""
VBX_WIN_USER3=""
VBX_WIN_PASS3=""
VBX_WIN_NUMIP3=""

## Info: VMs Linux ###
##
## Ayuda:
## VBX_LIN_TOTAL : cantidad de Maquinas Virtuales con Linux
##
## VBX_LIN_NAMEX : nombre de la maquina virtual X con Linux
##
VBX_LIN_TOTAL=1

VBX_LIN_NAME1="DebianSqueeze"
VBX_LIN_NAME2=""
VBX_LIN_NAME3=""
VBX_LIN_NAME3=""

### Info: Usuario que es propietario de las maquinas virtuales
###
VBX_USR="rondamon"
### Maxima cantidad de tiempo a esperar para que se apague una
### sesion
MAX_SEC=30

### MODIFICABLE POR USUARIO ### MODIFICABLE POR USUARIO #######

###### NO MODIFICAR ###### NO MODIFICAR ###### NO MODIFICAR ####

setEnvVar(){
 RPC_NET=`which net`
 SYS_SU=`which su`
 SYS_AWK=`which awk`
 SYS_GREP=`which grep`
 SYS_TR=`which tr`
 SYS_WC=`which wc`
 SYS_CUT=`which cut`
 SYS_MKD=`which mkdir`
 SYS_CHW=`which chown`
 CUR_USR=`whoami`
 VBX_MNG=`which VBoxManage`
 VBX_USR_HOME=`$SYS_GREP $VBX_USR /etc/passwd|$SYS_CUT -d: -f6`
 VBX_DIR_LOGS=$VBX_USR_HOME/.VBoxLogs
 VBX_LOG_START=$VBX_DIR_LOGS/start.`date '+%d%m%y'`.logs
 VBX_LOG_STOP=$VBX_DIR_LOGS/stop.`date '+%d%m%y'`.logs
 VBX_LOG_SAVE=$VBX_DIR_LOGS/save.`date '+%d%m%y'`.logs
 if [ ! -d $VBX_DIR_LOGS ]; then
 $SYS_MKD $VBX_DIR_LOGS
 fi
 $SYS_CHW $VBX_USR:$VBX_USR $VBX_DIR_LOGS
}

checkVmRunning(){
 VM_TOTAL=`expr $VBX_WIN_TOTAL + $VBX_LIN_TOTAL`
 VM_TOTAL_RUNNING=`$SYS_SU $VBX_USR -c "$VBX_MNG list runningvms |$SYS_WC -l"`
 if [ $VM_TOTAL_RUNNING -eq $VM_TOTAL ]; then
 echo " - Todas las VMs estan ejecutandose"
 return 10
 elif [ $VM_TOTAL_RUNNING -eq 0 ]; then
 echo " - Ninguna VMs en ejecucion"
 return 0
 elif [ $VM_TOTAL_RUNNING -ne $VM_TOTAL ]; then
 echo " - Algunas VMs estan ejecutandose"
 return 5
 fi
}

checkStatusVms(){
 if [ "$1" = " " ]; then
 return 10
 elif [ "$1" != " " ]; then
 ## VM_STATUS=`$SYS_SU -c "$VBX_MNG showvminfo $1 |$SYS_GREP ^State |$SYS_AWK '{print $2}'" $VBX_USR`
 VM_STATUS=`$SYS_SU $VBX_USR -c "$VBX_MNG showvminfo \"$1\" |$SYS_GREP ^State |$SYS_TR -s ' ' ' '|$SYS_CUT -d ' ' -f 2"`
 ### echo VMSTATUSSSSSS $VM_STATUS
 if [ "$VM_STATUS" = "saved" ]; then return 1
 elif [ "$VM_STATUS" = "powered" ]; then return 2
 elif [ "$VM_STATUS" = "running" ]; then return 3
 fi
 fi
}

startWindows(){
 for i in `seq 1 $VBX_WIN_TOTAL`; do
 NAMEL="VBX_WIN_NAME$i"; NAMELL='eval "echo \$$NAMEL"'
 checkStatusVms "`eval $NAMELL`"
 STS=$?
 if [ $STS -eq 1 ] || [ $STS -eq 2 ]; then
 echo " - Iniciando VM Windows: " `eval $NAMELL`
 $SYS_SU $VBX_USR -c "$VBX_MNG startvm \"`eval $NAMELL`\" -type headless >> ${VBX_LOG_START} 2>&1"
 elif [ $STS -eq 3 ]; then
 echo " - La VM `eval $NAMELL` ya esta ejecutandose"
 fi
 done
}

stopWindows(){
 for i in `seq 1 $VBX_WIN_TOTAL`; do
 NAMEL="VBX_WIN_NAME$i"; NAMELL='eval "echo \$$NAMEL"'
 NAMEU="VBX_WIN_USER$i"; NAMEUU='eval "echo \$$NAMEU"'
 NAMEP="VBX_WIN_PASS$i"; NAMEPP='eval "echo \$$NAMEP"'
 NAMEI="VBX_WIN_NUMIP$i"; NAMEII='eval "echo \$$NAMEI"'
 checkStatusVms "`eval $NAMELL`"
 STS=$?
 if [ $STS -eq 2 ]; then
 echo " - "`eval $NAMELL`" esta apagada"; return 0
 elif [ $STS -eq 1 ]; then
 echo " - "`eval $NAMELL`" esta guardada"; return 0
 elif [ $STS -eq 3 ]; then
 echo -n " - "`eval $NAMELL`" deteniendo ..."
 ## $RPC_NET rpc SHUTDOWN -t 0 -C "Apagado desde el servidor de maquinas vituales" -f -I \"`eval $NAMEII`\" -U `eval $NAMEUU`%`eval $NAMEPP`
 $SYS_SU $VBX_USR -c "$VBX_MNG controlvm \"`eval $NAMELL`\" acpipowerbutton >> ${VBX_LOG_STOP} 2>&1"
 for j in `seq 1 $MAX_SEC`; do
 sleep 1; echo -n "$j."
 done
 echo ''; return 1
 fi
 done
}

saveWindows(){
 for i in `seq 1 $VBX_WIN_TOTAL`; do
 NAMEL="VBX_WIN_NAME$i"; NAMELL='eval "echo \$$NAMEL"'
 checkStatusVms "`eval $NAMELL`"
 STS=$?
 if [ $STS -eq 2 ] || [ $STS -eq 1 ]; then echo ''
 elif [ $STS -eq 3]; then
 echo " - Salvando VM Windows: " `eval $NAMELL`
 $SYS_SU $VBX_USR -c "$VBX_MNG controlvm \"`eval $NAMELL`\" savestate >> ${VBX_LOG_SAVE} 2>&1"
 fi
 done
}

startLinux(){
 for i in `seq 1 $VBX_LIN_TOTAL`; do
 NAMEL="VBX_LIN_NAME$i"; NAMELL='eval "echo \$$NAMEL"'
 checkStatusVms "`eval $NAMELL`"
 STS=$?
 if [ $STS -eq 1 ] || [ $STS -eq 2 ]; then
 echo " - Iniciando VM Linux: " `eval $NAMELL`
 $SYS_SU $VBX_USR -c "$VBX_MNG startvm \"`eval $NAMELL`\" -type headless >> ${VBX_LOG_START} 2>&1"
 elif [ $STS -eq 3 ]; then
 echo " - La VM Linux `eval $NAMELL` ya esta ejecutandose"
 fi
 done
}

stopLinux(){
 for i in `seq 1 $VBX_LIN_TOTAL`; do
 NAMEL="VBX_LIN_NAME$i"; NAMELL='eval "echo \$$NAMEL"'
 checkStatusVms "`eval $NAMELL`"
 STS=$?
 if [ $STS -eq 2 ]; then
 echo " - "`eval $NAMELL`" esta apagada"
 return 0
 elif [ $STS -eq 1 ]; then
 echo " - "`eval $NAMELL`" esta guardada"
 return 0
 elif [ $STS -eq 3 ]; then
 echo -n " - "`eval $NAMELL`" deteniendo ..."
 $SYS_SU $VBX_USR -c "$VBX_MNG controlvm \"`eval $NAMELL`\" acpipowerbutton >> ${VBX_LOG_STOP} 2>&1"
 for j in `seq 1 $MAX_SEC`; do
 sleep 1; echo -n "$j."
 done
 echo ''; return 1
 fi
 done
}

saveLinux(){
 for i in `seq 1 $VBX_LIN_TOTAL`; do
 NAMEL="VBX_LIN_NAME$i"; NAMELL='eval "echo \$$NAMEL"'
 checkStatusVms "`eval $NAMELL`"
 STS=$?
 if [ $STS -eq 2 ] || [ $STS -eq 1 ]; then echo ''
 elif [ $STS -eq 3]; then
 echo " - Guardando VM Linux: " `eval $NAMELL`
 $SYS_SU $VBX_USR -c "$VBX_MNG controlvm "`eval $NAMELL`" savestate >> ${VBX_LOG_SAVE} 2>&1"
 fi
 done
}

statusVm(){
 for i in `seq 1 $VBX_WIN_TOTAL`; do
 NAMEL="VBX_WIN_NAME$i"; NAMELL='eval "echo \$$NAMEL"'
 checkStatusVms "`eval $NAMELL`"
 STS=$?
 if [ $STS -eq 1 ]; then
 echo " - STATUS: "`eval $NAMELL`" esta guardada"
 elif [ $STS -eq 2 ]; then
 echo " - STATUS: "`eval $NAMELL`" esta apagada"
 elif [ $STS -eq 3 ]; then
 echo " - STATUS: "`eval $NAMELL`" esta ejecutandose"
 fi
 done
 for i in `seq 1 $VBX_LIN_TOTAL`; do
 NAMEL="VBX_LIN_NAME$i"; NAMELL='eval "echo \$$NAMEL"'
 checkStatusVms "`eval $NAMELL`"
 STS=$?
 if [ $STS -eq 1 ]; then
 echo " - STATUS: "`eval $NAMELL`" esta guardada"
 elif [ $STS -eq 2 ]; then
 echo " - STATUS: "`eval $NAMELL`" esta apagada"
 elif [ $STS -eq 3 ]; then
 echo " - STATUS: "`eval $NAMELL`" esta ejecutandose"
 fi
 done
 echo ''
}

setEnvVar
echo ''
echo '#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*'
echo '* Script de Arranque y Apagado de Maquinas Virtuales (VMs) #'
echo '#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*'
echo ''
case $1 in
 start)
 echo '*** Iniciando VMs, espere a que inicien los sistemas ***'
 startLinux
 startWindows
 ;;
 stop)
 echo '*** Deteniendo VMs, espere a que terminen de apagar los sistemas ***'
 stopLinux
 stopWindows
 ## si no se apago la VM se guarda su estado para proteccion del filesystem
 checkVmRunning
 STS=$?
 if [ $STS -ne 0 ]; then
 saveWindows
 saveLinux
 elif [ $STS -eq 0 ]; then echo ''; echo " - Todas las VMs Apagadas"; echo ''
 fi
 ;;
 status)
 statusVm
 ;;
 restart)
 $0 stop; $0 start
 ;;
 *)
 echo ''; echo "Modo de Uso: $0 {start|stop|status|restart}"; echo ''
 ;;
esac

###### NO MODIFICAR ###### NO MODIFICAR ###### NO MODIFICAR ####

Algunas cosas a mejorar a futuro son el tema del apagado con sistemas Windows, ya que lo hice por llamada rpc del ejecutable net del paquete de samba, pero no pude conseguir que funcione en todos los sistemas windows donde he probado, de todas formas  si quieren probarlo deben descomentar la linea numero 171 dentro de la función stopWindows y comentar la linea 172. De otra forma asi tal como esta por defecto en el caso de host Windows procederá a un apagado normal como si hubieramos pulsado el boton de apagado comun y corriente.

Casi me olvido, esa pequeñes de script va con licencia GPL asi que sientanse libres de modificarlo como quieran y adaptarlo a sus necesidades.

Dejo link de descarga mediafire: http://www.mediafire.com/?4b8s692dhlgqc7p

Saludos a todos

El pelado Angel es uno de esos  personajes  de caricatura pero que existen en la vida real, ademas es un tipo que a pesar de no ser informático y estar en otra carrera se ha dedicado mucho y desde hace años a aprender todo lo que pueda en el rubro informático, tal es así que al día de hoy ha pasado de ser un usuario de tiempo completo de  Windows a usar Linux solamente sin siquiera  tener el sistema de las ventanitas  instalado en alguna partición de su pc, o al menos eso dice.

Entre uno de sus fanatismos, en camino a ser mejor usuario de Linux, tiene por buena costumbre grabar en vídeo todo proceso nuevo que este aprendiendo, y no le salgas con usar un konqueror, dolphin o algun otro gestor de archivos grafico, prefiere quedarse con la terminal de texto y trata de hacer todo lo que pueda allí. Para esta tarea se volvió  mas amigo de  recordMyDesktop que es una aplicación para hacer screencast de todo lo que hagas en tu desktop linux o seleccionar algún área de pantalla en particular y grabarla.

El inconveniente de recordMyDesktop sucede cuando se necesita grabar algun procedimiento de CLI (Interfaz de Linea de Comandos, del ingles Command Line Interface) fuera del entorno grafico, tal como  querer documentar una serie de largos comandos.

Para salir del paso en esas circunstancias encontre ttyrec, una aplicación que graba sesiones de terminal de texto y no es necesario tener activa una sesion de X para poder hacerlo.

Los debianitas lo instalamos simple, con:

# apt-get install ttyrec

Para iniciar la grabación debemos  ejecutar el siguiente comando en consola de texto:

$ ttyrec

y luego trabajar normalmente en la sesion de terminal realizando toda la serie de pasos que deseemos documentar,  para finalizar la grabacion hara falta púlsar la combinacion de teclas CTRL+C

Por defecto las sesiones se guardan en el archivo $HOME/ttyrecord sino se especifica un archivo destino con el parametro -a.

Luego para reproducir y visualizar la sesion guardada debo usar el comando:

$ ttyplay $HOME/ttyrecord

Con las teclas + y – se puede ir controlando la velocidad de reproducción.

Publicando nuestras sesiones de consola en la web

Puede suceder que tengas la necesidad de compartir  con alguien tu sesion de CLI guardada con ttyrec, para ello se creo el sitio playterm.org.

Alli se pueden subir los archivos generados con ttyrec los cuales quedaran accesibles a travez de un reproductor web y tendran una url asociada .

Auditoria

Recientemente he leido de otra aplicacion de ttyrec, se trata de usarlo como herramienta de auditoria para generar una grabación de todo lo que ejecute un usuario al conectarse a una terminal, no parece ser muy complicado hacerlo, lo voy a probar, ya estaré volviendo a ttyrec.

Introducción

El uso de sistemas de control de versiones en proyectos de desarrollo de software permite principalmente a los desarrolladores trabajar en forma rápida, coordinada y a la vez algo despreocupada, pues les brinda muchas posibilidades de gestión de los archivos versionados.  Son herramientas esenciales en todo proyecto de software y hoy por hoy existe una amplia variedad disponibles para su elección, subversion, git, bazaar y otras por mencionar solo algunas alternativas libres.  Cual de ellas usar sera algo totalmente dependiente de nuestras necesidades especificas post análisis de las ventajas y desventajas provistas por cada una.  Otro componente muy necesario durante la etapa de madurado de un proyecto de software son las herramientas conocidas como sistemas de seguimiento/traceo  de errores/incidencias; estas permiten a los desarrolladores/testers reportar/documentar  los distintos tipos de problemas/errores que se vayan descubriendo en el sistema, asi es que se generan reportes de incidencias o tickets, los que normalmente tienen asociados valores comunes tales como: una prioridad, un encargado, detalle del tipo de error, archivos adjuntos que brinden mas datos al reporte, un estado del reporte (incidencia abierta, asignada, cerrada, corregida, o algún estado personalizado, solo por decir algunas).

trac es una herramienta que combina un grupo funcionalidades bastante útiles que son un sistema de reporte de incidencias (o issues como lo llaman sus creadores), una wiki para generar en forma colaborativa la documentación, una visualización del avance del desarrollo por linea de tiempo,  seguimiento del avance del proyecto por hitos/metas y una excelente combinación con subversion. trac esta desarrollada en lenguaje python y es distribuida con licencia GNU/GPL.

Al finalizar se tendrá un servidor de subversion funcionando via protocolo http,  junto a trac como gestor de incidencias, wiki , etc… ,  también voy a configurar el repositorio svn para permitir gestionar los estados de los tickets de trac desde los commits realizados via subversion.  Esta implementacion la realice en un sistema debian linux, con una versión de trac 0.11 (la actual es la 0.12,  esta versión trae mejoras en particular la actualización de tickets vía commits varia un poco  respecto de la 0.11.ya escribiré sobre ella mas adelante).

1. Empecemos con Subversion (svn)

Bueno, para empezar no nos olvidemos que lo principal es contar con un repositorio de subversion donde alojar nuestro proyecto de software. Asi que manos a la obra:

Crear un repositorio svn

Paquetes a instalar:

# apt-get install subversion

El repositorio va a estar ubicado en el path /ruta/svn y es importante que esa ruta este accesible por el usuario/grupo de apache. Ahora si,  creo el repositorio subversion:

# svadmin create /ruta/svn/repositorio-proyecto1

y realizo la importación inicial de  proyecto1:

# svn import /home/sources/proyecto1 file:///ruta/svn/repositorio-proyecto1

Donde en /home/sources/proyecto1 tengo la estructura del fuente del proyecto que quiero versionar, el cuarto parámetro del comando indica el repositorio donde se va a subir este código.  Es importante ejecutar este comando como usuario root. Luego se debe asignar al repositorio el usuario/grupo con el cual se esta ejecutando el servidor web Apache2, en el caso de sistemas basados en debian este es www-data.

# chown www-data: -R /ruta/svn/repositorio-proyecto1

Si miramos este directorio veremos una serie de sub-directorios y archivos que conforman la estructura típica de un repositorio subversion, donde deberán prestar atención al directorio llamado hooks,  al que volveremos luego mas adelante en esta guía.

2. Ahora a crear el entorno trac

Al crear un entorno trac generamos un directorio con una estructura de sub-directorios asociada a un entorno subversion.

Paquetes a instalar:

# apt-get install trac

Iniciamos  el ambiente de trac,  se nos solicitara algunos parámetros de configuración donde /ruta/trac/trac-entorno1 es la ruta donde se va a crear el entorno de trac.

# trac-admin /ruta/trac/trac-repositorio1 initenv
Creating a new Trac environment at /ruta/trac/trac-repositorio1

Trac will first ask a few questions about your environment
in order to initialize and prepare the project database.

 Please enter the name of your project.
 This name will be used in page titles and descriptions.

Project Name [My Project]> Mi Proyecto de Prueba

 Please specify the connection string for the database to use.
 By default, a local SQLite database is created in the environment
 directory. It is also possible to use an already existing
 PostgreSQL database (check the Trac documentation for the exact
 connection string syntax).

Database connection string [sqlite:db/trac.db]> <ENTER>

 Please specify the type of version control system,
 By default, it will be svn.

 If you don't want to use Trac with version control integration,
 choose the default here and don't specify a repository directory.
 in the next question.

Repository type [svn]> <ENTER>

 Please specify the absolute path to the version control
 repository, or leave it blank to use Trac without a repository.
 You can also set the repository location later.

Path to repository [/path/to/repos]> /ruta/svn/repositorio-proyecto1
Creating and Initializing Project
 Installing default wiki pages
 TracTickets imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracTickets
 TracNotification imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracNotification
 TracBrowser imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracBrowser
 InterTrac imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/InterTrac
 TracModWSGI imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracModWSGI
 TracImport imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracImport
 WikiFormatting imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/WikiFormatting
 TracSyntaxColoring imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracSyntaxColoring
 TracWorkflow imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracWorkflow
 TracIni imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracIni
 WikiPageNames imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/WikiPageNames
 TracNavigation imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracNavigation
 WikiDeletePage imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/WikiDeletePage
 SandBox imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/SandBox
 WikiMacros imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/WikiMacros
 TracRevisionLog imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracRevisionLog
 TracFineGrainedPermissions imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracFineGrainedPermissions
 TracStandalone imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracStandalone
 TracUpgrade imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracUpgrade
 TracQuery imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracQuery
 TracFastCgi imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracFastCgi
 TracEnvironment imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracEnvironment
 TitleIndex imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TitleIndex
 TracAdmin imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracAdmin
 InterWiki imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/InterWiki
 WikiRestructuredText imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/WikiRestructuredText
 TracReports imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracReports
 WikiProcessors imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/WikiProcessors
 TracChangeset imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracChangeset
 InterMapTxt imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/InterMapTxt
 TracAccessibility imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracAccessibility
 TracSearch imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracSearch
 TracWiki imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracWiki
 TracCgi imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracCgi
 TracInstall imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracInstall
 TracLinks imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracLinks
 TracInterfaceCustomization imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracInterfaceCustomization
 WikiHtml imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/WikiHtml
 PageTemplates imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/PageTemplates
 TracPermissions imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracPermissions
 TracUnicode imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracUnicode
 WikiRestructuredTextLinks imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/WikiRestructuredTextLinks
 TracTicketsCustomFields imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracTicketsCustomFields
 WikiStart imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/WikiStart
 TracRss imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracRss
 CamelCase imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/CamelCase
 TracGuide imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracGuide
 RecentChanges imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/RecentChanges
 TracPlugins imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracPlugins
 TracRoadmap imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracRoadmap
 WikiNewPage imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/WikiNewPage
 TracTimeline imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracTimeline
 TracModPython imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracModPython
 TracLogging imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracLogging
 TracBackup imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracBackup
 TracSupport imported from /usr/lib/python2.6/dist-packages/trac/wiki/default-pages/TracSupport
 Indexing repository
 [6]
---------------------------------------------------------------------
Project environment for 'Mi Proyecto de Prueba' created.

You may now configure the environment by editing the file:

  /ruta/trac/trac-repositorio1/conf/trac.ini

If you'd like to take this new project environment for a test drive,
try running the Trac standalone web server `tracd`:

  tracd --port 8000 /ruta/trac/trac-repositorio1

Then point your browser to http://localhost:8000/trac-repositorio1.
There you can also browse the documentation for your installed
version of Trac, including information on further setup (such as
deploying Trac to a real web server).

The latest documentation can also always be found on the project
website:

  http://trac.edgewall.org/

Congratulations!

Luego de esto si necesitamos cambiar algunos de estos parámetros recordemos que podemos hacerlo modificando el archivo de configuración del ambiente trac generado, en nuestro caso en:

/ruta/trac/trac-repositorio1/conf/trac.ini

Siempre que queremos podremos modificar nuestro entorno generado con trac, mediante el comando:

# trac-admin /ruta/trac/trac-repositorio1
Welcome to trac-admin 0.11.7
Interactive Trac administration console.
Copyright (c) 2003-2009 Edgewall Software
Type:  '?' or 'help' for help on commands.
Trac [/ruta/trac/trac-repositorio1]>

que nos da acceso a una consola de administración  desde donde se pueden gestionar muchos de los parámetros del entorno trac vía comandas propios. Un  problema que se puede presentar es que les suceda como a mi que cambie de lugar del repositorio de subversion y por consiguiente el entorno trac empezó a tirar errores a pesar de haber realizado las modificaciones del nuevo path en trac.ini. Para ello desde  la consola administrativa de trac y ejecutar el comando resync:

Trac [/ruta/trac/trac-repositorio1]> resync

3. Configuración de Apache2

Trac viene por defecto con su propio servidor web para gestionar los entornos creados que corre por defecto en el puerto 80. En mi caso en el servidor donde voy  a usar trac voy a poner un apache con dominios virtuales en el mismo puerto. Instalo tanto el servidor web como la librería que me permite acceder a repositorios subversion desde apache y la que me permite gestionar trac  desde apache via python. En mi caso particular  voy a dedicar un subdominio interno asociado al repositorio por lo cual voy a crear un dominio virtual. Paquetes a instalar:

# apt-get install apache2 libapache2-svn libapache2-mod-python

Habilito los módulos necesarios en Apache, el modulo para reescritura de urls:

# a2enmod rewrite

y el modulo con soporte de python para apache, que es necesario para que apache reemplazar al web server interno que viene con trac.

# a2enmod python

Creo mi archivo de subdominio en /etc/apache/sites-availiable/ :

# touch /etc/apache2/sites-availiable/trac.midominio.org.ar

con el siguiente contenido:

<VirtualHost *:80>
   ServerName    trac.midominio.org.ar
   ServerAlias   www.trac.midominio.org.ar
   ServerAdmin   webmaster@midominio.org.ar
   DocumentRoot  /ruta/trac
   <Directory /ruta/trac>
      Options Indexes FollowSymLinks MultiViews
      AllowOverride None
      Order allow,deny
      allow from all
   </Directory>

   ##### Logs: Configuración de LOGs
   ErrorLog ${APACHE_LOG_DIR}/midominio.org.ar.error.log
   LogLevel warn
   CustomLog ${APACHE_LOG_DIR}/midominio.org.ar.access.log combined

   ##### Ruta a TRAC : http://trac.midominio.com.ar/
   # Rewrite ./trac to ./trac/
   # RewriteEngine on
   # RewriteRule ^(.*)\/trac$ $1/ [NC]
   <Location />
      SetHandler        mod_python
      PythonHandler     trac.web.modpython_frontend
      PythonInterpreter main
      PythonOption      TracEnvParentDir /ruta/trac
      PythonOption      TracUriRoot      /
      SetEnv PYTHON_EGG_CACHE       /tmp
   </Location>
   ### Validacion de acceso a TRAC : http://midominio.org.ar/*/login
   <LocationMatch ^(/[^/]+)?/login>
      AuthType     Basic
      AuthName     "Login a TRAC"
      AuthUserFile /etc/apache2/passwd-trac
      Require      valid-user
   </LocationMatch>
   ### Referencia al repositorio SVN : http://midominio.org.ar/svn
   <Location /svn>
      DAV svn
      SVNParentPath /ruta/svn
      SVNListParentPath on
      AuthType     Basic
      AuthName     "Repositorio SVN"
      AuthUserFile /etc/apache2/passwd-trac
      Require      valid-user
   </Location>
</VirtualHost>

Una ves hechas esta modificaciones reniciamos el servicio de apache con:

# /etc/init.d/apache2 restart

4. Accediendo al repositorio subversion a traves de Apache2

Los usuarios serán creados en un archivo común que sera usado  tanto por  trac para la validación en su interfaz como por subversion para la autenticacion de los usuarios en su proyecto. Creación de usuarios:

# htpasswd -c /etc/apache2/passwd-trac  usuario

Al añadir un segundo usuario debo quitar el parámetro -c del comando anterior, sino creara nuevamente el archivo passwd-trac. Este archivo es al que referenciamos desde la configuración del virtualhost de apache2, donde también lo usamos para realizar el acceso de nuestros usuarios a trac. La forma de referenciar al repositorio al hacer un checkout  es:

# svn co http://trac.midominio.org.ar/svn/repositorio-proyecto1

Accediendo a la interfaz de trac

Según he armado esta guía la interfaz de trac estaría disponible en la dirección http://trac.midominio.org.ar y se vería así:

5. Asociando los commits a la actualización de los tickets en trac

La funcionalidad comit ticket updater hasta donde he visto es fabulosa, porque permite que cada usuario de subversion que se baje una copia de código al momento de redactar un comentario por cada commit realizada tenga la opción de interactuar con el sistema de tickets que provee trac. Bueno empecemos, creo un directorio donde este accesible el script

# mkdir /usr/share/trac/contrib
# cp /usr/share/trac/contrib/trac-post-commit-hook /usr/share/trac/contrib

Dentro del directorio hooks del repositorio de mi proyecto en svn, el que mencionamos anteriormente,  crear el archivo post-comit :

# touch /home/svn/repositorio-proyecto1/hooks/post-commit

Luego lo hago ejecutable:

# chmod 755 /home/svn/repositorio-proyecto1/hooks/post-commit

y, asigno usuario y grupo del servidor web

# chown www-data.  /ruta/svn/repositorio-proyecto1/hooks/post-commit

y lo edito con el siguiente contenido :

#!/bin/sh
REPOS="$1"
REV="$2"
LOG=`svnlook log -r $REV $REPOS`
AUTHOR=`svnlook author -r $REV $REPOS`
TRAC_ENV='/ruta/trac/trac-proyecto1'
/usr/bin/python  /usr/share/trac/contrib/trac-post-commit-hook \
-p "$TRAC_ENV"  \
-r "$REV"       \
-u "$AUTHOR"    \
-m "$LOG"

ATENTI!  que es necesario setear la variable TRAC_ENV de la linea 6 con el valor correcto sobre la ruta al entorno trac que corresponda al proyecto.

¿Como redactar los commits para interactuar con los tickets de trac?

Un vez hecho esto, como ya dije, los usuarios al hacer un commit contra el repositorio tendrán la opción de gestionar el  estado de los tickets disponibles. Esto se hace añadiendo en los comentarios  algunos comandos, estos son:

Comandos Detalles
close, closed, closes, fix, fixed, fixes Los números de ticket especificados con estos comandos son cerrados con el contenido del mensaje del commit añadido como detalle
references, refs, addresses, re, see Los números de problemas especificados con estos comandos son dejados en su estado actual, pero el contenido del mensaje del commit es agregado a las notas de los tickets

Ahora la pregunta obvia seria ¿ como escribo los comandos?,  es bastante simple, se debe respetar  la siguiente notación:

comando #1
comando #1, #2
comando #1 & #2
comando #1 and #2

Donde #1 y #2 son números de tickets existentes en trac. O también puede usarse esta otra notación:

comando ticket:1
comando ticket:1, ticket:2
comando ticket:1 & ticket:2
comando ticket:1 and ticket:2

Estos comandos se analizan desde el script post-commitubicado en el directorio hooks del repositorio svn. Se parsea todo el mensaje de detalle de un commit cada vez que este se ejecuta y si se encuentran los comandos en los formatos especificados se realiza la acción que corresponda. Pongamos un ejemplo,  podemos enviar  un “commit”  con el siguiente comentario:

“Cambios en tales modulos y mejoras en otros componentes. fixes #12 and #20, and refs #22”

Con lo cual cerrariamos los tickets 12 y 20 con un estado fixes y agregariamos este mensaje tambien como nota al ticket 22.

6. Conclusiones:

En mi experiencia he trabajado y he visto entornos donde tanto el sistema de seguimiento de errores como el de control de versiones estaban implementados en forma separada,  por consiguiente la tarea del desarrollador era doble, ademas de comentar en los commits debían redundar en tareas  al tener que escribir exactamente lo mismo en respuesta a alguna incidencia reportada.  Tener integradas ambas herramientas, sumado a  la posibilidad de  interactuar con los tickets creados permite al grupo reducir tiempo valioso dedicado en escribir documentación del proceso de desarrollo, que es algo que los desarrolladores no suelen tener en en top de la lista de sus prioridades principales. La experiencia dentro de la interfaz de trac es muy ágil para el usuario, se tiene las linea de tiempo  (timeline) donde se puede visualizar todas las modificaciones hechas dentro del entorno, desde una nueva entrada en la wiki a cambios en los tickets o la hoja de ruta (roadmap) desde donde se pueden seguir los estados del proyecto en cada Hito/Meta (o milestones como los llama trac).

Una ventaja, si se la puede ver así, es que al finalizar esta  guía quedara configurado un servidor web donde podemos tranquilamente escalar la configuración para  ubicar otros repositorios subversion en el path /ruta/svn y sus entornos trac asociados en el path  /ruta/trac/, es decir podremos situar múltiples proyectos de software.

Este comando corto me salvo las papas muchas veces cuando me toco jugar con el MBR (Master Boot Record) y las particiones.

Se usa únicamente la utilidad dd que sirve para copiar contenido de archivos de la entrada standar a la salida standart y se juega con la potencia caracterista heredada de los sistemas unixes de la representacion de dispositivos en archivos.  Donde /dev/sda es el disco  en cuestión.

Para hacer el respaldo:

dd if=/dev/sda of=/pendrive/backup_mbr_20110629.mbr bs=512 count=1

Y asi de facil, para restaurar el MBR :

dd if=/pendrive/backup_mbr_20110629.mbr  of=/dev/sda bs=512 count=1

Con bs=512 le digo que el tamaño de bloque a copiar es de 512 bytes, con count=1 le digo que solo un  bloque , en este caso el primero bloque, que es donde se ubica el MBR.

Simple y rapido.

Hamachi  es una solución provista por la empresa LogMeIn que permite implementar de manera rápida y fácil una solución de VPN en aquellas redes donde nos encontramos con gateways con restricciones de acceso, basta con bajar un aplicativo cliente e instalarlo para crear  nuestras redes “privadas” y agregar equipos a ellas.

Antes de trabajar con Hamachi ya había implementado redes privadas virtuales en Linux con  pptp, openvpn y otras herramientas, y la verdad que con estas soluciones siempre tuve que  disponer de uno a un par de  puertos  públicos habilitados para poder validarme y establecer el vinculo desde los equipos clientes hacia las subredes privadas  situadas detrás de un server que corría el servidor de vpn, también necesitaba de ciertos privilegios  para aplicar cambios en la configuración del gateway de salida a  Internet.  Con Hamachi esta visión cambio dado que la conexión de los clientes se establece hacia la nube, lo cual elimina las restricciones antes mencionada. Desde el aplicativo  podemos crear VPNs y asociarlas a una contraseña, misma que deberá tener cada equipo que vaya a unirse a la red. La arquitectura de conexión de los equipos en la versión libre de Hamachi permite tener hasta un máximo de 16 equipos unidos por red y en la versión comercial hasta 256.

Los instaladores de la version 2 para Linux se pueden bajar desde aqui:

https://secure.logmein.com/labs/

Lo bueno en mi caso, ya que trabajo en una gran parte con sistemas Debian, es que estan disponibles  los paquetes .deb, tanto para arquitecturas de 32 y 64 bits,  también hay paquetes en formato  .rpm y .tgz.

Algunos comandos de hamachi2 en consola

Para operar con hamachi es necesario iniciar el correspondiente servicio. En sistemas  basados en Debian el demonio se ubica en /etc/init.d y  se arranca con :

# /etc/init.d/logmein-hamachi start

Una medida de seguridad para no ejecutar los comandos habituales como usuario root es especificar en el archivo h2-engine-override.cfg otro usuario normal de sistema. Para ello debemos crear archivo en :

/var/lib/logmein-hamachi/h2-engine-override.cfg

y agregarle la siguiente linea:

Ipc.User         MiUsuario

Este archivo sirve para setear algunos valores por defecto para el servicio, tales como  recordar contraseñas de acceso a redes, proxy de salida a internet y otros.

Algunos comandos básicos para trabajar con Hamachi en consola:

Establecer conexión con la red de Hamachi:

$ hamachi login

Para crear  una red:

$ hamachi create NOMBRE_DE_RED PASSWORD

(si no se especifica una contraseña de acceso se solicita a continuación)

Unir el equipo actual a una red determinada:

$ hamachi join NOMBRE_DE_RED

Establecer un ID de red, este nombre sera con el que nos visualizaran otros miembros de la red:

$ hamachi set-nick APODO_DE_PC

Listar las estaciones y redes en las que estamos:

$ hamachi list

deberia visualizar algo asi:

 $ hamachi list
 * [VPNWorking007]
       084-117-321   mami                       5.5.53.21
       083-007-603   cigarra                    5.18.6.92
       084-182-025   mona                       5.13.219.234
     * 081-254-316   verdulera                  5.52.140.58    via server  TCP
       083-324-547   licuadora                  5.51.236.176
       083-861-081   sabandija                  5.92.53.168
       098-845-416   peper                      5.121.121.142
       091-045-595   anonymous                  5.139.128.135
       092-402-648   lagartillo                 5.156.181.226
 * [VPNCasera]
       085-054-603   cigarra                    5.18.6.92
       087-389-571   sodipodi                   5.39.224.253
     * 091-332-879   casita                     5.117.152.16   via relay   TCP

En el listado se observa que estoy unido a dos redes , VPNWorking007 tiene 9 nodos unidos, y VPNCasera tiene 3, y se ve que hay un equipo (cigarra) en común en ambas redes .

Si sos mas de las ventanitas…

Y de ves en cuando ando algo vago y no quiero tipear todo asi que bue, me baje e instale haguichi, un Gui para hamachi2 , ciertamente hay que tener instalado hamachi en el sistema.

 Url de descarga: http://www.haguichi.net/

Versiones viejas para Linux

Buscando por la red encontré una version 0.9 de Hamachi para Linux, es totalmente funcional al dia de la fecha, la contra que tiene es que no hay versiones disponibles para plataformas de 64 bits y que si bien una vez que la tenemos funcionando permite conectarse a otras redes  no permite acceder a otros  equipos que no tengan instalada la misma version.

Un punto bueno, si se lo puede ver asi,  es que esta versión es  una alternativa para aquellos equipos con distribuciones Linux viejas y con  arquitectura de 32 bits donde no pueda instalarse la version 2 de hamachi.

Url de descarga: http://files.hamachi.cc/linux/

En conclusión

Hamachi me ha salvado de horas de viaje  hasta equipos ubicados en  entornos  donde me he visto restringido de realizar algún tipo de gestion en los permisos de accesos desde/hacia Internet y  por consiguiente impedido de  implementar otras alternativas.  También ha sido de mi agrado la disponibilidad de esta herramienta para plataformas windows, linux y mac, puesto que cubre el espectro de arquitecturas en las que usualmente trabajo.  Tal cual dice la leyenda de hamachi , es una herramienta de cero configuración y así es como ha sido,  fácil , y rápido.  Aun así me reservo un grado de paranoia al momento de recordarme algo que no me cae bien en los servicios Cloud,  y que  es algo inherente a ellos ,  el desconocimiento que tiene el usuario acerca de lo “que se hace” y “como se hace ” dentro de la dichosa nube, mas aun en permitir el trafico de una parte de nuestra red privada a través de un servidor de terceros.

En lo que respecta a los resultados de  mis búsquedas aun no he podido  encontrar una alternativa similar en software libre, algo que es de mi preferencia.

Particularmente en mi trajin diario administro muchos servidores UNIX/Linux en forma remota mediante el protocolo  de acceso encriptado SSH. Buena cantidad de estos equipos se encuentran accesibles desde Internet y por lo tanto quedan expuestos a posibles atacantes. Es una tarea basica de un SysAdmin reducir las posibilidades de exposición de los servicios hacia Internet a dichos atacantes. Para ello existen, en el caso de SSH desde tips y herramientas para reforzar la configuración del mismo, y principalmente el mismo manual de ssh. Tal es así que en esas busquedas locas que realizo por la net me tope con Pam_Captcha. PAM Captcha realiza una implementacion de preautenticacion mediante ingreso de código captcha en interfaz asccii para prevalidar el acceso e intentar reducir los ataques de fuerza bruta que se puedan efectuar contra  nuestro servidor SSH.

Que es PAM? : Son las siglas de Pluggable Authentication Modules, o traduciendo seria Módulos de Autentificacion Conectables, que en un sistema GNU/Linux actual  es el núcleo de las autenticaciones de los usuarios que permiten  acceder a las aplicaciones  o servicios del sistema. Debido a su característica modular es posible entre otras posibilidades la combinación de mecanismos de autentificacion del usuario, que es lo que vamos a hacer en el presente articulo.

Implementando PAM_Captcha Para poner  a funcionar empezamos por descargarlo de:

http://www.semicomplete.com/projects/pam_captcha/

$ wget -c http://semicomplete.googlecode.com/files/pam_captcha-1.5.tar.gz
$ tar xvfz pam_captcha-1.5.tar.gz
$ cd pam_captcha-1.5
$ sudo make

Si tuviste algún problema al compilar se deben instalar las siguientes dependencias, Figlet  y los headers del paquete de las librerias de PAM. En mi caso particular (uso Debian Squeeze) instale los módulos libpam0g-dev y figlet, dependencias para que se compile correctamente el modulo.

$ sudo apt-get install libpam0g-dev figlet

Una vez ejecutado el:

$ sudo make

dentro del directorio que descomprimimos, y si vemos que no se genero ningún error, ya deberíamos tener disponible el archivo libpam_captcha.so en el directorio. Cambiamos los permisos del archivo a

$ sudo chmod 644 libpam_captcha.so

y lo copiamos al directorio donde se localicen los modulos de PAM, en mi caso:

$ sudo cp libpam_captcha.so /lib/security

A continuación modificamos el archivo de configuración de PAM para Ssh en /etc/pam.d/sshd, añadiendo la siguiente linea:

auth       requisite     pam_captcha.so    math randomstring

Los parámetros finales son opciones del modulo Pam, donde math muestra como captcha un calculo aritmético simple, randomstring una cadena aleatoria de caracteres y números, y dda es una opción que solo existe a niveles de diversión :). Luego hay que modificar algunos parámetros de configuración del demonio SSH, para ellos cambiamos  el siguiente archivo:

/etc/ssh/sshd_config

añadiendo o modificando las lineas a los siguientes valores:

PasswordAuthentication no
ChallengeResponseAuthentication yes

Luego de esto reiniciamos el servidor ssh

$ sudo /etc/init.d/ssh restart

Y listo ! :). Espero les sirva. Saludos a todos. Dejo un screencast con un paso a paso de como se vería la implementacion y el funcionamiento de Pam_Capchat:

Enlace directo a vimeo: http://vimeo.com/15587452