/ prog

BPS

sehhh, BPS! (Battle Programmer Shirase) ese anime que no nos hace sentir mejor persona y gira en torno a las prodigiosas habilidades del buen Akira Shirase (programador/sysadmin/cracker/animal-o-cosa y mejor persona) y sus situaciones comprometidas medio ecchi (con chicas de edad “no especificada”) que situan en un dilema moral a aquellos que le solicitan algun favor

Por supuesto que Akira nunca tiene que consultar documentacion, copiar y pegar errores en el navegador y los unicos fallos que se atreven a presentarsele, son desde luego, los que el mismo provoca. Para el resto de desgraciados que inmerecidamente habitamos la misma dimension, solo nos queda revolcarnos en la podredumbre y anotar “recetas” nada elegantes, concretas, ni profundas sobre configuraciones que apenas se entienden y desde luego, no nos haran ser “programadores”, “expertos” o populares. Ha, Ha, Ha, Ha

y? nahh, habia estado revisando algunos vps(s)… unas maquinas (virtuales) que rentas con una cantidad pactada de cpu, disco, ram e internete que no deberia de apagarse a ninguna hora y en la que puedes poner tus mierdas, en particular un servidor web gestionado “a mano”. Esto por supuesto, (paleando las limitaciones de almacenamiento casi igual de costoso que la tinta de impresora) sera tan bueno y satisfactorio como los tutoriales copy-paste de internet (y un monton de nesedad) te permitan realizar

mientras hacia dichas pruebas “gratuitas” que forzosamente necesitaron varias busquedas por “el mejor” tutorial para “XXXXXX” version “YYYYYY”, se acumularon una cantidad considerable de enlaces asi como ficheros de configuracion que para la siguiente “reinstalacion” seguramente no recuerde. Por ello mejor dejarlo medio organizado para el yo del futuro.

debo aclarar que es solo un primer intento al que se combino (por mi constante insatisfaccion) el proyecto de tener un servidor en casa autogestionado (torrente 247, ftp, stream de videos/musica, etc, etc). Asi que el resultado es medio uno y medio otro, pero (imaginariamente) centrado en poner en funcionamiento el servidor en casa.

Je, eso de rentar un vps con internete a velocidad de primer mundo mola un guevo, aunque si quieres hacerte de unos buenos TeraBytes de almacenamiento deberias ir buscando una buena hipoteca… si es que tienes casa… ignorando ese aspecto, el precio por lo que ofertan es razonable, aunque la tranquilidad y “el placer” de tener tu propia infraestructura, viendole parpadear los leds directamente es mucho mayor, supongo.

mientras me hago con una rapsberry/micro-server/nuc/mini-itx-de-bajo-consumo-24x7x∞ tocara conservar (y pagar dentro de un par de meses) el vps. Temporalmente hice las pruebas en una media-laptop con 12 años de antiguedad, 512MB de ram, 40GB HDD con debian estable 9.5 sin entorno grafico. Al final consume ~30MiB de ram y casi sin movimiento del procesador y, es necesario remarcar que su procesador mono nucleo va mas fluido que el procesador virtual del vps. Tambien, el contar con el equipo en la red local hace que la conexion via ssh no tenga nada de retraso.

al lio, pues!

Red

el hardware en cuestion trae un adaptador wifi (intel) que funciona sin instalar drivers privativos. No me gusta conectar el cable de red, por que creo que inesperadamente algun relampago podria cegar la vida del aparato. Asi pues, mientras menos cables (un ups, interruptores magneticos y un multicontacto de interruptor con “luz roja”) de por medio, mayor tranquilidad mental

si bien antes habia visto eso de configurar la red con ip fija, nunca lo habia llebado a cabo, encima varios comandos se han vuelto obsoletos y systemd extiende sus tentaculos por todos los sitios.

Haciendo caso a la wiki de debian lo primero seria colocar los permisos apropiados al fichero de configuracion de las interfaces de red

> chmod 0600 /etc/network/interfaces

despues, como en mi caso con un wifi cifrado con WPA2 tendriamos que obtener unos digitos hexadeci-magicos, con el comando

> wpa_passphrase ssid contraseña
network={
        ssid="ssid"
        #psk="contraseña"
        psk=ccb290fd4fe6b22935cbae31449e050edd02ad44627b16ce0151668f5f53c01b
}

