Tag: Linux

Como implementar Basic Auth en Tomcat7

Hasta ahora no me habia surgido la necesidad de tener una ruta en tomcat que necesitase un acceso con una validacion por parte del servidor de aplicaciones. Normalmente esta validacion se hace desde apache con el modulo auth_basic que permite pedir un usuario y una contraseña para acceder a una ruta concreta o incluso a un fichero concreto.

Si tienes el modulo JK para conectar apache y tomcat, este problema lo tienes resuelto. porque puedes seguir haciendo la autenticacion a traves de Apache. Pero que pasa si no quieres/no te apetece, o simplemente no sabes implementar mod_jk o no quieres cargar al servidor con un apache para servidor tus aplicaciones java por el puerto 80/443?

Pues puedes hacerlo de la siguiente manera:

1º Busca el fichero tomcat-users.xml que habitualmente esta en la ruta /var/lib/tomcat7/conf/ en una instalacion estandard por paqueteria de Debian.

vi  /var/lib/tomcat7/conf/tomcat-users.xml

2º Descomenta la seccion inferior dentro de la etiqueta
Edita el rol, y en el rolename pon el nombre que se te ocurra. Por ejemplo en mi caso

<tomcat-users>
<role rolename="application"/>
<user username="nombre_de_usuario" password="clave_de_usuario" roles="application"/>
</tomcat-users>

Evidentemente los datos vana a gusto del consumidor (nombre_de_usuario, clave_de_usuario, application)

