Ayer tuve que reiniciar mi querido home server tras mucho tiempo sin hacerlo. Tal y como ocurre en la informática, las cosas de repente dejan de funcionar, y esta no es una excepción: el “currante” (que así que como llamo a mi home server) dejó de funcionar. Al conectar un monitor me encontré con la pantalla en negro y el mensaje “Welcome to GRUB!”. ¿Un error al iniciar? Dudoso, pero había que probarlo.

Tras reiniciar el equipo seguía ocurriendo lo mismo. Tal y como podéis ver en los posts donde explico cómo montar un home server utilizo Debian squeeze para dicha tarea, que actualmente monta GRUB2.Anteriormente me había encontrado alguna corrupción de GRUB2 en los ordenadorres de amigos que utilizan Ubuntu. Dicha distribución obtiene los paquetes de la versión inestable de Debian, así que lo lógico era pensar que estos errores se habían propagado. En mi caso no es así, y según he comprobado parece que GRUB2 ha dejado de funcionar con fit-pc2 (el equipo que utilizo para el “currante”) por problemas de compatibilidad con el chipset Poulsbo. De cualquier modo, es una buena oportunidad para explicar cómo solucionar problemas graves de GRUB.

Nombre de los dispositivos de disco

Para solucionar un problema de arranque en una máquina hay que tener claro cómo trabaja linux con los dispositivos de disco. Como ya sabréis, linux utiliza unos archivos especiales que se encuentran en el directorio /dev/ para trabajar con los distintos dispositivos hardaware (y algunos virtuales) y los discos no son una excepción.

De esta forma, si utilizamos discos antiguos con interface PATA, estos archivos se nombrarán de la siguiente manera:

• /dev/hda -> Dispositivo PATA maestro conectado al primer canal IDE.
• /dev/hdb -> Dispositivo PATA esclavo conectado al primer canal IDE.
• /dev/hdc -> Dispositivo PATA maestro conectado al segundo canal IDE.
• /dev/hdb -> Dispositivo PATA esclavo conectado al segundo canal IDE.
• Y así sucesivamente.

Si por el contrario utilizamos cualquier otro tipo de disco (SCSI, SATA, disco USB, Pendrive o casi cualquier otra cosa) encontraremos la siguiente nomenclatura

• /dev/sda -> Primer dispositivo detectado.
• /dev/sdb -> segundo dispositivo detectado.
• Y así sucesivamente.

En ambos casos las particiones se nombran numéricamente comenzando por el 1. Pongo unos ejemplos:

• /dev/hda3 -> tercera partición del disco duro maestro conectado al primer canal IDE.
• /dev/sda1 -> primera partición de, por ejemplo, un disco SATA.

De ahora en adelante yo trabajaré con /dev/sda como disco a reparar y /dev/sda1 como partición que contiene /boot.

Arrancar desde un sistema de rescate

Como estamos tratando problemas de GRUB doy por supuesto que no se puede arrancar. Ante esta situación la mejor solución es utilizar el sistema de rescate de nuestra distribución o una distribución Live, que arrancaremos mediante lector óptico, pendrive, red o como mejor nos parezca, sepamos y podamos. Eso sí, debemos tener en cuenta que la versión de kernel del entorno que utilicemos para arrancar debe ser suficientemente cercana a la del entorno a recuperar. En mi caso utilizo el Live CD de Ubuntu 9.04 por comodidad, ya que da un entorno muy usable nada más arrancar. De cualquier modo, una vez arrancado el sistema nos iremos a un terminal para ingresar en la instalación de linux que se encuentra en el disco duro. para ello primero hay que hacer algunos montajes:

sudo mkdir /target
sudo mount /dev/sda1 /target
sudo mount --bind /dev /target/dev
sudo mount -t sysfs sysfs /target/sys
sudo mount -t proc proc /target/proc

Veamos en qué consisten estos pasos:

1. Creación de un punto de montaje, algo trivial. Puedes utilizar el que quieras cambiándolo en el resto de líneas.
2. Esta línea monta la partición raíz en /target. Si tenemos directorios con otras particiones, tales como /boot, /var, /tmp, etc es necesario montarlas también.
3. Montamos el sistema de ficheros virtual de dispositivos. Como no hemos arrancado el kernel del disco duro que hemos montado, indicamos a mount que utilice los ya existentes en el entorno de recuperación.
4. Sysfs es un sistema de ficheros virtual que contiene información de hardware, drivers y parámetros de configuración del kernel. Realmente no sería necesario, pero lo monto por seguridad.
5. Proc es otro sistema de ficheros virtual que contiene da acceso a mucha información sobre los procesos que están corriendo en el sistema. Es necesario tenerlos montado para poder ejecutar comandos.

Y accedemos al sistema de nuestro disco:

sudo chroot /target

A partir de este momento ingresaremos en un shell del sistema operativo del disco duro a recuperar, aislada casi completamente del entorno de rescate que hemos utilizado para arrancar la máquina.

