Archive for category Linux

Instalar PostgreSQL 8.3 en CentOS desde Yum

Trabajar con servidores Linux, muchas veces comporta trabajar con CentOS. CentOS es una distribución de Linux muy orientada a servidores corporativos y ofrece un rendimiento muy alto en una amplia gama de entornos.

Para trabajar con este sistema es mejor estar habituado al trabajo con el gestor de paquetes de Red Hat (RPM) y Yum, sino tendremos que buscar información sobre como manipular los repositorios y encontrar el software necesario para nuestras aplicaciones. En el siguiente artículo intentaré detallar como instalar un servidor de bases de datos PostgreSQL 8.3 en un CentOS 5.2 (mis pruebas se han realizado en una instancia de Amazon EC2 con una imagen de CentOS 5.2 proporcionada por RightScale).

Desactivar los repositorios por defecto de CentOS

Para poder instalar la versión 8.3 de PostgreSQL tenemos que deshabilitar los repositorios de PostgreSQL que vienen con nuestro sistema operativo. Si no hicieramos este paso es posible que sólo consiguiéramos instalar la vesión que proporcionan los paquetes de la distribución en cuestión.

Para desactivar dichos repositorios debemos editar el fichero /etc/yum.repos.d/CentOS-Base.repo. Yo lo hago con Nano porque me parece un editor más ligero que otros pero el editor cada uno prefiere el suyo:
$> nano /etc/yum.repos.d/CentOS-Base.repo
Y en las secciones base y updates tenemos que excluir PostgreSQL, Para ello añadiremos exclude=postgresql* al final de cada sección. Dichas secciones deben acabar pareciendose a lo siguiente:
[base]
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep$
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
exclude=postgresql*

[updates]
name=CentOS-$releasever - Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep$
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
exclude=postgresql*

Añadir los repositorios de PostgreSQL 8.3

Una vez desactivados los repositorios por defecto debemos definir los nuevos repositorios. Para ello utilizaremos los RPM de la página de repositorios de PostgreSQL. En la página copiaremos en enlace de la última versión de la rama 8.3 y iremos a la línea de comandos:
$> cd /tmp
$> wget http://yum.pgsqlrpms.org/reporpms/8.3/pgdg-centos-8.3-6.noarch.rpm
$> rpm -ivh pgdg-centos-8.3-6.noarch.rpm

NOTA: Recuerda que debes cambiar la URL de descarga del paquete RPM por la que corresponda en el momento que realices la operación.

Instalar el servidor de base de datos

Una vez activados los repositorios tenemos que instalar el servidor de base de datos:
$> yum install postgresql postgresql-server
Es posible que en este paso nos de un problema de librerías por culpa de un paquete llamado apr-util. En este caso deberemos instalar primero este paquete (por separado) y luego volver a lanzar la instalación del servidor:
$> yum install apr-util
$> yum install postgresql postgresql-server

La solución al problema de dependencias no debería reproducirse si instalamos el servidor de bases de datos en estos dos pasos.

Arrancar el servidor y habilitar conexiones remotas

Para arrancar el servidor seguiremos los pasos siguientes:
$> service postgresql initdb
$> service postgresql start

Con esto ya tendremos el servidor de base de datos arrancado y aceptando conexiones en local, pero no podremos acceder al servidor desde conexiones remotas. Para habilitar las conexiones remotas debemos asegurarnos que no hay ningún tipo de bloqueo que no sea el del servidor Postgre, modificar dos ficheros y reiniciar el servicio. El primer fichero que vamos a modificar es /var/lib/pgsql/data/pg_hba.conf.

En pg_hba.conf se tiene que dar acceso a la red desde la que vamos a acceder (dirección IP), en el ejemplo vamos a usar 0.0.0.0/0 pero se debería cambiar por nuestra dirección para tener un control más estricto. Para dar acceso a una red añadiremos los siguiente al fichero:
host all all 0.0.0.0/0 trust

El segundo fichero que debemos modificar es /var/lib/pgsql/data/postgresql.conf. En este debemos buscar la línea que pone:
listen_addresses='localhost'
Y poner:
listen_addresses='*'

Una vez realizados estos cambios se tiene que reiniciar el servicio:
$> /etc/init.d/postgresql restart

