Recientemente, empezé a preocuparme más por la seguridad de los sistemas ya que, me he dado cuenta de que en general internet es un lugar bastante hostil. Debido hace poco a la vulnerabilidad Ghost, me preocupe por el estado del sistema cuando se trata con bugs aún no descubiertos por lo que una cosa prudente en un servidor abierto a internet es configurar la seguridad preventiva.

Ahora bien, Debian tiene muchas herramientas de seguridad que se pueden instalar facilmente desde los repostiorios oficiales como Selinux o Apparmor, pero si se quiere algunas cosas no tan oficiales pues es un poco dificil encontrarlas. En este caso yo estaba buscando instalar el Kernel Gr-Security en Debian

Gr-security y Pax son una serie de parches al kernel linux que protegen contra posibles vulnerabilidades en el kernel y que además brindan un sistema parecido a Selinux o Apparmor. Lo mas interesante del kernel grsecurity es que protege contra los desbordamientos de memoria, que de vez en cuando se encuentran en el kernel. Así protege que cada uno de los programas no se "salten" a donde no deben, debido a bugs en el código. Lo mejor es que esto es implementado sólo con el hecho de correr el kernel Gr-security, que además es compatible "out of the box" con casi todas aplicaciones. Digo casi todas por que en realidad Gr-security interfiere con la capacidad del kernel de usar Apparmor, por lo que si usamos Appramor para securizar Debian, es mejor pensar antes de instalar dicho kernel. Lo positivo es que Gr-security posee su propia implementación de RBAC, parecida a Apparmor y fácil de usar, por lo que en realidad no se pierde y se gana mucho al instalar este kernel. Ahora bien, siempre cabe la posibilidad de que algunas cosas fallen debido a la implementación del kernel, sobretodo si son programas que implementan funciones en las cosas que modifica Gr-security, por lo que si se está corriendo cosas como Docker o linux containers, hay que tener cuidado antes de implementar dicho kernel. Yo no uso ninguna de estas dos tecnologías en los servidores con Gr-security, al menos por ahora, por lo que no sé si son afectadas por los parches Gr-security, pero aconsejo precaución. En cualquier otro caso Gr-security será una capa más en la cebolla de la seguridad.

Hay dos formas de instalar el kernel Gr-security, la primera es bajar el kernel vanilla, parcharlo con los parches disponibles en: http://grsecurity.net/ o en Debian https://packages.debian.org/wheezy/linux-patch-grsecurity2. Ahora parchar y compilar un kernel no es algo que se puede explicar en un artículo tan corto. Pero este procedimiento no es tan complicado, tiene sus ventajas y desventajas:

Desventajas:

1. El uso del CPU durante la compilación es mucho, por lo que no es viable compilar el kernel en un servidor en producción. Esto se puede resolver compilando el kernel en una maquina de escritorio o similar y después subiéndolo aunque se cae en el riesgo de caer en incompatibildades.
2. Podría haber problemas de incompatibildad en los drivers del nuevo kernel y el antiguo, sobretodo si se está compilando una version diferente.
3. Es dificil saber que drivers incluir, la mayoría de los kernels incluyen todos los drivers como módulos cargables, por lo que copiando la configuración por defecto debería de funcionar, pero requiere de cierta experiencia.
4. Si aparece una vulnerabilidad grave en el kernel y es neceario cambiarlo, habrá que hacer todo el proceso de nuevo, por lo que es más comodo usar un repositorio.

Ventajas:

1. Se puede compilar el kernel sin módulos por seguridad, aunque esto requiere de experiencia y saber para que sirve cada uno, ya que es fácil romper cosas. Por ejemplo se puede deshabilitar el soporte ipv6, cuando no se use.

Lo más facil somo se vió es usar paquetes precompilados puestos a nuestra disposición por el proyecto Mempo, a traves de sus repositorios.

