Llevo tantos años siguiendo a SuSE, que ni siquiera me había planteado seriamente alguno de sus rivales, ni a nivel doméstico ni empresarial, SuSE tenía todo, una versión community y una de pago con soporte, seguía estando allá arriba junto a Red Hat.

Pero los tiempos cambian, unos se adaptan, y otros no.

En estos últimos años, he seguido utilizando OpenSuSE y viendo sus cambios de versión en solo 1 año vista, las actualizaciones que explotan destruyendo entornos de producción con pocos años, y teniendo que revisar todos los cambios de la siguiente versión antes de hacer el salto, debido a que podías llegar a perder un servidor sin darte cuenta por un motivo desconocido.

A todo esto, YaST cada vez era menos útil, debido a que los cambios tan rápidos hacían que YaST no llegara a actualizarse al mismo nivel.

Mientras, Red Hat junto a Fedora, y la versión CentOS de la comunidad han hecho unos grandes avances y cada vez han ido cogiendo más mercado, hasta el punto de luchar tu a tu contra Ubuntu en zonas domésticas, y quedarse el liderazgo en el ámbito empresarial.

Por todo esto, traigo una guía rápida para instalar CentOS.

El servicio de DHCP quizás es uno de los más olvidados, en muy raro que no esté disponible, y al funcionar de forma transparente, nadie le hace caso, además, en un sistema doméstico o una PYME, normalmente es el router del proveedor de Internet quien se encarga de esto, así que está ahí, pero nadie le hace caso.

La realidad es que es uno de los servicios más importantes, y más ahora con tantos dispositivos conectados a la red y que no pueden ajustar una IP fija, sin DHCP, muchos dispositivos ni siquiera funcionarían.

Además de asignar una IP diferente a cada dispositivo, este se debe encargar de poder definir una IP fija a una Mac, de esta forma podremos asignar IPs que no cambiarán a esos dispositivos que no pueden contener estáticas o para evitarnos tener que poner fijas a dispositivos que se mueven fuera de la red, otra aún más importante es poder enviar las DNS que queremos utilizar, y este último es lo que provoca que valga la pena obviar el servicio original de un router y tener un servidor DHCP propio.

Últimamente PostgreSQL es la base de datos que más está siendo implementada, debido a su origen OpenSource y su potencial que le permite estar a la altura de las grandes bases de datos de pago.

También hay que sumar la cantidad de años que tiene, lo que la hace una base de datos sólida, y con más funcionalidad que MariaDB, si principal rival en el OpenSource.

Actualmente muchas aplicaciones aceptan (e incluso recomiendan) su uso, si a eso añadimos que también está ganando dentro del mundo cloud y contenedores, la convierte en una base de datos a tener en cuenta.

Solo unas pocas bases de datos han conseguido sobrevivir a lo largo de los años, y aun menos son las que compiten por usarse en grandes aplicaciones. Entre estas grandes bases de datos, posiblemente DB2 de IBM sea la más olvidada, aunque cuando compites contra Oracle, es difícil ganar, y Microsoft SQL Server tampoco se ha quedado corta en el mercado.

Aun con todo, DB2 ha seguido evolucionando para no quedarse atrás, y aunque IBM ha tenido ideas realmente malas en su evolución (como reemplazar la consola administrativa, ligera y funcional, por un eclipse imposible de instalar en el propio servidor y apenas sin nada), a seguido luchando hasta los tiempos actuales.

Con los años, he aprendido que DB2 está a la altura de sus rivales, y el único motivo por el que nunca ha despegado, es el tema de licenciamiento, IBM ofusca todo esto a límites, realmente, es más complejo entender o conseguir la licencia que quieres, que no instalar y utilizar esta base de datos.

Actualmente disponemos de la versión de Community Edition, que será la que utilizaré en este caso.

Aunque la tecnología no ha parado de cambiar, MariaDB/MySQL sigue siendo una de las bases de datos más utilizadas para pequeños proyectos, además de seguir siendo OpenSource.

Su simplicidad y buen funcionamiento la hace muy práctica en muchos entornos y es raro no acabar teniendo al menos una de estas instaladas, por ejemplo, el proyecto Wordpress en el que se basa este blog, únicamente acepta esta base de datos.

Los días se vuelven más tranquilos cuando sabes que todos los sistemas están ejecutando las copias de seguridad automatizadas, y estos te avisan de que todo está funcionando correctamente.

