Solucionar errores de renovación de certificados Let’s Encrypt en Virtualmin

Para los que administramos nuestros servidores con Virtualmin y probamos desde que apareció la gestión de certificados SSL con Let’s Encrypt, la renovación de los mismos probablemente nos esté dando varios quebraderos de cabeza. Dos de los errores más comunes son:

  • Permission Denied al ejecutar mkdir
  • Invalid response from http://www.example.com/.well-known/acme-challenge/…

La solución de ambos problemas es sencilla. En caso del Permission Denied, se produce porque la primera implementación de Let’s Encrypt en Virtualmin usaba el usuario root para crear la carpeta .well-known y sus contenidos mientras que ahora, como debería ser, utiliza el usuario ‘propietario’ del dominio. Para solucionarlo, desde el File Manager en el panel o a través de SSH, eliminamos la carpeta y cuando ejecutemos la renovación la vuelve a crear con los permisos correctos.

El error de Invalid response, se produce porque no puede acceder desde afuera a la dirección indicada. Se suele producir por varias razones, un .htaccess o web.config muy restrictivos, una política de redirección en Nginx o que se esté forzando la conexión https para todas las conexiones a través de la configuración del servidor. Se puede solucionar agregando una excepción para la carpeta .well-know o, desactivando temporalmente, las políticas que puedan estar evitando el acceso en la configuración de nuestro servidor web.

Mapear una conexión SFTP a una unidad en Windows

El acceso mediante SSH al servidor es más seguro, rápido y potente. Nos permite trabajar  como si estuviéramos delante del equipo. SFTP no es más que SSH FTP, es decir, permite trabajar con la conexión SSH como si fuera FTP con la ventaja de la encriptación y la transferencia binaria.

Todo sería color de rosa si no fuera porque los clientes de Windows que permiten la conexión mediante SFTP (WinSCP, PSFTP y Filezilla) no son muy dados a compartirla con otros programas como nuestro editor favorito o el Explorador de Archivos.

Unidad SFTPEl mapeo de la conexión SFTP como unidad nos permite solucionar esto para la mayoría de los programas.

 

En la práctica queda funcionando como cualquier otra unidad de disco aunque un poco más lenta para leer.

How To

Para poder hacerlo vamos a necesitar dos programas:

  • Dokany, librería que simplifica la adaptación de nuevos sistemas de ficheros a Windows. En vez de tener que desarrollar un driver para Windows podemos solucionarlo mediante una API o una DLL.
    URI: https://github.com/dokan-dev/dokany
  • WinSshFS 4every1 edition, el programa que sen encarga de gestionar nuestras conexiones SFTP y pasarle la información a Dokany para que Windows la muestre de forma amigable.
    URI: https://github.com/dimov-cz/win-sshfs

Es importante tener en cuenta que la última versión de WinSshFS fue desarrollada para la versión 0.7.4 de Dokany y no soporta ni funciona con las más nuevas. Además, Dokany 0.7.4, nos requiere tener instalado el Microsoft Visual C++ 2013 Redistributable.

Las instalaciones son sencillas y no requieren más que darle para adelante (Dokany) o extraer algunos archivos (WinSshFS).

WinSshFSUna vez intalado todo, nos dirigimos a la carpeta donde hayamos descomprimido el WinSshFS y arrancamos el programa.

La interfaz es sencilla y bastante intuitiva. Ponemos los datos de la conexión, seleccionamos la letra de unidad donde queremos montar, damos en ‘Mount’ y deberíamos ver aparecer en nuestro sistema la nueva unidad con nuestros archivos.

Actualización 1: Dokany para ofrecerte la descarga del redistributable aunque lo tengas instalado.

 

Actualización 2: Otros dos proyectos interesantes con Dokany mssqlfs y torrent-mount

Usar repositorios Git como paquetes de Composer

No todos los proyectos de GitHub están registrados en packagist.com o tienen creado un “composer.json” que nos permita agregarlo de forma sencilla en nuestro proyecto. Por suerte, composer nos permite salvar esta situación cargando los datos del repositorio directamente en nuestro archivo de dependencias.