se puede usar paxtest para probar la protección del kernel, este en Debian solo esta disponible para i386, yo sólo para probar baje el paquete 64 bit de arch linux, lo descomprimí ya que es solo un script en bash y ejecutables compilaodos en c e instale manualmente los ficheros, usando cp , este seguramente no es muy buen método, pero me fue imposible construir el paquete Debian de paxtest, creo que es por esto que no hay versión 64 bits de este. Una vez "instalado" paxtest podemos hacer las pruebas de protección del kernel.

Hay que tener mucho cuidado con el logueo del kernel gr-security ya que como viene instalado loguea todos los eventos del sistema, abarrotando rapidamente la partición de log del sistema. Esta opción es configurable.

http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options

Notas:

No se porque el repo de Mempo esta abajo desde hace un buen rato, por lo que no se si el proyecto continua con vida. Antes se encontraban en essta web. http://deb.mempo.org/

Aún se puede encontrar una página aquí:

https://rawgit.com/mempo/mempo-websites/master/mempo-main/html/index.html

Aquí se encuentra la web el proyecto, peor su principal dirección esta caida junto con sus repos. Ahí informa que tiene repos en freenet para evitar este tipo de cosas, pero no me puesto a investigar si realmente sirven. Parece ser que su dominio venció o algo por el estilo pero los repos ya no funcionan.

Se pueden encontrar builds del kernel gr-security aquí:

http://molly.corsac.net/~corsac/debian/kernel-grsec/packages/

Espero que el proyecto Mempo no haya muerto y no pase de un nombre de dominio caducado. Entre al IRC y no obtuve respuesta respecto a esto, pero al menos había gente. Si alguién leyendo esto sabe del estado del proyecto, peude dejar un comentario.

Mas info: https://wiki.debian.org/grsecurity

Después del año 2000 el Internet pasó de ser un espacio descentralizado utilizado por pocas personas, a ser difundido de manera mundial y usado para múltiples propósitos con una centralización creciente y pocas empresas concentrando gran parte de las visitas de Internet. Va en aumento el número de horas que pasamos en Internet, cada vez se vuelve una parte importante de nuestra vida.

Facebook .

En el 2004 Marck Zuckerbeg lanzó Facebook, en sus inicio una red social privada para estudiantes de Harvard pero que se abrió a todo el mundo en el 2006. Este pronto llegó a nuestro país, y es ahora una de los sitios con mayor número de usuarios.

En pocos años Facebook se constituye en una empresa multimillonaria y que concentra gran parte de la información confidencial de los usuarios. No fue la primer Red Social, pero es ahora una de las mas grandes. Facebook se ha vuelto parte de la vida diaria.

Twitter.

Fue creado en 2006 por Jack Dorsey como una red social de rápida interacción bajo el concepto de microblogging, limitando la información enviada por el usuario en un tweet a 140 caracteres, y varias fotos o un video. Es ahora una de las plataformas de comunicación mas usadas mundialmente.

Estas dos empresas ambas con sede en Estados Unidos hoy concentran gran parte del tráfico de internet y han adquirido tal importancia que muchas de las campañas de marketing de empresas, partidos políticos, individuos e instituciones se hacen a través de estas redes. Es importante destacar que estas redes también han potenciado varios movimientos sociales como los de la primavera árabe o el movimiento 132 en México, por lo que sus usos no se ven limitados al marketing o interacción social diaria.

Redes sociales descentralizadas.

El problema está en que gran parte de los datos personales de los usuarios es controlada por una empresa y depende de la utilización que esta pueda hacer de ellos. Para ser precisos si se tiene un perfil en Facebook los datos van a a dar al centro de datos en Palo Alto California, donde están sujetos a las leyes y jurisdicción estadounidenses. Edward Snowden desaconseja el uso de estas redes sociales debido a los problemas de privacidad seguridad y vigilancia que estas implican. Otro problema se encuentra en la censura y control de la información propiciadas por la política de uso que las empresas imponen a estas redes sociales.

