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

Avahi

La mala noticia es que para lograr acceder por nombre a máquinas Linux en una red local con garantías la mejor solución es disponer de un servidor DNS (Bind es la opción Open Source más extendida), y en esta entrada no hablaremos sobre servidores DNS.

En esta entrada utilizaremos Avahi, una implementación gratuita de Zero-Configuration Networking que permite difundir y descubrir servicios y equipos en una red local. Quizás a alguno le resulte más familiar si citamos a Bonjour, que es la implementación propietaria que tiene Apple de esta tecnología.

Y en función de nuestras necesidades es posible que Avahi nos sirva o no (lógico). El principal motivo es que no basta con instalarlo en la máquina a la que queremos acceder por nombre (llamémosla máquina Destino), sino que cada equipo que quiera acceder por nombre a la máquina Destino debe poder trabajar con la tecnología Zero-Configuration Networking para interpretar la información publicada por nuestra máquina Destino.

Máquinas Destino y Clientes

Pongámonos en situación, de un lado tenemos una máquina corriendo Ubuntu, en mi caso es una Raspberry Pi corriendo la versión 16.0.4.2 de Ubuntu Mate. El hostname de esta máquina es «maquina1», su ip 192.168.1.15 y para agilizar la lectura, como ya hemos dicho, la llamaremos máquina «Destino». En esta máquina hemos instalado un servidor web y queremos acceder a ella mediante hostname.

Del otro lado tenemos una serie de equipos con distintos SSOO que son los que quieren consumir el servicio web accediendo por nombre. A estas máquinas las llamaremos «Clientes» y vamos a suponer que tenemos:

1. Cliente Linux, corriendo Ubuntu 18.
2. Cliente Windows, corriendo Windows 10.
3. Cliente Android, corriendo Android Oreo 8.1.

Lo siento por los amantes de Apple pero no tengo ningún dispositivo de la manzanita para probar, aún así si eres uno de ellos sigue leyendo porque estoy convencido que te será de utilidad.

Instalar y configurar Avahi

Comenzaremos realizando las instalaciones necesarias en la máquina Destino. En función de vuestra distro es posible que todos o algunos de estos paquetes ya estén instalados.

sudo apt-get update
sudo apt-get install avahi-daemon
sudo apt-get install avahi-utils
sudo apt-get install libnss-mdns

Y acto seguido editaremos la configuración de Avahi. Es buena idea que antes de editar cualquier archivo de configuración guardéis una copia que os ayude a volver al punto inicial si fuera necesario, aunque vamos a tocar muy poca configuración.

suco cp /ect/avahi/avahi-daemon.conf /etc/avahi/avahi-daemon.conf.bck
sudo vim /etc/avahi/avahi-daemon.conf

En el archivo de configuración nos centraremos primero en el nombre de la máquina y el dominio. Mi recomendación es que mantengáis la configuración por defecto, es decir ser coherentes y que el host-name coincida con el de la propia máquina y que el dominio sea «local». De esta forma accederemos a la máquina con maquina1.local.

[server]
host-name=maquina1
domain-name=local

Nos aseguraremos también de que las siguientes opciones se encuentren como mostramos:

[publish]
disable-publishing=no
disable-user-service-publishing=no
publish-addresses=yes

Reiniciamos el servicio y lo agregamos al arranque de nuestra máquina:

sudo service avahi-daemon restart
sudo update-rc.d avahi-daemon defaults

Y con esto hemos terminado con la máquina Destino.

Maquinas Clientes

Como ya mencionamos cada máquina cliente debe ser capaz de trabajar con la tecnología Zero-Configuration Networking para poder alcanzar la máquina Destino por nombre, así que veamos caso a caso.

Desde Linux

En cada equipo con sistema operativo Linux con el que queramos acceder por nombre a la máquina Destino deberemos instalar Avahi. Así que no tenemos más que repetir las instrucciones definidas en el apartado «Instalar y Configurar Avahi».

Desde Windows

Por defecto Windows no nos dejará acceder por hostname y por ahora no existe implementación de Avahi para este sistema operativo. En su defecto podemos instalar el programa «Servicios de impresión Bonjour para Windows», de Apple, que aunque está pensado para otro uso nos permitirá cubrir nuestra necesidad y alcanzar la máquina Destino por nombre.