Antes de reiniciar deberíamos de salir de la shell chroot y desmontar todo lo que hemos montado:

exit
umount /target/dev
umount /target/sys
umount /target/proc
umount /target

• El primer comando sale de la shell chroot.
• El resto desmonta todo.

Tras esto se puede reiniciar el sistema de forma segura.

Solución de problemas de GRUB2

Y llega el momento de ponerse manos a la obra. El procedimiento que muestro a continuación es para errores de instalación de GRUB2. Si tienes errores en la generación de los archivos de configuración te recomiendo que leas la Wiki oficial del proyecto GRUB. La mayoría de los problemas con GRUB2 se pueden solucionar con su reinstalación:

grub-install --recheck /dev/sda

Esta orden reinstalaría GRUB2 en mi disco duro SATA principal. La opción –recheck fuerza a regenerar el fichero devices.map que contiene el listado de discos. De esta forma nos aseguramos de que GRUB2 tiene la información de los discos correcta y actualizada, que suele ser el principal motivo por el que deja de funcionar. Tras esto reiniciar y comprobar el resultado.

Si aún así GRUB2 sigue resistiéndose, lee el manual que se encuentra en la Wiki oficial del proyecto GRUB.

Si lo anterior falla, volver a GRUB Legacy

Si como en mi caso has agotado todas las posibilidades y encuentras que hay un problema con GRUB2 y tu hardaware, sería conveniente volver a la versión antigua de GRUB para poder seguir arrancando el sistema y buscar o abrir un bug al respecto.

NOTA: instala GRUB Legacy como último recurso. Aunque es estable tiene pocas funciones y el código tiene problemas serios de diseño, a parte de que su ciclo de vida ha finalizado. Te recomiendo encarecidamente que no utilices este método a no ser que no tengas más remedio.

Tras reiniciar el entorno de rescate y acceder por chroot a tu sistema, lo primero sería desinstalar GRUB2:

aptitude purge grub-pc
rm -r /boot/grub

Te recomiendo que antes de lanzar esto hagas una copia de /boot/grub en cualquier sitio, por lo que pueda pasar. Tras haber desinstalado completamente GRUB2 instalamos el paquete de GRUB1:

aptitude install grub-legacy

Con este comando habremos instalado el paquete, sin embargo grub no se instalará en nuestro disco duro ni se configurará, para ello hay que realizar los siguientes pasos:

grub-install /dev/sda

Esto se puede quejar del stage1, ignoramos el error. Tras esto sería conveniente comprobar que la información de /boot/grub/device.map es correcta. En mi caso, para asegurarme que funciona, cambié el nuevo sistema de identificadores de disco por el archivo de dispositivo, quiere decir:

(hd0)   /dev/disk/by-id/ata-ST3400620AS_6QH00FGT

por

(hd0)   /dev/sda

Una vez hecho esto proseguimos la instalación y configuración:

grub #Entramos en grub. "grub>" representa el prompt de GRUB
grub> root (hd0,0)
grub> setup (hd0)
grub> quit
update-grub

Este último comando genera el fichero menu.lst y añade los kernels y sistemas operativos que tengamos instalados. Salimos del entorno de rescate tal y como indico más arriba y ¡listo! ya tenemos GRUB instalado, configurado y funcionando.

A finales de junio se publicó la nueva versión mayor de WordPress, la 3.0. Entre sus muchas novedades, la que más me ha gustado es la capacidad de hospedar varios blogs de forma nativa, capacidad que se conoce como multisite. En este sentido, se nos ofrecen dos posibilidades para montarlo en función de las capacidades de nuestro servidor web:

• Con subdominios: son de la forma blog1.dominio.com blog2.dominio.com, etc. Es la forma más conveniente ya que cada blog genera su propio robots.txt y muchos plugins funcionan un poco mejor así. La desventaja es que requiere la capacidad de habilitar subodmains wirldcard en el servidor DNS, o al menos eso dicen en wordpress, ya que en este artículo os mostraré cómo montar un multisite sin esta capacidad.
• Con subdirectorios: son de la forma dominio.com/blog1 dominio.com/blog2, etc. Este requiere mod_rewrite en el servidor php, que suele estar disponible, por lo que es mucho más compatible. Como desventajas, la ausencia de las ventajas que tenemos con subdominios: disponemos de un solo robots.txt y algunos plugins cuesta hacerlos funcionar.

En cualquiera de estas modalidades de instalación podemos aplicar un plugin de mapeo de dominios, lo que se traduce en que se pueden administrar varios blogs de varias webs diferentes desde una sola instalación de wordpress. En mi caso esto ayuda tremendamente, ya que gestiono 3 webs distintas con wordpress, cada una de ellas con su propia instalación, muchos plugins en común, etc. Esto significa que cada vez que sale una nueva versión de wordpress tengo que actualizar cada blog independientemente, cada vez que sale un plugin más de lo mismo, y si encima añadimos que el sistema de actualización automática de wordpress no me funciona por las características de mi servidor de hosting esta capacidad es todo un aliciente. Como valor añadido, con este sistema sólo se usa una base de datos, que también facilita las cosas en servidores de hosting.