A su vez, no hay nada como recibir decenas, o cientos de e-mails de cada servicio de copia de seguridad, avisando de que todo ha funcionado correctamente, o no. Esto provoca que, o no se lean los mensajes, o se activen reglas para desviarlos, pero en definitiva obtenemos lo mismo: nadie revisa los mensajes, así que no sabemos si realmente funciona o no.

La opción más clásica es únicamente notificar si ha fallado, pero esto también es un problema, ya que si un proceso falla al punto de no poder enviar mensajes (por ejemplo, si se queda sin espacio), no lo sabremos nunca, así que nos obliga a ir revisando el sistema manualmente.

Para solucionar esto, podemos redirigir las notificaciones hacia otro sistema que pueda revisar si ha funcionado o fallado y avisarnos únicamente si ha fallado o si no ve ningún mensaje cuando sí debería haberlo recibido, para ello disponemos de Nagios.

Anteriormente publiqué una entrada de cómo configurar un servidor de sincronización horaria utilizando NTP, debido a la importancia de que todos los servidores de una red tengan exactamente la misma hora para evitar problemas de sincronización.

Con el tiempo, ha surgido un nuevo proyecto Chrony, que se ha asentado como el nuevo estándar, por encima de NTP, debido a que varias ventajas.

A partir de OpenSuSE 15, NTP ha sido sustituido por Chrony, e incluso YaST ha sido modificado para incorporar a este, así que, aunque podemos seguir instalando el viejo NTP y borrar a Chrony, la mejor opción es dar el paso y cambiar hacia este.

WebSphere Application Server (WAS en adelante) es un servidor de aplicaciones Java desarrollado por IBM. Este compite contra Tomcat, JBOSS, Glassfish y otros, pero está diseñado exclusivamente para el uso empresarial permitiendo gestionar un cluster con facilidad.

Existen varias versiones de WAS, pero principalmente se dividen en la Liberty y la normal (Application Server o Application Server Network Deployment), aunque normalmente me dedico a explicar aplicaciones OpenSource o las versión gratuita de una aplicación, en este caso me decantaré por la versión no-Liberty de WAS, la cual es de pago, esta se orienta a PYMES o grandes empresas únicamente, pero debido a la carga de trabajo que requieran sus aplicaciones, WAS puede ser una gran mejora en comparación a sus rivales.

Como ya comenté en otra entrada, los LDAP son uno de los servicios más importantes, este centraliza la información del usuario en un único punto y todos los servicios utilizan a este, simplificando enormemente la gestión, actualizando datos en tiempo real o casi real y evitando que los usuarios tengan tantos usuarios y contraseñas diferentes que les sea imposible encontrar cual es el correcto.

Debido a la importancia del LDAP, también lo es seleccionar cuál utilizaremos, actualmente existen varias opciones gratuitas como OpenLDAP u Oracle Directory Server (ODSEE), así como otras de pago, la más conocida es Active Directory (AD en adelante) de Microsoft.

En mi caso, siempre me he decantado por ODSEE, pero este provenía de Sun y, al ser comprado por Oracle, ha sido totalmente abandonado, así que no queda más remedio que aceptar tener un LDAP obsoleto o migrar a otro, la opción más lógica en este caso sería OpenLDAP, pero debido a mis necesidades este no es compatible con algunas aplicaciones que necesito, así que me he decantado por AD.

Migrar de un LDAP no-AD a un AD o a la inversa no es sencillo, ya que ninguna configuración de nuestros servicios funcionará por defecto, AD es diferente al resto, siempre, y hay que tenerlo en cuenta.

Quizás lo más complicado no es instalar un nuevo servicio, ya que una vez está instalado y configurado, este ya funciona por sí mismo normalmente. El problema radica en instalar una nueva máquina que requiera de ciertas configuraciones para hacer uso de ese servicio, y eso en sí, tampoco es un problema, el problema es cuando son 10 o más servicios, ya no es solo instalar el Linux que toque y configurar la red, ahora toca configurar todos los servicios necesarios para que la red lo "acepte".

Este artículo trata de una instalación simple de OpenSuSE, lo más sencilla posible, para su uso como servidor donde se empezará a instalar nuevos servicios y este ya se conectará a los servicios básicos de la red.