Desde Android

Lamentablemente no he encontrado ninguna aplicación o demonio para Android que permita que cualquier aplicación que corra en este sistema operativo sea capaz de acceder por nombre a nuestra máquina Destino, una lástima. Si conoces alguna solución para ello estaría muy agradecido de que la compartas en un comentario.

IOS y MacOSX

Como he dicho no tengo ningún dispositivo de Apple para realizar pruebas, pero conociendo que tienen su propia implementación de de Zero-Configuration Networking (Bonjour), me atrevería a decir que podremos acceder por nombre a nuestra máquina Destino sin necesidad de instalar ningún software adicional.

Comprobar el funcionamiento

Aunque es de primero de pre-escolar (creo que ahora lo llaman infantil), me gusta comprobar las cosas, y la forma más sencilla de hacerlo es utilizar el comando ping. Si lo hemos conseguido obtendremos algo así:

ping raspi.local
PING raspi.local (192.168..15) 56(84) bytes of data.
64 bytes from 192.168.1.15 (192.168.1.15): icmp_seq=1 ttl=64 time=6.68 ms
64 bytes from 192.168.1.15 (192.168.1.15): icmp_seq=2 ttl=64 time=4.61 ms

Y si algo no funciona como esperamos obtendremos algo así:

ping maquina1.local
ping: maquina1.local: Nombre o servicio desconocido

Y como dijimos que en la máquina Destino teníamos un servidor web, al escribir maquina1.local en la barra de direcciones del navegador, obviamente, accederemos al contenido publicado.

Conclusión

Con Avahi podemos acceder por nombre a máquinas con sistema operativo Linux en nuestra red local. Su mayor limitación es que nos veremos obligado a que tanto la máquina a la que queremos acceder, como las máquinas con las que queremos acceder deben tener instalada una implementación de Zero-Configuration Networking.

Así que si bien resuelve ciertas situaciones y necesidades, si pensamos en una red de varias decenas de equipos con distintos sistemas operativos existen otras alternativas más escalables.

Como siempre me gustaría saber cómo cual es tu experiencia, ¿has usado Avahi? ¿accedes por ip? ¿utilizas otra tecnología u otros programas? Deja un comentario y danos tu opinión.

Por otro lado, en función de diferentes factores relacionados con un proyecto de desarrollo podemos trabajar en equipo, que es lo más probable, o solos. Cuando trabajamos en equipo es lógico que el software de control de versiones se encuentre en un servidor centralizado. Cuando trabajamos solos podemos decidir que solo esté en nuestra máquina.

Personalmente incluso trabajando en solitario en un proyecto me gusta versionar contra en un servidor centralizado por dos motivos principales:

1. Mayor seguridad ante una eventualidad en mi equipo local, circunstancia que no evita que el proyecto deba estar respaldado por copias de seguridad.
2. Posibilidad de trabajar en múltiples dispositivos, una opción más o menos interesante en función de nuestras circunstancias.

En caso de que el proyecto que tengamos entre manos sea de ámbito personal, es más que razonable pensar que no todos disponemos de un servidor en casa dónce centralizar el versionado. Esta situación la podemos resolver con un viejo pc, o si no disponemos de uno con una Raspberry Pi que haga las veces de servidor. Aquí te dejo un enlace al artículo Instalar y configurar Git en una Raspberry PI con Ubuntu Mate, por si quieres probarlo.

Así que vamos al lío y para ello asumiremos que nuestro servidor está configurado con la ip 192.168.1.10 y el nombre de nuestro usuario es usuario.

Creamos nuestro repositorio remoto

Lo primero que debemos hacer es crear y configurar correctamente un repositorio vacío en la máquina remota, así que empezaremos por conectarnos a ella:

ssh usuario@192.168.1.10

Ya en la consola remota creamos el directorio dónde alojaremos el repositorio que vamos a crear, personalmente creo un directorio en el que incluyo todos los repositorios:

cd ~
mkdir gitRepositoryRoot
cd gitRepositoryRoot
mkdir nuevoProyecto
cd nuevoProyecto

Y por fin creamos nuestro repositorio vacío y lo configuramos:

git --bare init
git config core.sharedrepository 1
git config receive.denyNonFastforwards true
git config --bool core.bare true

El último paso en la máquina remota es asignar los permisos adecuados al repositorio:

find objects -type d -exec chmod 02770 {} \;

Creamos nuestro repositorio local

Una vez que nuestro repositorio está correctamente creado en el servidor deberemos crear un repositorio local a partir de los fuentes que ya tenemos para posteriormente enlazarlo y enviarlo al repositorio que previamente hemos creado en la máquina remota.

Creamos el repositorio local y añadimos los fuentes existentes que supondremos que se encuentran en /var/www/nuevoProyecto:

cd /var/www/nuevoProyecto
git init
git add *
git commit -m "Commit inicial"

Creamos el repositorio y añadimos los fuentes:

git remote add origin ssh://usuario@192.168.1.10/home/usuario/gitRepositoryRoot/nuevoProyecto
git push -u origin master

Comprobamos que todo ha salido bien

Por último comprobaremos que hemos realizado el proceso correctamente y todo funciona correctamente.

git checkout origin/master
git branch -f master origin/master
git checkout master

Conclusión

Trabajemos en grupo o en solitario versionar nuestro código en una máquina remota es una tarea sencilla que aporta grandes beneficios. Cómo siempre me gustaría saber cómo lo haces tú, qué haces distinto, si este artículo te ha ayudado… Si te animas a compartir deja un comentario.

Los ejemplos de este documento han sido probados tanto sobre Ubuntu Mate 16.0.4.2 y Apache 2.4.18 como sobre XUbuntu 18.04 con la versión 2.4.29 de Apache, aunque funcionarán sobre la mayoría de distribuciones Linux con la versión 2.4 de Apache.

Para el resto del artículo, asumiremos que la ip de la máquina dónde estamos configurando los host virtuales es 192.168.1.10.

¿Qué es un virtual host en Apache 2?

Virtual host es la herramienta que Apache pone a nuestra disposición para poder publicar más de una página web en un mismo servidor Apache, y que además,  nos permite mantener configuraciones diferentes para cada host virtual.

Al realizar una petición al servidor web, Apache puede identificar a que site (host virtual) queremos acceden en función de tres variables relacionadas con la solicitud realuzada al servidor:

1. La IP
2. El Host Name
3. El puerto

En este artículo distinguiremos los host virtuales por el puerto, pues es lo que utilizo habitualmente en mi entorno de desarrollo por una simple cuestión de comodidad.

Nociones de configuración

Toda la configuración de Apache 2 se encuentra bajo la carpeta /var/apache2. Los archivos de configuración para los virtual hosts se encuentran dentro de dos carpetas en particular:

1. /var/apache2/sites-available. En esta carpeta se encuentran todos los archivos de configuración de los hosts virtuales, cada host se corresponde con un archivo.
2. /var/apache2/sites-enabled. En esta carpeta se crearán enlaces simbólicos a los archivos de la carpeta sites-available para los host que queramos activar en cada momento.

Con la instalación de Apache, se creará por defecto, el archivo /etc/apache2/sites-available/000-default.conf y su correspondiente enlace simbólico en la carpeta sites-enabled que se encarga de configurar el host virtual por defecto al que accedemos tras instalar Apache.

Cómo crear un virtual host

Crear host virtuales es una tarea relativamente habitual, así que los señores desarrolladores de Apache nos lo han puesto bastante sencillo.

A continuación crearemos un host virtual para alojar un entorno de pruebas de este blog. Para entender mejor el proceso, a pesar de que es sencillo, lo dividiremos en cuatro pasos:

Paso 1: Creamos el directorio que alojará nuestra web

Lo primero será crear el directorio dónde alojaremos los archivos que posteriormente serviremos.

cd /var/www
sudo mkdir ahierro.es
cd ahierro.es
sudo mkdir public

La carpeta que serviremos será public, es buena idea guardarse un nivel de directorio para archivos relacionados con el proyecto que no deben ser accesibles desde una url en el navegador. Esto es bastante habitual en muchas aplicaciones y frameworks.