Como respuesta a esto han surgido varias iniciativas para combatir la centralización de datos, se han creado una serie de redes sociales alternativas, que aspiran a ser descentralizadas y hechas con software libre, de igual manera que el correo electrónico. De esta manera mediante el uso de un protocolo común todos los usuarios podrán tener su información en el servidor que ellos elijan, en el cual confíen o inclusive tener su información en una computadora-servidor en su propia casa. Esta es la idea detrás de iniciativas como Gnu/Social y Diaspora. Redes sociales descentralizadas que buscan combatir los problemas generados por las redes sociales centralizadas.

La ventaja sobre de la descentralización sobre la centralización, es sobretodo que cada una de estas plataformas forman una red de servidores, los cuales no son susceptibles de apropiación empresarial o de explotabilidad de los datos personales de los usuarios con fines de mercado o de investigación, otorgando un mayor control y privacidad al usuario sobre sus datos. También la estructura misma de las redes las hace poco propensas a la censura o caídas del sistema, ya que aunque los nodos en particular pueden caer, es poco probable que toda la red caiga.

Otro concepto clave de estas redes es que son de código libre, por lo que su código es revisado en busca de agujeros de seguridad para saber que hace el código con los datos del usuario, además de ser modificable por los usuarios con conocimientos pertinentes. Entre las principales redes sociales alternativas se encuentran:

Diaspora es una iniciativa creada por varios estudiantes del New York University's Courant Institute of Mathematical Sciences , aunque pronto pasó a ser desarrollada por su comunidad de usuarios. Se despliega a través de pods es decir servidores autónomos en los que los usuarios pueden registrarse y comunicarse con toda la red Diaspora u otras redes sociales. Actualmente se puede encontrar la lista de pods con espacio disponible aquí. Otra alternativa a Diaspora es Friendica que se haya en un estado de desarrollo más avanzado, con una lista de pods disponibles aqui.

También existe la posibilidad de poner tu propio pod. Hay que destacar que estas dos redes sociales, son de código totalmente libre, lo que permite a los usuarios instalarlas en su propia computadora y modificarlas a gusto.

Otras redes sociales descentralizadas, son Gnu/Social y Pump.io. Gnu/social está auspiciada por la Free Sfotware Foundation en Estados Unidos, y puede adquirir diversas formas. Se puede formar una plataforma parecida a Facebook, o puede adoptar la forma de una plataforma de microblogging parecida a twitter, llamada Quitter.

Es de destacar también el objetivo no lucrativo de estas redes sociales, ya que por lo general los pods no están implementados por empresas sino por fundaciones o colectivos de hackers. EL objetivo último de estas redes sociales, no es encerrar a los usuarios en sitios particulares, sino que se está trabajando en un protocolo de comunicación común, para que el usuario pueda comunicarse con otros usuarios en otros pods o en otras redes (Un usuario de Diaspora se comunique con un usuario de Friendica y de Gnu/social), todo esto para evitar el encierro o la dependencia tecnológica en una organización o empresa y aumentado las ventajas de la descentralización. Esto ya es viable en varias de estas redes sociales, permitiendo comunicarse incluso con un perfil de Facebook o Twitter. En un futuro se está pensando la implementación de herramientas de encriptación como GPG, ya usada ampliamente en el correo electrónico para garantizar la privacidad de las comunicaciones.

Hasta ahora, el número de usuarios de estas redes es limitado, pero con el Internet volviéndose un lugar cada vez más hostil para la privacidad, es importante pensar en estas redes como alternativa, y tener mucho cuidado con los datos personales dejados en la web.

Anteyer, en la lista de seguridad de Debian se anunció el fin del soporte de seguridad para chromium, ya que es imposible construir las nuevas versiones de chromium, con los compiladores disponibles en Debian Wheezy. Esto es indicador de varias cosas, en primer lugar: Wheezy se empieza a quedar viejo, se aproxima el fin de su ciclo de vida. En segundo lugar google publica nuevas versiones de chromium demasiado pronto sin preocuparse por la compatibilidad reversa.

