Instalar JBoss AS7 en entornos Red Hat

24 Febrero 2015 at 19:54 by Adrián Pérez

JBoss_logoJBoss es un Servidor de Aplicaciones Java completo, de código abierto, desarrollado por Red Hat. Y sí, yo también pienso en Apache Tomcat en estos momentos, pero hay diferencias entre ellos explicadas por ejemplo aquí o aquí. Voy a copiar literalmente una respuesta de StackOverflow que explica la diferencia entre un Servlet Container como Tomcat y un Application Server como JBoss:

"A servlet-container supports only the servlet API (including JSP, JSTL).

An application server supports the whole JavaEE - EJB, JMS, CDI, JTA, the servlet API (including JSP, JSTL), etc.

It is possible to run most of the JavaEE technologies on a servlet-container, but you have to install a standalone implementation of the particular technology." por Bozho

Ahora que quizá tenemos algo más claro qué es JBoss y por qué este post no habla sobre Tomcat, faltará ver qué diferencias hay entre la versión de la comunidad y la enterprise (más info aquí). Como es de esperar, la versión de la comunidad siempre irá por delante respecto a la empresarial en cuanto a novedades y funcionalidades, con lo cual no estará tan testeada ni será tan estable como debería ser la versión empresarial, más pensada para alojar aplicaciones críticas.

En esta entrada se instalará y pondrá en marcha la versión de la comunidad.

Configuración inicial de un servidor CentOS

5 Febrero 2015 at 13:07 by Adrián Pérez

centosHace ya unos años, y sin ningún software de administración tipo Puppet/Chef/Ansible, creamos un documento para que todos los técnicos pudieran decir la suya respecto a los pasos a dar tras instalar un sistema operativo Linux (CentOS en nuestro caso), con tal de no olvidarnos ninguno e ir mejorando entre todos este proceso de configuración inicial de un servidor. Eso significa que si tú, amado lector, tienes cualquier sugerencia de mejora, no dudes en dejarla en los comentarios.

Hoy en día, ese documento, muy pensado para instalaciones CentOS 6, tanto en entornos Cloud Computing como para en máquinas propias, es algo parecido a lo que listo a continuació.

NOTA: No te tomes todos los puntos al pie de la letra, seguramente querrás valorar si lo que propongo a continuación tiene sentido en tu entorno antes de aplicarlo, y seguro que más de un punto es mejorable.

1. Actualización del SO

Tras la instalación, es una buena idea forzar un update para estar a la última de los paquetes de nuestro SO.

yum update

2. Deshabilitar selinux

Selinux es una herramienta útil, pero que no compensa, y proporciona más dolores de cabeza de los que pretende solucionar. Es por eso que proveedores como RackSpace o Hetzner proveen sistemas con Selinux deshabilitado de fábrica. Si aún así quieres trabajar con Selinux, seguramente este sea el momento de configurarlo adecuadamente. En caso contrario, símplemente deshabilitalo tal y como sigue:

vi /etc/selinux/config
SELINUX=disabled

Tras deshabilitarlo, será necesario reinciar el sistema para activar los cambio. Así pues, reinicia para evitar tener problemas con los próximos pasos.

Instalar yum en Red Hat 4

22 Julio 2014 at 10:24 by Adrián Pérez

old manBueno, hoy me he encontrado con un (muy) antiguo server Red Hat 4 que no tenía yum instalado. Hace un tiempo ya me pasó algo parecido, así que he decidido crear un post para documentar cómo lo solucionamos.

Lo primero es verificar que no tenemos yum instalado. Para eso, como root, podemos ejecutar:

[root@myOldServer ~]# yum
bash: yum: command not found
[root@myOldServer ~]# whereis yum
yum:
[root@myOldServer ~]# rpm -q yum
package yum is not installed

Posteriormente, nos aseguramos de la versión y la arquitectura de nuestro servidor, para saber qué paquetes exactos necesitaremos:

