Latest Entries »

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/

Ya que hoy es el día del Administrador de Sistemas aprovecho la ocasión y cito un excelente post obtenido de un blog amigo muy interesante, uds dirán si se sienten identificados, les falta aun o por que camino van para ser un SysAdmin perezoso:

Hace muchísimo tiempo me enviaron este texto (lo encontré por acá) y es mi compendio de axiomas de trabajo en la administración de Sistemas, he decidido hacer una traducción libre de este artículo para que mis lectores disfruten un rato y comiencen a ser un poco más perezosos.

Si ves un administrador de sistemas, un técnico de soporte o un administrador de servidores, que siempre anda dando vueltas, como tratando de sofocar fuegos, que constantemente se ocupa de cuestiones relativas a detalles en la producción de sistemas y/o servidores; usted podría pensar que él está trabajando muy duro, ¡siempre tan dedicado!, esa es la concepción para la mayoría de las personas (de hecho, es una concepción de contratar esas personas “bomberos”), pero en realidad él no está haciendo bien su trabajo.

Si vemos a este administrador de sistemas (Unix/Linux, administrador de servidores, DBA o administrador de red) que parece estar todo el día “jugando”, que no parece estar haciendo mucho en la oficina, siempre relajado y casi nunca aparece ningún trabajo duro visible, puede estar seguro de que él está haciendo realmente bien su trabajo.

Estas son las 12 razones por las que un administrador de sistemas (sysadmin) perezoso, es el mejor administrador de sistemas.

Razón 1 ¿Quién es el jefe?: La razón principal por la que los Administradores de sistemas perezosos son los mejores es a causa de su actitud. Ellos ven las máquinas un poco diferente a la forma como las ven en otros departamentos de TI. Hay una diferencia notable entre los administradores de sistemas perezosos y otros admininistradores (ejemplo: los desarrolladores). Los desarrolladores piensan que están para servir a las máquinas mediante el desarrollo de código. No hay nada de malo en este enfoque, ya que los desarrolladores tienen mucha diversión allí; Sin embargo, los administradores de sistemas hacen todo lo contrario; ellos piensan que las máquinas están allí simplemente para servirles. Todo lo que tienes que hacer es alimentar la máquina y mantenerla feliz, dejando que la máquina haga todo el trabajo pesado, mientras pueda relajarse y simplemente dedicar su tiempo a ser perezoso. El primer paso para ser un administrador de sistemas perezoso es un ligero cambio en la actitud, y dejar que la máquina sepa que usted es quien manda.

Razón 2 Automatiza hasta el café: Ser un sysadmin perezoso no significa ser holgazán, debe esforzarse inicialmente para que todo fluya con soltura, debe escribir guiones de programación para trabajos repetitivos; en este aspecto ser perezoso es ser inteligente. Un administrador de sistemas inteligentes es un maestro en todos los lenguajes de scripting (bash, awk, sed, egrep, etc.) y cada vez que se vea obligado a hacer algún trabajo, y si hay una remota posibilidad de que ese mismo trabajo se repita en el futuro, entonces escribe un guión que repita este trabajo. De esta manera, en el futuro cuando se le pida hacer el mismo trabajo, no tiene que pensar, sino que simplemente tiene que ejecutar el script, y volver a ser perezoso.

Razón 3 evitar las pérdidas: Copia de seguridad de todo. Siendo sysadmins perezosos, siempre deben tener una copia de seguridad. Un administrador de sistemas perezoso sabe que debe realizar un poco de trabajo en la creación de procesos de copia de seguridad y escribir secuencias de comandos de copia de seguridad para todos los sistemas y aplicaciones críticas. Cuando el espacio en disco no es un problema, él programa la tarea de respaldo para cada aplicación, incluso para aquellas aplicaciones que no son críticos; de esta manera, cuando algo va mal, él no tiene ponerse a correr a recuperar cosas y sólo hay que restaurar desde la copia de seguridad, y volver a la lectura de comics que estaba haciendo antes.
Esta es también la regla #1 en las tres reglas del administrador de sistemas que JAMÁS se debe romper.

Razón 4 Crea un plan de recuperación ante desastres: A un Administrador de sistemas no le debería gustar correr cuando las cosas van mal (y ciertamente no debería habituarse a ello). Cuando las cosas están funcionando sin problemas, se debe tomar algo de tiempo para crear un DRP (Disaster-Recovery Plan); así, cuando las cosas vayan demasiado mal, pueden seguir el plan de recuperación rápida y que las cosas vuelvan a la normalidad, y volver a ser perezoso de nuevo!.