3º Ahora nos queda el ultimo paso, que es editar el WEB-INF/web.xml dentro de la aplicacion a proteger y añadir al final, antes de la etiqueta

        <security-constraint>
                <web-resource-collection>
                        <web-resource-name>Wildcard means whole app requires authentication</web-resource-name>
                        <url-pattern>/*</url-pattern>
                        <http-method>GET</http-method>
                        <http-method>POST</http-method>
                </web-resource-collection>
                <auth-constraint>
                        <role-name>application</role-name>
                </auth-constraint>

                <user-data-constraint>
                        <!-- transport-guarantee can be CONFIDENTIAL, INTEGRAL, or NONE -->
                        <transport-guarantee>NONE</transport-guarantee>
                </user-data-constraint>
        </security-constraint>

        <login-config>
                <auth-method>BASIC</auth-method>
        </login-config>

En nuestro ejemplo se protege todo el context de la aplicacion, con lo que para acceder a ella habra que introducir las credenciales que aparecen en el tomcat-users.xml

Por ultimo solo nos queda rebotar el servidor de aplicaciones tomcat

/etc/init.d/tomcat7 restart
Via: AVAJAVA

Instalación de Cluster de Tomcat7 con multiples instancias y FarmDeployer.

La instalación de una instancia de Tomcat sobre Debian en cualquier version es casi lo mas sencillo del mundo. Simplemente apt-get install tomcat7 (con la instalación previa del JDK correspondiente) y el sistema lo hace todo solo. Incluso lo arranca. Listo para colgar tus aplicaciones java, en la carpeta webapps por defecto.

Si quieres una cosa mas compleja pero que te da mas control sobre la instalación, nos pasamos a una instalación desde los binarios que provee desde la web oficial, la Fundación Apache.

El siguiente grado de complejidad seria montar distintas instancias de tomcat. Esta parte es interesante si tienes mas de una aplicación corriendo en el servidor debido a que te permitira varias cosas. Hacer deploy y undeploy de aplicaciones en cómodos compartimentos y sin afectar al servicio que dan el resto de aplicaciones. En caso de un rebote, el tiempo de parada sera unicamente el de la instancia que estes rebotando. Si una aplicación da una excepción y se para, o bien se queda sin memoria no afectara al funcionamiento del resto. Ademas se puede configurar el uso de memoria de cada instancia haciendo un estudio de carga de cada aplicación por separado en cada instancia. Con una sola instancia es mucho mas complicado optimizar el uso de memoria, ya que cada una de las aplicaciones hace uso de los recursos del servidor según la programación de dicha aplicación o los conocimientos del desarrollador.

La penultima vuelta de tuerca esta en construir un cluster. Un cluster permite tener N maquinas dando servicio al mismo tiempo, y con sesiones replicadas. Así en caso de que una maquina se caiga, la otra maquina que forma parte del cluster mantiene el servicio funcionando.

En nuestro ejemplo de configuración, debido a que tenemos 4 instancias, debemos de poner en funcionamiento 4 clusters. Cada cluster une una instancia en cada uno de los servidores. Asi, configuraremos nosotros vamos a configurar 4 instancias en 2 servidores físicos. En caso de añadir mas servidores cada cluster tendría tantos nodos como servidores físicos tengamos. Y por otra parte tendremos tantos clusters como instancias queramos desplegar. El ejemplo de arquitectura se visualiza mejor en la siguiente imagen.

Arquitectura de cluster

Arquitectura de cluster

El ultimo paso que queremos dar sirve para solucionar el problema del despliegue automatico. Cuando tenemos un servidor y una instancia, desplegar una aplicación es sencillo, casi trivial. Consiste en tener un fichero war, colocarlo en la carpeta webapps, verificar que el autodeploy en la configuración de tomcat esta en true, y dejar que el servidor haga su trabajo. En una configuración mas compleja con 4 instancias en 2 servidores implicaria desplegar 8 ficheros war, lo cual ya es una tarea mas compleja. El final, el despliegue de aplicaciones obliga a “subir” tantos ficheros war como el numero de instancias multiplicado por el numero de servidores del cluster. Por ello existe una característica dentro de la configuración del cluster de tomcat que se llama FarmDeployer. Esta característica permite desplegar un war en TODOS los servidores que forman parte de un cluster. Esto automatiza y simplifica mucho las tareas de despliegue de nuevas aplicaciones, ya que el FarmDeployer detecta el hash del fichero war subido a la carpeta definida en el modulo y en caso de detectar un war distinto lo despliega en todos los nodos.

A partir de aqui comenzamos con la configuración. El punto de partida es un servidor Debian con las siguientes características:
Dell R310 1 CPU Intel Xeon X3430 64 Bits, 32 GB de RAM, 2x300GB HD SAS 15K en RAID1
Debian 7.5 Wheezy
Securización a gusto de cada uno, pero en mi caso 5 cosas básicas:
Cambio de puerto ssh por defecto.
Acceso a root directo anulado.
Acceso interactivo con contraseña anulado.
Acceso obligatorio con par de claves RSA. Si alguien tiene una version de ssh 6.4 podrá usar la autenticación de certificado y verificación en 2 pasos con authenticator que multiplica la seguridad exponencialmente.
Ademas del correspondiente filtrado de ssh con el firewall perimetral y bloqueo por ip origen.

La siguiente configuración se realiza en los 2 servidores de manera identica.

Creamos un usuario para la instalación de tomcat

groupadd tomcat7
useradd -s /sbin/nologin -g tomcat7 -d /usr/local/tomcat7 tomcat7
passwd tomcat7

Ponemos la clave que queramos (no tiene influencia en el resultado)

Procedemos a instalar previamente la maquina virtual de java.

Con permisos de root

su -
echo "deb http://ppa.launchpad.net/webupd8team/java/ubuntu precise main" | tee /etc/apt/sources.list.d/webupd8team-java.list
echo "deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu precise main" | tee -a /etc/apt/sources.list.d/webupd8team-java.list
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys EEA14886
apt-get update
apt-get install oracle-java7-installer

Esto instala la version:

java version "1.7.0_55"
Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)

Procedemos a descargar la ultima version de tomcat7 (7.0.56):

wget http://ftp.cixug.es/apache/tomcat/tomcat-7/v7.0.56/bin/apache-tomcat-7.0.56.tar.gz

descomprimimos en la carpeta que nos parezca oportuno (nuestra home esta correcto):

tar -xvzf apache-tomcat-7.0.56.tar.gz

Para proceder a montar las instancias de tomcat hay que tener en cuenta que ha de hacerse la instalación de cada instancia en 2 partes: una parte común a cada instancia que va en una ruta igual para todas las instancias, y una segunda parte que se monta en una ruta diferenciada para cada instancia.

En nuestro caso:

mv /home/usuario/apache-tomcat-7.0.56 /usr/local/
ln -s /usr/local/apache-tomcat-7.0.56 /usr/local/tomcat7

Ajustamos los permisos:

chown -R tomcat7:tomcat7 /usr/local/tomcat7

Ficheros comunes: CATALINA_HOME

/usr/local/tomcat7/bin
/usr/local/tomcat7/lib
/usr/local/tomcat7/endorsed

Ficheros por cada instancia: CATALINA_BASE:

/var/www/instancia-xx/conf
/var/www/instancia-xx/logs
/var/www/instancia-xx/temp
/var/www/instancia-xx/watch
/var/www/instancia-xx/webapps
/var/www/instancia-xx/work

Donde instancia-xx es la ruta que debes de cambiar para cada instancia. Para hacerlo rapido copiamos del CATALINA_HOME las rutas que deben estar diferenciadas:

Creamos las carpetas de cada instancia:

mkdir -p /var/www/instancia-01
mkdir -p /var/www/instancia-02
mkdir -p /var/www/instancia-03
mkdir -p /var/www/instancia-04

Asignamos permisos:

chown -R tomcat7:tomcat7 /var/www/instancia-0*
chmod -R 755 /var/www/instancia-0*/webapps/

