Hechas las presentaciones, vaya por delante lo de siempre: un servidor completamente seguro es el que está encerrado entre muros de hormigón sin ningún tipo de conexión. Obviamente, así no sirve para nada, entonces tendremos que buscar el correcto equilibrio entre conectividad y seguridad. Como me toca acabar el año configurando nuevos servidores, os dejo una pequeña guía para asegurar el acceso por SSH.

Lo primero, modificar el fichero de configuración de SSH que encontrareis en /etc/ssh/sshd_config y agregamos las siguientes líneas (en muchos casos las encontrareis comentadas).

Protocol 2
LoginGraceTime 20
PermitRootLogin no
MaxAuthTries 2
MaxStartups 3
AllowUsers pepito

La primera línea le indica que unicamente se puede hacer uso de la versión 2 del protocolo de comunicación. La primera versión tiene algunas vulnerabilidades conocidas y está obsoleta por lo que lo recomendable es no usarla si no se necesita.

El LoginGraceTime hace referencia al tiempo en segundos que la pantalla de login permanecerá abierta, en el ejemplo hemos dejado 20 segundos, un tiempo más que suficiente para indicar usuario y contraseña.

Con PermitRootLogin establecido a no evitaremos que el usuario root pueda autenticarse a través de SSH para acceder al servidor. El problema es que los sistemas Linux y Unix crean al usuario root, lo que garantiza a un atacante que ya conoce el usuario, sólo queda la contraseña. De esta forma será mucho más complicado, obviamente no uses nombres conocidos o estarás en el mismo caso.

Otro de los límites que podemos imponer es definir la cantidad de veces que podemos fallar al autenticarnos. Con MaxAuthTries definimos el número de intentos, con 1 sería más que suficiente, pero a los que nos toca andar con varios servidores a la larga terminas equivocándote la primera vez de ahí que lo defina con 2 intentos. Lo que ocurrirá después del segundo fallo es que se cerrará la conexión.

Con MaxStartups se indican la cantidad de conexiones simultaneas que se permiten, en este caso hemos optado por 3, un número razonable para aquellos servidores a los que se accede por SSH únicamente para su administración. Con esto evitaremos que un ataque por fuerza bruta pueda realizar miles de conexiones simultaneas para atacar.

Y por último, pero no menos importante, AllowUsers. Con esta directiva le indicamos al SSH que usuarios exclusivamente se pueden identificar en el sistema. También podemos aumentar la seguridad definiendo desde que redes puede acceder un determinado usuario. Basta con poner los nombres de los usuarios separados por espacios, si se quiere indicar un host podemos hacerlo poniendo el usuario seguido del símbolo @ y el host (Ej: pepito@127.0.0.1).

Con esto ya tenemos nuestro SSH un poco más seguro. Guardamos el fichero y reiniciamos el servicio.

Lo segundo que haremos para evitar que nos ataquen será instalar Fail2ban, un programa controla los logs y que nos permite vetar todas aquellas IP’s que fallan un determinado número de veces. El baneo se realizará usando el firewall, así que lo que hace realmente Fail2ban es crear y borrar reglas en función de la información que se registra en los logs.

El requisito para instalar Fail2ban es tener Python, tenéis disponibles paquetes compilados para instalar o podeis tirar de repositorios. Una vez instalado tan solo es necesario configurar las reglas que queremos tener activas, tenéis bastante información en su web y un archivo de configuración de prueba en /etc/fail2ban/jail.conf

Cuando el proyecto está bajo el paraguas del software libre, herramientas como las proporcionadas por www.sourceforge.net son de mucha ayuda. Entre ellas se encuentra el uso de Subversion o CSV para la gestión de versiones. Personalmente prefiero subversion.

Este es un pequeño HOWTO de como configurar subversion corriendo bajo Apache, se presupone que se tiene instalado Apache, Subversion, el módulo DAV para Apache y las herramientas de administración de Subversion.

Lo primero que debemos hacer es crear un directorio para nuestro repositorio. Nuestro directorio principal para guardar nuestro control de versiones sobre subversion será /var/subversion/, dentro crearemos un subdirectorio donde se almacenarán los datos con subversion:

# mkdir /var/subversion/repositorio

Ahora debemos crear la estructura de subversion para almacenar las versiones y asignarle permisos para poder acceder:

# svnadmin create /var/subversion/repositorio/
# chmod 777 -R /var/subversion/repositorio/

Con esto ya tenemos listo el repositorio, ahora debemos generar el acceso a través de URL, para ello usaremos el módulo de Apache WebDav. Editaremos el fichero de módulo DAV de Apache (en Devian lo encontraremos en /etc/apache2/mods-available/dav_svn.conf), al final del fichero incluiremos las siguientes líneas:

# Acceso repositorio SVN

DAV svn
AuthType Basic
AuthName “Servidor Subversion”
SVNPATH /var/subversion/repositorio

En “Location” debemos poner la URL por la que queremos acceder al repositorio y en SVNPATH debemos colocar la ruta absoluta hacia el directorio que contendrá los ficheros de nuestro repositorio. Con esto ya debería estar funcionando nuestro repositorio con Subversion, basta con enlazarlo desde cualquier IDE que soporte control de versiones y comenzar a guardar las versiones de vuestros proyectos.

Como subversion no es sólo lo que he comentado, existe un estupendo manual donde podéis encontrar todas las funciones que ofrece este gestor de versiones.

Para su instalación bastará con obtener la última versión del script desde el repositorio de Sourceforge y copiarlo a /usr/bin.

#wget http://downloads.sourceforge.net/project/qmhandle/qmhandle-1.3/qmhandle-1.3.2/qmhandle-1.3.2.tar.gz
#tar xzvf  qmhandle-1.3.2.tar.gz
#cp /qmhandle-1.3.2/qmHandle /usr/bin/

A partir de aquí podremos manejar la cola de Qmail a través de qmHandle, estas son las opciones con las que contamos (qmHandle –help):

#qmHandle –help

qmHandle v1.3.2
Copyright 1998-2003 Michele Beltrame

Available parameters:
-a : try to send queued messages now (qmail must be running)
-l : list message queues
-L : list local message queue
-R : list remote message queue
-s : show some statistics
-mN : display message number N
-dN : delete message number N
-fsender : delete message from sender
-f’re’ : delete message from senders matching regular expression re
-Stext : delete all messages that have/contain text as Subject
-h’re’ : delete all messages with headers matching regular expression re (case insensitive)
-b’re’ : delete all messages with body matching regular expression re (case insensitive)
-H’re’ : delete all messages with headers matching regular expression re (case sensitive)
-B’re’ : delete all messages with body matching regular expression re (case sensitive)
-t’re’ : flag messages with recipients in regular expression ‘re’ for earlier retry (note: this lengthens the time message can stay in queue)
-D : delete all messages in the queue (local and remote)
-V : print program version

Additional (optional) parameters:
-c : display colored output
-N : list message numbers only
(to be used either with -l, -L or -R)

You can view/delete multiple message i.e. -d123 -v456 -d567

Para revisar la cola de correo debemos ejecutar qmHandle -l, que nos devolverá una salida parecida a esta:

#qmHandle -l

Total messages: 0 –> Recuento del total de mensajes en cola
Messages with local recipients: 0 –> Correos locales en cola
Messages with remote recipients: 0 –> Correos remotos en cola
Messages with bounces: 0 –> Correos rebotados
Messages in preprocess: 0 –> Correos preprocesados

En este caso quiero plantear una comparación entre dos de los frameworks más extendidos Zend y Symfony.

Documentación y aprendizaje. Com he dicho la curva de aprendizaje para poder usar correctamente y con soltura un framework necesita de un esfuerzo, mucho más si llevamos años programando sin usarlo. Symfony dispone de guias y manuales en abundancia, y además cuenta con numerosos foros en varios idiomas donde la comundad va resolviendo dudas. En el caso de Zend, a pesar de ser el framework de la empresa que está detrás de PHP, la comunidad es algo escasa, por tanto su documentación también.

Pruebas unitarias. Symfony dispone de tareas por linea de comandos para realizar testing, y además genera una clase vacia con cada nuevo controdalor desde el que poder realizar las pruebas. Zend no dispone de esta funcionalidad, algo que me parece muy importante a la hora de lanzar una aplicación a un entorno de producción.

