Tag Archive: Sysadmin


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/

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.

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

Bien aquí va una herramienta útil para aquellos que realizamos administración de múltiples sistemas en forma remota vía protocolo OpenSSH, la verdad que cuando empecé hace años solo accedía a un par de ventanas con lo cuales no me resultaba molesto por allí realizar repetición de comandos, pero creanme , cuando se necesita mantener mas de 2  servidores he aquí que nos surge la necesidad de algún aplicativo que nos de las bondades que nos da ClusterSSH.

Tal vez aun seguís preguntándote , ¿pero que tipos de tarea puedo realizar en forma simultanea ?, dejame que te de alguna idea para comenzar de las tareas que se puede ejecutar en paralelo:

  • Actualización simultanea de algún aplicativo empaquetado o dist-upgrade (caso de Debian o derivados )
  • Descarga manual de aplicativos que necesitan ser instalados mediante el método convencional (./configure, make, make install)
  • Búsqueda en  Logs de parámetros comunes
  • Actualización de regla genérica en herramienta de firewall.
  • Procedimientos de mantenimiento de base de datos
  • otros….

si sos un Debian User, justo como yo, procedemos a instalarlo mediante:

# apt-get install clusterssh

Una vez instalado el aplicativo y sus dependencias disponemos del ejecutable cssh , el cual dará aparición de una pequeña ventanita como esta:

Pantalla de Inicio de ClusterSSH
Pantalla de Inicio de ClusterSSH

Allí la opción mas útil es la que se encuentra bajo el Menú “Hosts” y se llama “Add Host” , también podemos iniciarla con la combinación de teclas CTRL + PLUS(+) (osea tecla “Control” mas tecla “Mas”), lo que provoca la aparición de esta ventanita:

Ventana de Añadir Host en ClusterSSH
Ventana de Añadir Host en ClusterSSH

Ahora en dicha ventana solo bastaría poner el nombre del servidor en formato URL o Numero IP para acceder al SSH de dicho equipo, asumiendo que lo tengamos corriendo en el puerto típico que es el TCP numero 22, pero sucede comúnmente y a mi me ha pasado que debido a que lo primero q pensaría un oportuno atacante es husmear en dicho puerto para encontrar un server SSH andando, así que lo que suelo hacer es cambiar el puerto y poner uno distinto al 22, relax muchachos o damas, que tenemos 65536 para elegir, exceptuando los típicamente empleados por otros protocolos nos quedan muchos para decantarnos. En fin si tu caso es este, y pusiste un puerto atipico, se lo pasamos en la linea de la ventana de Add Host, escribiendo por ejemplo:

midominio.rechingon.org:2222

por si queres un usuario particular, a ver veamos con ponerlo así

pasokon@midominio.rechingon.org:2222

y listo, ya especificamos user and port.

Ahora , bien tu reacción podría ser , “pero me pone por las bolas tener que andar especificando User and Port, aparte de tipear todo el dominio”, bueno, si te estabas diciendo justamente esto o alguna frase similar de disgusto, podes realizar configuraciones personalizadas creando tu archivo .csshrc, veamos

$ touch ~/.csshrc

$ mcedit  ~/.csshrc

yo uso mcedit o a veces vim para editar archivos como editores de preferencia, y agregamos algunas lineas como las siguientes:

ignore_host_errors = yes

isp1 = usuario@midominio1.com.ar
isp2 = usuario@miotrodominio.net:4444
empresa1 = otrousuario@empresa1.com.ar:5666
empresa2 = usuario@empresa2.com.ar:221
oficina  = yo@miempresa.com.ar:2201
micluster1 = isp1 isp2
micluster2 = empresa1 empresa2 oficina
clusters = micluster1 isp1 isp2 micluster2 empresa1 empresa2 oficina

Bien, expliquemos un poco lo que hacemos aquí, la primer linea si bien en las ultimas versiones dice que esta en status DEPRECATED, yo a algunos servidores que administro no he podido conectarme si no fuera porque esta alli dicha opción, asi q la mantengo en mi archivo .csshrc. Uds vean como les resulta. De las lineas de 2 a 6  defino mis host asociándolos a etiquetas a gusto y placer del usuario, en el caso del ejemplo identifique los hosts de acuerdo a su funcionalidad “isp1” o a un lugar donde pertenezcan, pero en mi preferencia me gusta identificar los host con sus nombres,  particularmente al instalar un servidor suelo asignarle un nombre de mujer, al menos en mi caso es mas fácil recordarlos :).

En las lineas 7 y 8  referencio dichos los Hosts ya definidos de acuerdo a otra etiqueta, que es básicamente un tag cualquiera con el cual los agrupamos, de esta manera podemos iniciar una serie de sesiones en forma paralela con solo cargar el nombre de dicha agrupación (Consejo: no usen una misma password para gestionar el inicio de sesion en diferentes servidores, seria lo mas fácil, pero por favor no lo hagan no es lo mas recomendable).
Finalmente en la linea 9 se define la sección “clusters” , recordar que debe haber una sola sección “clusters” donde iran todas las etiquetas definidas, tanto de hosts y de agrupaciones de host, es importante incluir esta sección , porque sin ella todo lo definido anteriormente no funcionara.
Por mas configuraciones:

$ man cssh

:-P, se los recomiendo, porque aparte de lo descrito esta herramienta tiene algunas otras  funcionalidades útiles para trabajar con las ventanas de sesión iniciadas.

Casi me olvido, una buena alternativa para evitar  la típica validación contra OpenSSH, es el uso de certificados para realizar la conexión contra los servidores.