Para hacerlo debemos cargar la información del proyecto en el array “repositories”, especificando dónde están los fuentes, el nombre, la versión, étc.

{
  "repositories": [
    {
      "type": "package",
      "package": {
        "name": "fullcalendar/fullcalendar",
        "version": "2.5.0",
        "dist": {
          "url": "https://github.com/fullcalendar/fullcalendar/archive/v2.5.0.zip",
          "type": "zip"
        },
        "source": {
          "url": "https://github.com/fullcalendar/fullcalendar.git",
          "type": "git",
          "reference": "tags/v2.5.0"
        },
        "require": {
          "components/jquery": ">=1.7.1",
          "moment/moment": ">=2.5.0"
        }
      }
    },
  ]

Como vemos, en última instancia, lo que hacemos es indicar manualmente toda la información que debiera tener el proyecto si estuviera cargado en el repositorio de packagist.com. Una vez hecho esto podemos usar el paquete como cualquier otro dentro de este proyecto con el nombre indicado en la propiedad “name”.

Por ejemplo, el archivo “composer.json” de un proyecto donde incluyamos la librería Fullcalendar Scheduler, que depende de esta, quedaría así:

{
  "name": "rvaccaro/agenda",
  "authors": [
    {
      "name": "Roberto Vaccaro",
      "email": "xxxx@xxxx.com"
    }
  ],
  "repositories": [
    {
      "type": "package",
      "package": {
        "name": "fullcalendar/fullcalendar",
        "version": "2.5.0",
        "dist": {
          "url": "https://github.com/fullcalendar/fullcalendar/archive/v2.5.0.zip",
          "type": "zip"
        },
        "source": {
          "url": "https://github.com/fullcalendar/fullcalendar.git",
          "type": "git",
          "reference": "tags/v2.5.0"
        },
        "require": {
          "components/jquery": ">=1.7.1",
          "moment/moment": ">=2.5.0"
        }
      }
    },
    {
      "type": "package",
      "package": {
        "name": "fullcalendar/scheduler",
        "version": "1.1.0",
        "dist": {
          "url": "https://github.com/fullcalendar/fullcalendar-scheduler/archive/v1.1.0.zip",
          "type": "zip"
        },
        "source": {
          "url": "https://github.com/fullcalendar/fullcalendar-scheduler.git",
          "type": "git",
          "reference": "tags/v1.1.0"
        },
        "require": {
          "components/jquery": ">=1.8.0",
          "moment/moment": ">=2.5.0",
          "fullcalendar/fullcalendar": ">=2.5.0"
        }
      }
    }
  ],
  "require": {
    "fullcalendar/scheduler": "1.1.*",
  }
}

Usar Git+PuTTY para conectarse a repositorios en Windows

Instalar GIT para Windows – Descarga
Instalar PuTTY – Descarga 

Utilizar PuTTYgen para crear un par de claves
Abrir PuTTYgen, cambiar la cantidad de bits y el tipo de clave si hiciera falta. Hacer click en “Generate”. Mover el mouse en el cuadrado vacio hasta que la barra de progreso se llene. Una vez que esté generada la clave se habilitan los botones “Save public key” y “Save private key” que nos permiten guardar, respectivamente, la clave pública y la privada. El nombre se puede elegir libremente, conviene utilizar el mismo. La clave pública no tiene extensión predeterminada pero es práctico utilizar txt para acceder más rápidamente.

Agregar la clave privada a Pageant

Agregar la clave pública al servidor GIT

Indicar que PuTTY es tu almacén de claves SSH
…asignando la variable de sistema o usuario GIT_SSH al ruta de “plink.exe”, ubicado en la misma carpeta de PuTTY. En Windows 7, entrar al Panel de Control, Sistema, Configuración avanzada del sistema, Variables de Entorno, en Variables de usuario o del sistema hacer click en Nueva. Usar como nombre GIT_SSH y como valor la ruta completa a plink, por ejemplo: “C:\Program Files (x86)\PuTTY\plink.exe”