Servidor

Instalación de PostGIS para PostgreSQL

Cada vez son más las aplicaciones que hacen uso de localizaciones dentro de su funcionamiento y que además, necesitan almacenarlas de alguna forma dentro de su base de datos. Es entonces cuando PostgreSQL toma ventaja frente a MySQL gracias a la existencia de PostGis.
PostGIS

PostGis es un software libre, tiene licencia GNU General Public License (GPL), convierte nuestra base de datos PostgreSQL en una base de datos espacial capacitada para almacenar y trabajar con datos espaciales.

La instalación es muy sencilla, esta que indico aquí es la que usé en local y en un servidor en producción con Ubuntu 12.04, supongo que en versiones posteriores será similar con algún cambio en las versiones de paquetes pero diría que la mecánica es la misma, pero si tenéis alguna duda preguntad en comentarios y lo vemos entre todos.

Instalamos los paquetes:

sudo apt-get install python-software-properties
sudo apt-add-repository ppa:ubuntugis/ppa
sudo apt-get update
sudo apt-get install postgresql-9.1-postgis
sudo apt-get install build-essential postgresql-9.1 postgresql-server-dev-9.1 libxml2-dev proj libjson0-dev xsltproc docbook-xsl docbook-mathml gettext postgresql-contrib-9.1 pgadmin3
sudo apt-get install python-software-properties
sudo apt-add-repository ppa:olivier-berten/geo
sudo apt-get update
sudo apt-get install libgdal-dev

Una vez realizadas estas instalaciones, verficamos la versión de libGDAL, que debe ser 1.9.0

$ gdal-config --version
1.9.0

También verificamos la de libGEOS

$ geos-config --version
3.3.2

Ahora debemos actualizar la versión de libGEOS a la 3.3.3, para ello realizamos los siguientes pasos:

sudo apt-get install g++ ruby ruby1.8-dev swig swig2.0 ''--- added to other instructions, not installed by default in 12.04 & required for this make
wget http://download.osgeo.org/geos/geos-3.3.3.tar.bz2
tar xvfj geos-3.3.3.tar.bz2
cd geos-3.3.3
./configure --enable-ruby --prefix=/usr

Al final del proceso de configuración debe aparecer lo siguiente:

Swig: true
Python bindings: false
Ruby bindings: true
PHP bindings: false

Finalmente, compilamos:

make
sudo make install
cd ..

y comprobamos nuevamente la version, que ya si debe ser la 3.3.3:

$ geos-config --version
3.3.3

 

Continuamos con la instalación de PostGis:

wget http://postgis.refractions.net/download/postgis-2.0.6.tar.gz
tar xfvz postgis-2.0.6.tar.gz
cd postgis-2.0.6
./configure --with-gui

El final de esta instalación debe decir algo así:

PostGIS is now configured for i686-pc-linux-gnu
-------------- Compiler Info -------------
C compiler: gcc -g -O2
C++ compiler: g++ -g -O2
-------------- Dependencies --------------
GEOS config: /usr/bin/geos-config
GEOS version: 3.3.3
GDAL config: /usr/bin/gdal-config
GDAL version: 1.9.0
PostgreSQL config: /usr/bin/pg_config
PostgreSQL version: PostgreSQL 9.1.3
PROJ4 version: 47
Libxml2 config: /usr/bin/xml2-config
Libxml2 version: 2.7.8
JSON-C support: yes
PostGIS debug level: 0
Perl: /usr/bin/perl
--------------- Extensions ---------------
PostGIS Raster: enabled
PostGIS Topology: enabled
-------- Documentation Generation --------
xsltproc: /usr/bin/xsltproc
xsl style sheets: /usr/share/xml/docbook/stylesheet/nwalsh
dblatex:
convert:
mathml2.dtd: /usr/share/xml/schema/w3c/mathml/dtd/mathml2.dtd

para finalizar la instalación, compilamos:

make
sudo make install
sudo ldconfig
sudo make comments-install

una vez terminados estos pasos, creamos el usuario de postgres:

sudo apt-get install postgresql-client
sudo -u postgres createuser --superuser $USER
sudo -u postgres psql
postgres=# password postgres (la password que he puesto es postgres)

Finalmente, creamos la plantilla template_postgis, que es la clave para la creación de una base de datos de tipo espacial.

sudo su postgres
sudo createdb template _postgis
sudo createlang plpgsql template_postgis
sudo psql -d template_postgis -f /usr/share/postgresql/9.1/contrib/postgis-2.0/postgis.sql
sudo psql -d template_postgis -f /usr/share/postgresql/9.1/contrib/postgis-2.0/spatial_ref_sys.sql
sudo psql -d template_postgis -c "SELECT postgis_full_version();"

