Tag Archives: administración de sistemas

Programación para Administradores de Sistemas

Cuando estuve estudiando el título de Administración de Sistemas Informáticos es cuando me acerqué a los lenguajes de scripting (por el año 2002), y fue cuando comencé a aprender lenguajes como PHP, Python, Ruby y Perl.

El lenguaje Perl me llamó la atención, sobre el resto, porque había sido un lenguaje creado por Larry Wall, un administrador de sistemas… ¡en un mes!, supongo que lo que creó fue la parte más básica del sistema, pero al mismo tiempo la más importante, ya que, como él mismo comenta, Perl fue la simplificación del uso de herramientas como awk, sed, shell script y C.

En la mayoría de trabajos que he tenido, después de eso, cuando un administrador de sistemas desarrollaba algún proyecto, alguna aplicación o decía que programaba, lo hacía en Perl. No en vano, ha sido considerado por muchas distribuciones, empresas y comunidades, como el lenguaje de facto para las actividades típicas de administración de sistemas, entre las que se encuentran tareas tan vitales como: la instalación del sistema, asistentes de configuración, pasarelas intermedias (como amavis)…

Uno de los grandes miedos de la gente que programa en este lenguaje, es la mítica frase de que Perl es un lenguaje write-only, es decir, de los que se usan solo para escribir código que no hace falta mantener (o de usar y tirar), aunque proyectos grandes y la comunidad en sí manteniendo y ampliando el lenguaje, han demostrado que Perl es un gran lenguaje de programación en el que se pueden desarrollar grandes cosas y darles mantenimiento sin problema ni riesgo.

Programming Perl (3rd Edition)
Larry Wall, Tom Christiansen, Jon Orwant; O'Reilly Media, Inc. 2000

El libro que aconsejo para adentrarse en el mundo de Perl es el que escribió su creador, Larry Wall, aunque a partir de su tercera edición, que está acompañada de mucho más contenido aportado por autores como Tom Christiansen, uno de los primeros que se sumó al mundo y comunidad de Perl; y Jon Orwant, el editor de The Perl Journal, cuya publicación cesó hace ya algunos años.

El libro es algo extenso y asusta al primer vistazo, no en vano son 1070 páginas. Pero una vez se ha abierto y visto el índice, se entiende su extensión y deja de asustar. Realmente, el libro se parte en cinco apartados bien diferenciados:

  • Introducción… bueno, esta la podemos leer a modo informativo, o podemos obviarla. Son unas 50 páginas.
  • Los detalles desagradables… un título un poco extraño, pero se entiende, porque son los detalles del lenguaje en sí, lo que permite, lo que se puede hacer con él, la sintaxis, los elementos… todo. Es la parte más importante del libro, en mi parecer. Unas 350 páginas, más o menos.
  • Perl como Tecnología, nos adentra en lo que hace el intérprete internamente, cómo se puede optimizar su uso, el depurador, los hilos, interfaz con C… sería la parte avanzada del lenguaje. Unas 150 páginas.
  • La Cultura de Perl, es el uso de CPAN, el administrador de paquetes, prácticas comunes, seguridad, haciendo Perl portable entre plataformas, documentación, etc. Un poco de Perl en la comunidad y cómo compartir código en la forma en la que lo hacen muchos. Unas 100 páginas.
  • Material de Referencia… como no podía faltar, toda la referencia de los paquetes básicos de las librerías que trae consigo Perl. Esta quizás es la parte más extensa del libro, pero la que más se puede emplear en el día a día, realmente.

Una lectura muy recomendable para todos aquellos que quieren adentrarse en la programación de Perl de una forma más íntima, conociendo la comunidad, cómo compartir código, cómo aprovechar el código que ya está disponible para Perl y las mejores prácticas de programación en este lenguaje.

La importancia de la actualización

Desde hace años, me vengo encontrando con sistemas instalados que hay que mantener o sobre los que hay que desarrollar, que son instalaciones de hace 5 ó 7 años. Estas instalaciones suelen ser máquinas con RedHat 9, RedHat EL 2, 3 ó 4, o Fedora Core 2 ó 3. En esos años RedHat estaba muy metido en el entorno empresarial y Fedora Core fue una respuesta libre (totalmente) a la desaparición de RedHat Desktop.

El caso es que la empresa y la comunidad que soportan ambas distribuciones (incluso distros comos OpenSuSE o SuSE, Mandriva y otras similares) les pasa que desarrollan versiones de forma bastante rápida (una o dos al año), con lo que, pasando 5 años, pueden haber salido unas 10 versiones posteriores del producto.

