El error es muy similar a este otro «E: No se pudo bloquear /var/lib/apt/lists/lock – open (11 Recurso no disponible temporalmente)«, y es fácil confundirlos si no prestamos la atención suficiente. Ambos ocurren cuando realizamos tareas de instalación o des-instalación de software, la diferencia radica en que mientras uno está relacionado con Apt, el otro está relacionado con Dpkg.

El error

El error se produce al intentar instalar o des-instalar alguna aplicación. Cuando el sistema hace uso del gestor de paquetes Dpkg, y éste intenta bloquear los recursos necesarios para realizar sus tareas, se encuentra que estos ya están bloqueados y lanza el siguiente error:

E: No se pudo bloquear /var/lib/dpkg/lock - open (11 Recurso no disponible temporalmente)
E: Unable to acquire the dpkg No se pudo bloquear el directorio (/var/lib/dpkg/), ¿quizás haya algún otro proceso utilizándolo?

Es bastante habitual que ese bloqueo esté producido por algún problema en operaciones anteriores, y que en el momento de encontrarnos con el error no exista ningún proceso activo utilizando esos recursos. No obstante debemos asegurarnos de ello.

La solución

La solución es rápida y sencilla. Como hemos dicho, comenzamos comprobando si existe algún proceso activo utilizando el archivo que genera el bloqueo:

sudo fuser -v /var/lib/dpkg/lock

En caso de que haya algún proceso activo provocando el bloqueo deberemos decidir si lo dejamos terminar o si por el contrario lo matamos, mi recomendación es ser razonablemente pacientes. Si optamos por matarlo, volveremos a hacer uso del comando fuser, añadiendo dos modificadores más:

sudo fuser -vki /var/lib/dpkg/lock 

Si era un proceso el causante del y este ha concluido su tarea, lo más probable es que el error ya no persista.

Si por el contrario no había proceso activo, o lo había pero decidimos matarlo, deberemos eliminar el archivo que sigue generando el bloqueo:

sudo rm /var/lib/dpkg/lock

Y con esto ya habremos terminado y podremos realizar la tarea que no pudimos inicialmente.

El caso es que en los últimos meses me he encontrado en varias ocasiones con el error del título, y con este otro «No se pudo obtener el bloqueo /var/lib/dpkg/lock – open (recurso temporalmente no disponible)«, que es tan parecido que si no leemos atentamente puede llevarnos a errar en el diagnóstico del problema. Y si bien las soluciones son prácticamente iguales, los detalles distan mucho, y podríamos estar intentando curar un catarro con las medicinas para curar una gastroenteritis. Pero no me enrollo mas y vayamos al lío.

El error

El error se produce al intentar actualizar los repositorios o realizar otras tareas relacionadas con el gestor de paquetes Apt, y la salida en pantalla completa es la siguiente:

E: No se pudo bloquear /var/lib/apt/lists/lock - open (11 Recurso no disponible temporalmente)
E: No se pudo bloquear el directorio (/var/lib/apt/lists/)

El origen del problema radica en que intentamos acceder a un recurso que está bloqueado por otro proceso. Lo más habitual es que ese otro proceso ya no exista, y que el recurso que necesitamos haya quedado bloqueado por algún problema en una operación anterior. No obstante, es mejor ser cautos y verificar si ese bloqueo esté motivado por una algún proceso activo.

La Solución

La solución al problema es rápida y sencilla. En primer lugar comprobamos si existe algún proceso utilizando el archivo que genera el bloqueo:

sudo fuser -v /var/lib/apt/lists/lock 

En caso de que haya algún proceso, deberemos decidir si lo dejamos terminar o si lo matamos. Si optamos por matarlo, podemos hacerlo con el mismo comando fuser, tan solo añadiendo algunos modificadores más:

sudo fuser -vki /var/lib/apt/lists/lock 

Y acto seguido, e independientemente de si había o no un proceso activo, eliminamos el archivo que provoca el bloqueo:

sudo rm /var/lib/apt/lists/lock

Y con esto ya podríamos volver a actualizar nuestros repositorios o realizar la tarea que no pudimos completar al encontrarnos con este inconveniente.

El caso es que tengo un pc (o tablet) Microsoft Surface Pro 1 en el que tenía instalado Windows 10. La verdad es que esa combinación funciona muy bien para el uso que hago de este dispositivo: consultas varias en internet, escribir este blog, sincronizar algún gadget, etc., en fin, un uso lúdico y poco intensivo. Pero desde hace ya algún tiempo rondaba por mi cabeza la idea de probar cómo iría con alguna distribución de Linux.

Microsoft Surface Pro 1

Para aquellos que no conozcan este dispositivo os dejo una pequeña presentación. El equipo tiene ya algunos añitos, concretamente 6, salio a la venta en 2012 pero yo lo adquirí en 2013. Tiene un procesador Intel Core I5-3317U con dos cores a 1.70GHz, 4GB de memoria RAM, 128GB de disco duro SSD y una pantalla de 10,6 pulgadas con una resolución de 1920×1080.

En la practica es un equipo pesado en relación a su tamaño, se calienta demasiado y su batería difícilmente duraba dos horas con Windows 8 o con Windows 10.

Elección de distribución