Sin embargo, antes de migrar las instalaciones anteriores a una nueva unificada tenía que dejar el nuevo sistema funcionando al menos con las mismas capacidades de que disponía en el sistema anterior, y una de las más importantes es poder gestionar los ficheros robots.txt virtuales y sitemaps de cada uno de los blogs. Digo lo de robots.txt virtuales porque utilizo varios plugins para que “adopten la forma” que yo quiero, en vez de generarlo manualmente. Además, para gestionar el sitemaps utilizo un plugin llamado Google XML Sitemaps, y hacerlo funcionar con multisite y mapeo de dominio no es algo inmediato. Si añadimos que mi hosting es compartido y como casi todos no permite crear el subdomain wildcard entonces la cosa se puede volver realmente complicada.

Pese a que en principio todo parece estar en contra se puede montar, y la finalidad de este post es explicaros cómo. Para hacer más fácil la compresión del proceso voy a utilizar como ejemplo la web de mi grupo a la que se puede acceder desde el dominio www.ipsilon-metal.com y que está contenida en la red multisite que he creado desde el dominio vidakovic.es

Instalación de wordpress

La instalación inicial de wordpress es la misma de siempre. Descargamos el paquete de instalación de www.wordpress.org. Las instrucciones de instalación están contenidas en el propio paquete que nos descargamos y no debería darnos ningún problema.

Una cosa a tener en cuenta es que hay que instalarlo en el dominio principal, en mi caso vidakovic.es. Esto es importante para que el sistema de subdominios trabaje correctamente.

Configuración de multisite con subdominios

Tal y como he comentado, para montar multisite con subdominios el equipo de wordpress indica que hay que habilitar la función Subdomain Wirldcard en el servidor DNS. Sin embargo, en los hostings compartidos esto no suele ser posible.

Para solucionar este problema primero veamos qué es. Subdomain Wildcard es una característica de los servidores DNS que hace que cualquier subdominio que no esté definido en el servidor apunte al dominio principal. Me explico: si tuviera habilitada esta característica al acceder a loquesea.vidakovic.es el DNS redireccionaría automáticamente a vidakovic.es. La configuración consiste en insertar una entrada conteniendo *.vidakovic.es en fichero de configuración de la zona correspondiente.

Y ahora viene la pregunta del millón: ¿para qué necesita WordPress que hagamos esto? Pues muy sencillo, para que cuando creemos un nuevo blog en nuestra red el DNS redirija el subdominio directamente a nuestro dominio principal sin necesidad de definirlo en ningún sitio, y Worpress encargase de seleccionar el blog al que queremos acceder según la URL que ha recibido.

Pues bien, si antes de cear un nuevo blog creamos en el DNS el subdominio que corresponda a la dirección del nuevo blog y que apunte a nuestro dominio principal, no necesitamos definir el Subdomain Wildcard, ya que hemos definido el subdominio manualmente y hemos indicado a dónde va dirigido.

Os explico cómo hacerlo.

1. Configuración del multisite

Para ello hay que seguir las instrucciones oficiales que se encuentran en http://codex.wordpress.org/Create_A_Network

Hay que saltarse el paso 2 “Setting wildcard subdomains” y seguir los pasos para instalar el multisite CON SUBDOMINIOS ignorando las advertencias del sistema sobre la configuración del DNS.

Llegados a este punto wordpress ya está configurado como multisite y por lo tanto podemos crear nuevos blogs en nuestra red a través del menú “Súper Admin”. ¡Alto! No lo hagas todavía, antes hay trabajo que hacer.

2. Instalar y configurar el plugin de mapeo de dominios

Este plugin es el que hará posible que cada unos de los blogs tenga su propio dominio. La dirección donde podéis descargarlo es: http://wordpress.org/extend/plugins/wordpress-mu-domain-mapping/

Para instalarlo y configurarlo seguir las instrucciones que se incluyen en el readme

3. Creación de un subdominio para un nuevo blog de la red

Cada vez que queramos crear un nuevo blog tendremos que crear previamente un subdominio con el mismo nombre que insertaremos como “dirección del sitio” en el proceso de creación del blog en la red, independientemente del título que le demos al blog. Para ello vamos a la configuración DNS de nuestro hosting y creamos un subdominio (por ejemplo en mi caso ipsilonmetal.vidakovic.es) que tenga el mismo destino que el dominio principal donde tenemos instalada nuestra red de wordpress (siguiente con el ejemplo, en mi caso tendría que apuntar al mismo sitio que apunta vidakovic.es).

4. Creación del nuevo blog en la red

A continuación nos vamos al panel de control de wordpress del dominio principal y creamos un nuevo blog desde el menú Super Admin -> Sitios