Plantillas y plugins. Al sistema de plantillas de Zend le queda todavía un largo camino que recorer, mientras que en Symfony el sistema está ya muy avanzado, con la posibilidad de agragar módulos. Y otro tanto ocurre con los plugins, en Symfony es posible aumentar sus funcionalidades a base de plugins, mientras que Zend carece de esta característica.

Bases de datos. El trabajo con base de datos en Zend se limita a usar ActiveRecord (que no digo que esté mal), pero en Symfony tienes la posibilidad de usar el motor de base de datos que quieras, incluyendo el propio Zend_Db, algo que aporta una enorme flexibilidad al desarrollador que puede elegir en cada proyecto cual es la mejor opción.

Como conclusión a lo dicho quiero añadir, para todos aquellos que quieran dar el salto a hacer desarrollos basados en un framework, que a pesar de que al principio pueda resultar un poco engorroso con el tiempo os ayudará a mantener una limpieza de código y un mantenimiento de aplicaciones mucho más sencillo.

A xornada iniciarase ás 12:00 horas coa presentación do Galinux, o sistema operativo libre e en galego promovido pola Dirección Xeral de Promoción Industrial e da Sociedade da Información e enmarcada no Plano Estratéxico Galego da Sociedade da Información (PEGSI 2007-2010).

A continuación impartirase un obradoiro titulado “Introdución a Drupal”, no que se abordará a instalación deste sistema de xestión de contidos (CMS), así como a súa configuración para a creación dunha web particular, empresarial ou unha comunidade online.

• ScribeFire. Convierte a Firefox en un editor enriquecido conectado a tu blog.
• Wordpress Helper. La documentación de Wordpress disponible en Firefox, muy recomendable para poder echar un vistazo en cuanto lo necesites.
• Screen Grab to Wordpress. Permite hacer capturas de pantalla y enviarlas directamente a Wordpress.
• Wordpress Scanner. Revisa la seguiridad de tu blog, nunca se sabe cuando puedes recibir un ataque que destroce todo el trabajo realizado.
• Broken Link Checker. Con este plugin puedes revisar los enlaces que tengas en tu blog y saber cuales ya no están diponibles. Muy útil cuando tienes muchos enlaces.
• Google Syntactic Hichlighter. Mejora la visiulización de tus artículos.
• Insights. Abre tu blog a los nuevos servicios disponibles en la red como Flickr, Youtube o la Wikipedia.
• Windows Live Writer. Con la aplicación de Microsoft podemos crear nuestros artículos offline. Aunque yo no le veo mucha utilidad, ¿será porque soy usuario de Linux?
• Revision Control. Este plugin nos permitirá llevar un control de las revisiones que se realizan de cada artículo, muy útil en blogs con varios autores.
• Organize Series. Si estabas pensando en crear un tutorial que va a llevar muchos artículos, este es el complento ideal, te permite hacer una serie de artículos relacionados entre si.
• Wordpress Comment Moderation Notifiers. Herramienta que te ayudará a controlar los comentarios.
• Wordpress Comment Ninja. Si quieres extender las posibilidades de control sobre los comentarios.
• Adserve. Controla la publicidad de tu wordpress.
• Simple Tags. Si cuando escribes un artículo no sabes que tags lo describen, esta herramienta de hará algunas sugerencias.
• Twitter Tools. Este herramienta te permitirá lanzar a Twitter un micropost cada vez que escribas un artículo.

Por su parte Dell y Asus llegan a la misma conclusión, depués de achacar que el boom inicial de Linux fue debido a que el hardware apenas podría ejecutar XP con soltura, y que encuanto el hardware ha evolucionado los fabricantes siguen ofreciendo aquello que los usuarios demandan. Para añadir más leña al fuego, todo apunta a que los netbooks podrían tener un hardware suficiente para poder ejecutar Windows Vista.

Por una parte puedo entender que los usuarios prefieran los malo conocido que lo bueno por conocer, pero con esto nos alejamos del concepto inicial de netbook. El netbook está pensado para ser un equipo totalmente centrado en el acceso a la nube, donde el usuario mantiene todo lo que necesita (correo electrónico, perfiles de redes sociales, fotografías, videos, documentos, etc).

¿Para que necesita un usuario un hardware potente, cuando la única misión del netbook es acceder a los servicios que viven en la nube? Parece incluso ridículo elevar el precio de un netbook por un hardware capaz de hacer correr un sistema operativo que consume demasiados recursos o con una gran cantidad de almacenamiento cuando no se va a almacenar nada.

