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.

Migrar de Apache/PHP a Nginx/PHP en CentOS

24 Febrero 2015 at 12:49 by Adrián Pérez

nginx2Si contamos con un servidor Apache, quizá nos interese pasarlo a nginx con el menor downtime posible. Yo he hecho alguna prueba partiendo del siguiente entorno:

  • CentOS release 6.6
  • Apache/2.2.15 sin módulos adicionales
  • VirtualHosts para un proyecto PHP 5.3.3

Lo que haremos con nginx es instalarlo y configurarlo de forma muy básica en un puerto diferente y posteriormente una vez esté todo bien, cambiar puertos de escucha.

ATENCIÓN: Si estás pensando en migrar de Apache a Nginx, en producción, ten en cuenta que dependiendo de tu entorno, deberás hacerlo de una u otra manera. No es lo mismo migrar un proyecto python que sirve Apache via mod_wsgi, que un proyecto PHP que ni si quiera usa mod_rewrite (como en este ejemplo). Este post, por tanto, te puede servir de punto de partida, pero no es la "guía definitiva".

Instalación de nginx

En primer lugar, deberemos crear el fichero para acceder al repositorio de nginx, pues éste no viene en los repositorios de CentOS.

[root@lab01 ~]# vi /etc/yum.repos.d/nginx.repo
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=0
enabled=1

Tras configurar el repo, ya podremos instalar nginx via yum:

[root@lab01 ~]# yum install nginx

Medidas de seguridad en WordPress

16 Octubre 2014 at 10:24 by Adrián Pérez

seguridadWordPress va genial, pero todo sea dicho, también puede ser un coladero si no se ponen medidas para hacerlo seguro. A continuación listo algunas de las medidas que se podrían aplicar para empezar a hacer de nuestro site, un sitio más seguro.

1. Eliminar el usuario "Admin"

Si vas a instalar un WordPress de cero, no uses "admin" como nombre de usuario. Tampoco "root" ni "administrador" ni cosas así. Si en su momento instalaste WordPress con el usuario "admin", lo mejor es que crees un nuevo usuario con permisos de Administrador (ésto puedes hacerlo fácilmente desde el panel de control de WordPress) y una vez creado, te loguees con tu nuevo usuario y elimines el usuario "admin". Tranquilo, al borrar el usuario te pedirá si quieres conservar los posts escritos por "admin" y a qué otro usuario atribuírselos. Sólo con ésto te evitarás más de un dolor de cabeza.

Ah, también ayuda usar un password complejo, a ser posible una combinación de mayúsculas, minúsculas, números y carácteres alfanuméricos.

Default VirtualHost en Apache

10 Julio 2014 at 8:48 by Adrián Pérez

Black Hole

A continuación, algunas notas sobre el comportamiento del primer VirtualHost definido en Apache.

En un entorno Apache con VirtualHosts, el primer VirtualHost es importante, pues será el VirtualHost por defecto. Ésto significa que será el VirtualHost con mayor prioridad, y por tanto atenderá a cualquier petición al server contra un dominio no especificado en ningún VirtualHost.

Usualmente tendremos definidos VirtualHost *:80 así como *:443. En este caso, tendremos un default para *:80 y un default para *:443. Si definieramos nuestros VirtualHost especificando IP:puerto, entonces tendríamos un default para cada IP:puerto definido.

El primer VirtualHost, no es más que el primer VirtualHost definido en el httpd.conf. Si usamos como es habitual un fichero de configuración por cada VirtualHost, dentro del directorio "conf.d" incluido por el httpd.conf, entonces el primer VirtualHost será el que primero aparezca, ordenado por nombre. Por esta razón se suele especificar el VirtualHost "default" en un archivo con nombre "_defaul.conf", para que se liste primero.

En la documentación oficial de Apache, además, comentan que este primer VirtualHost debería tener un ServerName y un DocumentRoot iguales a los definidos de forma global en el fichero de configuración global de Apache.

Fuentes:

http://httpd.apache.org/docs/2.2/vhosts/details.html