Como he dicho antes, la dirección del sitio debe corresponder con el subdominio que hemos creado (en mi ejemplo ipsilonmetal.vidakovic.es). Se rellenan el resto de datos y ya tenemos el sistema funcionando.

5. Mapear el nuevo blog a su dominio principal

Una vez creado el blog vemos que podemos acceder a él (en mi caso a través de ipsilonmetal.vidakovic.es), pero queda algo importante. Lo que queremos es que dicho blog tenga su propio dominio. Para ello debemos seguir 2 pasos:

1. Debemos ir a la configuración DNS del dominio del nuevo blog y hacer que éste apunte al mismo sitio al que apunta el dominio del blog principal de la red. Ya sé que suena un poco lioso, aquí va el ejemplo: tendría que hacer que ipsilon-metal.com apunte al mismo sitio que apunta vidakovic.es
2. En el panel de control del nuevo blog (no el de la red principal), ir a Herramientas -> Domain Mapping y añadir el dominio que queremos marcando la opción de que sea el principal. En mi caso tendría que añadir ipsilon-metal.com o www.ipsilon-metal.com (deprendiendo de cómo queramos que se vea en la barra de direcciones).

Desde ese momento sólo podremos acceder al dicho blog a través de su dominio principal (www.ipsilon-metal.com) y no el subdominio de la red (ipsilonmetal.vidakovic.es).

Configuración del plugin de sitemaps

Ya tenemos una red de wordpress por subdominios instalada y funcionando y somos capaces de mapear los blogs a dominios. Además puedes comprobar que cada blog, al ser un subdominio, tiene su propio robots.txt. Ahora queda la creación de sitemaps, para lo que utilizaremos el plugin Google XML Sitemaps tal y como he indicado anteriormente. El problema es que este plugin no soporta multiblog, aunque el autor está trabajando en una versión que lo soporte. Mientras que esto sea así, Ian Dembowski ha creado un workaround fácil y rápido que funciona a las mil maravillas. Estos son los pasos a seguir.

1. Instalar el plugin

Lo haremos por el procedimiento habitual y lo dejaremos DESHABILITADO.

2. Eliminar la detección de multiblog

El plugin tiene la habilidad de detectar si está funcionando en un entorno multisite y si es así no se activa, mostrando un mensaje indicando que no es compatible con dicha funcionalidad. Procederemos a desactivar este aviso permitiendo que el plugin se active. Para ello tenemos que editar el archivo wp-content/plugins/google-sitemap-generator/sitemap.php donde comentaremos de la línea 53 a la 58, dejándolo de la siguiente manera:

//Check for 3.0 multisite, NOT supported yet!
//if((defined('WP_ALLOW_MULTISITE') && WP_ALLOW_MULTISITE) || (function_exists('is_multisite') && is_multisite())) 	//{
//if(function_exists('is_super_admin') && is_super_admin()) {
//	add_action('admin_notices',  array('GoogleSitemapGeneratorLoader', 'AddMultisiteWarning'));
//}
//
//	return;
//}

2. Activar y configurar el plugin

Una vez hecho esto ya podemos activar el plugin. Es MUY IMPORTANTE ACTIVARLO INDIVIDUALMENTE para cada sitio, y no utilizar la opción de activarlo para la red completa.

En la configuración nos iremos al apartado “localización de su fichero sitemap”. Ahí debemos seleccionar la opción de localización automática y cambiar el nombre del fichero. El nuevo nombre del fichero deberá ser sitemap-<dominio_mapeado>.xml. Continuando con mi ejemplo de la web de Ipsilon (www.ipsilon-metal.com), la configuración del plugin quedaría de la siguiente manera:

Configuramos las opciones que queramos del plugins y guardamos los cambios. Una vez hecho esto pulsamos sobre la opción de generación manual para que nos cree el primer sitemap.

3. Configuración del fichero .htaccess

Tras esto configuramos el fichero .htaccess para que redireccione el archivo sitemap.xml al que realmente queremos. Para ello debemos añadir el siguiente bloque tras las 3 primeras líneas que contiene el fichero:

# Google XML sitemaps
RewriteRule ^sitemap.xml sitemap-%{SERVER_NAME}.xml [L]
RewriteRule ^sitemap.xml.gz sitemap-%{SERVER_NAME}.xml.gz [L]

NOTA: si existe algún fichero llamado simplemente sitemap.xml en la raíz del directorio principal de worpress debemos borrarlo.

4. Probar que todo funciona correctamente

Ya está todo configurado. Lo primero sería comprobar que el fichero se ha creado correctamente. Para ello accedemos al sitemap que hemos creado, que en mi ejemplo sería http://www.ipsilon-metal.com/sitemap-www.ipsilon-metal.com.xml y debería de aparecer el fichero que hemos generado.

Lo segundo sería comprobar que las reglas el archivo .htaccess están funcionando correctamente. Siguiendo con el ejemplo de la ilustración yo accedería a http://www.ipsilon-metal.com/sitemap.xml y vería el mismo contenido que en el fichero anterior.