Para los usuarios que usan chromium, se recomienda dejar de usarlo y preferir un navegador como iceweasel, que aún tiene soporte de seguridad. Si es posible, desintalarlo del todo del sistema. Ahora bien, ¿Qué tan peligroso puede ser seguir usando chromium?, la verdad no mucho, al menos por ahora, sin embargo aunque a nivel personal no implique mucho riesgo, si puede implicarlo en una organización con miles de computadoras corriendo chromium.

Inmediatamente algunos voluntarios están proponiendo soluciones para ver si es posible paliar esto.

Todo esto me lleva a una reflexión más sobre los modelos de seguridad de cada uno de los sistemas operativos, y que es lo que esto implica.

Hace poco acabo de instalar mi primer sistema Openbsd, en una maquina vitual, me impresiono la política de distribución que tienen para su sistema. Sacan una nueva versión cada seis meses y sólo le dan soporte de seguridad a las dos últimas versiones, lo que significa que el soporte dura cuando mucho un año. Un año!!!!!, y en el mundo Gnu/linux nos quejamos cuando una distribución dura 6 meses, como sería el caso de Fedora, mas o menos.

Pero la pregunta es ¿Por que Theo De Raadt y el equipo de OpenBSD decidió esta política de funcionamiento? Según las palabras de la página de OpenBSD, pues simplemente por que ellos no creen en la compatibilidad binaria reversa. Como un sistema BSD más parecido a UNIX, se instala todo desde repositorios oficiales o de plano se compila usando el sistema de ports. Los paquetes viejos y no mantenidos salen de la distribución, asi como el código fuente defectuoso y no compilable. Esto desde luego crea un entorno por si mismo hostil hacia el código fuente mal escrito y no mantenido que refuerza la seguridad total del sistema. La consecuencia secundaria es obvia: fuera aplicaciones viejas de Openbsd, olvidate de usar programas precompilados viejos, con vulnerabilidades de seguridad y otras cosas peores. Obviamente el software instalable se restringe a software con código fuente libre y con licencia compatible BSD, lo que vuelve auditable el sistema entero.

Como comparación tenemos distribuciones LTS como Debian que implementan unas aplicaciones estables, parches de seguridad, además de un cómodo repositorio backports, donde se encuentran las aplicaciones nuevas. Es posible hacer funcionar a veces los programas de anteriores versiones de Debian o incluso de Ubuntu. Además de que el soporte extendido permite que estas distribuciones sean usadas para servidores y entornos mas estables, ya que no hay que estar cambiando tan seguido.

Pero la cuestión es esta: si el modelo de desarrollo más seguro es el de OpenBSD, basada más en código fuente. ¿Por que este no es mas implementado en servidores?. No es que no se utilize, pero su uso se limita más a routers y firewalls. El argumento a favor de este modelo es que es más facil gestionar el cambio si este es hecho poco a poco, es decir que es mucho más facil actualizar un sistema cada 6 meses, y corregir los pocos errores que surjan que migrar un sistema de 10 años de antigüedad, como por ejemplo Centos o Red Hat. En estas distros su modelo de distribución está basado en: (Pensamiento de un sysadmin vago) A ver a quien le toca actualizar esto en 10 años, espero no ser yo.

Ahora, Debian se halla entre esos dos extremos por lo que pienso que su modelo de distribucion es ideal para servidores, aunque no tanto para escritorios, ya que se mueve muy rápido. Esto partiendo del supuesto de que los administradores de servidores son gente que sabe del tema, y que les toca gestionar el cambio, mientras que los usuarios "normales", lo único que quieren es usar un sistema que sirva. Quizá el modelo de distribución para escritorio sería Centos, Ubuntu LTS o similares.