http://httpd.apache.org/docs/2.2/vhosts/name-based.html

Flickr! Foto por ( (( marS )) )

Mostrar el autor en las búsquedas de Google

21 Febrero 2014 at 13:59 by Adrián Pérez

Google-SearchA raíz del estudio "Eye Tracking Study" que vi publicado en Twitter, donde se mostraba el impacto de tener Google Authorship configurado para aparecer junto a tus resultados de búsqueda en Google, me decidí a implementarlo en el blog. Desafortunadamente a los dos meses de implementarlo, Google decidió reducir el número de resultados con foto de autor. Aun así, me he decidido a publicar los pasos para configurar el Google Authorship en los resultados de búsqueda, en mi caso, para un WordPress.

Configuración de Google Authorship

Para ello, tuve que seguir una serie de pasos (la verdad, parecía más sencillo de lo que finalmente fué).

  1. En primer lugar, descargué e instalé el plugin para WordPress Google Plus Authorship. Para configurarlo, bastará con indicar el enlace a tu perfil de G+.
  2. Desde G+, tuve que crear un enlace en la sección "Contributor" hacia helloit.es (el blog en el que creo el contenido).
  3. Después, en el blog, tuve que añadir un "by <nombre>" en cada post. El nombre ha de coincidir con el nombre del perfil de G+. Ésto puede hacerse de varias formas. La más sencilla es que tu tema lo permita, pero si no (como fué mi caso) deberás modificar el código de single.php y el loop.php para añadir algo parecido a lo siguiente (ésto dependerá del tema y los plugins que tengas instalados):

by <?php the_author(); ?>

Fuente: http://wordpress.org/support/topic/trying-to-add-author-to-post

Cómo configurar VirtualHosts para HTTPS

8 Octubre 2013 at 16:10 by Adrián Pérez

ApacheEn Apache, usamos los VirtualHosts para poder definir diferentes proyectos web, cada uno con su propio dominio (o dominios), escuchando tras el mismo puerto e IP. Ésto podemos hacerlo para conexiones HTTP normales, pero antiguamente no se podía para HTTPS, puesto que la conexión venía cifrada y por tanto Apache no podía saber a qué dominio se quería acceder.

Al parecer, desde el 2006 se incorporó una extensión que le permitía al cliente (el navegador del usuario) enviar el dominio a consultar en la primera petición, antes de iniciar la transferencia cifrada de datos, permitiéndo así al servidor poder usar el mecanismo de VirtualHosts para tener varios sitios web HTTPS escuchando por el mismo puerto (típicamente el 443).

Requisitos

Seguramente nuestro servidor Linux con Apache ya tenga instalados los requisitos para funcionar, pero para asegurarnos, bastará con confirmar que tenemos:

  • openSSL 0.9.8f o posterior instalado
  • mod_ssl instalado en Apache

En mi ejemplo, un Fedora release 13 (Goddard) con Apache 2.2.15, lo he confirmado así:

[root@myServer]# openssl version
OpenSSL 1.0.0d-fips 8 Feb 2011

[root@myServer]# httpd -M | grep -i ssl
ssl_module (shared)

[root@myServer]# grep -i ssl /var/log/httpd/error_log*
Apache/2.2.15 (Unix) DAV/2 PHP/5.3.3 mod_ssl/2.2.15 OpenSSL/1.0.0-fips mod_wsgi/3.4 Python/2.7.5 configured -- resuming normal operations

Si no tienes openssl ni mod_ssl, puedes instalarlo con yum y posteriormente reiniciar Apache:

[root@myServer]# yum install openssl mod_ssl
[root@myServer]# /etc/init.d/httpd restart

Python 2.7 en CentOS 6 con mod_wsgi

5 Junio 2013 at 19:12 by Adrián Pérez

python2En este post, veremos cómo instalar una nueva versión de Python (la 2.7.5) manteniendo la versión del sistema (2.6.6 en CentOS 6), forzando al mod_wsgi de Apache a usar la nueva versión en lugar de la de sistema. La idea es no tocar la versión de sistema, puesto que si cambiamos dicha versión, seguramente nos encontraremos más adelante con problema de dependencias en prácticamente cualquier actualización o instalación que queramos hacer con yum.