[root@myOldServer ~]# uname -m 
x86_64
[root@myOldServer ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux ES release 4 (Nahant Update 6)

VLANs y múltiples alias de red en Red Hat 6

23 Abril 2014 at 12:36 by Adrián Pérez

networking vlanPara poder trabajar con VLANs tageadas en un servidor Red Hat Enterprise 6.0 con múltiples alias de red, tendremos que esforzarnos un poco. En mi caso, he partido de un servidor con una única tarjeta de red (eth0) configurada con 10 alias, todo IPs del mismo rango, del siguiente estilo:

eth0:0 192.168.1.2
eth0:1 192.168.1.3
...
eth0:10 192.168.1.12

Por supuesto, el servidor contaba con un default gateway configurado en cada uno de los alias:

GATEWAY=192.168.1.1

Con este servidor en producción, y con mucho sudor frío, he pasado a configurar el rango 10.0.0.2-10.0.0.25 en el servidor, con default gateway 10.0.0.1, todo perteneciente a la VLAN 30, y todo tageado, también usando la misma interfaz eth0, y lo más importante, manteniendo la configuración de red original (es decir, acabaremos teniendo el servidor configurado para trabajar con 2 rangos de IPs diferentes, uno de ellos perteneciente a la VLAN 30).

Por cierto, si estás pensando en seguir los pasos aquí descritos en un servidor en producción, te recomendaría testearlos primero en un entorno de test, y tener un plan B para recuperar la conectividad con el servidor en caso de cometer algún error.

Actualizar automáticamente un servidor

12 Marzo 2014 at 12:09 by Adrián Pérez

updateÚltimamente he estado leyendo sobre cómo y cuando actualizar un servidor Linux (Fedora/CentOS/Red Hat en mi caso), de cara a aplicar los últimos parches de seguridad y mantener el sistema actualizado. Resulta que no soy el único que se pregunta sobre si hay algún tipo de guía, recomendaciones, o mejores prácticas para updatear sistemas.

Después de leer y leer, y ver las numerosas razones tanto a favor como en contra de los updates automáticos, la siguiente frase en la documentación oficial de Fedora resume cuándo habilitar las actualizaciones automáticas, por lo general:

"If the machine is a critical server, for which unplanned downtime of a service on the machine can not be tolerated, then you should not use automatic updates. Otherwise, you may choose to use them."

Es decir, por norma general sería una buena idea habilitar las actualizaciones automáticas en todo servidor que no sea crítico, siempre y cuando tengamos la posibilidad de deshacer los updates instalados, o revertir los cambios, en caso de error.

Añadir un disco a un servidor con RAID1 existente

22 Noviembre 2013 at 14:42 by Adrián Pérez

hard diskEn este post se pretende explicar cómo usar la herramienta HP Array Configuration Utility CLI for Linux "hpacucli" para añadir un tercer disco a un servidor HP que ya cuenta con dos discos SAS en RAID1. Nos interesa añadir el tercer disco sin que forme parte del RAID, es decir, queremos añadir el tercer disco como si fuera un disco sin RAID, un disco normal. Ya hablamos de la herramienta hpacucli hace un tiempo aquí.

Entorno

El problema que nos encontramos es que por defecto, los discos los reconoce la controladora del RAID y no aparecen en el fdisk. Así pues, tras añadir físicamente el disco al servidor y tras el reinicio reglamentario para verificar que efectivamente el disco se ha reconocido, nos encontraríamos con que el disco continúa sin aparecer con el fdisk:

[root@myserver]# fdisk -l
Disco /dev/cciss/c0d0: 300.0 GB, 299966445568 bytes

Disposit. Inicio Comienzo Fin Bloques Id Sistema
/dev/cciss/c0d0p1 * 1 126 512000 83 Linux
/dev/cciss/c0d0p2 126 71798 292422656 8e Linux LVM

Disco /dev/dm-0: 234.9 GB, 234881024000 bytes
Disco /dev/dm-1: 10.5 GB, 10536091648 bytes
Disco /dev/dm-2: 21.0 GB, 20971520000 bytes
Disco /dev/dm-3: 31.5 GB, 31474057216 bytes
Disco /dev/dm-4: 1577 MB, 1577058304 bytes

Como se puede ver, únicamente aparece un disco en RAID físico, que sabemos que corresponde con los dos discos de sistema en RAID1. Ni rastro del nuevo disco.

Configurar SFTP con OpenSSH

20 Noviembre 2013 at 15:54 by Adrián Pérez

seguridadHoy toca ver cómo configurar openSSH (como siempre, en entornos Red Hat) para aceptar únicamente peticiones SFTP enjaulando a los usuarios sftp en sus homes. Para añadirle contenido, además, configuraremos este servicio en un segundo proceso que correrá en la máquina de forma independiente al proceso openssh habitual, para evitar tener problemas con nuestras conexiones SSH, y por tanto, se configurará un puerto de escucha diferente al habitual, en el ejemplo, el 12022.

Fichero de configuración

En primer lugar copiaremos el fichero de configuración de openssh para adaptar la copia a nuestras necesidades:

[root@myserver]# cp /etc/ssh/sshd_config /etc/ssh/sshd_config_12022
Lo abriremos con vi, y nos aseguraremos de cambiar el puerto de escucha por el nuevo puerto. Además, cambiaremos el "Subsystem sftp" por defecto y añadiremos al final las líneas correspondientes al enjaulado de usuarios:
# Cambiamos el puerto
Port 12022
 
# Modificamos el Subsystem original
#Subsystem sftp /usr/libexec/openssh/sftp-server 
Subsystem sftp internal-sftp 
 
# Añadimos el enjaulado 
Match Group sftp12022 
  ChrootDirectory /sftp/%u
  ForceCommand internal-sftp 
  AllowTcpForwarding no
Desde este momento, trabajaremos con el nuevo fichero de configuración sshd_config_12022, asegurándonos así de no intervenir en el servicio de openssh de la máquina que ofrece el servicio de SSH. Además de decirle a openssh que a partir de ahora usaremos el puerto 12022 para las coneciones SFTP, habremos definido que se enjaulará a todos los usuarios de sistema cuyo grupo principal sea el grupo "sftp12022". Además, estaremos enjaulando a todos estos usuarios en el directorio /sftp/nombreusuario.

Vaciar el error.log de MySQL

20 Agosto 2013 at 10:26 by Adrián Pérez

Un tema que me ha preocupado siempre, son los logs de MySQL, y más concretamente el error.log. En entornos de replicación, el error.log puede llegar a ser gigante cuando se usan sentencias que el sistema detecta como "advertencias". Por ejemplo:

[Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. The statement is unsafe because it uses a LIMIT clause. This is unsafe because the set of rows included cannot be predicted.

¿Cómo podemos vaciar el error.log de forma segura, sin que tenga impacto en el servicio de MySQL? Pues vamos a verlo.

Instalar el rpm de opendkim en Fedora 13

27 Abril 2013 at 18:58 by Adrián Pérez

Spam dkimDKIM (DomainKeys Identified Mail) es un mecanismo de autentificación para luchar contra el spam, que consiste en (y aquí prácticamente copio de la wikipedia) añadir una cabecera llamada "DKIM-Signature"que contendrá una firma digital tanto de la cabecera como del cuerpo del mensaje. El destinatario, hará una consulta DNS usando el dominio origen y un selector, contra un registro DNS del tipo TXT del estilo selector._domainkey.dominio.com que contendrá la clave pública necesaria para descifrar el valor de la firma de la cabecera y verificar así su procedencia.

Aquí explican mejor qué es y cómo funciona DKIM, pero en esta ocasión, lo que veremos no es explicar cómo funciona, si no cómo usar nuestro servidor de correo (postfix sobre un antiguo Fedora 13) para firmar nuestros mails mediante opendkim, instalando el rpm oficial en lugar de instalarlo mediante yum. Instalar el rpm seguramente tenga más trabajo que hacerlo desde yum, pero el proceso servirá en cualquier distribución basada en Red Hat.

Guardar la hora en el history de Linux

10 Abril 2013 at 19:43 by Adrián Pérez

history linux

Algo que nos puede venir muy bien, es modificar el history de linux para:

  1. Almacenar la fecha y la hora en la que se ejecutaron los comandos
  2. Aumentar el límite por defecto del history para almacenar más comandos

En entornos RedHat (he hecho la prueba en un CentOS 6.3), en lugar de modificar el .bashrc de cada usuario, se puede modifiar el script de bash global, para que afecte a todos los usuarios del sistema. Sin embargo, esta modificación no se debe hacer directamente en  /etc/bashrc, si no que es preferible crearse un fichero donde ir añadiendo las modificaciones globales, sin tocar los archivos de sistema.