En teoria, cuando el servicio arranque de nuevo debería ser posible establecer conexiones remotas al servidor con el usuario postgres y el password que le corresponda. En caso de que no se haya definido password para dicho usuario, éste se puede setear de forma manual. Como usuario ROOT ejecutamos el siguiente comando:
passwd postgres
El sistema nos pedirá que introduzcamos dos veces el password y listo! Espero que les sirva de ayuda.

, , , ,

3 Comments

Modificar la cantidad de memoria disponible para Tomcat

El rendimiento por defecto de un servidor Tomcat 6 es, normalmente, bastante bajo. Hace un par de días estaba realiando unas operaciones de recuperación de una aplicación en la que estamos trabajando y el servidor tardó varias horas en finalizar unas operaciones bastante básicas. Normalmente estas operaciones, al tomar tanto tiempo, se dan por perdidas en algún tipo de “deadlock” y se abortan (a no ser que se tenga el conocimiento de que van a durar tanto); pero a mi se me quedó la aplicación abierta en segundo plano (lo se… soy un desastre) y al final terminó las operaciones.

Al observar este comportamiento, recordé que había unos parámetros de configuración del Tomcat que modificaban el tamaño inicial y máximo de la pila de Java para un proceso y me puse a rebuscar entre las configuraciones de los diversos servidores con Tomcat a los que tenía acceso para recuperar esta pequeña “customización”.

Para modificar el tamaño inicial y máximo de la pila de Java para Tomcat (6) debemos modificar el archivo catalina.sh dentro del directorio bin en la raíz del directorio que contiene la instalación del Tomcat. La línea para añadir es la siguiente:
JAVA_OPTS="$JAVA_OPTS -Xms64M -Xmx1024M"
NOTA: Es importante que esta línea se añada furea de cualquier IF-ELSE del documento. Yo siempre lo añado justo antes de una línea comentada que pone Execute The Requested Command entre guiones, pero esto ya es a gusto del consumidor ;-)

El número que va después de -Xms es el tamaño inicial de la pila y el que va después de -Xmx es el tamaño máximo de ésta. La “M” sólo es para indicar que las dimensiones se están dando en MegaBytes. Dependiendo de los recursos de los que goza la máquina dónde tengamos el Tomcat estos parámetros deberán cambiar pero, por norma general, seguro que conseguimos una mejora en el rendimiento de nuestro servidor de aplicaciones Java.

, , ,

3 Comments

Problemas con Eclipse en Ubuntu 9.10

Si se trabaja con Eclipse, sea cual sea el lenguaje de programación que utilicemos, con el salto a Ubuntu 9.10 nos podemos encontrar que algunos botones dejan de funcionar correctamente.

Tanto con Eclipse como con otro software para Java (como Tomcat por ejemplo) soy partidario de descargar la versión adecuada del sitio web oficial. No es que no encuentre útil los paquetes .deb de los repositorios (para mi representan el 99% o más del software que tengo instalado en mi Ubuntu), sino que el software relacionado con Java me gusta tenerlo lo más “empaquetado” posible y conocer perfectamente dónde se han situado los archivos de configuración de dichos programas (a veces con el uso de apt-get perdemos un poco el control de dónde se encuentran algunos archivos de configuración).

Pues bien, como decía al principio de este apunte, con el paso a Ubuntu 9.10 he sufrido algún problema con muchas de las versiones de Eclipse (3.2, 3.4 y 3.5). El problema reside en que el programa parece no responder a según que botones. Para resolver este problema debemos crear un script (p.e: eclipse.sh) y poner los siguientes comandos:

#!/bin/sh
export GDK_NATIVE_WINDOWS=1
/path/a/eclipse/eclipse

Sustituyendo /path/a/eclipse/eclipse por la ruta donde se encuentra el archivo ejecutable de eclipse. Para arrancar damos permisos de ejecución a dicho archivo:

sudo chmod +x eclipse.sh

Y ejecutamos Eclipse desde consola o desde Nautilus con este script (siempre).

Con esto solucionaremos los problemas de los botones de Eclipse en Ubuntu 9.10
eclipse

, , , , ,

No Comments