Esto genera problemas, sobre todo para la comunidad y la empresa que las mantiene, que deben de ir cerrando soporte de las antiguas, porque sino sería un caos el mantenimiento de 10 distros con versiones distintas de los códigos que se incluyen. A día de hoy, RedHat no suele mantener nada más que dos versiones, al última y su anterior, y Fedora Core, como mucho, da soporte a las 3 ó 4 últimas, con lo que, yendo actualmente por la versión 12, es lógico que el soporte a la versión 2 y 3 ha expirado hace bastante tiempo.

¿Qué pasa si hemos instalado un servidor web con estas distribuciones y queremos mantenerlo para nuestro correo, página web y otros menesteres?, pues que sino actualizamos, llegará el momento en el que haya vulnerabilidades en el código de nuestro servidor de correo, nuestro servidor web, o que queramos simplemente actualizar la versión del CMS que estamos usando y necesite una versión superior de Python, PHP o Ruby, o no tengamos forma de instalarla, a menos que vayamos tirando de compilación.

En Debian también pasa algo parecido. El ritmo de liberación de las distribuciones es más lento, con lo que da un tiempo mayor de permanencia de una distribución a su siguiente liberación. Pero el cambio es mucho mayor en este sentido, puesto que las versiones, cuando se cambian, son saltos bastante grandes y requiere de un mayor esfuerzo de adaptación.

¿Qué hacer?, básicamente, ir actualizando y mantenerse al tanto de cuando sale la siguiente liberación de la distribución que estamos usando y, sobretodo, planificar tiempos cada 5 ó 6 meses, para actualizar las distribuciones a sus versiones superiores, ya que así estaremos más protegidos de posibles vulnerabilidades.

Tener presente que si el cambio no se realiza, puntualmente, antes de que el soporte oficial a la distro que tenemos instalada expire, nos veremos en la situación de tener un sistema con agujeros de seguridad, que es propenso a fallos y sobre el que, cada día que pase, será más complicado instalar software nuevo.

La Regla de los Nueves

Esto es algo que aprendí, ahora hace ya unos 5 años, cuando comencé a instalar mi primer servicio de alta disponibilidad.

En un artículo sobre el tema, la alta disponibilidad, se decía que la disponibilidad de un servicio, servido únicamente por una máquina, normalmente es de un 90%, con lo que, a lo largo de un año (365 días) el servicio se ha mantenido en funcionamiento un máximo del 90%, aproximadamente, y ha tenido un tiempo de inactividad del 10% (más o menos unos 36 días).

Con sistemas de alta disponibilidad, es decir, teniendo más de una máquina siriviendo un servicio, la proporción se incrementa, pero siempre a razón de nueves. Es decir, con dos máquinas, tenemos una disponibilidad del 99%, con tres máquinas tenemos un 99,9%, con cuatro un 99,99% y así sucesivamente.

Como nota curiosa, hace poco leí que los sistemas desarrollados sobre Erlang/OTP tienen una alta disponibilidad de nueve nueves (99,9999999%), lo cual me parece algo increíble, pero totalmente cierto, ya que he probado la infraestructura y realmente es muy estable.

Debootstrap: probar sin ensuciar

Desde hace tiempo, llevo usando esta herramienta para generar jaulas de modo que pueda probar nuevos sistemas, servidores y/o configuraciones, sin necesidad de desconfigurar mi sistema actual.

El sistema se basa en tener una copia exacta y nueva de un sistema operativo basado en Debian GNU/Linux, que se instala en un directorio específico de nuestro árbol de directorios. El comando que genera la jaula, que tiene el nombre de debootstrap, se encarga de realizar la instalación del sistema a partir del directorio solicitado y con las fuentes solicitadas, es decir, si queremos instalar un woody, sarge, etch, lenny… o un gutsy, hardy, ibex… pues solo tenemos que indicarlo, con la URL de donde conseguir los paquetes y listo.

Por ejemplo, instalar en nuestro directorio /home/usuario/lenny una distribución lenny de Debian, sería hacer lo siguiente:

# debootstrap lenny /home/usuario/lenny http://ftp.rediris.es/debian

Esto tardará unos minutos hasta realizar la instalación completa, ya que se tiene que descargar los paquetes de internet, pero en el momento de finalizar, tendremos un sistema básico de lenny instalado en la ruta indicada.

Para poder usarlo, solo tendremos que hacer lo siguiente:

# mount -t proc proc /home/usuario/lenny/proc
# chroot /home/usuario/lenny

El hecho de montar el directorio proc es para poder tener acceso, desde la jaula, al kernel y poder lanzar servidores como apache, proftpd, postfix o similares.

Una vez dentro, podremos realizar las instalaciones y configuraciones que queramos realizar sin miedo de estar estropeando nuestra configuración normal.

PostgreSQL: configuración de acceso