Según esta premisa de la seguridad planteada por OpenBsd, deberíamos de usar en servidores distribuciones de corto soporte. Llevándolo un poco al extremo parecería que lo ideal sería usar Arch linux para servidores dejando a Centos o Ubuntu LTS, para los desktops y cosas no tan "vitales". Siguiendo con esta línea de pensamiento hay una distribución linux que se ajusta a esta medida, Gentoo, flexible pero robusta, moderna pero estable, mas apegada al pensamiento BSD conservador y utilizada en servidores, aunque complicada de configurar y mantener.

Pero a pesar de todos los pensamientos anteriores, la distro de facto en la empresa es Red Hat en servidores, en el escritorio (ni a distro se llega) es Windows. Windows merece una mención aparte en el tema de la seguridad, ya que en mi opinión se podria considerar el sistema mas inseguro de los mencionados. Tiene gran compatibilidad binaria reversa, usa programas binarios sin código fuente auditable por años sin ningún tipo de soporte de seguridad, las actualizaciones de seguridad no actualizan todos los programas, además de que necesita antivirus y demás porquerias. Además claro del modelo de software cerrado que promueve, pero es por estas mismas cualidades por las que triunfa en la empresa (sobretodo por la compatibilidad reversa de binarios precompilados), además de que poseee un gran tiempo de "soporte".

En conclusión: Como siempre, es el tema de la seguridad contra la comodidad, por un lado está el sistema operativo super seguro, OpenBSD, con código fuente auditable, herramientas de seguridad ultraprobadas, diseño minimalista, y acercamiento a la seguridad activa, pero con corto tiempo de soporte y no amigable al usuario sea este el usuario medio de PCs, o un administrador de sistemas. Por otro lado está Windows, un sistema pesado, lleno de binarios que ni sus programadores entienden pero que quedaron ahí para conservar la compatibilidad reversa, sin seguridad a nivel de separación de usuarios, sin soporte de seguridad para aplicaciones de terceros, que necesita usar antivirus, que promueve el uso de aplicaciones binarias de fuentes no comprobadas, pero eso sí, tiene una interfaz gráfica donde le puedes "picar" y creerte experto en computación, además de instalaciones de doble click, y cosas parecidas. Este esquema en el mundo de hoy (que ya no son los amigables años 90) es insostenible razón por la cual se le tienen que agregar 30 antivirus y demás cosas.

Me parece que un justo medio es Debian, amigable para el usuario, cómodo para el administrador y con actualizaciones de seguridad responsables o alguna otra distro linux. En fin, final de la reflexión.

Preguntas al aire:

¿Alguién usando windows en servidores por aquí?. ¿Que tan seguro es Red Hat o Centos? ¿Hay que cambiar todos a Gentoo, FreeBSD, OpenBSD, después de ver esta situación? ¿Cuál es el lugar de MacOS en todo esto?

Fuentes:

http://www.openbsd.org/security.html https://www.debian.org/security/

Una nueva vulnerabilidad se encontró en la libreria glibc, con la que corren la mayoría de las distribuciones Gnu/linux. Esta es sólo una pequeña reflexión y no un tutorial de como parchar. Curiosamente aunque Debian corre eglibc, también fue afectado.

Un buen tutorial sobre como parchar tu servidor o desktop lo puedes encontrar aquí:

http://www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/

En resumen, actualiza tu sistema desde los repos principales y todo estará parchado, a menos que corras algo tan antiguo como Centos 4, en cuyo caso, será mejor que te cuestiones por que haces algo como esto, más si es un servidor con acceso a internet.

En realidad esta vulnerabilidad se suma a la serie de bugs que se encontraron el año pasado en software relacionado con Gnu/linux como es heartbleed ( que en realidad afectó a todos los sistemas corriendo Openssl), shellshock (Mac y Linux), poodle (de nuevo openssl). A Gnu/linux le está lloviendo duro.