Por último, en el fichero virtual robots.txt debería aparecer una entrada al fichero sitemap real del dominio. En mi ejemplo contendría la siguiente línea:

Sitemap: http://www.ipsilon-metal.com/sitemap-www.ipsilon-metal.com.xml.gz

Llegados a este punto ya tenemos la web funcionando con su propia información de posicionamiento.

Hola! Comos algunos saben, además de esta web administro algunas más. Como la versión 3.0 de la plataforma WordPress soporta multisite, estoy migrando todos los blogs a este nuevo sistema. Esto significa que a veces, si entráis en la web, encontraréis que ésta no está disponible.

Lamento las molestias y espero tenerlo todo listo lo más rápidamente posible.

EDIT: la actualiación ya ha sido terminada. Gracias por vuestra paciencia

Los que estéis suscritos a los feeds de la página habréis visto un poco de jaleo entre anoche y esta mañana. Os pido disculpas, como sóis tan poquitos y además muy fieles a veces no os trato como debiera.

El motivo de todo este revuelo ha sido la inaguración de una nueva sección en la web: sobre mí. Aquí he hecho un muy breve resúmen de mi vida, una biografía musical y queda pendiente mi trayectoria profesional, que está casi terminada.

Por otro lado me alegra anunciaros que la web oficial de Ipsilon, el grupo en el que actualmente toco el bajo, ya está prácticamente terminada, es accesible públicamente y desde ella se pueden escuchar los 3 primeros temas que hemos publicado.

Ante la inclusión en el Anteproyecto de Ley de Economía Sostenible de modificaciones legislativas que afectan al libre ejercicio de las libertades de expresión, información y el derecho de acceso a la cultura a través de Internet, los periodistas, bloggers, usuarios, profesionales y creadores de internet manifestamos nuestra firme oposición al proyecto, y declaramos que…

1.- Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.

2.- La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial -un organismo dependiente del ministerio de Cultura-, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.

3.- La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.

4.- La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.

5.- Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.

6.- Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.

7.- Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.

8.- Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.

9.- Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.

10.- En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.   Por favor difunde este manifiesto en tu blog, Twitter, en redes sociales, en foros o imprímelo y repártelo.

Tal y como podéis apreciar he cambiado el tema de WordPress. Espero que éste resulte un poco más claro y más agradable a la hora de leer los contenidos, aunque el motivo real del cambio es que voy a utilizar una versión modificada del antiguo tema de esta web para la de mi nuevo grupo, que estoy montando durante estos días.

Espero que este nuevo aspecto os guste!

Hace poco me encontré con un problema bastante curioso. En casa Utilizo Debian Squeezee en mi máquina de trabajo habitual. Como esta versión se encuentra en fase testing, en ella van incluyendo las nuevas funcionalidades que tendrá el sistema en release. Una de estas nuevas funcionalidades es que finalmente pasan del sistema de arranque estático (asígnando un número a cada script de arranque que determinará cuándo arrancará) al sistema de arranque por dependencias que utiliza ubuntu. Quiere decir, ahora los scripts de arranque lo que contienen es la información sobre qué servicios necesita que estén activos para arrancar correctamente, y será el sistema quien arranque la aplicación cuando estime que puede hacerlo.

Al intentar hacer la migración al sistema nuevo, me encontré que no era posible porque no estaban purgados los paquetes de la rama 5.0 de MySQL, que unos días antes habían actualizado a 5.1. Entonces caí en la cuenta de que tanto apt como aptitude no purgan los ficheros de configuración cuando actualizan un paquete, tan sólo hacen un uninstall normal y corriente. Esto puede ocasionarnos más de un problema cuando instalamos actualizaciones, bien porque se lean configuraciones en formato antiguo o porque éstas interfieran con otros paquetes, como era mi caso. De cualquier modo, cuando se retiran paquetes de nuestro sistema porque están obsoletos o bien queremos purgar programas desinstalados hace tiempo, podemos ejecutar el siguiente comando:

aptitude purge ~c

Y de esta forma purgaremos todos los paquetes que hayamos desinstalado de nuestro sistema, bien por ser obsoletos o bien por el método estándar.

Una vez instalado y configurado el sistema operativo y compartidos los directorios por samba, es momento de terminar de configurar el entorno LAMP. Para ello vamos a instalar el servidor web Apache, php_mod para disponer de php en nuestro servidor y MySQL para poder trabajar con bases de datos.

Instalamos pues el software necesario:

sudo aptitude install apache2 libapache2-mod-php5 mysql-server-5.1
sudo aptitude install php5-gd php-fpdf

Cuando instalemos MySQL el sistema nos pedirá el password del usuario root.