De esta manera, lo que haríamos sería hacer una segunda instalación de la nueva versión de Python, que no comprometiera la instalación original. En el ejemplo, estamos usando un servidor CentOS 6.4 que por defecto, viene con Python 2.6.6, con un servidor Apache con mod_wsgi 3.2. Lo que queremos, es instalar Python 2.7.5 sin comprometer el Python del sistema, instalar los módulos de Python necesarios para nuestra aplicación, pero únicamente para la nueva versión 2.7.5, y finalmente, reconfigurar mod_wsgi para usar la nueva versión.

Para ello, podríamos seguir los pasos descritos a continuación:

Entorno

Comprobamos los detalles del sistema operativo:

[root@MyServer]#cat /etc/redhat-release
CentOS release 6.4 (Final)

Verificamos la versión de python del sistema:

[root@MyServer]# python --version
Python 2.6.6

Downgrade o cambio de versión de PHP

22 Febrero 2013 at 18:39 by Adrián Pérez

PHP choiceInteresante post, éste, que explica cómo cambiar la versión de PHP con un ejemplo real, ya sea, haciendo un downgrade de la versión de PHP o instalando a una versión concreta. Este ejemplo está ejecutando en una máquina con CentOS 6.3 64 bits, con el repositorio de remi instalado.

Primero, podemos ver qué versión tenemos.

# php -v
PHP 5.4.11 (cli) (built: Jan 16 2013 16:51:38)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies

Con yum, podemos, a continuación, ver qué versiones tenemos disponibles en los diferentes repositorios.

# yum --showduplicates list php
Available Packages
php.x86_64               5.3.3-3.el6_2.8                                                   base
php.x86_64               5.3.3-14.el6_3                                                    updates
php.x86_64               5.4.10-1.el6.remi                                                remi
php.x86_64               5.4.11-1.el6.remi                                                remi

Cloud Computing VS Servidor Dedicado

20 Enero 2013 at 20:33 by Adrián Pérez

Cloud ComputingGran pregunta. Difícil Respuesta. La fácil es... depende. Hasta aquí estaba claro. Pero no sólo depende de cuales sean tus necesidades, también depende de qué proveedor vayas a elegir.

Cloud Computing

He trabajado mucho durante los últimos dos años, con dos de las empresas de Cloud Computing más importantes, Amazon AWS y RackSpace. ¿Cómo me ha ido?

Bueno, para empezar he aprendido que Cloud Computing es sinónimo de flexibilidad y agilidad. Es trementamente útil para proyectos que reciben cargas de trabajo extremadamente diferentes en función del día o la hora, o en función del resultado de determinada campaña de márketing. Por ejemplo, puedes aumentar o disminuir los recursos de tu máquina, según necesites, en cuestión de minutos. Incluso Amazon tiene un servicio llamado "Cloud Watch Auto Scaling" que te permite aumentar o disminuir recursos de forma totalmente automática, en función de la carga del servidor. Escalado vertical tremendamente fácil y rápido.

Optimización de Apache

17 Julio 2012 at 12:38 by Adrián Pérez

httpd Apache
Siguiendo con el último post sobre fine tuning de MySQL para mejorar el rendimiento, me lanzo con otro post recopilatorio con un resumen de algunas de las recomendaciones oficiales de Apache, completadas con otras fuentes listadas al final del post.

Hardware y SO

En la documentación oficial de Apache se comenta, que el factor más importante para el rendimiento de un servidor es la RAM, lo cual me recuerda a una frase que reproduzco casi literalmente, pero de la cual no consigo recordar la fuente:

"Aumentar la RAM es la manera más rápida, barata y eficaz de mejorar el rendimiento"

Además de la RAM, se deberá prestar atención a la i/o de los discos, CPU y finalmente a la velocidad de la tarjeta de red, que deberán ser suficientes (ésto se deberá determinar por experimentación).