Es sorprendente que estas vulnerabilidades son parchadas horas o incluso minutos despues de anunciadas por los expertos en seguridad, como es el caso de shellshock, lo que nos habla de una buena gestión de la seguridad. Pero también son vulnerabilidades que existían desde hace hace años, que es lo que tienen en común. Por lo que en realidad pudieron ser descubiertas por los hackers Black Hat, desde hace un buen tiempo, lo que les permitiría controlar gran parte de la web. Esto en realidad asusta. No quiero ni pensar lo que pasa en sistemas de código cerrado como windows o Mac en donde no se publican parches rapidamente y este proceso tarda semanas a veces, o incluso con que tarde dias, como hizo Mac al parchar shellshock.

Heartbleed por ejemplo permite tener acceso a todo la memoria de un servidor que corra Openssl, esto en realidad hacía que la vulnerabilidad hiciera mas inseguro al servidor si corria por ejemplo https, de que si corría simple http. La única diferencia es que nadie sabia que estaba ahí. Lo mismo con shellshock. Y ahora los investigadores que descubrieron Ghost aseguran que crearon un email mediante el cual podían obtener privilegios root y una shell!!!!! Paranoid mode enabled.!!!!

Y encima de todo se viene systemd para las distros linux, que he estado leyendo tiene algunos fallos de seguridad medio feos, sobretodo relacionados con los logs, como este:

http://hackingthesystem4fun.blogspot.mx/2014/12/chicos-systemd-lovers-diganme-alguna.html

¿Que se puede hacer? Yo por lo mientras voy a empezar a aprender algo de BSD, ya que aunque no estan flexible como linux, de repente uno tiene la sensación de que Gnu/linux es un barco hundiéndose. Por varias cosas.

BSD al menos ha esquivado Shellshock y también Ghost. Le empezaré a echar un vistazo a OpenBSD el sistema super seguro, ya que en los tiempos que corren (NSA vigilante) tener seguridad extra no está demás aunque dificulte algo las cosas. Además de que de por si, internet es un lugar hostil. Esto lo sé sólo con ver la cuenta de ataques automatizados ssh a un servidor.

Lo que menos quiero encontrarme es que mis servidores fueron hackeados por una vulnerabildad misteriosa aún no descubierta, y que no se tiene ni idea de como un malware entró al sistema.

También sería bueno recalcar que mientras mas simple sea un sistema es mas seguro es, por ejemplo debo recalcar que la distribución Alpine Linux, se ha salvado de varias. Se salvo de shellshock, y de Ghost. Gracias a que usa busybox y ulibc, pero sobretodo a que es un sistema más simple. Tampoco usa systemd y además usa un kernel Grsecurity y Pax. Una buena opción, aunque no tan robusta como Debian.

De los bugs de openssl nadie se salvó. Para esta libreria existe como alternativa GnuTLS y mas recientemente Libressl.

Por lo mientras a corto plazo voy poniendo PAX en mis sistemas y a largo plazo a comenzar con BSD.

Esta es la segunda parte del tutorial para correr el un servidor murmur en Debian. Aunque el tutorial anterior delineaba lo básico. Cuando intenté cambiar algunas configuraciones empezé a tener problemas, por lo que escribo esto a manera de notas, y por si alguien lo necesita consultar. Trata sobre la configuración de los certificados SSL para que nuestro servidor sea reconocido como seguro.

Nota: En este artículo se utilizará mumble-server y murmurd como sinónimos ya que son lo mismo pero por la convención de los nombres de Debian tienen dos nombres diferentes, espero que esto no cause confusión.

Leer más…

Este es un minitutorial sobre como instalar un servidor murmur en Debian. Para quien no lo sepa, murmur es el servidor de mumble, un programa que puede sustituir a skype, para hablar con gente de lejos. Mumble fue pensado originalmente para los videojuegos y esta diseñado par trabajar con anchos de banda pobres, por lo que lo hace muy eficiente en cuanto a la transmisión de audio, mucho mejor que skype.