Estas instrucciones son una adaptación mía de la guía que seguí: http://trac.osgeo.org/postgis/wiki/UsersWikiPostGIS20Ubuntu1204

Espero que no os haya aburrido con este extenso primer post que escribo en LH :) .En próximas entradas ahondaremos más sobre bases de datos espaciales como esta que acabo de crear.

Virtual

Actualizaciones sólo de seguridad en Ubuntu y Debian

Actualizar sólo paquetes de seguridad en Ubuntu o Debian

Actualizaciones sólo de seguridad en Ubuntu y DebianOs pongo en situación, tenemos un servidor en producción y aunque mantengamos una política de recuperación rápida basada en snapshots o balanceo, la actualización del sistema es un asunto vital por dos razones: nuevas funcionalidades y sobre todo, seguridad.

Sin embargo, aunque los sistemas gestores de paquetes estilo apt o yum han resuelto gran parte del problema, no deja de ser un riesgos actualizar. ¿Por qué? Puede ser que el sistema por lo que sea, tenga una incompatibilidad hardware o con el software que ya tienes instalado.

Solución de compromiso que siempre recomiendo: actualizar sólo paquetes de seguridad. Veamos cómo hacerlo en distribuciones Debian y derivadas, como Ubuntu. El proceso tiene dos pasos.

Elegir sólo repositorios de seguridad

Primer paso, para ello hacemos una copia del original:

sudo cp /etc/apt/sources.list /etc/apt/security.sources.list

Paso seguido, lo editamos y dejamos sólo las direcciones de seguridad. Las reconoceremos porque incluyen security en su URL, algo así:

deb http://security.ubuntu.com/ubuntu raring-security main restricted

Actualizamos indicando que sólo mire en este nuevo fichero

En lugar del típico apt-get upgrade, le indicaremos un parámetro con la dirección del nuevo fichero:

sudo apt-get upgrade -o Dir::Etc::SourceList=/etc/apt/security.sources.list

Y asunto resuelto. A pesar de esto, seguirán apareciendo "security updates" pendientes, ya que hay actualizaciones de seguridad en el repositorio que no es "security" de nombre, ¿alguien ha conseguido resolver esto?

Copiar ficheros mediante SCP usando un fichero PEM para autenticarse

Ya habréis visto en este blog últimamente cómo conectarse a un servidor SSH usando un fichero PEM, en lugar de usar la típica combinación de usuario y contraseña. En breve hablaremos de cómo hacer lo mismo para usar rsync y hoy os traemos cómo hacerlo con scp:

scp -i  fichero.pem /ruta/orígen /ruta/destino

Que puede ser algo así como:

scp -i  miclave.pem mifichero.txt ubuntu@servidor.compute.amazonaws.com:/home/ubuntu/

Cambiar directorio por defecto de Apache

Si trabajáis con Apache, quizás os interese conocer cómo cambiar el directorio por defecto del mismo para poder cambiar la ruta de acceso a los datos del mismo a vuestro antojo. Tened en cuenta que por defecto suele ser: /var/www. Por partes.

Lo primero que hacemos es copiar la plantilla de sitios disponibles para crear una nueva:

sudo cp /etc/apache2/sites-available/default /etc/apache2/sites-available/misitio

Ahora debemos editar dicho fichero (recordad que debéis ser superusuarios para editarlo, con algo como gksudo gedit fichero no tendréis problemas para editarlo). En una de las primeras líneas aparece:

DocumentRoot /var/www

Debemos cambiar la parte derecha a lo que más os guste, por ejemplo:

DocumentRoot /home/carazo/miweb

Lo siguiente que tenéis que hacer es buscar la siguiente directiva:

<Directory /var/www/>

Y también cambiarla de forma análoga. Ya estamos en disposición de guardar el fichero y proceder a comunicarle a Apache que el sitio por defecto ha cambiado, para ello:

  • Deshabilitamos primero el anterior: sudo a2dissite default
  • Activamos el actual: sudo a2ensite misitio

Sólo queda reiniciar el servicio para que ponga en práctica los cambios:

sudo service apache2 restart

Modificar o activar el tamaño de caché de MySQL

En las instalaciones por defecto de MySQL, en muchas ocasiones, o aparece deshabilitada la caché de consultas o aparece, pero con muy poco espacio disponible.