Con esto ya tendremos instalados los paquetes de software principales necesarios para ejecutar las aplicaciones web más usuales en php. El siguiente paso sería activar las conexiones externas a mysql, de esta forma podremos, por ejemplo, gestionar nuestro servidor de forma gráfica desde nuestro equipo con las herramientas de gestión que provee MySQL. Para ello basta editar el archivo /etc/mysql/my.cnf y comentar la línea bind-address = 127.0.0.1 añadiendo una almohadilla (#) al principio de la línea. Una vez terminado reiniciamos el servidor mysql para que aplique los cambios de la configuración:

sudo /etc/init.d/mysql restart

El siguiente paso sería crear un superusuario propio en mysql y permitirle autenticar desde cualqueir máquina de nuestra red (o desde alguna específica, según queramos ajustar nuestro nivel de seguridad) para poder gestionar el servidor. De esta forma podremos crear usuario, bases de datos, etc desde nuestra máquina utilizando las herramientas gráficas de gestión.

mysql -u root -p mysql
CREATE USER 'nefeli'@'192.168.0.%' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON *.* TO 'nefeli'@'192.168.0.%' WITH GRANT OPTION;
FLUSH PRIVILEGES;
quit

Con estas órdenes he hecho lo siguiente:

• Conectar al MySQL con el usuario root (-u root), solicitando el password (-p) y conectando a la base de datos de gestión de MySQL (mysql). Esta base de datos contiene la información refenrente a las bases de datos que existen, los usuarios y sus privilegios, los parámetro de configuración del sistema, etc. El sistema nos pedirá el password de root para conectar.
• Crear un usuario (en este caso nefeli), y habilitar la conexión de este usuario desde la red 192.168.0.0 (quiere decir, cualquier ordenador que IP empiece por 192.168.0). Además el usuario tendrá un password (en este caso password). Es importante incluir las comillas (‘) en el comando, ya que indicará a MySQL que lo que está contenido entre estas con cademas de caracteres.
• Otorgar al usuario (en este caso nefeli) todos los privilegios de superusuario cuando se conecte desde la red 192.168.0.0), incluyendo el privilegio de otorgar privilegios (como dicen en inglés, esta frase es un poco tricky).
• Recargar los privilegios de la base de datos.

De esta forma ya habremos creado un superusuario que con el que podremos trabajar desde cualquier punto de nuestra red. Sería una buena idea que, cada vez que instalemos una aplicación que necesite acceder a una base de datos, le creemos un usuario propio con los permisos justos que necesite, y de esta forma tener el acceso a todas nuestras bases de datos debidamente controlado y securizado.

Por último, algo a tener en cuenta es que todos los comando que metemos en mysql se guardan en un fichero de log en el directorio del usuario donde lo hemos creado. Como hemos puesto un password en texto normal, sería una buena idea borrar las líneas donde apareza para tener el sistema completamente seguro. El nombre de este fichero es .mysql_history.

Bueno, pues ya tenemos un pequeño entorno web corriendo en nuesta máquina, con el que podremos instalar aplicaciones web dentro de nuestra red casera. En mi caso ya tengo instalado y funcionando jinzora, que utilizo tal y como comenté en otro post para reproducir música en la wii.

AVISO: este tema se encuentra en proceso de reconstrucción. Este fin de semana estará completamente reformado. Te recomiendo que esperes hasta entonces.