En mi ordenador personal utilizo Xubuntu, y estoy muy contento con esta distribución, de hecho me siento mucho más cómodo con su escritorio Xfce que con GNOME o KDE, así que fue mi primera opción. Pero tras probarlo desde un live usb lo descarté sobre la marcha, el teclado en pantalla no aparecía por defecto, y aunque sé que podría encontrar alguno en los repositorios, digamos que lo tomé como un presagio y no tenía ganas de buscarme complicaciones.

La segunda opción fue Ubuntu 19.04, también desde live usb. En este caso el teclado en pantalla apareció desde que situé el foco en un cuadro de texto. Y aunque en ese momento existían algunos detalles que no me convencían, la existencia de apartados dedicados a la configuración de accesibilidad para ratón y teclado, unido al teclado en pantalla me convencieron. Así que me despedí de Windows e instalé Ubuntu, un HD de 128GB no es territorio para que convivan dos sistemas operativos.

Experiencia con Ubuntu en dispositivos táctiles

Y ahora que ya os he soltado la chapa, vamos a revisar los aspectos que considero más relevantes de mi experiencia con Ubuntu en la tablet Microsoft Surface.

Teclado en pantalla

Ubuntu Desktop tiene el teclado en pantalla instalado por defecto, así que podremos utilizarlo tanto ejecutando la distro desde el live usb como en el proceso de instalación, y por supuesto una vez instalado en nuestro equipo.

El teclado en pantalla está estéticamente bien logrado y no me resulta nada intrusivo en el despliegue, es más estos dos puntos me parecen sensacionales. Su funcionamiento es bueno, salvo al escribir en la barra de direcciones de Firefox que tiene un comportamiento errático. Este problema no lo he notado en ningún otro programa.

El principal inconveniente con este teclado es que es excesivamente sencillo, no dispone de teclas de dirección, ni de teclas de función (F1, F2…), ni de teclas de control (Alt, Ctrl, Esc…). Parece pensado para utilizarse en una tablet tipo Android más que en un pc.

Esto me ha obligado a instalar un segundo teclado en palla para solventar las situaciones en las que necesito hacer uso de alguna de las teclas de las que no dispongo, algo que me resulta muy engorroso.

Este teclado auxiliar se llama Florence Virtual Keyboard, y está muy bien para salir del paso, pero personalmente no me convence como teclado principal. Si quieres instalarlo:

sudo apt-get update
sudo apt-get install florence

Afortunadamente este tipo de teclas, por el uso que hago del dispositivo, las utilizo poco. Pero si tú haces uso intensivo de ellas, el teclado en pantalla de Ubuntu se te quedará corto.

Stylus

La tablet Microsoft surface 1 viene con un lápiz o stylus con cuatro funciones principales: puntero, click izquierdo, click derecho y borrar. Mi stylus ha perdido esta última funcionalidad así que os hablaré de las otras tres.

El puntero funciona perfectamente, al igual que la simulación del click del botón izquierdo del ratón. La simulación del click derecho en cambio no funciona desde un principio, pero tras una sencilla búsqueda en internet pude solucionarlo. Tan solo tenemos que hacer que Ubuntu ejecute el siguiente comando tras el arranque:

xmodmap -e "pointer = 1 3 2 4 5 6 7 8 9 10"

Acciones táctiles

El manejo de la tablet sin el lápiz está conseguido a medias. Si bien la respuesta a las acciones táctiles es buena, no he conseguido simular el click derecho del ratón de una forma satisfactoria. A pesar de que en el apartado «Acceso Universal», dentro de la configuración de Ubuntu, existe un apartado para este propósito, el resultado no me ha convencido en absoluto.

Rotación de pantalla

La rotación de la pantalla es otra de las funcionalidades que vienen por defecto. Su funcionamiento es muy bueno, la respuesta al giro es adecuada y el escritorio y los programas se adaptan perfectamente a visualizaciones tanto horizontales como verticales. Además en las herramientas situadas en la esquina superior derecha podemos bloquear la rotación, algo muy de agradecer en un dispositivo de estas características.

Duración de la batería

Un aspecto que me ha sorprendido gratamente y que no me esperaba es la duración de la batería. Si con Windows 10 rara vez conseguía tener dos horas reales de uso de la tablet, con Ubuntu he conseguido duplicar esta autonomía. Evidentemente esto dependerá del uso que hagamos del dispositivo, y es posible que en usos más intensivos la diferencia entre los dos sistemas se reduzca.

Además, algo con un origen muy en relación a la duración de la batería, es que la tablet ahora se calienta menos que cuando tenía instalado Windows.

Conclusión

El uso de Ubuntu en dispositivos táctiles tiene sus luces y sus sombras. La experiencia de usuario está lejos de ser perfecta, pero aun así, para mi ha sido más que suficiente para decidirme a cambiar.

Créditos, referencia y artículos relacionados

• Averiguar que versión de Linux tengo instalada.
• Cómo instalar Linux dentro de Windows 10 utilizando WSL 1
• Actualización de Windows 10 machaca el gestor de arranque de Linux

Así que puestos a escribir sobre habilitar módulos, y dado que es una tarea bastante habitual habitual cuando instalamos un nuevo servidor web, o incluso cuando instalamos algunos paquetes de software sobre un servidor web existente, decidí escribir esta entrada más generalista.