Desde CATALINA_HOME copiamos las carpetas correspondientes a cada CATALINA_BASE, en la ruta de cada instancia.

cp -p -r /usr/local/tomcat7/conf/ /var/www/instancia-01/
cp -p -r /usr/local/tomcat7/logs/ /var/www/instancia-01/
cp -p -r /usr/local/tomcat7/temp/ /var/www/instancia-01/
cp -p -r /usr/local/tomcat7/watch/ /var/www/instancia-01/
cp -p -r /usr/local/tomcat7/webapps/ /var/www/instancia-01/
cp -p -r /usr/local/tomcat7/work/ /var/www/instancia-01/

cp -p -r /usr/local/tomcat7/conf/ /var/www/instancia-02/
cp -p -r /usr/local/tomcat7/logs/ /var/www/instancia-02/
cp -p -r /usr/local/tomcat7/temp/ /var/www/instancia-02/
cp -p -r /usr/local/tomcat7/watch/ /var/www/instancia-02/
cp -p -r /usr/local/tomcat7/webapps/ /var/www/instancia-02/
cp -p -r /usr/local/tomcat7/work/ /var/www/instancia-02/

cp -p -r /usr/local/tomcat7/conf/ /var/www/instancia-03/
cp -p -r /usr/local/tomcat7/logs/ /var/www/instancia-03/
cp -p -r /usr/local/tomcat7/temp/ /var/www/instancia-03/
cp -p -r /usr/local/tomcat7/watch/ /var/www/instancia-03/
cp -p -r /usr/local/tomcat7/webapps/ /var/www/instancia-03/
cp -p -r /usr/local/tomcat7/work/ /var/www/instancia-03/

cp -p -r /usr/local/tomcat7/conf/ /var/www/instancia-04/
cp -p -r /usr/local/tomcat7/logs/ /var/www/instancia-04/
cp -p -r /usr/local/tomcat7/temp/ /var/www/instancia-04/
cp -p -r /usr/local/tomcat7/watch/ /var/www/instancia-04/
cp -p -r /usr/local/tomcat7/webapps/ /var/www/instancia-04/
cp -p -r /usr/local/tomcat7/work/ /var/www/instancia-04/

Para poder levantar las instancias tenemos que cambiar varios parámetros en el fichero server.xml de cada instancia.

instancia-01