Esto es algo que siempre me toca buscar en Internet, puesto que es algo que hago una vez cada tantos meses, y siempre se me olvida de cómo empezar, así que, para tener la chuleta a mano, he decidido escribir esta entrada que, además de servirme ahora, seguro que me servirá en el futuro para cuando configure más servidores de este tipo.

Aquí os dejo el enlace: PostgreSQL: Instalación, Configuración y Trucos.

SQL Server vía ODBC en Debian Etch

Casi a punto de asistir a la liberación de lenny (la versión 5.0 de Debian), seguimos viendo que con etch, aún, tenemos lo suficiente para tirar perfectamente, y sin agregar paquetes de backport.

En este caso, voy a explicar como instalar y usar SQL Server vía ODBC desde cualquier aplicación en GNU/Linux, como pueden ser programas Java, Perl, PHP, Ruby…

En principio, vamos a tirar de apt-get para instalar algunos programas:

apt-get install tdsodbc unixodbc libct3 libltdl3 odbcinst1debian1

Lo siguiente es crear el fichero /etc/odbcinst.ini, que debe de contener lo siguiente:

[FreeTDS]
Description     = TDS driver (Sybase/MS SQL)
Driver          = /usr/lib/odbc/libtdsodbc.so
Setup           = /usr/lib/odbc/libtdsS.so
CPTimeout       =
CPReuse         =

Ahora, para cada base de datos a la que queramos conectarnos, habrá que agregar un bloque de este tipo en el fichero /etc/odbc.ini:

[contactos]
Driver      = FreeTDS
Server      = 192.168.1.5
Database    = contactos
TDS_Version = 8.0
Port        = 1433

El nombre de la conexión es el que se situa entre los corchetes, y el que se usará para referenciar a esa conexión.

Para comprobar, podemos ejecutar el comando isql con los siguientes parámetros:

isql contactos usuario clave

Con esto, desde interfaces como DBI (Perl y Ruby), podemos usar DSN del tipo DBI:ODBC:contactos para acceder a esta conexión, siempre pensando que el usuario y la clave debe de insertarse en el comando de conexión.

Asterisk: Configuración de Zapata

Este artículo ha pasado a formar parte de bosqueviejo.org, puede verlo en sus formatos html y pdf.

Software empaquetado y listo para usar

Los paquetes son una forma de distribuir software compilado para una arquitectura concreta. En Windows se distribuyen en comprimidos autoejecutables que autoconfiguran el entorno y en GNU/Linux también, pero de forma más controlada.

Los paquetes de GNU/Linux tienen que cumplir la especificación de ordenación de ficheros que establece la distribución en concreto donde se va a instalar la aplicación, así pues, nos encontramos a este respecto con dos grandes variantes: RPM y DEB.

Los RPM, obra de RedHat, son paquetes que se guardan comprimidos y contienen una serie de scripts para la instalación, actualización, eliminación y otras actividades similares. Además de esto, los paquetes contienen información de dependencia, es decir, que antes de instalarse en el sistema, deben de estar instalados otros paquetes para que el binario que contiene el paquete funcione correctamente. Es su garantía de funcionalidad y lo que lo diferencia de los paquetes binarios que se generan para Windows.

Los DEB son paquetes obra de Debian, que tienen las mismas características que los RPM, pero agregando algunas características más como sugerencias y recomendaciones. Las sugerencias son paquetes similares o que pueden trabajar en conjunto con el que se va a instalar. Las recomendaciones son paquetes que añaden funcionalidades al paquete que se está instalando, como por ejemplo la internacionalización, algún plugin, o algo por el estilo.

El uso de los paquetes RPM se lleva a cabo por el programa rpm, el cual es instalable en cualquier distribución (incluso Debian) y permite manipular los paquetes de tipo RPM para su instalación, listado e incluso creación. En los paquetes DEB tenemos dpkg, el cual se usa de forma idéntica a rpm (en concepto).

La facilidad de estos paquetes no es en sí la encapsulación, puesto que agregan muy pocas características en comparación con los famosos InstallShield de Windows y otros similares. La gran ventaja de estos sistemas son los repositorios. Un repositorio es un sitio accesible por HTTP, FTP o similar que permite la descarga de un paquete RPM y/o DEB para su instalación en el sistema.

Cada distribución ha ido creando su herramienta específica y podemos ver, entre otras, para RPM en Fedora yum, en SuSE es yast, en Mandriva es urpmi e incluso en todas las distribuciones basadas en RPM, se puede usar apt; para DEB tan solo tenemos apt. No obstante, hay otras distribuciones como Slackware y Gentoo, que no usan paquetes ni RPM ni DEB, los cuales también tienen herramientas para descarga de sus paquetes específicos desde Internet.

La configuración de APT la podemos ver en detalle en el siguiente enlace.

La configuración de YUM la podemos ver en detalle en el siguiente enlace.

La configuración de URPMI la podemos ver en el siguiente enlace.