Problemas al instalar Ubuntu 9.10 en un disco SATA

Con la llegada del Koala me ha surgido un problema para instalar Ubuntu en una máquina que tengo por casa.

Esta máquina tiene una placa base con dos puertos SATA, pero nunca he podido instalar Ubuntu (u otra distribución de Linux) con un disco de este tipo en modo nativo. Para instalrlo siempre he recurrido al modo RAID (desde la BIOS) para que me reconociera la unidad y no me había dado más problemas.

Después de ver que la actualización de 9.04 a 9.10 no funcionaba tan bien como me esperaba, me decidí a instalar el Koala desde cero. El problema era que en la pantala de definición de las particiones no aprecía la unidad SATA (un problema gordo si sólo tienes una unidad de este tipo). Para solucionar este problema decidí recurrir a los foros de ayuda de Ubuntu y, evidentemente, alguien había tenido este problema antes y aquí va la solución…

Instalar Ubuntu 9.10 en un disco SATA en modo RAID

  1. Arrancamos desde el CD de instalación de Ubuntu y entramos en modo Live CD (no instalación)
  2. Una vez arrancado el sistema desde el CD abrimos el terminal
  3. Eliminamos el paquete dmraid:
    sudo apt-get remove dmraid
  4. Arrancamos la instalación desde el icono del escritorio
  5. Instalamos el sistema con las unidades SATA presentes en el particionador

UbuntuKarmicKoala

Espero que os ayude :-)

, , , ,

4 Comments

Tomcat 6 en Ubuntu

Este es un post corto para poner de manifiesto un opinión basada en la experiencia profesional que he recogido trabajando con este servidor de aplicaciones y Ubuntu (versiones 9.04 y 9.10)
apache-tomcat_logo_nomatte

Cuando trabajeis con Tomcat 6 bajo Ubuntu, seguid estos pasos:

  1. Eliminad TODO rastro de OpenJDK
  2. Instalad el paquete de Java de Sun (sun-java6-jdk en mi caso)
  3. Descargad el Core de la página oficial de Tomcat
  4. Descomprimid el paquete y ubicad los archivos en la carpeta /usr/share/tomcat6

Siguiendo estos pasos en lugar del facílisimo “sudo apt-get install tomcat6″ tendremos una instalación de Tomcat completamente “compacta”. En el momento que deseáramos llevarnos esta instalación de Tomcat a otra máquina sólo necesitaríamos copiar los archivos y comprovar que en la máquina destino tenemos una versión compatible de Java.

Para arrancar el servidor tendremos que ejecutar como root ‘startup.sh’ en el directorio ‘/usr/share/tomcat6/bin/’ y para pararlo ‘shutdown.sh’ en el mismo directorio.

Disfrutad de vuestro Tomcat 6 ;-)

, , , ,

No Comments

Problema con un monitor externo y un portátil en Ubuntu 9.04

La detección y configuración de hardware en las últimas versiones de Ubuntu es, realmente, muy efectiva. Hace tiempo que la instalación de Ubuntu me resulta placentera porque en pocas ocasiones hace falta terminar de configurar ningún componente (con la excepción de mi Macbook blanquito).

Uno de los problemas principales a la hora de migrar a Ubuntu (y Linux en general) es la instalación de hardware una vez el sistema se ha instalado. Si el hardware se detecta automáticamente perfecto… No hace falta mover ni un dedo! Pero si el hardware no se detecta o se detecta de forma erronea, ya podemos cruzar los dedos para que le haya pasado a un friki mayor que nosotros, lo haya solucionado y lo haya empaquetado en un .deb.

Mi experiencia personal me dice que si el hardware no se detecta hay más esperanza que si se ha detectado pero no funciona correctamente, pero para esto ya hay opiniones para todos los gustos.

Después de esta pequeña introducción ya podemos adentrarnos en el tema que nos ocupa: un monitor externo en un portátil no detecta la resolución de forma correcta en Ubuntu 9.04.