Como podréis figuraros, la caché de consultas almacena en memoria física, la RAM, las últimas consultas realizadas y su resultado, de forma que si alguien repite dichas consultas, el acceso a su resultado sea casi inmediato comparado con recurrir a la base de datos en sí, a la que probablemente debamos acceder a disco y recorrer sus complejos árboles B y B+ internos.

El resultado de usar caché de MySQL es muy evidente en cuando a velocidad y en una entrada posterior os comentaré cómo sacar estadísticas para ver con más concreción cuál es la mejora.

¿Cómo activarla? ¿Cómo aumentar su tamaño?

Para ver si está activada nos dirigimos al fichero my.cnf (que probablemente esté en /etc o /etc/mysql) y buscamos dentro las siguientes cadenas:

query_cache_limit = 16M
query_cache_size = 512M

Como podéis imaginaros tenemos dos opciones:

  • Que no aparezcan dichas opciones: la caché está desactivada, podéis agregar dichas líneas sin problema en dicho fichero
  • Que aparezcan: ¿está activada? Pero, ¿qué significan dichas opciones?

Por partes:

  • query_cache_limit: establece la consulta máxima a cachear, por defecto viene a 1MB, yo trabajo en ocasiones con datos BLOB recurrentes, de ahí que haya puesto un valor exageradamente grande, 16MB.
  • query_cache_size: tamaño de la caché, si tenéis un equipo con varios gigas de RAM, con 512MB tendréis para almacenar muchísimas consultas y 512MB no os supondrán gran pérdida. De hecho si es un servidor sólo con MySQL sería razonable incluir incluso más cantidad, cada caso es particular y ya sabréis cuál es la mejor cifra por vuestra experiencia.

Una vez hecho eso, sólo debemos reiniciar el servicio y si MySQL arranca bien, todo está hecho, para confirmar, mirad la siguiente entrada para ver estadísticas y más datos:

sudo service mysql restart

Conectarse a un servidor por SSH con un fichero de certificado digital PEM

Creo que no soy el único que maneja a diario SSH para administrar servidores remotos desde la estupenda consola bash de Linux. Normalmente, el uso más frecuente, es autenticar usando un par usuario/contraseña, es decir algo así:

ssh administrador@dirección_equipo

Y luego introducir el password. Sin embargo, esta no es la única forma. Para mayor seguridad y sobre todo para evitar ataques de fuerza bruta, podemos generar un certificado digital en formato X.509 y guardarlo por ejemplo en un fichero .PEM, que almacenará dicho certificado codificado en Base64 y encerrado entre "-----BEGIN CERTIFICATE-----" y "-----END CERTIFICATE-----".

De esta forma, podremos conectarnos, si el certificado está registrado en el servidor, haciendo uso de éste sin necesidad de introducir usuario y contraseña, sino indicándole al cliente de ssh dónde buscar el fichero. Sería algo así:

ssh -i ruta-a-fichero.pem -v usuario@equipo

Monitorizar servidor web para ver si está caído o no de forma automática

Probablemente, tengáis más de una vez problemas con los servidores que mantenéis. Un problema típico es que un servidor web deja de dar servicio por cualquier razón. Cuando esto pasa depende de la gravedad, podemos tomar muchas acciones. A veces con reiniciar el servidor web, un proxy caché que tengas o cualquier otro, puede ser suficiente.

Para no tener que estar pendientes, lo ideal es que tengas este proceso automatizado y se ejecute cada cierto tiempo. ¿Cómo? Veamos.

Crear el script

Este es el primer paso, deberemos crear un fichero chequeo.sh o como queráis llamarlo con permisos de escritura e incluir dentro de él las siguientes líneas:

#!/bin/bash
url="aquí_tu_url";
response=$(curl -s -I -L $url | grep HTTP); 