Pero la principal ventaja que yo le veo, es la seguridad que obtenemos al correr todo esto en un servidor propio, y saltarnos la vigilancia de compañias como google o skype. Se puede instalar en una vieja maquina con Debian, cualquier cacharro de los 90 funciona para correr este servidor. Igualmente una raspberry pi, o inclusive existe una version para los routers con Openwrt. Los routers de marca linksys.

Leer más…

Administro algunos servidores, nada grande, sin embargo leo bastante sobre lo que pasa en el mundo Gnu/linux y me tomó por sorpresa todo lo que se está dando gracias a systemd. Tengo que admitir que systemd en Arch linux me ha corrido sin problemas, y sus tiempos de booteo son muy pequeños. Sin embargo después de haber manejado un sistema como Debian en servidores empiezo a entender el por que de esta polémica.

Systemd funciona bien en el escritorio y aunque no tengo tanta experiencia en la administración de servidores si puedo entender que es demasiado complicado para ser una de las partes principales del sistema, el pid 1, con la información que tengo disponible me coloco en la postura antisystemd.

En general systemd debería de ser una opción más, pero de ninguna manera una imposición. Yo encuentro confuso el que este intentando usurpar funciones como las de cron ¿Que tiene de malo cron? ¿Acaso funciona mal?. También encuentro confuso lo de los logs binarios, he usado esta función dos veces en mi vida a lo mucho, pero mi computadura de escritorio se prende y apaga todos los dias, solo corre procesos de escritorio y no la mantengo prendida meses ni dependo de ella para funciones cruciales. Mi experiencia con systemd se limita a mi Arch linux.

Una reflexión, con system V en Debian, nunca me falló nada, de hecho sólo me preocupo de este sistema a la hora del arranque, que en un servidor bien puede ser una vez cada año, sin embargo SystemD esta ahí todo el tiempo, con su omnipresencia impuesta. Me parece triste que Gnu/linux y un proyecto comunitario como Debian hayan llegado al extremo de una cuasi guerra civil por este programa. Tampoco me parece correcto la imposición de systemd sobre la mayoria de las distros linux.

Tengo un poco de miedo al futuro ya que aposté por Debian para todos mis servidores, no se si hice bien, por ahora seguirán corriendo tranquilos, pero cuando llegue la hora de cambiar a Jessie sentiré nervios, espero por el bien de todos que haya Jessie-lts como ya lo hay con squeeze, para tener mucho tiempo. Una vez en Jessie quizá les ponga systemd, pero si de alguna manera puedo evitarlo no lo haré. Quizá una vez que use systemd en servidores me de cuenta de sus bondades. Lo único que esperaría es que tenga la opción de elegir. No me queda claro, pero al día de hoy aún existe un paquete de systemV en Jessie, no se si se quedará ahí y se pueda evitar systemD. Quizá el proyecto Devuan sea la respuesta, quiza otra distro.

Hasta ahora tengo puesta la vista en Alpine linux que usa Openrc, paquetes binarios (no como Gentoo) y que opta por un diseño minimalista y seguro, este será mi escape en caso de emergencia, por lo mientras estoy tranquilo y disfruto la vida, que venga lo que tenga que venir. No se donde se está metiendo Gnu/linux cuando sus principales distros empresariales, Red Hat y Suse están usando Systemd. Espero que no empieze la catastrofe. El tiempo lo dirá.

Arch linux es una gran distribución linux, es muy flexible y adaptable al usuario de tal manera que se le puede llamar meta-distro. Sin embargo es una distribución rolling release, lo que significa que siempre tiene todo el software actualizado, por lo recibe todas las versiones nuevas de los paquetes, los cuales desde luego cambian. Es por eso que no es un sistema operativo estable. Esta es una guía para volverlos mas usable, aunque muchas de las cosas que aquí se dicen, aplican para cualquier sistema Gnu/linux, y muchas veces por extensión a cualquier SO.

Leer más…