NOTA: Los desastres que puedan suceder después de seguir estos pasos no son responsabilidad mia. A mi me han funcionado, cosa que no implica que funcione contigo!

  1. Conecta tu monitor a la salida VGA correspondiente.
  2. Crea un copia de seguridad de tu archivo de configuración xorg.conf:
    $ sudo cp /etc/X11/xorg.conf /etc/X11/xorg.conf.bak
  3. Borra el archivo de configuración:
    $ sudo rm /etc/X11/xorg.conf
  4. Reinicia el equipo con el monitor conectado y no te pongas nervioso! Cuando te aparezca un diálogo feo dile que ya sabes que no está el archivo de configuración y que quieres que se autogenere.
  5. Cuando inicies session con tu usuario configura las resoluciones desde la aplicación de System > Preferences > Display. Verás como las resoluciones de tu monitor externo han mejorado sensiblemente ;-)

Si se ha roto algo… me parece que es culpa del blog de al lado…

, , ,

3 Comments

Añadir un slave a un entorno de replicación MySQL

Siguiendo el hilo de los artículos de Laura Berdasco sobre levantar un entorno de replicación Master-Slave en MySQL, Vamos a explicar como añadir un esclavo más a un entorno de este tipo funcionando.
Estos pasos se han realizado en instancias de EC2 con acceso al puerto 3306 desde Internet (se pueden endurecer las políticas de seguridad en este punto pero para realizar las pruebas ya nos servirá esta configuración) y acceso por SSH en sistemas Ubuntu 8.10.