Razón 5 si no te puedes clonar, clona tus sistemas: La regla de los sistemas altamente redundantes. un sysadmin competente (y perezoso) no le gusta recibir llamadas en el medio de la noche a causa de algún problema de hardware que falló por una tontería; por ende, los sysadmins perezosos se aseguran que todos los componentes de su plataforma sean altamente redundantes. Esto incluye tanto hardware como software. Desde configurar tarjetas de red en modo bonding, RAID en discos, siempre al menos dos servidores o máquinas virtuales para cada cosa, siempre hay que tener al menos dos de todo. Por ende, cuando un componente falla, el sistema todavía sigue funcionando y el administrador del sistema perezoso puede dormir esa noche tranquilo y podrá trabajar en la reparación del componente roto mucho después de regresar temprano en la mañana.

Razón 6 Siempre debe haber espacio para crecer: Un sysadmin perezoso nunca permite que sus sistemas funcionen a plena capacidad. Siempre hay que disponer de espacio suficiente para el crecimiento inesperado; debe asegurarse que los sistemas tiene un montón de CPU, RAM y disco duro disponible; así, cuando su empresa decide volcar toneladas de información o genera inesperadamente muchos archivos, así no sufrirá insomnio pensando si la plataforma colapsará al quedarse sin recursos.

Razón 7 Sea proactivo: Ser un sysadmin perezoso no quiere decir que sólo se sientan y no hacen nada todo el tiempo. Siendo perezosos, se dedican a adelantarse a los hechos y ser proactivo. Los sysadmins perezosos odian ser reactivos. Se anticipan a los problemas y al crecimiento (razones 5 y 6). Cuando tienen algún tiempo libre, se dedican a investigar cómo evitar nuevos problemas, escribir nuevos scripts y modificar la plataforma para durante los problemas seguir siendo perezoso.

Razón 8 Ama tu teclado: combinaciones de teclado, un sysadmin perezoso conoce todos los atajos de teclado para todas sus aplicaciones favoritas. Si va a pasar mucho tiempo todos los días en una aplicación, lo primero que hace es dominar las comnbinaciones de teclas para esa aplicación. por eso los sysadmins perezosos aprenden a usar editores proactivos como emacs o vim, ya que a él le gusta gastar menos tiempo en la solicitud de la información a su máquina, para volver a ser perezoso.

Razón 9: Maestro de la línea de comandos: Cada sysadmin perezoso que conozco es un maestro de la línea de comandos. A veces la gente se sorprende de ver tanto tiempo al sysadmin en una “pantalla negra”; Esto no solo se aplica a sistemas Linux/BSD sino también a DBA’s, administradores de red, etc. Aunque exista una aplicación con interfaz gráfica para una tarea, usted verá al sysadmin lanzando una línea de comandos, En una interfaz de instalación de programas, por ejemplo, tendrás que cargar la aplicación, esperar que cargue, buscar el programa, darle a “seleccionar” y luego a “instalar”, en una cónsola escribes “migestor install miprograma” y listo, sabes exactamente que hacer en cada momento. Hay dos razones básicas por qué los sysadmins perezosos les encanta una línea de comandos. Por un lado, se pueden hacer las cosas más rápidamente en la línea de comandos (si se sabe hacerlo, claro está). Por otra parte, le hace sentir que él es el jefe y no la máquina. Cuando se utiliza la línea de comandos, usted está en control del sistema, usted sabe exactamente lo que quiere hacer y sabe lo que va a obtener. Cuando se utiliza una interfaz gráfica de usuario, usted está a merced del flujo de trabajo gráfico y no tiene el control total.

Razón 10 Aprende de los errores: a un sysadmin perezoso no le gusta cometer el mismo error dos veces. Él odia trabajar en problemas inesperados; pero, cuando surge algún problema inesperado, trabaja en su corrección y piensa acerca de por qué ocurrió, y de inmediato pone las cosas necesarias en su lugar para que el mismo problema no vuelva a ocurrir. Trabajar sobre el mismo problema dos veces es un pecado para un sysadmin perezoso. A un sysadmin perezoso le gusta trabajar en el problema una sola vez, hacer las cosas para evitar el mismo error que ocurra en el futuro, y volver a ser perezoso.