El problema radica en que el usuario final se ha planteado la compra de una netbook como un portatil tradicional, con un menor tamaño lo que lo hace más transportable, pero con un precio más reducido. La mayoría de los usuarios que compren un netbook, al menos de momento, pensando en hacerlo el sustituto de un portatil tradicional, se están equivocando y acabará provocando una visión distorsionada sobre la calidad del producto.

Entonces, ¿qué debemos tener en cuenta a la hora de comprarnos un netbook? Lo principal sus posibilidades de acceso, bien mediante redes wifi, conexiónes de red, Wimax, 3G, etc. Esa es la principal característica, y para acompañarlo un sistema operativo que consuma pocos recursos (y ahí Linux lleva las de ganar) y una buena memoria RAM capaz de permitirnos mantener unas cuantas ventanas del navegador abiertas con los distintos servicios.

A lo largo de estos meses me han preguntado si tal o cual netbook era un buen equipo. Y mi respuesta siempre ha sido la misma, ¿vas a utilizarlo para acceder a Internet y usar todos los servicios que están disponibles en la nube sin hacer uso de los programas de escritorio, excepto en casos puntuales? Si la respuesta es SI, entonces adelante lo que necesitas es un netbook, en caso contrario busca un portatil con mayores prestaciones, seguro que no terminarás defraudado con las posibilidades del producto.

El servidor Esclavo mantiene una conexión permanentemente abierta con el Maestro y se comprueba la ultima posición escrita en el log binario del Maestro, cuando se detectan cambios estos se replican el las tablas del servidor Esclavo.

Antes de ponerse a configurar MySQL con una replicación, hay que tener en cuenta la compatibilidad entre versiones. Como norma general debería de intentarse que la versión de MySQL del Maestro y del Esclavo fuesen la misma, y lo más actualizada posible. De todos modos, un Esclavo con una versión más actualizada que el Maestro suele funcionar, pero no al contrario.

Una vez que conocemos como funciona, y realizadas las comprobaciones de versiones podemos configurar Maestro y Esclavo para que ejecuten la replicación. Comenzaremos por la configuración del Maestro. Debemos editar el fichero my.cnf que encontraremos normalmente en /etc/my.cnf o en /etc/mysql/my.cnf dependiendo del sistema que usemos.

Debemos buscar y editar, o crear en caso de que no existan, dentro de la sección [mysql] las siguientes líneas:

[mysql]
log-bin = mysql-bin
server-id = 1
binlog_do_db = base_de_datos_a_replicar, db2, db3
binlog_ignore_db = bases_de_datos_a_ignorar, db4, db5

La opción log-bin activa el log binario de mysql, y server-id sirve para indicar el id del servidor maestro, debe ser un número entero positivo entre 1 y 2³². Con binlog_do_db le indicamos las bases de datos que queremos copiar (separadas por comas) y con binlog_ignore_db aquellas que no queremos replicar. Una vez realizados los cambios debemos reiniciar el servidor mysql.

Ahora necesitamos crear un usuario en el Maestro (se recomienda que se use un usuario de MySQL exclusivamente para hacer la replicación) y asignarle los permisos de replicación con el siguiente comando:

mysql> GRANT REPLICATION SLAVE ON *.*
-> TO ‘usuario_replicacion’@'%’
-> IDENTIFIED BY ‘pass_usuario’;
mysql> FLUSH PRIVILEGES;
mysql> LOCK ALL TABLES READ ONLY;

Debemos sustituir usuario_replicacion por el nombre de usuario que hemos creado para hacer la repicación y pass_usuario por la contraseña de ese usuario. El valor ‘%’ indica que ese usuario puede acceder desde cualquier host remoto, si queremos indicarle que pueda acceder desde un determinado nombre de dominio o IP debemos cambiar % por la IP o nombre de dominio que queramos que acceda a la replicación.

En el fichero de configuración del Esclavo debemos indicarle un server-id distinto del servidor Maestro, también un número entero positivo entre 1 y 2³². Por ejemplo:

[mysql]
server-id = 2