ssid = nombre de wifi. El campo psk tendria despues que agregarse dentro de la configuracion (/etc/network/interfaces). Para evitar erorres, mejor redireccionar la salida a dicho fichero. Ya dentro de este, se podra editar con mayor comodidad

> wpa_passphrase mi-ssid mi-contraseña >> /etc/network/interfaces
> emacs /etc/network/interfaces

y bueno… en este punto el tutorial copy-pasteable suguiere configurar la red con conexion automatica, nos dejan este ejemplo:

auto wlan0
iface wlan0 inet dhcp
        wpa-ssid mi-ssid
        wpa-psk ccb290fd4fe6b2293cbae351449e050edd2ad044627b16ce1510a48bb7c7c01b

donde deberiamos substituir wlan0 por el nombre de nuestra interfaz de red wifi, que podemos obtener con el comando

> ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp6s7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 00:0a:e4:f6:20:5b brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.177/24 brd 192.168.1.255 scope global enp6s7
       valid_lft forever preferred_lft forever
    inet6 fe80::20a:e4ff:fef6:205b/64 scope link
       valid_lft forever preferred_lft forever
3: wlp6s5: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:16:ce:63:f0:e2 brd ff:ff:ff:ff:ff:ff

mmm, no se que sea lo, pero enp* (enp6s7) seria la interfaz “por cable”. wlp* (wlp6s5) la interfaz inalambrica. Asi que substuimos wlan0 por wlp6s5.

y para arrancar la red, bastaria con:

> ifup mi-interfaz-inalambrica

(puede que si tenemos otra red ya habilitada, sea necesario antes hacer ifdown mi-interfaz-habilitada)

… luego intente con la configuracion estatica agregando/mezclando algunos campos, tal que asi:

auto wlp6s5
iface wlp6s5 inet static
        address 192.168.1.66
        netmask 255.255.255.0
        wireless-channel 1
        wireless-mode ad-hoc
        wpa-ssid mi-ssid
        wpa-psk ccb290fd4fe6b22935cbae31449e050edd02ad44627b16ce0151668f5f53c01b

se suponia que address seria la ip estatica, pero esta configuracion no me daba internet, aunque si permitia conectar en la red local.

Ante el fracazo de lograr la ip estatica por wifi, ademas de escuchar que el tio de un conocido que salia con la prima de una prima de un amigo sobre que en los servidores web no se permite la conexion por wifi, conecte el cable y por suerte, esta ocacion la configuracion si fue satisfactoria, quedando tal que asi:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

allow-hotplug enp6s5
iface enp6s5 inet static
      address 192.168.1.177
      netmask 255.255.255.0
      gateway 192.168.1.254

# auto wlp6s5
# iface wlp6s5 inet dhcp
#       wpa-ssid mi-ssid
#       wpa-psk ccb290fd4fe6b2293cbae351449e050edd2ad044627b16ce1510a48bb7c7c01b

se comento la parte referente al wifi, por lo demas enp6s5 es la interfaz cableada

gateway es la “direccion” del router/modem (la caja del internet). Para haberiguar esta direccion ejecutamos

> ip r
default via 192.168.1.254 dev enp6s5 onlink
169.254.0.0/16 dev enp6s5 scope link metric 1000
192.168.1.0/24 dev enp6s5 proto kernel scope link src 192.168.1.177

(la “puerta de enlace” (o gateway) esta despues de default via, en este caso 192.168.1.254)

address (supongo) tendria que iniciar con los primeros tres rangos del gateway y terminar con el numero que queremos para la ip fija, en mi caso 177 por-que-si

netmask es un numero que nos permite enmascarar que consultas son filtradas hacia “algun sitio” (o algo asi). Segun varios post del internete, el numero magico es 255.255.255.0

SSH

con la ip fija, el siguiente paso logico por comodidad como tambien para economizar en monitores, vendria a ser conectar via ssh. Primero instalamos el servidor ssh en nuestro server-de-pruebas

> apt install openssh-server

esto deberia poner operativo el servidor, podriamos corroborarlo con

> systemctl status sshd
● sshd.service - OpenSSH server daemon
...
   Active: active (running) since Mon 20XX-YY-YY
...

apareceria el en color verde al igual que active (running), si no fuera asi quiza

> systemctl enable sshd
> systemctl start  sshd

desde ahora continuaremos toda la interaccion desde la maquina donde vamos a conectar hacia el servidor

> ssh nasciiboy@192.168.1.177