En este paso del proceso es importante dejar correctamente configurados los permisos de acceso a los archivos y carpetas de nuestro host virtual. Para ello os dejo un enlace al artículo Archivos y permisos de usuario en Apache 2 y Linux por si queréis echarle un vistazo.

Paso 2: Creamos el archivo de configuración del nuevo host virtual

Ahora crearemos el archivo de configuración en /etc/apache2/sites-available, lo más sencillo es hacerlo desde otro que ya exista. Es muy importante que lleve la extensión .conf o el comando a2ensite no funcionará más adelante:

cd /etc/apache2/sites-available
sudo cp 000-default.conf ahierro.es.conf

Lo editamos:

sudo vim ahierro.es.conf

Inicialmente tenemos algo así:

<VirtualHost *:80>
# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.example.com

ServerAdmin webmaster@localhost
DocumentRoot /var/www/html

# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf
</VirtualHost>

Y tras modificarlo debe quedar así:

<VirtualHost *:80>
# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.example.com

ServerAdmin webmaster@localhost
DocumentRoot /var/www/ahierro.es/public

# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf

<Directory /var/www/ahierro.es/public>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>

</VirtualHost>

Como podemos ver en la línea 1 hemos cambiado :80 por :8085, con lo que estamos indicando que a este virtualhost accederemos mediante este puerto. Personalmente suelo comenzar con el puerto 8080, en este ejemplo he especificado el 8085 porque ya tengo otros cinco host virtuales.

En la línea 12 lo único que hemos hecho es actualizar la referencia al directorio raíz para asegurarnos que apunta al lugar adecuado.

Y por último hemos añadido una nueva sección a partir de la línea 30 con unas directrices básicas entre las que hemos habilitado el módulo mod_rewrite, necesario para la re-escritura de urls.

Paso 3: Abrimos el puerto adecuado en Apache

Por defecto Apache solo atiende solicitudes por el puerto 80. Para conseguir que también atienda las que llegan por el puerto 8085, que es el que hemos indicado en nuestro fichero de configuración del virtual host, debemos editar el archivo /etc/apache2/ports.conf.

sudo vim /etc/apache2/ports.conf

El contenido del fichero es algo así:

# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default.conf

Listen 80
Listen 8085

<IfModule ssl_module>
Listen 443
</IfModule>

<IfModule mod_gnutls>
Listen 443
</IfModule>

Vemos que la  línea 5 hace referencia al puerto 80, nosotros hemos añadido una línea más, la 6, indicándole que escuche también el puerto 8085.

Paso 4: Habilitamos el nuevo virtualhost

Si os habéis fijado hablamos de los directorios sites-available y sites-enabled, pero solo hemos trabajado con el primero. Para crear el enlace simbólico lo haremos con el comando a2ensite:

sudo a2ensite ahierro.es.conf

Y por si te lo estás preguntando, si, un ln o un cp servirían de igual manera. Y ahora que el enlace simbólico ya se encuentra en el directorio sites-enabled solo nos queda reiniciar apache:

sudo service apache2 restart

Paso 5: Comprobamos que todo funcione correctamente

Podemos comprobar que todo ha salido bien con dos sencillos pasos

1. Creamos un archivo index.html y lo guardamos en el directorio público del host virtual que acabamos de crear, en este caso /var/www/ahierro.es/public.
2. Accedemos a la ip del servidor seguida de dos puntos y el puerto: http://192.168.1.10:8085/index.html.

Si vemos el contenido del archivo index.html es que todo ha salido bien, en caso contrario deberemos buscar el problema en función del mensaje de error obtenido.

Conclusión

Una forma sencilla de organizar nuestros proyectos siempre que no sean demasiados.

Personalmente, en el virtual host por defecto (puerto 80),  creo un sencillo fichero con enlaces a todos los hosts virtuales y otros accesos directos que me interesa tener a mano como pueden ser phpmyadmin o phpinfo. Esto suele ahorrarme unos minutos preciados minutos cada día.

Y como siempre me gustaría saber tú opinión,  ¿utilizas los virtual host? ¿los identificas por puerto? ¿organizas tus proyectos de otra forma? Deja un comentario y aprendamos juntos.

Créditos, referencias y artículos relacionados