Ahora a titulo de simple usuario y critico, esta herramienta me ha servido demasiado a la hora de realizar alguna de las tareas arribas mencionadas, de todas formas algo le debo echar en falta, y es la posibilidad de mantener encriptada o cifrada la informacion relativa a los hosts que administro , el hecho de que este allí en un archivo de texto en mi $HOME no es algo que me tenga muy tranquilo. En fin. Es solo mi opinión.
Salud!

Seguramente mucho de nosotros, usuarios de GNU/Linux, en especial los que estamos hace un tiempo en el mundillo hemos lidiado con el dichoso “lilo” , selector de arranque o boot manager como también suele conocercelos, la idea de este programita es instalarse en el sector de arranque de un disco rígido y desde allí ejecutarse para permitirnos durante tiempo de arranque, y apenas leído el disco rígido de nuestra computadora , seleccionar con que sistema operativo de los que tengamos instalados vamos a iniciar sesión, además entre otras opciones los boot managers normalmente nos permiten refinar mas el tipo de parámetros que queremos pasar al sistema operativo que seleccionamos, tales parámetros como opciones del kernel para nuestro núcleo linux tales como partición de arranque , imagen initrd a usar, módulos a cargar , parámetros de dichos módulos, etc..

Bueno, la cosa es que para los que ya lo conocen, LILO ha sido desde hace tiempo la opción preferida, quizás hoy en día tiene mas alternativas  que años atrás, pero la idea siempre fue brindarnos la opción de elegir con que arrancar. Luego de una instalación típica de un gnu/linux , normalmente no necesitamos configurar nada,  la mayoría de los instaladores lo configuran automáticamente, pero en caso de que ese no sea nuestra situación deberíamos saber que  /etc/lilo.conf es el archivo para modificar su configuración.

Lo típico indica que el usuario común lo instala en su disco rigido y sigue con su vida como si nada, pero hoy yo me enfocare en la posibilidad que tenemos de emplear lilo para iniciar un sistema GNU/Linux que se encuentra espejado mediante RAID 1 por software

He aquí un archivo típico de configuración adaptado para iniciar con disco en modo RAID 1 con un sistema con dos disco IDES espejados, de misma capacidad y marca (Ojo, esto no es necesario en RAID por software en GNU/Linux):

# Support LBA for large hard disks.
#
lba32
# Overrides the default mapping between harddisk names and the BIOS’
# harddisk order. Use with caution.
#disk=/dev/hde
#    bios=0x81
#disk=/dev/sda
#    bios=0x80
# Specifies the boot device.  This is where Lilo installs its boot
# block.  It can be either a partition, or the raw device, in which
# case it installs in the MBR, and will overwrite the current MBR.
#
boot=/dev/md0
# Specifies the device that should be mounted as root. (`/’)
#
root=/dev/md0
raid-extra-boot=/dev/hda,/dev/hdc
# Enable map compaction:
# Tries to merge read requests for adjacent sectors into a single
# read request. This drastically reduces load time and keeps the
# map smaller.  Using `compact’ is especially recommended when
# booting from a floppy disk.  It is disabled here by default
# because it doesn’t always work.
#
# compact
# Installs the specified file as the new boot sector
# You have the choice between: bmp, compat, menu and text
# Look in /boot/ and in lilo.conf(5) manpage for details
#
#install=/boot/boot-menu.b

# Specifies the location of the map file
#
map=/boot/map

# password=tatercounter2000
#
delay=20
timeout=150
# Boot up Linux by default.
#
default=”Linux”

image=/vmlinuz
initrd=/initrd.img
label=”Linux”
append=”apm:on”
read-only
optional

image=/vmlinuz.old
initrd=/initrd.img.old
label=”LinuxViejo”
append=”apm:on”
read-only
optional

#other=/dev/hda3
#    label=Winchows

De este archivo nos interesan las lineas 14,17, 18, comentemos:

Linea 14:

boot=/dev/md0

Indica el dispositivo de inicio (o booteo), es donde lilo se instala, bla bla! RTFM of lilo; el porque es /dev/md0 y no un tipico /dev/hda o /dev/hdd o lo que fuese es que justamente es un dispositivo que se crea al momento de definir los discos raid por software y adjuntarles los disco reales, sean estos IDE o SATA. Normalmente tienen esa notacion , si fue el primer dispositivo raid creado md0, el segundo md1 and so on…

Linea 17:

root=/dev/md0

Aquí se especifica la  particion  definida como raiz del sistema (/)

Linea 18:

raid-extra-boot=/dev/hda,/dev/hdc

Y esta a mi parecer la mas importante, aqui especificamos cuales son los disco que conforman el dispositivo raid, y en los cuales se escribira lilo al momento de ejecutar su arrancable.

Al terminar de realizar las modificaciones en /etc/lilo.conf, bastaria con ejecutar lilo en linea de comandos como root para que se actualize su contenido en el MBR (Master Boot Record), o inicio de la particion elegida.

server:/# lilo

Added Linux *
Added LinuxViejo
The boot record of  /dev/md0  has been updated.
The boot record of  /dev/hda  has been updated.
Warning: /dev/hdc is not on the first disk
The boot record of  /dev/hdc  has been updated.
server:/#

La linea que sale marcada con asterisco indica que es el kernel seleccionado por defecto para iniciar. Como se observa se actualiza el registro de inicio tanto en el dispositivo RAID md0 como también en cada una de las particiones que lo conforman.

Listo, eso es todo , ya deberíamos tener nuestro sistema listo para que arranquemos con ambos discos o con solo uno de ellos. Se puede probar iniciando y observando como inicia con cualquiera de los disco que arranquen.
Espero haya sido de utilidad este poseo, apropos, casi me olvidaba, al principio mencione alternativas a lilo, una de ellas , y bastante extendida en cualquier instalador actual es GRUB, con muchas mas opciones y bondades que LILO, y también con opción de configurarse para iniciar en modo RAID, pero eso lo veremos en otro post.