Ya que hemos preparado el acceso por red es hora de ponernos manos a la obra con los servicios que nuestro pequeño servidor ofrecerá. Pero antes de nada, sería conveniente crear un puñado de usuarios y grupo en el sistema. En concreto, yo crearé un usuario para mi pareja, que tendrá el mismo nombre y contraseña que ella tiene en su equipo con windows para que acceda de forma transparente (windows manda de forma automática las credenciales de usuario. Además está creados mi usuario (desde la instalación) y será creado un usuario invitado (para que pueda acceder al ssh y algunos recursos compartidos). En cuestión de grupos, crearé un grupo llamado “descargadores” que contendrá usuarios y demonios, un grupo llamado “habitantes” que contendrá los usuarios correspondientes a mi pareja y a mí, y uno de invitados (toda la sección de invitados no será incluida en este tutorial).

sudo useradd lucerita
sudo passwd lucerita
(salida por pantalla del proceso)
sudo groupadd descargadores
sudo groupadd habitantes
sudo usermod -G descargadores,habitantes yo
sudo usermod -G descargadores,habitantes lucerita

Es imprescindible asignar una password a los nuevos usuarios, ya que hasta que no se haga el usuario permanecerá desactivado y no podremos hacer nada con él.

Gestión de permisos: Listas de control de acceso (ACL)

Ante un sistema al que van a acceder varios usuarios surge un problema: la gestión de los permisos que dichos usuarios van a tener a los recursos compartidos. En el caso que estamos ilustrando, tenemos un grupo de usuarios (habitantes) que van a tener acceso total (lectura, modificación y ejecución) a una serie de recursos compartidos, y otro grupo (descargadores) a los que hay que aplicarles el mismo criterio para otros recursos.

Linux, Como buen sistema basado en UNIX, contaba inicialmente con el sistema estándar de estos entornos para controlar quién puede hacer qué dóne, el llamado UGO (user, group, others). Sin embargo en muchos casos este sistema es insuficiente, y para solventar esto aparecieron las listas de control de acceso. En nuestro home server su necesidad se hace patente, así que vamos a ver como se monta y configura. Si quieres ampliar tu conocimiento sobre este tema, te recomiendo que leas este completo HOWTO.

Vamos a ilustrar este ejemplo con el directorio de descargas del home server. Lo primero es crear el directorio que contenga los archivos descargados por programas que tengamos residentes en el sistema

sudo mkdir descargado
sudo chown yo:descargadores descargado
sudo chmod 775 descargado

Ambos demonios lo incluiremos posteriormente en el grupo “descargadores” al que le acabamos de dar permisos de lectura, escritura y ejecución en estos direcotrios, y de esta forma tenemos controlado el acceso de aplicaciones y usuarios al tiempo que no comprometemos el sistema. De estos directorios sólo compartiremos, en principio y como es lógico, descargado.

Pasamos pues a instalar samba. Para facilitar la tarea de administración de recursos compartidos podemos utilizar swat, que es un pequeño servicio web para configurar samba de una forma un poco más visual y agradable.

sudo aptitude install samba swat

Durante el proceso de instalación nos pedirá el grupo de trabajo. Por comodidad podemos especificarlo, aunque posteriormente también se puede cambiar de una forma fácil y cómoda. También mientras instalamos, samba leerá todo nuestro listado de usuarios, contraseñas y grupos y los inluirá para que puedan hacer login. Si posteriormente queremos agregar un nuevo usuario podemos utilizar el siguiente comando:

sudo smbpasswd -a <nombre_usuario_unix>

Cuando terminemos de instalar tendremos swat disponible, con lo que podríamos abrir un navegador  apuntar a http://<ip_de_la_maquina>:901. Nos pedirá el nombre de usuario y password, y para dentro!

Como se puede apreciar las opciones de configuración son muy numerosas y nos podemos perder fácilmente. Esto es debido a que samba no sólo está pensado para ofrecer recursos simples, sino que permite sincronizar con directorio activo de windows y dominios, de tal forma que todo esto se vuelve muy complejo. Así pues, un poquito de ayuda no viene mal.

En el apartado  global, pondremos la opción preferred master a True. ¿Qué significa esto? Veámoslo.

Las versiones de escritorio de windows son capaces de funcionar de forma descentralizada, esto quiero decir, sin servidor, o al menos sin ningún ordenador especialmente configurado para tal efecto. El problema de no utilizar un servidor central es que los ordenadores tienen que estar contínuamente enviando y recibiendo información para saber qué otro ordenadores están conectados a la red y qué cosas tienen, y posteriormente si siguien ahí o hay otros nuevos.

Esto genera un tráfico de red desmesuradamente alto, por lo que hay montada una solución intermedia, y es que la máquinas puedan funcionar como servidor pero con un sistema de autoconfiguración que sea complemente transparente para el usuario. Además este sistema tiene que ser capaz de tolerar las contínuas idas y venidas de equipos de la red. Así pues se ha creado un sistema de votación, en el que cuando se solicita, todos los equipos aportan una puntuación basada en varios criterios y eligen a un servidor central, que se encargará de memorizar el estado de todas las máquinas de la red y al que todo el mundo preguntará.

Esta opción permite que se lanze el proceso de votación cada vez que nuestra máquina samba se conecta a la red. Como samba posee una puntuación alta suele proclamarse ganador y se convierte en maestro. Esto nos viene de perlas, porque como el equipo estará siempre encendido podrá controlar perfectamente los ordenadores que se conectan y desconectan de la red y mantendrá el broadcast de nuestra red un poco más saneado (para lo que suele ser entornos Windows).

Tras esto nos vamos al apartado shares y añadimos recursos compartidos. Os dejo una plantilla de cómo he configurado yo los recursos:

[musica]

	path = /mnt/musica

	valid users = +habitantes

	read only = No

	create mask = 0774

	directory mask = 0775

Quiere decir, creo que recurso que se llama música, con path en /mnt/musica. Restrinjo los usuarios válids a los pertenecientes al grupo habitantes (el + indica que es un grupo de UNIX, quiere decir, un grupo existente en nuestro linux). Permito que el propietario y el grupo de usuarios tengan acceso completo a los archivos y directorios contenidos en este.

NOTA: La cláusula valid user implica que ningún usuario que no se haya autenticado como miembre de habitantes podrá acceder a este recurso.

Queda por resolver el tema del montaje de las unidades desde sistemas linux. Para ello es necesario utenticarse como el usuario que hemos elegido, pero si añadimos una línea en fstab para que el sistema se monte al iniciar el equipo el usuario que monta es root. Tampoco deseamos incluir a root en el montaje para evitar problemas de seguridad, además de que necesitamos encontrar un método seguro para no poner el password como texto plano el dicho archivo. esto lo solucionaremos creando un archivo de credenciales. Iniciamos una shell de de root y cremos un archivo (por ejemplo /root/montaje) con el siguiente contenido:

username=<usuario>

password=<mi_password>

Lo guardamos y cambiamos los permisos para que sólo root pueda acceder a él:

chmod 600 /root/montaje

A continuación añadimos el recurso en /etc/fstab:

//192.168.0.254/musica /mnt/musica smbfs credentials=/root/montaje,uid=1000,iocharset=utf8 0 0

Una vez terminado con el programa de instalación de Debian procederemos, como es lógico, a reiniciar el sistema. Ingresaremos como usuario root, ya que todavía no tenemos sudo y todas las operaciones que debemos hacer son de administración.

Lo primero de todo, aprovechando que tenemos una instalación mínima, sería cambiar el tipo de distribución, de estable (que es lo que hemos instalado)  testing. Durante este proceso aprovecharemos también para añadir ramas del repositorio para tener disponible todo el software de podamos necesitar. Para ello debemos editar el archivo /etc/apt/sources.list y dejarlo de la siguiente forma:

#Repositorios de software de Debian
deb http://ftp.nl.debian.org/debian/ testing main non-free contrib
deb-src http://ftp.nl.debian.org/debian/ testing main non-free contrib
#Actualizaciones de seguridad de Debian
deb http://security.debian.org/ testing/updates main contrib non-free
deb-src http://security.debian.org/ testing/updates main contrib non-free

Una vez editado procedemos a la actualización:

apt-get update
apt-get dist-upgrade

El sistema realizará cambios sustancias, tales como cambiar GRUB por GRUB2 o implantar el nuevo sistema de arranque de servicios por dependencias que sustituirá al antiguo basado en números estáticos. Una vez terminada la actualización reiniciamos el equipo y comprobamos que GRUB2 se ejcuta sin problemas. Si es así, una vez iniciado el equipo y haber ingresado como root ejecutamos:

upgrade-from-grub-legacy

Y nuestro sistema quedará finalmente actualizado a testing. Un problema que se me ha planteado al cambiar al sistema de arranque por dependencias es montar los discos duros USB de forma manual a arrancar la máquina. Dado que no tenemos entorno gráfico que lo haga por nosotros, los discos duros USB no son montados automáticamente, sino que tenemos que hacerlo nosotros de forma manual. Lo normal es crear los puntos de montajes en /mnt e incluir en fstab las entradas correspondientes. La cuestión es que  en la máquina en la que lo estoy instalando el sistema el arraque por dependencias  intenta montar los discos antes de haber detectado los USBs, por lo que realmente no lo hace.

Esto se puede solucionar fácilmente recurriendo a /etc/rc.local. Este script es ejecutado cada vez que se termina de alcanzar un runlevel de multiusuario (2, 3, 4 o 5), por lo que poniendo aquí las instrucciones de montaje estas se ejecutarán una vez terminado el inicio del equipo. No es la solución más elegante, pero es temporal al fin y al cabo (hasta que se solucione el problema en el arranque por dependencias). Así pues, lo que haremos es añadir las entradas al fstab y añadir lo siguiente en /etc/rc.local:

mount -a

Y ahora realmente hemos terminado de instalar squeeze.

Lo siguiente sería instalar y configurar sudo para no tener que trabajar con root.

aptitude install sudo
visudo

las líneas mínimas que tendríamos que crear en el fichero de sudoers serían (sustituir lo que se encuentra entre < > por los valores que correspondan a vuestra máquina):

# Host alias specification
Host_Alias LOCAL = localhost, <nombre_del_host> , 127.0.0.1, <ip_LAN_del_host>

# User privilege specification
root    ALL=(ALL) ALL
<nombre_del_usuario>  LOCAL=(ALL) ALL

Esto nos permitirá hacer sudo cuando ingresemos con nuestro usuario en la máquina, pero nunca para ejecutar comandos remotamente, manteniendo debiamente la seguridad. Una vez hecho esto salimos de root y entramos con nuestro usuario, con el que trabajaremos a partir de ahora.

El siguiente paso sería instalar un servidor ssh para poder trabajar con la máquina en remoto (ya sea desde nuestra propia máquina de red local o desde internet.

sudo aptitude install ssh

Esto instalará el servidor y el cliente. El cliente de ssh apenas ocupa unos Ks y nunca se sabe cuándo podemos necesitarlo, así que no está de más que nos lo instale. Yo he cambiado el puerto del servidor SSH para, de esta forma, evitar la mayoría de los ataques. para ello editaríamos /etc/ssh/sshd_config y la línea Port. También puede ser interesante cambiar el archivo /etc/issue.net para que oculte nuestra versión del sistema operativo y de paso ponga algún mensaje amenazador. Una vez terminados los cambios, reinicamos el servidor SSH para que nos aplique el cambio de puerto:

sudo /etc/init.d/ssh restart

A partir de este momento ya podemos quitar el teclado y el monitor de la máquina y acceder por SSH a la misma para continuar la instalación.