Y es que en la actualidad, en una instalación estándar de Apache 2 sobre Ubuntu 18 se instalan más de 100 módulos, de los cuales sólo hay activos algo más de una veintena.

Habilitar módulos

Lejos quedan los tiempos en los que para habilitar módulos de Apache teníamos que editar el archivo apache.conf, tarea que generalmente no consistía más que en descomentar alguna línea. Hoy basta con ejecutar el comando a2enmod y reiniciar el servidor:

sudo a2enmod modulo
sudo service apache2 restart

Pero descubramos que hay detrás de de este comando.

Los módulos disponibles por Apache 2 se encuentran dentro del directorio /etc/apache2/mods-available/. Lo que quiere decir que si el módulo que queremos habilitar no se encuentra ahí tendremos que copiarlo y asignarle los permisos adecuados.

Por otro lado, los módulos habilitados se encuentran en el directorio /etc/apache2/mods-enabled/. Pero en este caso en lugar de encontrar archivos, encontraremos enlaces simbólicos a los archivos situados en la carpeta /etc/apache2/mods-available/. Así que una alternativa al comando a2enmod es el comando ln:

sudo ln -s /etc/apache2/mods-available/modulo /etc/apache2/mods-enabled/modulo
sudo service apache2 restart

Deshabilitar módulos

Y para deshabilitar módulos la operación es muy similar, con la salvedad de que en lugar de utilizar el comando a2enmod utilizaremos el comando a2dismod:

sudo a2dismod modulo
sudo service apache2 restart

O simplemente eliminaremos el enlace simbólico:

sudo rm /etc/apache2/mods-enabled/modulo
sudo service apache2 restart

Comprobaciones y logs de errores

Podemos saber si un módulo se ha instalado correctamente revisando la salida de la función phpinfo() de php, en la sección apache2handler.

Y en caso de experimentar cualquier tipo de problema, el primer lugar dónde consultar qué está ocurriendo son los logs de error de Apache 2, en el archivo /var/log/apache2/error.log.

cat /var/log/apache2/error.log

Créditos, referencias y artículos relacionados

• Imagen de portada por Wichan Yodsawai.
• Servidor Web en Raspberry PI y Ubuntu Mate.
• Como configurar Virtual Hosts en Apache 2 y Ubuntu.
• Archivos y permisos de usuario en Apache 2 y Linux.

La instalación es muy sencilla y no nos tomará más de 10 o 15 minutos, así que vamos al lío.

Requisitos para instalar Linux en Windows 10 con WSL 1

Nuestro equipo debe cumplir básicamente dos requisitos:

• Tener instalado Windows 10 con versión 16215.0 o posterior .
• Que la instalación de Windows 10 sea de 64 bit.

Además es recomendable disponer al menos de un Pentium 4 a 2.4 GHz o superior, 2 GB de memoria RAM o más y 5 GB de espacio libre en el disco o más.

Instalar WSL 1

El primer paso será instalar el paquete Windows Subsystem for Linux. La forma más sencilla es abrir PowerShell como administrador y ejecuta la siguiente instrucción.

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

La alternativa gráfica pasa por:

1. Abrir el Panel de Control.
2. Acceder al grupo Programas.
3. Abrir la ventana para Activar o desactivar las características de Windows.
4. Marcar la opción Subsistema de Windows para Linux y aceptar.

Con cualquiera de las dos opciones nos pedirá reiniciar.

Elegir e instalar una distro Linux

Con WSL instalado es hora de elegir la distribución que queremos instalar de las disponibles en la tienda de Microsoft. A continuación te dejo una lista de las principales:

• Debian GNU/Linux
• Ubuntu 16.04 LTS
• Ubuntu 18.04 LTS
• OpenSUSE Leap 15
• OpenSUSE Leap 42
• SUSE Linux Enterprise Server 12
• SUSE Linux Enterprise Server 15
• Kali Linux

Y como comenté en la entrada Ejecutar Linux en Windows 10 con WSL, existe una lista de distribuciones alternativas creadas específicamente para WSL:

• Fedora Remix for WSL
• WLinux
• WLinux Enterprise
• Alpine WSL

Es posible que con el paso del tiempo estas listas varíen, al final del artículo tienes un enlace a la documentación oficial de Microsoft dónde encontrarás la lista de distribuciones actualizada.

Una vez que la descarga y la instalación estén completadas ya podremos abrir nuestra flamante consola de Linux desde Windows! Solo deberemos buscar en el menú de inicio el icono de la distro que hayamos instalado y abrirla como cualquier otra aplicación.

En el primer arranque de nuestra consola notaremos que realiza algunas operaciones para finalizar la instalación y posteriormente nos pedirá que elijamos un nombre de usuario y una contraseña. Tal y como nos indica la consola no es necesario qué coincidan con los de Windows.

Y con esto hemos acabado. Si todavía no lo habéis probado os recomiendo una vez más, aún a riesgo de parecer pesado, el artículo Ejecutar Linux en Windows 10 con WSL, que estoy convencido de que os resultará de utilidad.

Créditos y Referencias

• Documentación de Windows Subsystem for Linux
• Ejecutar Linux en Windows 10 con WSL