Para añadir un esclavo a un entorno debemos seguir los siguientes pasos:

  • Paramos el servidor MySQL del esclavo en funcionamiento (de aquí en adelante slave-1). En la consola del slave-1 con el siguiente comando:
    sudo /etc/init.d/mysql stopPara ejecutar este comando debemos acceder a la consola del slave-1 por SSH o localmente.
  • Paramos también le servidor MySQL del esclavo que queremos arrancar (de aquí en adelante slave-2). En la consola del slave-2 con el mismo comando que en paso anterior.
  • Copiamos los archivos del direcotrio /var/lib/mysql del slave-1 al slave-2. Para esta operación necesitamos la clave (keypair) para acceder por SSH del slave-1 al slave-2, en nuestro caso se encuentra en /mnt/keypair.pem.

    Si no tenemos este archivo en el slave-1 desde el ordenador en que la tengamos deberemos ejecutar este comando:
    scp -i /path/to/keypair.pem /path/to/keypair.pem root@dns.slave-1.com:/mnt/keypair.pemEste comando nos sube por SSH el archivo keypair.pem situado en /path/to al directorio /mnt del servidor remoto (dns.slave-2.com) identificandose como root con el mismo archivo (opción -i). Para realizar esta acción debemos identificarnos como root (a veces puede fallar la ejecución con ‘sudo’).

    Una vez con el archivo keypair.pem en el slave-1 copiaremos tambien con el comando ‘scp’ el contenido del directorio /var/lib/mysql de slave-1 al slave-2. En la consola del slave-1:
    scp -r -i /mnt/keypair.pem /var/lib/mysql/* root@dns.slave-2.com:/var/lib/mysql/Cuando se hayan copiado todos los archivos podemos poner en marcha el servidor MySQL del slave-1.

  • Una vez copiados estos archivos es importante cambiar el propietario. En la consola del slave-2 ejecutar los siguientes comandos:
    cd /var/lib/mysql
    sudo chown -R mysql:mysql *
    Si no realizamos este cambio de propietario es posible que el servidor de MySQL del slave-2 no arranque correctamente.
  • Cambiar el server-id del slave-2. Editando el archivo con vim o nano tenemos que abrir el archivo /etc/mysql/my.conf y dónde encontremos una linia así (o con otro número):
    ...
    server-id=2
    Cambiar el número que aparece por un server-id que no se esté utilizando en el entorno de replicación.
  • Para poder arrancar el servidor MySQL del slave-2 sólo nos queda dar permisos de replicación en el master. En la consola del master entramos en el cliente mysql:
    mysql -u root -pY ejecutamos la siguiente consulta:
    mysql> GRANT REPLICATION SLAVE ON *.* TO 'usuario_replica'@'dns-slave-2.com' IDENTIFIED BY 'pwd_del_usuario_replica';
  • Arrancamos el servidor MySQL del slave-2. En la consola del slave-2 ejecutamos el comando:
    sudo /etc/init.d/mysql start

Para comprovar que todo ha ido correctamente debemos realizar alguna modificación en el master y asegurarnos que se distribuye a las dos replicas afectadas. Para más información podeis visitrar los compeltos artículos que Laura tiene en su blog sobre la replicación en MySQL: Replicación MySQL con Master-Slave sobre Ubuntu 8.10 (master) y Replicación MySQL con Master-Slave sobre Ubuntu 8.10 (slave).

, , , , , ,

No Comments

Mover los archivos de datos de MySQL Server

En ocasiones es posible que nos interese tener los archivos dónde se encuentran los datos de MySQL en un directorio diferente del que viene configurado en la instalación del servidor. Vamos a ver que pasos debemos seguir si en un momento dado queremos migrar los datos de un MySQL Server a un directorio diferente.

Estos pasos han funcionado en diferentes equipos ejecutando un MySQL Server 5.0 con replicación (tanto en modo master cómo en slave) sobre un sistema Ubuntu 8.10. Los archivos de datos en este caso están almacenados en /var/lib/mysql y los vamos a migrar a /home/mysql

  • Creamos el directorio mysql en /home (si no lo tenemos creado ya):
    cd /home
    sudo mkdir mysql
  • Paramos el servidor de MySQL:
    sudo /etc/init.d/mysql stopEste paso hay diferentes formas de ejecturalo, se puede utilizar cualquier comando que pare el servidor MySQL.
  • Copiamos todo el contenido de /var/lib/mysql a /home/mysql :
    sudo cp -R /var/lib/mysql/* /home/mysql/Es muy importante no dejarse la opción -R ya que es la que nos permite copiar directorios con todo su contenido.
  • Una vez copiado el contenido si vamos al directorio /home/mysql veremos que el propietario de los archivos es root. Por este motivo debemos cambiar el propietario de todos los archivos y directorios (incluído /home/mysql):
    sudo chown -R mysql:mysql /home/mysqlOtra vez la opción -R nos permite realizar la operación recursivamente por todos los sub-directorios.
  • Editamos el fichero de configuración del servidor:
    sudo gedit /etc/mysql/my.confEn este ejemplo hemos empleado Gedit pero evidentemente puede editarse con editores del tipo vi o nano.

    Y en la línea dónde encontramos esto:
    ...
    datadir = /var/lib/mysql

    Ponemos lo siguiente:
    ...
    datadir = /home/mysql

  • Es posible que si intentáramos arrancar el servidor de base de datos funcionara pero en la mayoría de casos debemos modificar la configuración de AppArmor. Primero modificaremos uno de los archivos de configuración:
    sudo gedit /etc/apparmor.d/usr.sbin.mysqldY vamos a realizar la siguiente modificación, dónde nos encontremos con las líneas siguientes:
    ...
    /var/lib/mysql/ r,
    /var/lib/mysql/** rwk,
    Vamos a poner lo siguiente:
    ...
    /var/lib/mysql/ r,
    /var/lib/mysql/** rwk,
    /home/mysql/ r,
    /home/mysql/** rwk,
    Si hacemos estas modificaciones pero no volvemos a arrancar AppArmor no nos va a servir de nada, así que antes de seguir al ultimo paso debemos ejecutar el siguiente comando:
    sudo /etc/init.d/apparmor restart
  • Para finalizar sólo tenemos que volver a arrancar el servidor MySQL:
    sudo /etc/init.d/mysql startSi todo ha ido bien el servidor no tardará mucho en arrancar ;)
    • Si una vez realizados estos pasos queremos asegurarnos que el servidor realmente esta almacenando los datos en el directorio que le hemos señalado podemos crear una base de datos vacía y ir al directorio /home/mysql/ y ejecutando el comando ‘ls’ mirar si se ha creado un directorio con el nombre de la base de datos nueva.

      Espero que os sirva!

, , ,

1 Comment

Variables de entorno en Ubuntu

Como usuario avanzado-administrador de sistemas Linux siempre ha habido un tema que me parecía oscuro y extraño, las variables de entorno.

Tener definido un PATH adecuado para poder disfrutar de la facilidad que supone autocompletar los comandos sólo con apretar el tabulador siempre es recomendable (si no ponemos absolutamente todos los directorios dentro claro…), pero alterar estas variables siempre se supone un trabajo extra que no siempre estamos dispuestos a realizar.

Bien, pues aquí va un pequeño ‘flash’ de como podemos añadir directorios al PATH para encontrar comandos ejecutables y setear variables de entorno:

  • Entramos a editar el archivo /etc/environment como administradores
    sudo gedit /etc/environment
  • Nos vamos a encontrar con el siguiente contenido:
    enviroment
  • Para añadir directorios al PATH sólo tenemos que añadir un separador (:) antes de cerrar las comillas y escribir la ruta absoluta del directorio.
    Si queremos añadir el directorio /home/user/games/WorldOfGoo al PATH nos tendrá que quedar el siguiente contenido en el archivo environment:
    PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/user/games/WorldOfGoo"
  • Para añadir variables de entorno sólo tendremos que escribirlas en una nueva linea.
    Si queremos setar la variable de entorno JAVA_HOME con el valor “/usr/lib/jvm/java-1.5.0-sun” el contenido del archivo será el siguiente:
    PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
    JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun

Podeis encontrar más detalles de variables de entorno en Ubuntu aquí

, , , ,

3 Comments

Tu primera página web con Amazon EC2

En la actualidad, Amazon posee uno de los recursos más interesantes para el hospedaje de aplicaciones web que necesiten gran escalabilidad (tanto para aumentar la capacidad de cómputo como para disminuirla y no pagar por recursos que no nos van a hacer falta). Este recurso es un grupo de servicios web entre los cuales podemos encontrar almacenamiento en S3, bases de datos muy simples con SimpleDB o, el que nos va a centrar en este post, servidores escalables en EC2 (EC2 viene de Elastic Cloud Computing).
aws-tutorial
La explicación teórica de qué es y qué no es EC2 voy a dejarla para un posible post posterior, de la misma forma, tampoco vamos a entrar a describir el proceso de alta en una cuenta de Amazon EC2, que en el fondo se trata de una simple gestión administrativa. Por consiguiente, a partir de aquí sólo vamos a cubrir el cómo visualizar una página web simple partiendo de una cuenta “virgen” de Amazon EC2.

Prerrequisitos

Los prerrequisitos para afrontar el proceso que vamos a describir son los siguientes:

  • Tener localizadas los ficheros de certificado y clave privada del certificado X.509 que nos identifican en los servicios de Amazon.
  • Tener acceso total a la cuenta de Amazon AWS (es lógico pero no está de más comentarlo).

Escoger y arrancar la AMI

Una vez identificados en el sistema de Amazon (ALERTA: dependiendo del navegador y el sistema operativo que estemos utilizando es posible que se nos pida nuestra identificación más de una vez en el proceso) debemos dirigirnos al ‘AWS Management Console’ y dentro de este a la pestaña ‘Amazon EC2′.

Nuestro primer objetivo cuando nos encontremos en dicha pestaña será arrancar una AMI (Amazon Machine Image, en otras palabras un servidor virtual). Esto lo podemos llevar a cabo desde el Dashboard y desde las secciones de Instances y AMIs. Sea cual sea el camino escogido iremos a parar al siguiente diálogo:

aws-tutorial

Como ya hemos comentado en anteriores posts, en este blog hay un aprecio bastante grande a Ubuntu y, por tanto, basaremos esta primera instalación en nuestra distribución favorita. En la pestaña comunity AMIs seleccionaremos sólo los sistemas de 32-bits (para poder escoger la máquina más económica posible) y el sistema operativo Ubuntu. Para la realización de este proceso yo he escogido la imagen con el manifest: alestic/ubuntu-8.10-intrepid-base-20081222.manifest.xml. Es de las primeras opciones que nos aparecen con la versión 8.10 del sistema operativo. Cuando localicemos la AMI sólo tenemos que pinchar en el link “select” y pasar al siguiente paso.

En un primer momento tendremos que crear una clave para identificar nuestras instancias (en el paso ‘Create Key Pair’). Tenemos que ir con sumo cuidado a la hora de guardar esta clave porque nos permitirá el acceso a la instancia por diferentes métodos más adelante. Después de haber creado esta instancia debemos configurar el Firewall de la máquina de forma que sea lo más segura posible pero que podamos acceder a ella por SSH (en un entorno de producción dejaríamos cerrado el puerto para posteriormente dar acceso sólo desde las IP que consideráramos seguras con las herramientas de EC2).

Para acabar de arrancar la máquina virtual sólo nos quedará definir el número de instancias (poned 1), el tipo (poned small, la más barata), seleccionar la Key Pair que acabámos de crear para identificar la instancia y dejar seleccionados los dos grupos en Security groups. No vamos a entrar en las opciones avanzadas porque para mostrar una página web estática no nos afectan pero existe un gran abanico de posibilidades para configurar las AMIs que queremos arrancar.

aws-tutorial1

Una vez pulsado el botón “Launch” vamos a tener que esperar unos segundos para que la máquina arranque definitivamente.

Conectarse de forma remota a la instancia

En la sección de Instances ahora deberíamos ver un registro nuevo (con el status running) que podemos seleccionar. Una vez seleccionado, si hacemos click en el botón Connect nos dará los datos para acceder a la máquina via SSH.

El ejemplo de comando que nos ponen en el diálogo que se abre cuando hacemos click en Connect es un buen ejemplo, si sustituimos el nombredelakeypair.pem por el path completo donde está este archivo en nuestro ordenador podremos acceder a la instancia sin ningún problema. En Ubuntu el path podría ser /home/user/Keys/nombredelakeypair.pem

Instalar un servidor web

Para poder mostrar una página web deberemos instalar un servidor web en la instancia. Podemos decantarnos por Apache2 o Lighttpd para poner un par de ejemplos. En la consola de la instancia con ejecutar el siguiente comando tendríamos el servidor Lighttpd corriendo sin más problemas:
sudo apt-get install lighttpd*En el post anterior hay una explicación más extensa de las posibilidades de este servidor web.

Dar acceso a través del puerto 80 a la instancia

Una vez instalado el servidor web, si nos dirijimos a la DNS pública que nos indica el panel de instancias veremos como el navegador no acaba de encontrar la página que deseamos. Esto es porque por defecto las instancias tienen cerrados los puertos de comunicación (al pagarse por tráfico es conveniente que estén cerrados por defecto). Para poder abrir estos puertos debemos tener instaladas las herramientas de EC2 en nuestro ordenador local.

El siguiente apartado sólo está probado sobre Ubuntu 8.10 y por lo tanto no puedo asegurar que funcione ni en otras versiones de la misma distribución:

Para instalar las herramientas de EC2 en nuestra Ubuntu 8.10 debemos seguir estos pasos:

  • Instalar la versión 5 de Java (pero la versión de Sun, nada de OpenJDK)
  • Descargar la herramientas de su web (podeis encontrar el enlace en su guia)
  • Descomprimir las herramientas en un directorio accesible
  • Seguir las intrucciones de como setear las herramientas que hay en el apartado Setting up the Tools de la guía oficial. NOTA: En Ubuntu, antes de empezar a ejecutar el comando ‘export’ debemos ejecutar el comando ‘bash’ para que arranque este interprete y no intentar lanzar las instrucciones con el comando ‘sudo’ se deben introducir todas los comandos tal como se exponen en la web de Amazon.
  • bash
    export EC2_HOME=/ruta/a/las/herramientas
    export PATH=$PATH:$EC2_HOME/bin
    export EC2_PRIVATE_KEY=/ruta/a/las/claves/pk-XXXXXXXXXXXXXXXXX.pem
    export EC2_CERT=/ruta/a/las/claves/cert-XXXXXXXXXXXXXXXXX.pem
    *Esto es un recopilatorio de los comandos que se tienen que ejecutar POR SEPARADO. Para saber el significado de cada uno consulta la sección Setting up the Tools de la guía.

  • Una vez instaladas las herramientas sólo debemos correr el comando siguiente y ya podremos acceder a la página web de ejemplo del servidor que hayamos instalado en la instancia de Amazon

ec2-authorize default -p 80A partir de aquí… lo dejo a vuestra imaginación.

, , , , ,

2 Comments