actualización

  • Esta semana fue liberada la RELEASE versión 12.0 de FreeBSD, con lo cual procedí a actualizar mi estación de trabajo y alguno de nuestros servidores. Este artículo documenta el procedimiento de migración desde la versión 11.2-RELEASE. Procedimiento similar a cada una de las actualizaciones anteriores.

    Entre las mejoras incluidas en esta versión se destacan:

    • Se actualizó OpenSSL a la versión 1.1.1a (LTS); Unbound a la versión 1.8.1; y OpenSSH a 7.8p1.
    • Se actualizaron Clang, LLVM, LLD, LLDB, compiler-rt y libc++ a la versión 6.0.1.
    • Se actualizó el controlador de terminales virtuales vt con varias mejoras de rendimiento.
    • Se agregó el controlador netdump, el cual permite transmitir crash dumps a un host remoto luego de un system panic.
    • Mejoras en el soporte gráfico para el hardware contemporáneo.
    • El firewall pf ahora se puede utilizar dentro de un jail utilizando vnet.
    • Y se ha actualizado KDE a la versión... (sonido de redoblantes) 5.12.5!!! Es un gran salto desde la versión (actualmente instalada) 4.14.38.
    • Además se modificaron muchas configuraciones por defecto y actualizaron aplicaciones de nivel usuario con el objetivo de mejorar la seguridad e incorporar nuevas funcionalidades. Revisar el detalle completo en las release notes.
  • La semana pasada, más precisamente el 13 de agosto, fue liberada la versión estable más reciente de FreeBSD: 10.2-RELEASE. En este breve artículo se explica paso a paso el proceso de actualización desde una versión anterior.

  • Hoy recibí por correo 8 anuncios de seguridad de Moodle, incluyendo 3 vulnerabilidades graves, por ende llegó el momento de planificar una actualización urgente.

    Este artículo describe paso a paso cómo actualizar, casi totalmente desde línea de comandos y siguiendo la documentación oficial, un sitio Moodle instalado mediante una copia con git.

  • El día de ayer me enteré, gracias a la lista de correo de seguridad de Arch Linux, de una vulnerabilidad severa en Grafana para las versiones previas a 5.3.2. Por ende procedí a actualizar mi instalación de Grafana.

    Este artículo podría haberse titulado "Cómo actualizar Grafana en Debian".

  • Hoy liberé un nuevo script Bash, llamado "checkmyfarm", para dar soporte a mi sistema de actualización de servidores en paralelo. Este script tiene el propósito de enviar un único mail incluyendo el resumen de actualizaciones disponibles en todos los servidores de la granja, y reemplaza al viejo verificar_actualizaciones.sh (el cual corría individualmente en cada servidor). De esta forma, en lugar de recibir un mail por cada servidor, recibo un único mail con el resumen de actualizaciones disponibles en todos los servidores de mi granja.

  • Es más largo el título que el artículo y el procedimiento.

  • En este artículo voy a explicar cómo actualizar Slackware, la más antigua (no confundir con vieja) distribución GNU/Linux con vida, utilizando como ejemplo la versión 13.1

    En Slackware existe la herramienta automatizada slackpkg para manejar los paquetes. Slackpkg es una herramienta para instalar o actualizar paquetes de forma sencilla a través de Internet. Es posible tener una instalación mínima de Slackware e instalar/actualizar los paquetes necesarios.

  • Esta semana me tomé el tiempo de actualizar mi Slackware 14.1 a la última versión estable: 14.2.

    Este sistema operativo fue instalado y está funcionando desde febrero de 2014 (cuando adquirí mi portátil):

    09:15 root@vaio emi # mount | grep " / "
    /dev/sda5 on / type ext4 (rw)
    09:15 root@vaio emi # tune2fs -l /dev/sda5 | grep created
    Filesystem created:       Fri Feb  7 15:47:35 2014
    

    En este artículo voy a demostrar el procedimiento de actualización (upgrade) de Slackware a la versión 14.2, y compartir mi (exitosa) experiencia.

  • SSH es una herramienta para loguearse en un sistema remoto y ejecutar comandos. Provee un mecanismo de comunicación seguro encriptado entre dos hosts sobre una red insegura. SSH se conecta y se loguea en el sistema remoto indicado y el usuario debe probar su identidad utilizando alguno de los métodos de autenticación disponibles dependiendo de la versión del protocolo utilizada (por ejemplo usuario y contraseña, clave pública mediante certificados, basado en hosts, challenge-response). Generalmente utilizamos SSH para iniciar una sesión en un sistema remoto, pero lo que muchos puede que no sepan es que SSH no sólo sirve para iniciar una sesión remota, sino que también tiene la posibilidad de simplemente ejecutar un comando en el sistema remoto y retornar su salida, en lugar de abrir una shell.

  • En este artículo voy a explicar cómo actualizar desde KDE 4 a Plasma 5 en FreeBSD 12 de forma simple, fácil y sin dolores de cabeza.

  • En 2016 puse mi primer servidor OpenBSD en producción, en la versión 5.9, y el día de hoy llegó el momento de actualizarlo a la versión 6.0. Este artículo explica el procedimiento paso a paso (con mucho mayor detalle que la FAQ oficial).

  • Por razones de compatibilidad, sobretodo cuando instalamos paquetes por fuera del manejador yum (por ejemplo al compilar e instalar un paquete que no está en los repositorios a partir del código fuente), necesitamos que alguna librería o paquete requerido no sea actualizado a una versión más actual.

  • Esta serie de artículos está dedicada a compartir los principios básicos que todo SysAdmin debe respetar, practicar y predicar entre sus pares. Estos principios los he tomado (y orgullosamente puedo decir que he respetado casi en su totalidad) del artículo General SysAdmin Principles & Guidelines publicado por el Dr. Joe Chung.

  • En el artículo Sysadmin vago: cómo actualizar todos los servidores de tu organización ejecutando un único comando expliqué de qué forma es posible lanzar actualizaciones de múltiples servidores GNU/Linux (Debian y CentOS) desde un simple script Bash, utilizando un servidor de administración centralizado y SSH con autenticación con clave pública.

    La limitación de este esquema era que trabajaba de forma secuencial, es decir, se actualizaba de a un sistema por vez. Por lo tanto en este artículo voy a demostrar cómo he mejorado mi script para lanzar todas las actualizaciones en paralelo (so pena de saturar un poco el enlace y/o Web proxy) sin necesariamente perder el control del proceso.

  • En el artículo Jails en FreeBSD presenté un esquema de jails a partir del cual sería posible actualizar el sistema base de todos los Jails en una única operación. Este se basaba en separar el filesystem de los jails en dos partes: una compartida de sólo lectura (sistema base) y otra privada de lectura/escritura (configuraciones, paquetes y directorios de trabajo). En este artículo voy a detallar el proceso de upgrade de un host con múltiples jails.

  • Pasaron dos releases desde que actualicé mi servidor OpenBSD por última vez, por lo que ya es hora de actualizarlo nuevamente. He aquí la experiencia migrando dos releases de manera consecutiva.

  • Finalmente llegó el día de actualizar un viejo servidor Ubuntu Server 10.04 Lucid, el cual estaba prestando servicios Web de forma ininterrumpida desde 2011. Al ser hijo de Debian, es una tarea generalmente muy sencilla y sin grandes dolores de cabeza.

    Como muchos administradores de sistemas sabrán, en abril de 2015 finaliza el soporte para las versiones Ubuntu Server 10.04.* LTS. Por lo tanto es hora de migrar a 12.04 LTS ("Precise"), y por qué no luego a 14.04 LTS ("Trusty"). Siempre que sea posible, por cuestiones de compatibilidad, claro está.

  • Este artículo explica cómo lograr que las últimas versiones de paquetes liberadas estén disponibles para actualizar en nuestro sistema FreeBSD. La idea es disponer de lo último de lo último (en cuanto a versiones de paquetes se refiere) lo antes posible, para que nuestro sistema quede siempre en un estado bleeding edge.

  • Los sysadmins GNU/Linux amamos todas las herramientas que automaticen tareas y simplifiquen la administración de los servidores. Este artículo presenta un script que he desarrollado para verificar a diario las actualizaciones de paquetes disponibles en los repositorios y enviar un mail con el resumen.

  • Un problema que tenemos muchos administradores de sistemas GNU/Linux es cómo ejecutar tareas de mantenimiento de forma eficiente sobre muchos servidores al mismo tiempo. Desde el momento en que nuestra organización pasa a tener varias decenas de servidores, ejecutar operaciones de mantenimiento simples, como por ejemplo actualizar el sistema, pasan a ser tareas tediosas que consumen tiempo y recursos humanos.

    Claro que muchas de las tareas de mantenimiento de un sistema operativo se pueden automatizar utilizando scripts y tareas programadas. Sin embargo algunas requieren intervención humana: un claro ejemplo es actualizar el sistema. No se puede actualizar el sistema a ciegas y esperar que todo funcione. Muchas actualizaciones requieren reinicio de servicios o nuevas versiones de archivos de configuración. Sin contar con los conflictos producidos por aplicaciones a medida atadas a versiones específicas de paquetes. Por ello el administrador de sistemas debe examinar lo que cada gestor de paquetes ofrece actualizar, para evaluar si se debe proceder o se requiere alguna clase de intervención manual. Además el administrador de sistemas tiene en cuenta si una actualización requiere reiniciar servicios (lo que tal vez requiera posponer la actualización de un servidor para no afectar la operatoria de la organización) y durante la actualización debe actuar ante incompatibilidades producto de nuevas versiones de archivos de configuración.

    Pero, a pesar de estas limitaciones, es posible automatizar el proceso de autenticación en cada sistema remoto. Utilizando un usuario con autenticación SSH con clave pública y capacidad de actualización del sistema, se evita que el administrador deba abrir decenas de sesiones SSH remotas para lanzar las actualizaciones. De esta forma se agiliza el proceso, sin perder control sobre el mismo (como veremos).

    En este artículo voy a explicar detalladamente cómo, utilizando un servidor de administración centralizado, elaborar una arquitectura de autenticación que permita lanzar actualizaciones de múltiples servidores remotos desde un simple script Bash.