Si se están configurando varios esclavos cada uno de ellos debe de tener un server-id único, y diferentes del server-id del maestro. Una vez guardados los cambios reinicia el servidor MySQL.

Ahora ya tenemos listos Maestro y Esclavo para realizar la conexión. Ahora debemos hacer un volcado de la base de datos del servidor Maestro que queremos replicar:

[root@servidor-maestro]:~$ mysqldump -u usuario -p nombre_db > nombre_db.sql

Con este comando haremos un volcado de la base de datos a un fichero. Debemos sustituir nombre_db por el nombre de la base de datos que vamos a replicar y usuario por el nombre del usuario con privilegios de administracion. Si no tenemos contraseña para ese usuario no incluiremos la opción -p, en caso contrario nos pedirá la contraseña antes de realizar el volcado.

Ya solo nos queda un paso en el Maestro, conocer el nombre del log binario que se está utiliando y la posición del mismo, accedemos a la línea de comandos de MySQL y ejecutamos:

mysql> SHOW MASTER STATUS;
+——————-+———-+——————-+————————+
| File                         | Position | Binlog_Do_DB | Binlog_Ignore_DB  |
+——————-+———-+——————-+————————+
| mysql-bin.0005 |           98  |                                 |                                        |
+——————-+———-+——————-+————————+

Guardamos esos datos y desbloqueamos las tablas del maestro con:

mysql> UNLOCK ALL TABLES;

Ahora volvemos al esclavo y cargamos el volvado de la base de datos del maestro que realizamos antes:

[root@servidor-esclavo]:~$ mysql -u usuario -p nombre_db < nombre_db.sql

Cuando se temine la carga de la base de datos, accedemos a la línea de comandos de MySQL del esclado para indicarle los datos del maestro e iniciar el esclavo:

mysql> CHAGE MASTER TO MASTER_HOST = ‘ip_del_servidor_maestro’;
mysql> CHAGE MASTER TO MASTER_USER = ‘usuario_replicacion’;
mysql> CHAGE MASTER TO MASTER_PASSWORD = ‘pass_usuario’;
mysql> CHAGE MASTER TO MASTER_LOG_FILE = ‘mysql-bin.0005′;
mysql> CHAGE MASTER TO MASTER_LOG_POS = 98;
mysql> START SLAVE;

Después de esto el servidor Esclavo iniciará la replicación copiando todo lo sucedido desde la posición del log binario indicada hasta ese instante. Para confirmar que todo es correcto podemos ejecutar el siguiente comando en la consola de MySQL:

mysql> SHOW SLAVE STATUS \G
****************** 1. Row ***********************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.54
Master_User: usuario_replica
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.0005
Read_Master_Log_Pos: 98
Relay_Log_File: esclavo-rely-bin.0001
Relay_Log_Pos: 105
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0

Aunque apareceran más cosas, las he omitido, lo que debeis tener en cuenta es Seconds_Behind_Master pues indica el tiempo en segundos que el Esclavo tiene con respecto al Maestro. Creo que no me queda nada, teneis más información en el manual de MySQL, y si teneis alguna duda dejadla en los comentarios.

Entre las nuevas caracterísiticas de Wordpress 2.7, llamada Coltrane, cabe destacar:

• mayor uso de javascript
• cambio del menu superior por uno lateral a la izquierda
• acceso más rapido a todas las secciones
• posibilidad de minimizar el área de menu, aumentado el área de trabajo
• personalización del area de trabajo, pudiendo arrastrar los modulos para colocarlos

Pero esto no es todo lo que podrás encontrar en la versión 2.7 de Wordpress, si no lo has hecho ya, te recomiendo que actualices tu blog, seguro que después no querrás volver a las versiones anteriores.

[Descargar Wordpress 2.7] [Versión en español Worpress 2.7]

La recomendación era regresar a la versión 5.2.6, a la espera de que fuese lanzado PHP 5.2.8, pues bién tan solo un día más tarde ya estaba disponible 5.2.8 con el fallo corregido. A aquellos que instalasen 5.2.7 se recomienda actualizar a 5.2.8 para evitar cualquier problema de seguridad en ese sentido.

En cuanto a la RC PHP 5.3.0alpha3 trae consigo muchas novedades, entre ellas los namespaces, el cambio de compilador de gcc a cc, o un redondeo más preciso al trabajar con decimales.