Creo que todo usuario de Linux estará de acuerdo conmigo en que la mejor forma de instalar Linux es hacerlo de la forma tradicional, es decir, con sus correspondientes particiones, de forma que podamos encender nuestro PC directamente en nuestra distro preferida con el cien por cien de recursos y opciones disponibles.

Pero esto no es siempre posible, y aunque lo fuera tenemos múltiples opciones que podemos aprovechar en función de nuestras necesidades, como por ejemplo:

• Ejecutar Linux en modo live USB o CD.
• Crear una máquina virtual con la distro que elijamos.
• Instalar Linux en un SBC (Single Board Computer) como puede ser una Raspberry Pi.
• Instalar Linux dentro de Windows 10, como si de una aplicación más se tratase.

Todas éstas son opciones muy válidas y tienen sus propias ventajas e inconvenientes con respecto a una instalación tradicional. Nosotros hoy, tal y como reza el título de esta entrada, nos centraremos en la última de ellas.

Inconvenientes de ejecutar Linux desde Windows

Puesto que de partida ya imaginamos que este sistema tendrá muchas limitaciones, hablaremos primero de ellas, para luego ver sus virtudes:

• Solo podemos hacer uso de la consola, es decir, no tenemos disponible ningún sistema de escritorio.
• La lista de distribuciones disponibles es muy limitada.
• El rendimiento es bastante inferior a una instalación nativa. Por lo que he podido leer el rendimiento debería ser superior al de una máquina virtual, por mi experiencia con WSL 1 no pondría la mano en el fuego por ello.

Seguro que tiene muchas más limitaciones, pero estas han sido para mi las más evidentes o las que más me han afectado mientras hago uso de este sistema, y son muchas menos de las que en un principio había esperado.

Ventajas de ejecutar Linux desde Windows

Y una vez vistas las desventajas, veamos ahora algunas de sus virtudes:

• Disponer de toda la potencia de la consola de Linux sin necesidad de reiniciar, levantar una máquina virtual o conectar a un host Linux. Esto lo agradecerán sobre todo los usuarios más habituales y avanzados de Linux.
• Reducir el número de reinicios para alternar entre sistemas operativos. Aunque esto no es más que una consecuencia del punto anterior.
• Poder acceder a los archivos de Windows desde la consola de Linux, con lo que conseguimos utilizar la potencia de la consola de Linux en el propio sistema de ficheros de Windows.
• Si eres desarrollador web y trabajas en Windows, podrás olvidarte de aplicaciones que seguro conoces como WAMP, XAMPP, Appserv, etc. Podrás tener un servidor LAMP dentro de Windows, con todos los beneficios que ello supone.

Al igual que indiqué con los inconvenientes, parecen pocas ventajas y seguro que tiene muchas más, pero estas son las que hasta el momento más me han aportado a mi.

¿Merece la pena instalar Linux dentro de Windows?

Y una vez vistas las ventajas y los inconvenientes, la pregunta que surge automáticamente es si merece la pena instalar Linux dentro de Windows, y para mi la respuesta es un Si rotundo.

Evidentemente una instalación de estas características nunca podrá sustituir a una instalación tradicional, pero esta no es la intención de WSL. En cambio si la vemos como un complemento a nuestro sistema operativo Windows, es una funcionalidad que le hace ganar muchos puntos: podremos utilizar herramientas como VIM o Emacs, todos los comandos disponibles en Linux sobre los archivos de Windows, servidores como Apache, MySQL u Open SSH, etc.

Y lo mejor es que no tienes que elegir, es decir, yo en mi equipo tengo una instalación tradicional de Ubuntu y Windows 10 con Grub en la partición de arranque. Pero es que además dentro de Windows 10 tengo instalado otro Ubuntu con WSL que lo complementa y lo potencia, así que de nuevo la respuesta es Si.

Distribuciones de Linux disponibles para instalar en Windows

Ya lo adelantamos en el apartado de limitaciones, la lista de distribuciones de Linux disponibles para instalar es bastante limitada:

• Debian
• Ubuntu
• Suse
• openSuse
• Kali Linux

Y es que teniendo en cuenta la gran cantidad de distribuciones de Linux existentes es de esperar que muchos usuarios echen de menos su distribución preferida, pero si valoramos el uso que haremos de esta distro es posible que la oferta no esté nada mal.

También existen algunas distribuciones derivadas de las «originales» creadas específicamente para trabajar con WSL como son:

• Fedora Remix for WSL
• WLinux
• WLinux Enterprise
• Alpine WSL

Algunas cosas que te interesará saber

Y a modo práctico, algunos tips variados que he creído que podrían resultar interesante y que no he podido encajar en ninguna otra parte de esta entrada son las siguientes:

• Desde Linux tendrás acceso al sistema de archivos de Windows en la ruta /mnt/c. La «c» se corresponde con la letra de la unidad a la que queremos queremos acceder.
• Aunque cierres la venta de tu Linux el sistema seguirá funcionando de fondo, por lo que podrás hacer pleno uso de servicios como Cron, Apache2, etc.
• No podrás hacer uso de copiar y pegar como es habitual en un emulador de consola en el escritorio de Linux o una sesión de SSH con Putty.
• En un mismo SSOO Windows puedes instalar más de una distribución de Linux.
• Aunque no lo he probado, puedes mantener varias instalaciones de SSOO Linux corriendo en versiones distintas de WSL.