Razón 11 Nunca quedarse atrás: Aprende nuevas tecnologías. No hay nada malo en aprender una nueva tecnología para conseguir un trabajo mejor o simplemente para mantenerse al día con el crecimiento de la tecnología. Pero, nuestro sysadmin perezoso no aprende las nuevas tecnologías por este motivo; en cambio, se entera de las nuevas tecnologías, porque a él le gusta estar en control de los sistemas todo el tiempo. Él sabe que él es el jefe (Razón 1). Así que, cuando una nueva tecnología aparece, este se toma el tiempo para estudiarla. Ahora tiene nuevas herramientas que le permiten mantener el sistema activo, mientras que él sigue siendo un perezoso. Se documenta y aprende una nueva tecnología solo para mantener su egoísta pereza.

Razón 12 Nunca confiar en la mente, Documente todo: No todos los sysadmins perezosos lo hacen; sólo los mejores administradores de sistemas perezosos hace esto. Nunca a un sysadmin perezoso le gusta que le molesten cuando está en la playa disfrutando de sus vacaciones. Entonces, ¿qué hace? documenta todo, deja bitácoras y resoluciones para todo, así que cuando él no está cerca, otro técnico de soporte puede hacer el trabajo de rutina y hacer avanzar las cosas simplemente leyendo la documentación sin molestar las vacaciones del sysadmin. Hay también otra razón más íntima para que el administrador del sistema perezoso documente todo, porque pueden olvidarse las cosas. Puesto que él es perezoso, quizás tiende a olvidar lo que hizo hace un mes. Dado que nunca le gusta pensar el mismo tema dos veces (Corolario de la Razón 10), se documenta todo y cuando tiene que hacer lo mismo en el futuro, pues busca en su documentación para comprender como se hace.

Ahora, usted considerará que ser un sysadmin perezoso no es cosa fácil, es muchísimo trabajo duro, si usted no es un administrador de sistemas, puede que ahora aprecie al administrador vago que ve sentado en su computadora viendo Facebook mientras todo funciona perfectamente, recuerde que no funciona así solo. Si usted es un administrador de sistemas y siempre está dando vueltas apagando fuegos como bombero, usted ya sabe lo que tiene que hacer para ser perezoso.

¡A trabajar hoy, para descansar mañana!

Fuente: http://phenobarbital.wordpress.com/2012/07/23/las-12-razones-por-las-que-un-administrador-de-sistemas-perezoso-es-un-buen-administrador/

Felicidades a todos aquellos sobre los cuales recae el poder de administrar / controlar / gestionar / securizar / monitorizar / recuperar / redundar / optimizar / etc…. (y otros calificativos de la infinidad de tareas que realizamos) aquellos equipos informáticos  que permiten a este mundo fuertemente dependiente de la tecnología  seguir girando nanosegundo a nanosegundo!

Felicidades a aquellos héroes olvidados y poco apreciados, escondidos tras un ticket, con horarios poco comunes de trabajo, que laburamos desde casa los sabados/domingos, que innovamos e investigamos constantemente y principalmente porque día a día disfrutamos hacer nuestro trabajo y pasión  ! !

Feliz Dia del SysAdmin!!!

Feliz dia del administrador de Sistemas !!!

Link: http://sysadminday.com/

El proximo 26,27 y 28 de junio se llevara a cabo en la ciudad de Rosario el Encuentro regional de Telecomunicaciones 2012, en su 15va edicion.

Algunos de las presentaciones son:

Seminarios:

Talleres: 

  • Motion Graphics – Fecha:Martes 26 de Junio del 2012. Disertante: Juan Pablo David – MDP Sistemas Digitales
  • Automatización en Radio – Fecha:Miércoles 27 y Jueves 28 de Junio del 2012. Disertante: Fabio Lastra – SERVIDATA

Workshops: 

Web Oficial: http://www.encuentrosregionales.com/2012/

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/

Feliz 1ro de mayo!

Feliz día del trabajador a todos !!


SOPA y PIPA  este asunto aun no termino, estas leyes  están volviendo recicladas con otro nombre  pero con el mismo o peores consecuencias para los usuarios de Internet

¿Qué significa un proyecto de ley como el PIPA/SOPA para nuestro mundo de intercambio pleno? En las oficinas de TED, Clay Shirkyhace un manifiesto; una llamada a defender nuestra libertad de crear, analizar, vincularnos y compartir, en lugar de consumir pasivamente.

Fuente: http://www.ted.com/

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