cambiar nasciiboy por el usuario de vuestra maquina, colocar la @ y luego la ip. En caso de tener un puerto distinto al establecido por defecto (22), agregar -p numero-puerto

ahora bien, para hacer mas seguro (y comodo) conectar con el servidor, deberiamos configurar un par de llaves desde la maquina donde conectaremos

> ssh-keygen
> cd ~/.ssh

luego copiamos la llave publica al servidor. A mano seria asi:

> scp id_rsa.pub nasciiboy@192.168.1.67:.ssh/authorized_keys

o, “sin saber ni como”, con el comando dedicado ssh-copy-id:

> ssh-copy-id nasciiboy@192.168.1.67

finalmente deberiamos configurar el demonio (sshd) para que no permita la conexion por contraseña, solo mediante llaves. Modificamos dentro de /etc/ssh/sshd_config

PubkeyAuthentication yes
...
PermitEmptyPasswords no
...
PasswordAuthentication no

tambien podriamos modificar el parametro

PermitRootLogin yes

cambiando yes a no, p-e-r-o, creo que la conexion por llave es suficientemente segura y si la contraseña de root es demaciado compleja como para ni saberla o se tiene paranoia de escribirla, dejar esta opcion encendida igual y no es mala idea

recargamos la configuracion del daemon ssh

> systemctl reload sshd

probamos que la sesion ssh mediante llaves funcione e instalamos/configuramos las comodidades que creamos convenientes (htop, dfc, emacs, etc, etc)

nginx

basicamente

> apt install nginx

luego desde nuestra red local podriamos confirmar si esta arriba el servidor web

> elinks 192.168.1.177

por el momento, un servidor sin comentarios, php, javascript, ni ninguna mierda mas, es todo lo que necesito. Como mi web se genera estaticamente, podria copiarse directamente todo el contenido dentro de /var/www/http

> rsync -avz --delete ~/nasciiboy.land/public/ /var/www/html/

he copiado el directorio que contiene mi web dentro de la home de root. Desde hay genero el sitio estatico con hugo que a su vez crea el directorio public el cual finalmente se sincroniza con el directorio por defecto del contenido del servidor /var/www/html

importante si acaso al visitar el sitio reciben como bienvenida 403 Forbiden, seguramente el sitio no tenga los permisos de lectura apropiados. La solucion

> chmod -R 755 /var/www/html

en este punto bien podemos configurar (solo) un poco el servidor

Dentro de /etc/nginx/nginx.conf (dentro del bloque de configuracion http { ... }) creo que es buena idea no mostrarle la version particular que se esta ejecutando a los malintencionados. Basta colocar:

...
server_tokens off;
...

(los punto y coma son importantes, tenerlos en mente)

nginx tiene unos logs (/var/log/nginx) donde pone cosas como las ips de quien accede a nuestro flamante sitio. Estos ficheros se reescribiran si hacemos cosas como apagar-encerder el servidor. Para mantener estas preciadas metricas, lo mas sensato es hacer un

> systemctl reload nginx

y ver si todo fue bien con

> systemctl status nginx

pero… nada es tan sencillo. El servidor no volvia a encender, segun stackoverflow nginx tenia un bug en debian (se ve al consultar con systemctl status nginx)

...
nginx.service: Failed to read PID from file /run/nginx.pid: Invalid argument
...

la solucion

> mkdir /etc/systemd/system/nginx.service.d
> printf "[Service]\nExecStartPost=/bin/sleep 0.1\n" > /etc/systemd/system/nginx.service.d/override.conf
> systemctl daemon-reload
> systemctl restart nginx

mmm, por unos dias dude sobre la forma correcta de actualizar el contenido en /var/www/html, si habia que parar y encender el servidor o si hacer un reload. Segun parece no es necesario…

Aun no se muy bien como es esto de ver “las metricas” del servidor. Modificando un one-liner visto en el blog de davidochobits que a su vez lo vio en reddit, lanzo el siguiente comando

> cat /var/log/nginx/access.log | awk '{ print $1 }' | sort | uniq -c | sort -n | tail | perl -lane 'print $F[1], "\t", $F[0], "\t", "▄" x ($F[0] / 10)'
66.249.79.87    15  ▄
181.95.155.18   16  ▄
66.249.79.254   18  ▄
17.58.97.53     21  ▄▄
40.77.167.24    21  ▄▄
66.249.79.252   23  ▄▄
179.6.202.53    24  ▄▄
18.234.114.96   60  ▄▄▄▄▄▄
150.109.59.181  139 ▄▄▄▄▄▄▄▄▄▄▄▄▄
90.162.220.89   163 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