• Archivos y permisos de usuario en Apache 2 y Linux
• Ejecutar Linux en Windows 10 con WSL
• Servidor Web en Raspberry PI y Ubuntu Mate
• Clonar una web en un servidor local

Por otro lado existen varias opciones para trabajar con un servidor Git, algunas de las mas famosas son a través de plataformas de terceros como Github o Gitlab.

Nosotros hoy instalaremos y configuraremos nuestro propio servidor Git en una Raspberry Pi corriendo Ubuntu Mate y alojada en una red local. Esta entrada pertenece a la serie Raspberry PI como herramienta de apoyo para el desarrollo web, que es muy probable que encuentres interesante si has llegado hasta aquí.

Instalar Git

Para instalar Git en Ubuntu la opción más sencilla es hacerlo desde los propios repositorios del sistema operativo:
[cc lang=»bash»]
sudo apt-get update
sudo apt-get install git
[/cc]

Podemos comprobar la versión que se instala mediante la orden git -version:
[cc lang=»bash»]
git –version
[/cc]

Si queremos utilizar el PPA oficial de Git para tener la versión más actualizada antes de instalar deberemos agregarlo a nuestro repositorio.

[cc lang=»bash»]
sudo add-apt-repository ppa:git-core/ppa
[/cc]

[the_ad id=»1018″]

Configurar Git

Y una vez instalado es necesario realizar una configuración inicial básica, en este caso configuraremos nuestra identidad:

[cc lang=»bash»]
git config –global user.name «ahierro.es»
git config –global user.email noexiste@ahierro.es
[/cc]

En cualquier momento podremos comprobar nuestra identidad con los siguientes comandos:

[cc lang=»bash»]
git config user.name
git config user.email
git config –list
[/cc]

Conceptos básicos sobre la configuración de Git

Git utiliza el comando git config para obtener y para definir las distintas opciones de configuración. Esta configuración se guarda en tres archivos diferentes en función de su ámbito, a los que podemos hacer referencia desde el comando mediante un parámetro:

Cada nivel sobrescribe el anterior. Podemos ver un ejemplo en la configuración que ya hemos realizado:

[cc lang=»bash»]
git config –global user.name «ahierro.es»
[/cc]

Ojo, es posible que en función de tú dispositivo y navegador el parámetro de ámbito parezca precedido de un guión «-» cuando en realidad son dos «–» pero la tipografía no muestra espacio entre ellos.

¿Y tú qué opinas?

Como siempre quiero leer qué opinas,qué configuración echas en falta, si utilizas Git, Subversión u otro software, qué haces distinto, etc. Si quieres compartir, deja un comentario con tus experiencias

Esta entrada forma parte de la serie Raspberry Pi como herramienta de apoyo al desarrollo web, y está pensada para un servidor de uso personal. De cualquier manera, el contenido de esta guía es perfectamente aplicable a cualquier distribución de Linux basada en Ubuntu y a Raspbian.

Esta documento también puede utilizarse para la configuración de un servidor de una pequeña organización, en cuyo caso sería necesario tener en cuenta algunas consideraciones:

1. Una Rasperri Pi no es el hardware más adecuado. Debería instalarse sobre un hardware fiable y acordemente dimensionado a las necesidades del uso que se le dará.
2. Además del contenido de este artículo, deberían realizarse una serie de configuraciones extra enfocadas en la seguridad que no entran en el ámbito ni el alcance de este documento.
3. Este artículo esta pensado para la instalación y configuración de un servidor web en una red local, en caso de que el servidor sea accesible directamente desde internet, el punto anterior cobra mayor importancia, además de requerir algunos ajustes más.

Una vez que todos tenemos claro el ámbito y el alcance, vamos al lío.

Instalamos Apache 2

Este paso será muy sencillo, actualizamos los repositorios e instalamos Apache 2:

sudo apt-get update
sudo apt-get install apache2

Si todo ha ido bien ya podremos acceder al al servidor web desde cualquier pc conectado a la red local con tan solo introducir la ip en el navegador.

Para el resto de la entrada asumiremos que nuestra Raspberry está configurada con la IP estática 192.168.1.10.

Así que si introducimos en el navegador la dirección http://192.168.1.10  veremos la página por defecto de Apache 2:

Un aspecto muy importante en la configuración de Apache es asignar los permisos adecuados a la carpeta del servidor. Podemos pasar sin hacerlo pero más pronto que tarde nos encontraremos con problemas relacionados con permisos.

Comenzaremos asegurándonos de que /var/www/html pertenezca al grupo www-data y que tiene los permisos adecuados:

sudo chgrp www-data /var/www/html
sudo chmod 775 /var/www/html
sudo chmod g+s /var/www/html

Agregamos nuestro usuario al grupo www-data:

sudo usermod -a -G www-data usuario

Y por último nos aseguramos de ser los propietarios del directorio

sudo chown usuario /var/www/html

Con esto hemos concluido la instalación de Apache.

Instalamos PHP

Instalamos PHP:

sudo apt-get install php7.0

Es posible que en función de la distribución que utilicemos en lugar del paquete php7.0 encontremos otra versión. Podemos comprobarlo fácilmente con la siguiente orden:

sudo apt-cache search php

Y si por cualquier motivo necesitamos una versión específica de php, deberemos incluir el repositorio ondrej/php como hacemos a continuación:

sudo add-apt-repository -y ppa:ondrej/php
sudo apt-get update

En este caso he incluido la opción -y porque al intentar agregar el repositorio me mostraba un warning relacionado con la codificación de caracteres de los repositorios.

Acto seguido instalar la versión de php que necesitemos, en mi caso voy a instalar la versión 7.3:

sudo apt-get install php7.3

Tras reiniciar Apache ya habremos acabado:

sudo service apache2 restart

Para comprobar que php está correctamente instalado crearemos el archivo  /var/www/html/phpinfo.php con el siguiente contenido:

<?php php phpinfo(); ?>

Si todo es correcto al acceder a http://192.168.1.10/phpinfo.php veremos algo así:

Instalamos y configuramos MariaDB

Una vez que php está instalado, continuamos con la base de datos:

sudo apt-get install mariadb-server

Durante el proceso de instalación deberemos responder responder a algunas preguntas que sin complicación alguna.

El primer paso tras la instalación será configurar MariaDB para que podamos acceder remotamente, pues por defecto solo acepta conexiones desde el propio host:

sudo vim /etc/mysql/mariadb.conf.d/50-server.cnf

Esfe archivo puede cambiar en función de tu distribución y de la versión de MariaDB. En ocasiones puedes encontrarlo en /etc/mysql/my.cnf, en /etc/mysql/mysql.conf.d/mysqld.cnf, etc.

Localizamos la siguiente línea:

bind-address  = 127.0.0.1

La sustituimos por:

bind-address  = 0.0.0.0

Y reiniciamos la base de datos:

sudo service mysql restart

Con esto hemos habilitado el acceso remoto a MariaDB. Ahora crearemos un nuevo usuario para evitar trabajar con root. Para ello accedemos a la consola de MariaDB:

sudo mysql -u root -p

Una vez en la consola de MariaDB creamos nuestro usuario:

CREATE USER 'usuario' IDENTIFIED BY 'contraseña';

Y concedemos acceso remoto y a todas las bases de datos al usuario que acabamos de crear:

GRANT USAGE ON *.* TO 'usuario'@'%' IDENTIFIED BY 'contraseña';

En este punto es buena idea comprobar que todo ha salido bien. Podemos hacerlo abriendo una conexión al servidor de bases desde nuestro equipo de trabajo con alguna herramienta como MySQL Workbench.

Instalamos phpMyAdmin

Esta es una herramienta que siempre me gusta instalar a pesar de que en la mayoría de situaciones trabajo con MySql Workbenck. Para instalar basta con:

sudo apt-get install phpmyadmin

Y una vez instalado podremos acceder a ella mediante http://192.168.1.10/phpmyadmin.

Conclusión

Ya tenemos un servidor web completamente funcional corriendo sobre nuestra Rasperri PI, sencillo, económico y funcional. Ahora solo hay que usarlo.

¿Y tú?, ¿Crees que necesitamos aplicar alguna otra configuración? ¿Haces algo distinto? ¿Echas en falta algún paso? o simplemente ¿te ha servido de ayuda? Comparte tu experiencia y aprendamos todos.