<Server port="8005" shutdown="SHUTDOWN">
Connector port="8080" protocol="HTTP/1.1"
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

instancia-02

<Server port="8105" shutdown="SHUTDOWN">
Connector port="8180" protocol="HTTP/1.1"
<Connector port="8109" protocol="AJP/1.3" redirectPort="8443" />

instancia-03

<Server port="8205" shutdown="SHUTDOWN">
Connector port="8280" protocol="HTTP/1.1"
<Connector port="8209" protocol="AJP/1.3" redirectPort="8443" />

instancia-04

<Server port="8305" shutdown="SHUTDOWN">
Connector port="8380" protocol="HTTP/1.1"
<Connector port="8309" protocol="AJP/1.3" redirectPort="8443" />

Esto impide que haya conflictos a la hora de levantar las instancias.

El siguiente paso es configurar un script de arranque de las instancias.

vi /etc/init.d/tomcat7-01

#!/bin/sh
### BEGIN INIT INFO
# Provides: Tomcat
# Required-Start: $network
# Required-Stop: $network
# Default-Start: 2 3 5
# Description: Java Servlet and JSP Engine
### END INIT INFO

JAVA_HOME=/usr/lib/jvm/java-7-oracle/
JAVA_OPTS="-Xmx800m -Xms800m"
CATALINA_HOME=/usr/local/tomcat7
CATALINA_BASE=/var/www/instancia-01

case "$1" in
'start')
$CATALINA_HOME/bin/catalina.sh start
;;
'stop')
$CATALINA_HOME/bin/catalina.sh stop
;;
*)
echo "Usage: $0 { start | stop }"
;;
esac
exit 0

Creamos los otros 3 scripts de arranque y cambiamos el parámetro CATALINA_BASE para cada instancia.
En el caso del JAVA_OPTS, podemos configurar la memoria según la configuración de memoria física instalada en el servidor y los requerimientos de las aplicaciones que queramos desplegar.

Procedemos a darle permisos de ejecución a los scripts:

chmod 755 /etc/init.d/tomcat7-0*

Ya podemos arrancar con los servicios invocando el script con:

/etc/init.d/tomcat7-01 start

Añadimos el script al arranque del servidor:

chkconfig --add tomcat7
chkconfig tomcat7 on

Procedemos a la configuración del cluster. En este caso tenemos que añadir las configuraciones de cluster a cada uno de los 8 ficheros server.xml (1 por cada instancia y en 2 servidores, total 8).

Como ejemplo añado la configuración de 1 instancia en los 2 servidores y el resto de los ficheros solo es una cuestión de usar puertos distintos y cambiar las direcciones ip a las que hay que conectar cada instancia:

Instancia 01, Servidor 01

className="org.apache.catalina.ha.tcp.SimpleTcpCluster" channelSendOptions="8">

Instancia 01, Servidor 02

className="org.apache.catalina.ha.tcp.SimpleTcpCluster" channelSendOptions="8">

Para que cada instancia solo se vea con su par en la dirección del modulo Membership tiene que ser distinta en cada par de instancias que conforman el cluster.

En nuestra configuración la instancia-01 se comunica con su par por 228.0.0.4, la instancia-02 se comunica con su par por 228.0.0.5, la instancia-03 se comunica con su par por 228.0.0.6, y la instancia-04 se comunica con su par por 228.0.0.7

Esto debe de respetarse en las configuraciones de cada cluster ya que sino el funcionamiento sera erratico y fallara el FarmDeployer.

Este ultimo modulo esta definido en las ultimas 6 lineas de cada configuración del cluster, y permite que poniendo un war dentro de la carpeta definida como watchDir, el war en cuestión se despliegue en todos los servidores del cluster.

Esto solo debe de hacerse en el servidor que consideremos como master de la configuración (osea el numero 1) para tener un unico punto de publicación. Es por eso que en el servidor 2 ponemos el parametro watchEnabled=false.