ja, ja, que rastrero, y para contabilizar las visitas totales pues se filtra (sin tail) y suma la segunda columna con awk

> cat /var/log/nginx/access.log | awk '{ print $1 }' | sort | uniq -c | sort -n | perl -lane 'print $F[1], "\t", $F[0], "\t", "▄" x ($F[0] / 10)' | awk '{ tot+=$2 }; END { print "TOTAL " tot }'
TOTAL 625

si quisieramos ver a quien pertenece una ip (o dominio):

> whois 90.162.220.89
...
role:           Hostmaster Administrator FTE
address:        Parque Empresarial La Finca
address:        Edificio 9
address:        Paseo del Club Deportivo, 1
address:        28223 Pozuelo de Alarcon
address:        Madrid, Spain
admin-c:        HA1066-RIPE
admin-c:        HA1067-RIPE
tech-c:         HA1066-RIPE
tech-c:         HA1067-RIPE
nic-hdl:        HAF10-RIPE
remarks:        spam, abuse reports....mailto:abuse@orange.es
abuse-mailbox:  abuse@orange.es
mnt-by:         UNI2-MNT
created:        2005-08-19T10:24:55Z
last-modified:  2013-01-17T16:47:17Z
source:         RIPE # Filtered
...

entre estos, Tencent, Baidu y Google se concentran casi todas las consultas…

router

en este punto (o quiza antes (o despues…)) nos vendria bien conocer algunas cosas medianamente importantes, como cual es nuestra ip publica y que dispositivos hay en nuestra red local (como en caso de hacer un ssh a un dispositivo sin ip fija). Para lo segundo segun un post y corroborado en el mundo real, podemos conocer los dispositivos en la red local con