status=${response#* };
status=${status:0:3};

if [ "$status" != "200" ] 
then
    // acciones a efectuar
fi

Sólo necesitaréis tener instalado curl. Dentro de URL ponéis la URL que queráis vigilar, propia o externa y en acciones a efectuar pues ya veis qué os interesa más: enviaros un correo con la alarma, forzar un reinicio del servicio (service apache2 restart o service varnish restart) o llamar a otro script para cualquier otra acción.

Programar la ejecución

Todo esto está interesante, pero mucho más si lo metemos en el cron. Para ello nos vamos al fichero /etc/crontab como superusuarios e insertamos una línea más:

0-59 * * * * root sh /ruta-a-fichero/chequeo.sh

Guardamos y listo.

Migrar un servicio en caliente de un nodo a otro en un clúster

Hace ya tiempo que empecé a hablar en este blog de los cluster de alta disponibilidad y aunque mi intención era ser más asiduo en este tema, por circunstancias de que básicamente escribo sobre lo que estoy haciendo en cada momento, cuando el cluster lleva tiempo sin darme ruido no suelo poner una entrada sobre el mismo, sin embargo, como podéis suponer he tenido un problema hace poco y he recordado apuntar aquí lo siguiente.

Cuando arrancamos el cluster, los nodos empiezan a lanzar servicios. Es muy probable que uno de ellos se quede con más carga que el otro (incluso con toda la carga). ¿Cómo podemos verlo? Usando clustat. Podremos ver qué servicio está ejecutando en cada miembro del nodo.

Si queremos repartir la carga a mano sin que nuestros usuarios sufran paradas de los servicios, el cluster nos permite hacer esa operación en caliente: migrar un servicio de un nodo a otro, sin necesidad de que el servicio pare.

¿Cómo? Con clusvcadm. Por ejemplo para mover un servicio llamado vm:servidor_web (atento a indicar el nombre al completo) a otro miembro llamado NODO01-pri.misnodos.dom debemos hacer lo siguiente:

clusvcadm -M vm:servidor_web -m NODO01-pri.misnodos.dom

Fijaos que sólo hace falta indicar el nodo destino. El proceso tardará un rato, pero si hacemos un clustat cuando termine, veremos que la máquina está ejecutando ahora en el otro nodo.

Desinstalar Ubuntu Web Apps

El pasado miércoles os contaba cómo instalar Ubuntu Web Apps en nuestro sistema. Si no leíste esta entrada os recomiendo daros una vuelta antes ya que este post explica cómo desinstalar de nuestro sistema lo que previamente pudísteis haber instalado.

Bien, como casi siempre, abrimos un terminal: 

ahornero@6581-D:~$ sudo apt-get install ppa-purge
ahornero@6581-D:~$ sudo ppa-purge ppa:webapps/preview

Terminado, ya habremos eliminado Ubuntu Web Apps de nuestro sistema. Otra vez, bastante fácil.

Instalar Ubuntu Web Apps

Creo que muchos de vosotros, por lo que se lleva hablando un tiempo, conoceréis de qué se trata Ubuntu Web Apps. A grosso modo es algo así como un Mozilla Prism con integración de características dentro del escritorio, como la administración de los mensajes de chat desde el área de notificación, el control del reproductor multimedia (LastFM), etc.

Os recomiendo echarle un vistazo a este vídeo, os gustará:

Bien, veamos cómo instalarlo. Abrimos un terminal:

ahornero@6581-D:~$ sudo add-apt-repository ppa:webapps/preview
ahornero@6581-D:~$ sudo apt-get update
ahornero@6581-D:~$ sudo apt-get install unity-webapps-preview

Ciertamente, bastante fácil. Ya nos contáis qué os parece esta forma de trabajo y este cambio en nuestro sistema.

Instalar servidor LAMP – Apache, MySQL y PHP – en Ubuntu Linux 12.04 LTS Precise Pangolin

La versión 12.04 LTS de Ubuntu tiene un amplio soporte y resulta muy interesante para usuarios particulares y, sobre todo, empresas instalar un servidor LAMP en dicha distribución. Tener 5 años de soporte extendido da una seguridad y estabilidad más que considerable con respecto a otras versiones de Ubuntu. En esta versión instalarlo es aún más fácil que en otras versiones como la 11.04 ó 11.10.

Para empezar, abre la terminal y ejecuta lo siguiente:

sudo apt-get install lamp-server^

Introduce la contraseña de administrador de Ubuntu y, a continuación, escribe la contraseña para el administrador de MySQL y repítela.

En unos minutos tendrás el servidor LAMP instalado en tu disco duro.

Ahora cambia los permisos del directorio ejecutando en la terminal lo siguiente:

cd /var/www/
sudo chown -R nombreusuario .

Ahora en ese mismo directorio crea un archivo test.php y escribe lo siguiente:

<?php phpinfo(); ?>

Ahora reinicia Apache ejecutando lo siguiente en la terminal:

sudo /etc/init.d/apache2 restart

Ahora entra en un navegador y escribe lo siguiente en la barra de dirección:

http://localhost/test.php

Si todo ha ido bien, verás algo parecido a ésto:

¿Qué distribución estoy usando?

Parece una pregunta básica y si es tu equipo no tiene sentido hacérsela, pero cuando accedes vía SSH a un servidor del que no tienes muchos datos, sí que puede ser interesante.

La forma de averiguarlo, en consola:

cat /etc/issue

Mi salida ahora mismo:

Ubuntu 12.04 LTS

¿La vuestra?

WordPress consejos de seguridad

10 pasos básicos para asegurar una instalación WordPress

WordPress consejos de seguridadLa seguridad es un punto básico en un blog, portal, red social, foro... o cualquier otra aplicación realizada con WordPress. Os comento 10 pasos básicos, que deberéis realizar para estar seguros de tener una instalación WordPress sin problemas de seguridad (al menos con la menor cantidad de problemas posibles).

Esta entrada es una traducción, adaptación y mejora del original en inglés: 10 Basics Steps To WordPress Security de Designrfix.

Manten el núcleo de WordPress actualizado

El equipo entero de desarrolladores y colaboradores de WordPress hace un gran trabajo para tratar de tener los problemas de seguridad a raya, si no mantenemos actualizado el núcleo, este trabajo servirá para nada. En otros CMS (aún recuerdo las actualizaciones que hacía en Drupal) son más complejos, pero en WordPress con un sólo clic hasta actualizado. No hay excusa.

Manten también los plugins y los temas actualizados

Ídem que el anterior, pero esta vez me refiero a los plugins y a los temas. Si estáis usando un tema propio, en el que partís de otro anterior, recordad usar temas hijos.

Sustituye el usuario administrador que hay por defecto

El usuario administrador de WordPress se llama por defecto "admin". Desde hace unas versiones, podemos cambiarlo y llamarlo como queramos. Con este simple gesto nos quitamos bastantes amenazas (y de las más gordas) de en medio.

Utiliza una contraseña que sea segura y manten tu password en sitio seguro

De poco sirve tener seguridad a todos los niveles si perdemos la llave de todo esto: el par nombre de usuario y contraseña. El primero lo hemos reforzado en el punto anterior, el segundo debe ser un password con cierta complejidad. Dentro del propio WordPress podéis ver el grado de fortaleza de la contraseña, cuanto más mejor.

Otro tema es el "guardarla", lo mejor es en la cabeza, pero en caso de no poder usar esta opción por cualquier razón, por favor, que sea en un sitio adecuado, no en plano en el escritorio en un fichero de texto que se llame "contraseñas wordpress".

Utiliza un prefijo de tablas que no sea wp_

Todos los que veáis datos WordPress a menudo, sabréis las tablas vienen precedidas por un prefijo que por defecto es "wp_", por ejemplo, wp_posts, wp_options, etc. La idea es que en lugar de ser "wp_" este prefijo, sea otro, de forma que dificultemos aún más la labor a nuestro atacante en caso de, por ejemplo, inyecciones SQL.

Si aún no hemos instalado WordPress, es muy simple. Nos dirigimos al fichero wp-config.php cuando introducimos los datos de autenticación en la base de datos MySQL y sustituimos el valor de la variable $table_prefix  a otro diferente a "wp_".

Si ya tenemos el sistema instalado, deberemos efectuar además una operación de renombrado de tablas.

Quitar información de la versión

WordPress suele incluir una línea en la cabecera de HTML en la que informa sobre la versión que se está usando, algo así como: <meta name="generator" content="WordPress X.X" />.

En los sistemas de producción cuantas menos pistas demos mejor, así que en el fichero functions.php de nuestro tema la siguiente línea, al final del mismo:

remove_action('wp_head', 'wp_generator');

Usar sólo plugins seguros

El gestor de plugins de WordPress nos ofrece una visión de la valoración de los plugins, de la cantidad de descargas... es decir, tenemos algo de valoración objetiva sobre los mismos. La idea es que no instales plugins que apenas han sido usados o estén mal valorados, un plugin puede ser tu agujero de seguridad.

Los más populares, a priori, están exentos de ese tipo de problemas, y en caso de tenerlos, ofrecen actualizaciones.

Busca un buen servicio de alojamiento

WordPress es un CMS que ejecuta sobre un servidor Apache, una base de datos MySQL y un intérprete de PHP. Todos estos elementos, tienen sus propios fallos de seguridad, además del sistema operativo sobre el que residen, así que otra labor importante es esta: cercionarse de contratar un proveedor de hosting serio, de forma que no tengamos problemas debajo de WordPress.

No descuides tampoco tu equipo

¿Desde dónde inicias sesión en WordPress? Desde equipos locales. Aquí hay otro fallo de seguridad, si tenemos por ejemplo, un troyano, será más que posible que nuestras credenciales no sólo de WordPress sino de FTP o MySQL caigan en manos de terceras personas.