El ultimo tema que debemos de tratar es el mantenimiento de sesión. En el cluster que hemos montado, el primer modulo es el que indica como se comporta el cluster en cuanto al manejo de sesión.

className="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"/>

Los 2 nodos están configurados como DeltaManager, que es como decir que los 2 funcionan como Master en el manejo de sesiones. Los 2 servidores mantienen en memoria las sesiones de su servidor gemelo, para que en caso de que haya caída de un servidor, no se vea afectado el servicio. Esta configuración es la ideal para un balanceo de carga, ya que el balanceador reparte la carga entre todas las maquinas del cluster y si una de ellas cae, la saca del grupo y sigue repartiendo la carga al resto de servidores.

Para que los tomcats no se hagan un lio con las sesiones, debemos de configurar en cada instancia el JVMRoute de manera diferente.

name="Catalina" defaultHost="localhost" jvmRoute="servidor01-instancia-01">

lo que hace el servidor es añadir este jvmRoute como parte del id de sesión para poder almacenarlos de manera distintiva.

Lo unico que nos queda es ver en el log que los miembros del cluster se añaden y se eliminan con normalidad:

may 24, 2014 10:25:06 AM org.apache.catalina.ha.tcp.SimpleTcpCluster memberAdded
Información: Replication member added:org.apache.catalina.tribes.membership.MemberImpl[tcp://{192, 168, 0, 210}:4100,{192, 168, 0, 210},4100, alive=36148, securePort=-1, UDP Port=-1, id={54 -103 16 -90 92 20 67 -28 -101 -88 19 22 109 -78 44 77 }, payload={}, command={}, domain={}, ]

El cluster ya esta completamente configurado a nivel de tomcat.

El siguiente paso es configurar Los apaches para poder servidor las aplicaciones por el puerto 80 para verlas desde un navegador y con una URL facilmente recordable/escribible.

Para ello debemos de instalar en los servidores apache el paquete mod_jk

apt-get install libapache2-mod-jk

Solo tenemos que configurarlo de la siguiente manera:

 vi /etc/apache2/mods-enabled/jk.conf
# Where to find workers.properties
JkWorkersFile /etc/libapache2-mod-jk/workers.properties

# Where to put jk logs
JkLogFile /var/log/apache2/mod_jk.log

# Set the jk log level [debug/error/info]
JkLogLevel info

JkShmFile /var/log/apache2/jk-runtime-status

# Select the log format
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "

# JkOptions indicate to send SSL KEY SIZE
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories

JkMount /contexto_de_la_aplicacion_01/ ajp13_worker_01
JkMount /contexto_de_la_aplicacion_02/ ajp13_worker_02
JkMount /contexto_de_la_aplicacion_03/ ajp13_worker_03
JkMount /contexto_de_la_aplicacion_04/ ajp13_worker_04

JkMount /contexto_de_la_aplicacion-01/*.do ajp13_worker_01
JkMount /contexto_de_la_aplicacion-02/*.do ajp13_worker_02
JkMount /contexto_de_la_aplicacion-03/*.do ajp13_worker_03
JkMount /contexto_de_la_aplicacion-04/*.do ajp13_worker_04

# vi /etc/libapache2-mod-jk/workers.properties

worker.list=loadbalancer,stat1,ajp13_worker_01,ajp13_worker_02,ajp13_worker_03,ajp13_worker_04

worker.ajp13_worker_01.port=8009
worker.ajp13_worker_01.host=192.168.0.209
worker.ajp13_worker_01.type=ajp13
worker.ajp13_worker_01.lbfactor=1

worker.ajp13_worker_02.port=8109
worker.ajp13_worker_02.host=192.168.0.209
worker.ajp13_worker_02.type=ajp13
worker.ajp13_worker_02.lbfactor=1

worker.ajp13_worker_03.port=8209
worker.ajp13_worker_03.host=192.168.0.209
worker.ajp13_worker_03.type=ajp13
worker.ajp13_worker_03.lbfactor=1

worker.ajp13_worker_04.port=8309
worker.ajp13_worker_04.host=192.168.0.209
worker.ajp13_worker_04.type=ajp13
worker.ajp13_worker_04.lbfactor=1

En esta configuración cada worker controla las peticiones que llegan al apache y las deriva a la instancia que corresponde.
En nuestro caso la ip 192.168.0.209 corresponde a la ip del grupo de balanceo interno sobre el que tenemos el tomcat.

Por último en la configuración de los vhost de apache tenemos que configurar el punto de montaje de mod_jk, para que envie las peticiones a cada worker según la aplicación que este montada en cada instancia. Añadimos la configuración a nuestro virtual host preconfigurado.

vi /etc/apache2/sites-enabled/vhost-balanceo-tomcat.conf

JkMount /contexto_de_la_aplicacion-01/* ajp13_worker_01

Options -Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all

JkMount /contexto_de_la_aplicacion-02/* ajp13_worker_02

Options -Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all

JkMount /contexto_de_la_aplicacion-03/* ajp13_worker_03

Options -Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all

JkMount /contexto_de_la_aplicacion-04/* ajp13_worker_04

Options -Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
Mas Información:Instalación de la maquina virtual de Java

Como monitorizar la ejecucion de un cron de manera básica

bash

bash

Queremos monitorizar el servicio de cron en Linux, para un cron concreto. Dicho cron se lanza cada 15 minutos y queremos asegurarnos de que el cron lo ejecuta (bien o mal nos da lo mismo). El metodo para tener una notificacion si el cron no se ha ejecutado es la siguiente.

Primero instalamos el cron que queremos monitorizar, y le forzamos a escribir un fichero de log, con la informacion que queramos (lo que nos interesa es que se escriba en el mismo momento en que se ejecuta el cron).

El siguiente paso es crear el siguiente script


vi /home/user/scripts/cron/log/check_cron.sh

#!/bin/bash

file="/home/user/scripts/cron/log/salidaCron.`date +%d%m%g`.txt"
limite="/home/user/scripts/cron/log/limite"
touch -d '-16 minutes' $limite
if [ $limite -nt $file ]; then
  echo"----------------------------------------------------------------------" >> /tmp/timestamp
  echo "La fecha de modificacion del log es: " >> /tmp/timestamp
  stat $file | grep Modify| cut -d: -f2,3,4| cut -d. -f1 >> /tmp/timestamp
 echo "" >> /tmp/timestamp
  echo"----------------------------------------------------------------------" >> /tmp/timestamp
cat   /tmp/timestamp|  mail -s "Fallo de ejecucion de Script" user@dominio.com
fi

Este script hace lo siguiente:
-Crea un fichero con el comando touch con la hora actual menos el numero de minutos que queramos. En nuestro caso le ponemos 1 minuto mas que la frecuencia de ejecucion del cron que queremos monitorizar.
– Compara lel timestamp del fichero del limite que hemos marcado para comprobar el servicio, con el log que escribe el servicio instalado en el cron.
– Si la fecha del log supera el limite que hemos marcado, quiere decir que el cron se ha parado, y nos notifica al correo enviando el texto que hayamos definido.
– En nuestro caso veremos que el correo se manda a una hora superior a los 16 minutos de limite que hemos marcado, y con ello el fallo del servicio.
-Debido a que el script solo manda el correo ante fallo, lo instalaremos en un cron con la frecuencia que queramos. No demasiado alta porque si es asi, nos notificara con retraso.

Adjunto los crones como los tengo instalados:

*/15 * * * * /usr/bin/java -jar /home/user/scripts/cron/dist/.hagoloquesea.jar >> /home/ulysse/scripts/cron/log/salidaCron.$(date +\%d\%m\%g).txt
*/5 * * * * /home/user/scripts/cron/log/check_cron.sh

Tutorial de uso de Amazon EC2. Creando maquina virtuales gratis.

Desde hace mucho tiempo llevo trabajando en servicios de hosting, viendo la evolución de los productos que ofrecen los distintos proveedores de alojamiento. También he ido viendo las tendencias en los modelos de alojamiento: desde los hostings compartidos en España que valían una pasta larga por tener 20 MB en web, una base de datos Mysql y 5 cuentas de correo, hasta los potentes servicios de Hosting dedicado en los que había que invertir un buen capital, tanto en la contratación del servicio como en el personal para su administración y el consumo de recursos adicionales (red, backup…) que exigía mensualmente.

Desde hace ya unos años, el hosting se ha ido globalizando y extendiendo, y los precios han caído dramáticamente. Hoy en día se puede tener un hosting para una web estática por un par de dolares mensuales con espacio para aburrir y con un montón de cuentas de correo (aunque no las necesites).

También el hosting dedicado ha caído en picado, y hoy en día se puede tener un hosting dedicado básico por unos 50$ al mes. Para los que no tengan conocimientos o no necesiten potencia sigue estando los planes compartidos. Para los avanzados están los planes dedicados.

Hoy en día tendemos al hosting en cloud, como ya hablamos en el post de Gigas de hace un par de semanas. El cloud permite crear maquinas dedicadas en tiempo record y construir auténticas granjas de servicios con una complejidad extrema en días, cuando no hace mucho se tardaban meses. Desde el dimensionamiento de la plataforma, el pedido de servidores, la instalación de todas las maquinas, y finalmente construcción del servicio a ofrecer. Mucho tiempo y mucho dinero en recursos que hoy en día se realiza prácticamente en 4 clicks de ratón.

Y para poner un ejemplo hoy os dejo un manual de creación de una maquina virtual con Amazon AWS EC2. El servicio EC2 (Elastic Compute Cloud) permite crear maquinas virtuales dedicadas de múltiples tamaños y desde coste cero €.

Amazon nos permite crear instancias de servidores dedicados con una carga muy pequeña para aprender a manejar el servicio sin coste. Por mi parte os enseño con este tutorial como conseguirlo desde crear la instancia hasta arrancar el servidor dedicado y empezar su administración.

1º Conectar a la consola de AWS
Nos logeamos a la consola de Amazon desde https://console.aws.amazon.com/s3/home con nuestro usuario y contraseña (damos por sentado que ya nos hemos creado una cuenta de AWS). Una vez ingresados los datos de usuario y contraseña, observamos un marco con múltiples pestañas con todos los servicios que facilita AWS. Para poder crear maquinas virtuales, tenemos que irnos a la pestaña EC2.

2º Selección de zona de despliegue
El Cloud de Amazon permite seleccionar el “edge” o zona del mundo en donde desplegar tus maquinas. Esto es útil si tu servicio se va a ofrecer en una zona del mundo concreta, ya que los tiempos de latencia de red se incrementan si el cliente y el servidor están a mucha distancia. en nuestro caso tenemos una zona en Irlanda para dar cobertura a toda Europa que nos viene muy bien para nuestro propósito.

Pulsar para ampliar!!

Pantalla inicial del servicio

3º Creación de Instancia de Maquina Virtual
Si pulsamos el botón Launch instance empezamos a crear el servidor virtual con los parámetros que nosotros queramos:

Pulsar para ampliar!!

Selección de instalador Asistente/Avanzado

Pulsar para ampliar!!

Seleccionamos el Sistema Operativo y el tipo de procesador 32/64 Bits. Los indicados con una estrella se pueden usar como una instancia gratuita de tamaño Micro.

Pulsar para ampliar!!

Selección de Subzona dentro de la zona geográfica designada para arrancar el servidor

Pulsar para ampliar!!

El sistema permite usar un tipo de Kernel y de Memoria determinado previamente para otra instalación. Normalmente se dejara por defecto que el sistema decida cual es la mejor opción.

Pulsar para ampliar!!

Añadimos etiquetas al servidor para poder distinguirlo en el futuro. Si tenemos una sola maquina no es problema. Si manejamos 100 es importante poder distinguir que hace cada una de ellas.

Pulsar para ampliar!!

En esta parte creamos un par de claves RSA para poder acceder al servidor una vez arrancado. Después de crear la clave nos descargamos la private key que usaremos para acceder al terminal Linux por SSH. La clave publica se sitúa dentro del servidor en /root/.ssh/authorized_keys

Pulsar para ampliar!!

En este paso debemos de indicar la política de acceso al servidor para poder tanto manejarlo como dar servicio a aplicaciones. Lo mas critico es darle acceso al puerto 22 si es un servidor linux desde tu dirección ip origen si la sabes, o desde 0.0.0.0 (cualquier IP de internet) si no te la sabes o quieres acceder desde cualquier parte.

Pulsar para ampliar!!

Una vez configurados los pasos anteriores, llegamos al resumen antes de arrancar la maquina. Si todo es correcto, finalizamos el asistente. Podemos editar todas las opciones si hemos configurado mal alguna de ellas.

Pulsar para ampliar!!

Ya podemos ver en la lista de maquinas virtuales que se esta configurando la nueva instancia. En un par de minutos la maquina ya es accesible

4º Configuración de red del servidor creado
Ya solo nos queda acceder a él, y para ello necesitamos una dirección ip. En la sección Network & Security tenemos la opción de Elastic IP. Seleccionamos la opción “Allocate New Address”, seleccionamos EC2 para poder asignarla a una maquina virtual y ya tenemos la ip lista para usar.

Pulsar para ampliar!!

Una vez creada la IP en "Elastic IP" seleccionamos "Associate Address" y obtenemos una lista de los servidores a los que le podemos asociar la dirección IP. Una vez seleccionado y confirmado con el botón correspondiente, el servidor es accesible a través de la ip que ha generado el sistema.

Listo para acceder al servidor recién creado!
El servidor ya esta listo para acceder. Suponemos que si has llegado hasta aquí y necesitas usar una maquina dedicada linux, es porque tienes al menos unos conocimientos básicos de sistemas. Sino ahí van unos consejos:

Para conectar por SSH al servidor se usa un cliente de SSH, por ejemplo el mas universal es Putty. El puerto por defecto para acceder al servidor por SSH es el 22. Es interesante cambiarlo ya que los ataques de fuerza bruta usan puertos por defecto para intentar asaltar maquinas. El acceso inicial se hace como usuario root, aunque si eres muy osado y creas tu maquina con otras AMI distinta de la que yo he usado, puede que tenga otro usuario distinto de root para el acceso inicial. Si aun así el acceso es con root, es importante filtrar el demonio SSH para que no se permita el acceso de root directo sino a través de un usuario sin privilegios, ademas de que no se permita el inicio de sesión interactiva ni a cualquier usuario del sistema.

Enlaces útiles:
Página de inicio de Amazon AWS
Calculadora de Costes, por si quieres montar algo mas potente.
Cliente de SSH Putty

Apache ha pegado un pete.

Debido segun dicen ellos a que una clave SSH ha quedado compremetida, la web de apache.org lleva tirada toda la mañana con el siguiente mensaje: 

The Infrastructure Team of The Apache Software Foundation is currently investigating a
potential compromise of one of our servers. For security reasons most apache.org
services are therefore offline, but will be restored shortly. We apologies for any
inconvenience this may cause. 

10:42am UTC: Compromise was due to a compromised SSH Key, not due to any software
exploits in Apache itself.

More details soon.

10:53am UTC: We have restored services on our european mirror machine which was
not compromised. DNS should be shifting you over right about … now..

 

Pues esto no lo habia visto nunca. A saber cuales son las verdaderas razones.

Visto en Apache.org

  • Social


    Follow Me on Pinterest
  • Suscribete al Blog por Email

    Escribe tu direccion de Email para suscribirte a este Blog y recibir notificaciones de los nuevos posteos por Correo Electrónico.

  • A lo largo del Tiempo

  • -->