> nmap -sP 192.168.1.1-255
Starting Nmap 7.60 ( https://nmap.org ) at 2018-09-09 22:09 CDT
Nmap scan report for 192.168.1.66                            # movil
Host is up (0.21s latency).
Nmap scan report for nasciiboy.myddns.rocks (192.168.1.177)  # server (luego explico mas)
Host is up (0.00050s latency).
Nmap scan report for 192.168.1.214                           # mi pc
Host is up (0.00043s latency).
Nmap scan report for 192.168.1.253                           # un "repetidor"
Host is up (0.00093s latency).
Nmap scan report for rga.ip (192.168.1.254)                  # router
Host is up (0.0022s latency).
Nmap done: 255 IP addresses (5 hosts up) scanned in 14.53 seconds

o tambien dentro del router Estado > Lista de dispositivos LAN

luego, para conocer nuestra ip publica, el modelo de router que me da la compañia lo proporciona dentro de Estado > PPPoE

otras eficaces formas de conococer la ip publica sin movernos del terminal

> curl ifconfig.co # mas rapido que la opcion '.me'
187.225.125.52
> curl ifconfig.me
187.225.125.52

recordar que esta ip (amenos que tengamos un acuerdo con el proveedor) puede cambiar entre un apagon a otro. Mientras tanto pasemos a abrir los puertos de nuestro router

vamos a NAT > Mapeo de puertos, luego Agregar, Servidor web. En IP LAN ponemos la direccion fija de nuestro servidor apuntando al puerto 80, abriendo tambien el puerto 80 en la ip publica. Repetimos el proceso para el puerto 443 (https)

ddns

tenemos encendido el servidor, abiertos los puertos y podemos hacer una “consulta local”

> elinks 192.168.1.177

pero? podemos contactar con nuestra ip publica, darsela a nuestros amigos y ser populares?

> elinks 187.225.125.52

NO y ni en firefox funciona! Segun parece, algun “mecanismo de conexion de no se que, que es muy complicado” impide contactar desde nuestra red local consultando nuestra ip publica. Por que? ni idea, una consulta decia que era muuuhhh complicado y le creere

ja, ja, sucede que anteriormente probe esto de consultar desde la red local la ip publica… y al no tener resultado, considere que era un puto truño! Haaa, por que nadie lo explico?

con aquello de las pruebas que estoi haciendo con el vps rentado, conencte a el (en Frankfurt) via ssh y desde aya el elinks aputando a mi ip publica funcionaba a la perfeccion!

la solucion? ni idea, monta tus mierdas y prueba desde fuera como puedas

y bueno, como mencionaba previamente, si tenemos un contrato estandar con el proveedor de internet, la ip publica puede que cambie. Como es mas confortable pasar un dominio que una ip, la idea es recurrir a un servicio de terceros para que le siga la pista a los cambios en nuestra ip y de preferencia nos de un dominio no-muy-feo

entre las (dos) opciones que busque estaban no-ip y dynu. No recuerdo la causa, pero preferi dynu.

Hay que crearse una cuenta y te dan a elegir entre varios dominios (o colocar el tuyo, pero aun no es momento para ello), el que escogi fue nasciiboy.myddns.rocks (casi, nunca en linea)

tras el registro y demas, deberiamos tener un metodo para desde nuestro servidor reportar periodicamente nuestra ip (por ejemplo, cada minuto) y con ello actualizar la informacion en dynu y de ser posible automaticamente.

ellos tienen un programa para descargar en debian… je, je, si, ahorita me lo instalo, como no. Para los desconfiados ofrecen una serie de opciones de configuracion diversas, en mi caso con ddclient que ya viene en los repositorios

> apt install ddclient

en el proceso de instalacion, saltara una TUI para configurar la direccion a donde llamar, la contraseña, cuenta, etc. Pero esto no funciona del todo bien. Lo recomendable es siguiendo el tutorial de la propia dynu, modificar el fichero /etc/ddclient.conf de la siguiente manera

# ddclient configuration for Dynu
#
# /etc/ddclient.conf
daemon=60                                                    # Check every 60 seconds.
syslog=yes                                                   # Log update msgs to syslog.
mail=root                                                    # Mail all msgs to root.
mail-failure=root                                            # Mail failed update msgs to root.
pid=/var/run/ddclient.pid                                    # Record PID in file.
use=web, web=checkip.dynu.com/, web-skip='IP Address'        # Get ip from server.
server=api.dynu.com                                          # IP update server.
protocol=dyndns2
login=myusername                                             # Your username.
password=YOURPASSWORD                                        # Password or MD5/SHA256 of password.
MYDOMAIN.DYNU.COM                                            # List one or more hostnames one on each line.

es muy importante colocar la linea de pid, de lo contrario el programita este, hara consultas a lo bestia. Por lo demas solo cambiar login, password y MYDOMAIN.DYNU.COM

ahora si, podemos contactar desde fuera de casa con el “dominio provicional”, o, en busca de algun falso sentimento de tranquilidad agregar nuestro dominio a los hosts locales /etc/hosts

192.168.1.177 nasciiboy.myddns.rocks
127.0.0.1     localhost localhost.localdomain localhost4 localhost4.localdomain4
::1           localhost localhost.localdomain localhost6 localhost6.localdomain6

con esto escribiendo nasciiboy.myddns.rocks en firefox accederiamos al sitio local con el “dominio”. No se por que, pero con elinks esto no funciona

cosas

entre varias consultas y post ajenos que me da peresa enlazar, hay varios comandos interesantes para conocer “¡¿que?!” sobre ips, dns y puertos

(aqui una combinacion de salidas mezcladas de mi sitio en el vps y de las pruebas con el servidor local)

listar puertos abiertos TCP y UDP

> netstat -lntu
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:9418            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN
tcp6       0      0 :::9418                 :::*                    LISTEN
tcp6       0      0 :::80                   :::*                    LISTEN
tcp6       0      0 :::22                   :::*                    LISTEN

(listar todos los puertos en escucha, con netstat -l)

con dig podemos ver la configuracion del dns y tambien conocer la ip

> dig nasciiboy.land

; <<>> DiG 9.10.3-P4-Debian <<>> nasciiboy.land
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56488
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nasciiboy.land.			IN	A

;; ANSWER SECTION:
nasciiboy.land.		600	IN	A	46.101.138.205

;; Query time: 27 msec
;; SERVER: 67.207.67.2#53(67.207.67.2)
;; WHEN: Mon Sep 10 03:24:43 UTC 2018
;; MSG SIZE  rcvd: 59

nslookup para conocer la ip del servidor (aqui una prueba desde la red local)

> nslookup nasciiboy.myddns.rocks
Server:		192.168.1.254
Address:	192.168.1.254#53

Non-authoritative answer:
Name:	nasciiboy.myddns.rocks
Address: 187.225.125.52

siguiedo un post “para ser hacker” la receta para escanear todos los puertos

consultando (desde frankfurt) mi ip hogareña

> nmap -sS 187.225.125.52
Starting Nmap 7.40 ( https://nmap.org ) at 2018-09-10 14:01 UTC
Nmap scan report for dsl-187-225-125-52-dyn.prod-infinitum.com.mx (187.225.125.52)
Host is up (0.25s latency).
Not shown: 998 filtered ports
PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 45.50 seconds

solo estan abiertos los puertos del servidor. Tenia dudas sobre la seguridad de poner este tipo de servicio en digamos “la maquina de uso principal”, desde luego ignorando posibles inconvenientes como que tu equipo se quede congelado por algun programa, probar un codigo de recursividad desatada o si se queda sin ram/swap. Luego de todas estas pruebas, no parece algo especialmente inseguro. Por supuesto, si alguien te quiere joder, allara la forma, mientras ese dia llega, supondre que todo funciona como es debido y con la suficiente seguridad por-defecto.

otro comando mas nos permite ver los saltos entre los routers hasta el destino

> mtr nasciiboy.myddns.rocks

asta aqui los pasos con respecto al servidar local. Cuando adquiera la plaquita ideal con un chilion de ram, teras y nucleos ya colocare una guia mas rigurosa

https

CA error

cuando estaba alojada la pagina en github-pages ellos se encargaban de proporcionar el https. Al mover el dns al vps intente mediante los comandos que varios post muestran instalar let’s encrypt, entre uno de ellos, sugieren lo siguiente:

> apt install python-certbot-nginx

luego configurar /etc/nginx/sites-available/default cambiando

. . .
server_name _;
. . .

a

. . .
server_name mi-dominio www.mi-dominio;
. . .

luego, lanzar los siguientes comandos

> nginx -t
> systemctl reload nginx
> certbot --nginx -d mi-sitio.com -d www.mi-sitio.com

# en este punto se supone ya esta listo el certificado
# y esto es para actualizarlo automaticamente
> certbot renew --dry-run

pero ejecutar certbot no sirvio de mucho

Obtaining a new certificate
Performing the following challenges:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.

si ese es el caso, seguramente certbot habra dejado algunos inutiles timers y demonios de systemd. Para deshabilitar tales regalos, le avente lo siguiente al terminal (aunque no se si sea lo correcto)

> systemctl stop    certbot.timer
> systemctl stop    certbot
> systemctl disable certbot.timer
> systemctl disable certbot

auto-certificado

ante el fallo de certbot, mi primera opcion para no dejar que los buscadores ignoraran la opcion con https, fue crear mis propios certificados con casinos y colegilas

> mkdir /etc/nginx/ssl
> openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/ssl/nginx.key -out /etc/nginx/ssl/nginx.crt

a las preguntas que se sucedian respondi en el nombre de la organizacion como nascii-corp, para el correo mi correo regular (como seña de buena voluntad). El resto lo deje en blanco.

tras esto deberiamos modificar la configuracion de nginx (/etc/nginx/sites-available/default) para que escuche en el puerto 443. Coloco mi fichero entero:

server {
        listen 80 default_server;
        listen [::]:80 default_server;

        listen 443 ssl;

        # SSL configuration
        #
        # listen 443 ssl default_server;
        # listen [::]:443 ssl default_server;
        #
        # Note: You should disable gzip for SSL traffic.
        # See: https://bugs.debian.org/773332
        #
        # Read up on ssl_ciphers to ensure a secure configuration.
        # See: https://bugs.debian.org/765782
        #
        # Self signed certs generated by the ssl-cert package
        # Don't use them in a production server!
        #
        # include snippets/snakeoil.conf;

        root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.html index.htm;

        server_name nasciiboy.land www.nasciiboy.land;
        ssl_certificate     /etc/nginx/ssl/nginx.crt;
        ssl_certificate_key /etc/nginx/ssl/nginx.key;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ =404;
        }

        error_page 404 /404.html;

}

poner bien los punto y coma…

por supuesto el navegador se quejo

mirar la info del certificado

certbot strikes back

tras muchos intentos lanzando certbot (esperando sin razon un resultado distinto) y leyendo unos post de linuxito, pero sobre todo de la eff el certificado se materializo ejecutando lo siguiente

> certbot --authenticator webroot --installer nginx

los certificados funcionaron automagicamente, ja, ja, ja, no guarde el orden de lo que puse, para la proxima…

y eso es todo por este aglutinado de cosas, happy hacking!

/ prog