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.

La distribución de GNU/Linux que más he utilizado durante años es OpenSuSE, desde mucho antes de que cambiara de manos o de que tuviera esta versión open, en su día me enamoré de YaST y, posteriormente, de zypper.

Esta ofrece muchas ventajas que te permiten hacer rápidamente cualquier configuración típica, a su vez, es casi idéntico a SuSE, la versión de pago, la cual es compatible con la gran mayoría de aplicaciones empresariales, realmente solo RedHat y SuSE son consideradas compatibles con todo lo empresarial.

Pero entre sus grandes ventajas, no está la capacidad de actualizar rápidamente, hay que seguir algunos tediosos pasos, así que en este post intento explicar una versión mínima y rápida para estas actualizaciones.

Debido a que no siempre puedes estar físicamente en el lugar donde está tu server, o incluso puede que necesites un servicio de dentro de tu red cuando estás fuera, las VPN se han convertido en una de las grandes bases de conexión estés donde estés.

OpenVPN es un servicio que permite configurar fácilmente desde cualquier sistema operativo, incluso desde móviles, lo cual se convierte en unas de las opciones más aconsejables y además es gratis lo cual es una gran ayuda viendo el precio de la mayoría de VPNs del mercado.

El tiempo pasa, y aunque creamos que en todos los lugares va a la misma velocidad, no es así.

Con el tiempo, algunos servidores pueden desviar mucho la fecha, tanto que pueden llegar a superar varios minutos u horas respecto a la hora real, esto acaba siendo un problema, ya que muchas conexiones o sincronizaciones pueden fallar debido a este desvío entre dos servidores.

Para solucionar esto, existe el protocolo NTP que permite revisar la fecha de un servidor y sincronizar con ella. Con una simple llamada UDP se puede actualizar rápidamente la fecha, el problema es que, normalmente, todos los servidores actualizan 1 vez por semana, como mínimo, esto supone poco consumo de Internet, pero es más eficiente configurar un servidor local que preguntará a fuera y todos los demás preguntarán a este, así no malgastaremos ancho de banda y también evitaremos consumir recursos de servidores externos, que muchas veces son voluntarios.

Normalmente, cada servidor crea copias de seguridad de sus datos cambiantes, si tuviéramos cualquier problema, solo tendríamos que volver a pasar estos datos a la máquina o a una nueva con la misma configuración, pero construir una máquina igual no es tan sencillo, ni rápido.

En estos casos, lo más factible es tener una copia de seguridad de toda la máquina, en este caso simplemente la restauramos, copiamos la última copia de seguridad y ya volveremos a tener la máquina disponible. Si los servidores son máquinas virtuales, esto será bastante sencillo, ya que únicamente tendemos que copiar sus ficheros.

VMWare ESXi dispone de varias aplicaciones, normalmente de pago, que, mediante la API, permiten crear copias de seguridad. El problema es que el acceso a la API requiere tener la versión licenciada de ESXi, si solo dispones de ESXi Hypervisor (la versión gratuita), no tendrás acceso a esa API. Por si fuera poco, las aplicaciones que crean copias de seguridad suelen ser de pago e incluso más caras que el propio VMWare.

Así que, en vez de la API, se utilizará un proceso interno, un software gratuito que funciona en cualquier ESXi y crea copias de seguridad en caliente.

title: Instalar OpenSuSE 42.3 authors: rei.izumi tags: [OpenSuSE]Cuantos más servidores y servicios se tienen, más difícil es comprobar que todos estén funcionando correctamente, para ello hay aplicaciones que permiten revisar el estado de estos y avisar si alguno falla.

Uno de los más antiguos es Nagios, desde su web puedes ver rápidamente el estado de toda la red, tanto servidores como servicios, si alguno de estos falla, envía un e-mail para avisar de ello. También dispone de todo tipo de módulos nuevos e incluso puedes programar módulos nuevos, así que tienes total libertad para crear aquello que necesites.

En el campo de la programación hay muchos servicios que son necesarios en el día a día, aparte de los repositorios de código, están los repositorios de librerías. Las librerías construidas por otros o por un equipo propio necesitan ser almacenadas en algún servidor donde puedan ser recuperadas fácilmente, por ejemplo, Maven permite conectar a los diferentes repositorios compatibles en busca de las librerías necesarias para compilar una aplicación. Entre los diferentes repositorios de código se encuentra Nexus Repository Manager, que dispone de una versión gratuita que es más que suficiente para el uso normal.

En la actualidad es imposible recordar todas las IPs de dominio, para ello utilizamos los servidores DNS para que se encargan de resolver las IPs a partir del dominio, incluso varios servicios (Virtual Hosts de Apache por ejemplo) solo responderán como esperamos si utilizamos el dominio correcto, y no directamente su IP, por todo ello es tan importante tener un servidor DNS.

Hacia internet, al contratar un dominio público, este suele llevar su propio DNS que podemos configurar para crear nuevos subdominios del nuestro, pero en la red privada este no nos servirá, para ello la mejor opción es crear uno interno.

De entre todas las opciones, BIND es el servicio más extendido.