Diferencias entre WSL 1 y WSL 2

Y ya que abrimos el artículo haciendo referencia a las versiones de WSL, veamos cuales con las diferencias. WSL 1 y 2 ofrecen prácticamente la misma experiencia de usuario. Las mejoras de WSL 2 están enfocadas exclusivamente en el rendimiento, y focalizadas en dos puntos principales:

1. Mejora en el rendimiento del sistema de ficheros.
2. Mejora del rendimiento de las llamadas entre Windows y Linux mediante el sistema que han denominado Full System Call Compatibility.

Pero como todavía no he probado WSL 2, de momento no puedo daros mi opinión al respecto.

Créditos y Referencias

• Documentación de Windows Subsystem for Linux

Además de la versión de Linux que tenemos instalada, existen otros aspectos relativos al sistema que guardan bastante relación cómo son la distribución, si es un sistema de 32 o de 64 bits o la versión del kernel. Estos datos son un buen complemento y pueden resultar de gran ayuda cuando buscamos la versión de Linux.

Versión de Linux desde el terminal

La forma más rápida y sencilla de averiguar sobre que versión de Linux estamos trabajando es mediante el terminal, desde dónde tendremos múltiples opciones.

Comando lsb_release

Es mi opción más habitual. Lsb son las siglas de Linux Standard Base, un dato que quizás como a mi te ayude a recordar mejor este comando:

lsb_release -a

Y nos devolverá un resultado similar al siguiente, dónde además de la versión podemos ver la distro:

Distributor ID: Ubuntu
Description:    Ubuntu 16.04.6 LTS
Release:        16.04
Codename:       xenial

En caso de que el comando no te funcione, es decir, que no esté instalado por defecto, solo tendremos que instalarlo:

sudo apt-get update
sudo apt-get install lsb-release

Comando hostnamectl

Otra alternativa quizás menos específica pero que igualmente arrojará la información que buscamos es el comando hostnamectl. Este comando además nos devolverá información sobre la distribución, la versión del kernel, la arquitectura del procesador o la ID de la máquina:

hostnametcl

En este caso el resultado seria algo así:

   Static hostname: pcname
         Icon name: computer
        Machine ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
           Boot ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  Operating System: Ubuntu 16.04.6 LTS
            Kernel: Linux 4.4.38-v7+
      Architecture: arm

/etc/*-release

Otra alternativa aparentemente menos sofisticada pero igualmente válida es consultar la información de los archivos /etc/os-release, /etc/lsb-release o /etc/*-release. En función de nuestra distro la información se encontrará en uno o varios de estos archivos.

cat /etc/os-release

Las salidas que obtendremos pueden variar ligeramente, pero básicamente serán parecidas a la que muestro. En esta ocasión también vemos que obtenemos el nombre de la distribución.

NAME="Ubuntu"
VERSION="16.04.6 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.6 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial

Versión de Linux desde el escritorio

Desde el escritorio la cantidad de opciones se reduce, o no, pues mi recomendación, si sólo queremos conocer la versión de Linux sobre la que estamos trabajando es que presiones la combinación de teclas:

Ctrl + Alt + t

Y una vez que se abra el terminal uses una de las opciones que acabamos de ver.

Hardinfo

Una alternativa sencilla y lijera para ver información sobre la versión de Linux desde el entorno gráfico es utilizar el programa Hardinfo. Es muy probable que no esté instalado por defecto, si así, como es habitual:

sudo apt-get update
sudo apt-get install hardinfo

La aplicación es muy sencilla de utilizar y solo deberemos desplazarnos hasta el apartado «Sistema Operativo». Como veis en la captura de pantalla, la aplicación tiene mucha información extra de gran utilidad:

Otra información Interesante

Como comentamos al comienzo de la entrada existe cierta información que guarda mucha relación con la versión de Linux y que puede sernos muy útil. Veamos cómo obtener alguna de esta información.

Averiguar si una instalación de Linux es de 32 o de 64 bits

Es más que probable que en ciertas ocasiones quieras saber si tu instalación de Linux es de 32 o de 64 bits. Podemos averiguarlo utilizando alguno de los siguientes comandos:

getconf LONG_BIT

O:

uname -i

Averiguar la versión del kernel de Linux

Esta es otra duda muy relacionada que con el paso del tiempo y la sofisticación de Linux se ha vuelto algo menos común. De nuevo hacemos uso del comando uname:

uname -r

Y la salida que nos devolverá será algo así:

4.15.0-51-generic

Créditos y referencias

• Imagen de portada: Arek Socha

Esta es la tercera entrega de la serie Clonar una web en un servidor local, por lo que te recomiendo leer las entregas previas. No obstante, este artículo puede ser tratado como un artículo atómico asumiendo que perdemos ciertos matices.

Una de las ventajas del proceso de clonado de los archivos frente al de clonado de una base de datos es que si bien con la base de datos podíamos encontrarnos muchas limitaciones en función de los diferentes proveedores y planes de hostings, para clonar los archivos el único requisito que debemos cumplir con respecto a nuestro host remoto es tener acceso mediante ftp, algo que todos los hosting ofrecen.

Descarga de archivos

Para descargar los archivos nos serviremos del comando wget. Comenzaremos el proceso creando un script de consola y le asignándole los permisos necesarios:

mkdir ~/scripts
vim ~/scripts/cloneWebFiles.sh
chmod 0755 ~/scripts/clonWebFiles.sh

Con el siguiente contenido:

#!/bin/bash

wget -r -N -q --level=15 --user=user --password='password' --directory-prefix=~/webBackUp fttp://ftp.url.com

Dónde:

• -r, indica recursividad
• -N, indica que descargue solo archivos nuevos y/o modificados
• -q, oculta los mensajes de salida del comando
• –level=15, es el numero de niveles de recursividad
• –user=user, es el usuario ftp
• –password=’password’, es la contraseña del ftp
• –directory-prefix=~/webBackUp, es el directorio dónde copiaremos los archivos
• fttp://ftp.url.com, es el ftp con el path del que queremos descargar los archivos

Esto realizará una copia de los archivos de nuestra web en la carpeta ~/webBackUp/ftp.url.com. Esta operación suele tardar bastante tiempo, así que para agilizarla hemos optado por descargar únicamente los archivos nuevos y/o modificados recientemente, aun así con una web de tamaño medio tardará un buen rato.

Debemos destacar que no descargamos los archivos directamente a nuestro entorno de pruebas, sino que los descargamos a una carpeta intermedia. Esto lo hacemos por dos motivos:

1. Modificaremos algunos archivos antes de copiarlos en nuestro entorno de pruebas.
2. Podemos crear un segundo script que omita la descarga y que restaure nuestra copia mucho más rápido, muy útil en caso de querer descartar los cambios realizados y comenzar desde 0.

Modificación de datos relativos al entorno

Una vez hecha la descarga de los archivos deberemos modificar los que contienen datos relativos a nuestro host. En nuestro ejemplo, el archivo wp-config.php almacena la inforación de la conexión a la base de datos. En vuestro caso debereis localizar que archivos contienen este tipo de información antes de seguir avanzando.

La estrategia que seguiremos para ello sera la de realizar una copia inicial de forma manual de los archivos sensibles al entorno de pruebas. Una vez hecha actualizaremos los datos necesarios.

Por otro lado, automatizaremos una tarea que renombra estos archivos en la ubicación intermedia, de forma que cuando realicemos la copia al entorno de pruebas no se sobrescriban. Así que agregamos estas dos líneas a nuestro script:

rm ~/webBackUp/ftp.url.com/w-config.php.renamed
mv ~/webBackUp/ftp.url.com/w-config.php ~/webBackUp/ftp.url.com/w-config.php.renamed

Copia de archivos a la ubicación definitiva

Ya con los archivos descargados y una vez resuelta la problemática de la información sensible al entorno copiamos los archivos:

cp -r ~/webBackUp/ftp.url.com/* /var/www/targetVHost

Como vemos, este sistema solo copia los archivos nuevos y/o que han sufrido cambios, pero si hemos eliminado un archivo de nuestro host remoto no lo eliminará de nuestro host local. Para mi esta situación no supone un problema a día de hoy, así que simplemente no hago nada, pero siempre se puede preparar algún sistema que busque la diferencia de archivos entre la copia intermedia y el entorno de prueba y elimine los sobrantes de esta segunda ubicación.

El script

Y todo el rollazo que os he soltado se traduce básicamente en el siguiente script:

#!/bin/bash

wget -r -N -q --level=15 --user=user --password='password' --directory-prefix=~/webBackUp fttp://ftp.url.com
rm ~/webBackUp/ftp.url.com/w-config.php.renamed
mv ~/webBackUp/ftp.url.com/w-config.php ~/webBackUp/ftp.url.com/w-config.php.renamed
cp -r ~/webBackUp fttp://ftp.url.com/* /var/www/targetVHost

Programar la ejecución de la copia

Al igual que hicimos con la clonación de la base de datos programamos la ejecución del script con Cron:

crontab -e

E incluimos la siguiente línea en el archivo crontab:

0 2 * * 5 ~/scripts/clonWebFiles.sh

Aunque en principio ambos script podrían ejecutarse a la misma vez, hemos sido precavidos retrasando una hora la ejecución de la copia de los archivos, de forma que se ejecute cada viernes a las 02:00 de la madrugada.

Créditos y Referencias

• Articulo de la serie: Clonar una web en un servidor local.
• Entrega previa de la seie: Clonar una web: la base de datos.
• Imagen de portada: Martin Harry.

Esta entrada pertenece a la serie Clonar una web en un servidor local. Por ese motivo te recomiendo que leas dicho artículo para darle perspectiva a este. Sea como sea, este artículo puede ser leído sin la referencia anterior, pero perderemos ciertos matices que quizás resulten interesantes.

Backup de la base de datos remota

En función del hosting que tengamos contratado dispondremos de una serie de funcionalidades. Por norma general si has contratado un VPS o servidor dedicado tendrás la posibilidad de ejecutar scripts de consola, lo cual ofrece muchas posibilidades para la tarea que queremos realizar.

Si por el contrario dispones de un hosting compartido no sueles tener acceso a esta opción, así que para dar respuesta a la mayor cantidad de situaciones posibles realizaremos el backup con PHP, más concretamente haremos uso de la clase MySql Backup Lite que introducimos en la entrada Backup de base de datos MySQL con PHP. Y para programar la ejecución de esta tarea nos ayudaremos de nuestro servidor local, dónde programaremos la ejecución de un script que acceda a la url que realiza el respaldo.

Para no extendernos demasiado y no repetirnos, no copiaremos la clase en esta entrada, puedes encontrarla en los enlaces del párrafo anterior.

Así que crearemos un script en PHP en nuestro servidor remoto que llamaremos backUpDb.php en el directorio scripts que tras ser ejecutado generará una copia de la base de datos en el archivo backups/wordpressBackUp.sql.

include('MySqlBackup.php');

$arrayDbConf['host'] = 'dbHost';
$arrayDbConf['user'] = 'dbUser';
$arrayDbConf['pass'] = 'dbPassword';
$arrayDbConf['name'] = 'wordpressDbName';

try {

  $bck = new MySqlBackupLite($arrayDbConf);
  $bck->backUp();
  $bck->setFileDir('../backups/');
  $bck->setFileName('wordpressBackUp.sql');
  $bck->saveToFile();

}
catch(Exception $e) {

  die($e);

}

Si nuestro hosting tiene habilitada la conexión remota a la base de datos este paso podríamos ejecutarlo en el servidor local. Como no siempre tendremos esta opción, nos hemos decantado por la alternativa más universal.

Y puesto que en este ejemplo el backup es de una plataforma WordPress, y que por ese motivo los datos de conexión a la base de datos ya están especificados en un archivo de configuración escrito en PHP, sería más interesante hacer un include del archivo wp-config.php y obtenerlos desde ahí. De nuevo, en pro de mantener esta entrada lo más genérica posible hemos decidido hacerlo así.

Programar la ejecución del backup de la base de datos

Una vez más existen múltiples opciones para programar esta tarea, unas más elegantes que otras. En un VPS programar una tarea con Cron sería lo más lógico y eficiente, pero tal y como hemos comentado, tomaremos la opción que podemos aplicar independientemente del hosting que tengamos: utilizaremos Cron en nuestro servidor local para programar una tarea que ejecute el script de backup de base de datos que acabamos de crear en el host remoto.

Para ello creamos un script de consola y le asignamos los permisos necesarios:

mkdir ~/scripts
vim ~/scripts/cloneWebDb.sh
chmod 0755 ~/scripts/clonWebDb.sh

Con el siguiente contenido:

#!/bin/bash

curl -Is https://url.com/scripts/backUpDb.php

Y programamos la ejecución del script con Cron:

crontab -e

E incluimos la siguiente línea en el archivo crontab:

0 1 * * 5 ~/scripts/clonWebDb.sh

Asegurándonos de que el script se ejecuta cada Viernes a la 1 de la madrugada. Evidentemente puedes programar la periodicidad que más te convenga. Puedes visitar la entrada Programar tareas en Ubuntu con Cron para profundizar en la programación de tareas con Cron.

Descargar el backup de la base de datos

Lo siguiente es descargar el backup que acabamos de realizar. Lo haremos mediante el protocolo ftp, sirviéndonos del comando wget. Para ello agregamos una línea más a nuestro script clonWeb.sh, de forma que quede así:

#!/bin/bash

curl -Is https://url.com/scrpts/backUpDb.php
wget -q --user=user --password='password' --directory-prefix=~/webBackUp fttp://ftp.url.com/backups/wordpressBackUp.sql

Dónde:

• -q, oculta los mensajes de salida del comando
• –user=user, es el usuario ftp
• –password=’password’, es la contraseña del ftp
• –directory-prefix=~/webBackUp, es el directorio dónde copiaremos los archivos
• fttp://ftp.url.com/backups/wordpressBackUp.sql, es el ftp con el path del que queremos descargar los archivos

Con esto ya habremos descargado nuestra base de datos en el directorio ~/webBackUp/ftp.url.com/backups/wordpressBackUp.sql. El siguiente paso será restaurarla.

Restauración de la base de datos

Y para restaurar la base de datos en nuestro servidor local la estrategia que seguiremos será:

1. Eliminamos la base de datos.
2. Volvemos a crear base de datos vacía.
3. Restauramos la base de datos desde el backup.

Como puedes ver el proceso es bastante crítico pues elimina completamente la copia existente. Además hará que durante el tiempo que toma el proceso nuestro clon local no esté accesible. En mi caso el uso que le voy a dar es disponer de una réplica de una web en productivo en un servidor local para realizar pruebas. Para este uso el riesgo es perfectamente asumible, y en todo el tiempo que llevo utilizándola no he tenido ningún tipo de problema. Evidentemente, tú deberás evaluar si este riego y esta parada de servicio son asumibles para ti.

Así que crearemos un script SQL que elimine completamente la base de datos y vuelva a crearla. De nuevo lo haremos dentro de la carpeta ~/scripts y lo llamaremos dropAndCreateDb.sql. El contenido será el siguiente:

DROP DATABASE localDbName;
CREATE DATABASE localDbName;

Y agregamos dos líneas más a nuestro script de consola para ejecutar

#!/bin/bash

curl -Is https://urlToScript.com/backUpDb.php
wget -N -q --user=user --password='password' --directory-prefix=~/webBackUp ftp://ftp.miweb.com/path/backups/wordpressBackUp.sql
mysql -u localDbUserName -plocalDbPassword localDbName < ~/scripts/dropAndCreateDb.sql
mysql -u localDbUserName -plocalDbPassword localDbName < ~/webBackUp/ftp.url.com/backups/wordpressBackUp.sql

Actualización de los datos relativos al entorno

El último paso para dar por completado el proceso de clonación de nuestra base de datos será reemplazar todos los datos datos necesarios para que nuestro clon funcione perfectamente. Este paso es el que más puede variar de un entorno a otro, a continuación os dejo un ejemplo bastante básico para un blog realizado en wordpress:

update wp_options set option_value='http://192.168.1.10' where option_name='siteurl';
update wp_options set option_value='http://192.168.1.10' where option_name='home';
update wp_posts set guid=REPLACE(guid, 'blog.ahierro.es', '192.168.1.146:8085') where guid like '%blog.ahierro.es%';

Vosotros tendréis que localizar las tablas, campos y registro a modificar en vuestras plataformas. En el ejemplo expuesto las dos primeras líneas hacen referencia a datos de configuración y son imprescindible, pues de no actualizar estos campos nuestro wordpress local siempre redirigiría al remoto.

Créditos y Referencias

• Articulo de la serie: Clonar una web en un servidor local.
• Siguiente entrega de la serie: Clonar una web: los archivos.
• Clase MySql Backup Lite.
• Imagen de portada: Martin Harry.

Y cuando hablamos de «una copia exacta», queremos decir que tanto archivos como bases de datos estén perfectamente actualizados. Esto es muy útil para realizar pruebas de todo tipo: nuevos plugins, cambios de configuración, revisión de actualizaciones, etc.

Realizar esta tarea manualmente es tedioso, aburrido y consume mucho tiempo, eso sin contar que es probable que cuando nos propongamos realizar nuestras pruebas este entorno esté desactualizado, alterado por las últimas pruebas realizadas, o lo que es aún peor, no esté disponible. Así que una buena idea es automatizar esta tarea y programar su ejecución con la periodicidad que nos interese.

Algunos aspectos relativos al clonado

Resumen del proceso

Es buena idea tener una visión general del proceso antes de adentrarnos en él. Lo que vamos a hacer básicamente es un proceso ETL (Extract, Transform, Load) manual.

Como parte del proceso de extracción realizaremos una copia de seguridad de la base de datos y la descargaremos a una ubicación intermedia. Haremos lo mismo con los archivos del servidor.

Una vez tenemos todo lo necesario en nuestro servidor local, modificamos algunos datos como son archivos de configuración o los registros en la base de datos relativos al entorno.

Finalmente restauraremos la base de datos y sobrescribiremos los archivos de nuestro servidor local.

Local versus Remoto

A pesar de que cada una de las tareas que realizaremos no son complicadas por si mismas, alternaremos de host continuamente y eso puede generar alguna confusión, así que para seguir los pasos indicados sin error deberemos estar muy atentos al host en el que se realizan las distintas acciones. Identificaremos los hosts como «remoto», el servidor de producción que queremos clonar, y «local» el servidor de pruebas dónde queremos tener la copia.

Es importante que las versiones de LAMP (Linux, Apache, PHP y MySQL) sean lo más similar posible, de este modo es posible que nos ahorraremos algunos quebraderos de cabeza. Además, es recomendable dedicar un virtual host de Apache para este entorno en nuestro servidor local.

Ejemplo sobre WordPress

Y ya que estas líneas que lees están escritas sobre WordPress, utilizaremos esta plataforma como ejemplo para realizar el clonado. Esto quiere decir que por norma general, si queréis clonar otra plataforma, las mayores diferencias las encontraremos en los los registros de la base de datos y los archivos de configuración referentes al entorno.

Periodicidad

Como hemos dicho queremos automatizar el clonado de nuestra web para tener nuestra réplica preparada y actualizada en todo momento. Podemos establecer la periodicidad que más nos convenga, personalmente estoy cómodo con una semana por dos motivos:

1. En una semana no suelen producirse muchos cambios en el blog.
2. Algunas pruebas se extienden durante varios días, y una restauración diaria las sobrescribiría.

Además, siempre estamos a tiempo de lanzar una actualización manual en caso de ser necesario con la simple ejecución de un script. Si no tienes una web muy grande el proceso será relativamente rápido.

Requisitos hardware

En cuanto a los requisitos de hardware puedes estar tranquilo, pues no necesitas un gran servidor para implementar este sistema. Un ejemplo muy claro de ello es que para este blog lo tengo implementado con una humilde Raspberry Pi. Por si te interesa, aquí te dejo un enlace en el que puedes ver cómo de sencillo es montar un servidor web Apache sobre una Raspberry Pi.

Clonando nuestra web: el proceso

Llegados a este punto creo que al igual que yo ya tendréis ganas de poneros manos a la obra, así que no me enrollo más y vamos al lío.

Y puesto que esto se ha alargado un poco más de la cuenta, hemos dividido este artículo en varias entregas para que sea más fácil de seguir:

1. Clonar una web en un servidor local (es decir, esta entrada).
2. Clonar una web: la base de datos.
3. Clonar una web: los archivos.

Créditos y referencias

• Imagen de portada: Martin Harry.