Desde hace ya más de 5 años, mi currículum está escrito en LaTeX, usando (y modificando) la plantilla Awesome CV. Además, le añadí un par de cosas para hacerlo “bilingüe” y poder compilar o bien al inglés o al castellano, haciendo que el documento esté disponible en múltiples idiomas.

Gracias a iflang, dependiendo de la opción que le pasemos al importar el paquete babel, se renderizará el documento en un idioma u otro.

\documentclass[a4paper]{awesome-cv}
\usepackage[<lang>]{babel}
\usepackage{iflang}

\newcommand{\es}[1]{\IfLanguageName{spanish}{#1}{}}
\newcommand{\en}[1]{\IfLanguageName{english}{#1}{}}

\begin{document}
  \es{¡Hola Mundo!}
  \en{Hello World!}
\end{document}

Sin embargo, es necesario cambiar <lang> a mano, por lo que no puede ser automatizado. Una opción sencilla sería usar sed para modificar el fichero, pero puede no estar instalado en el sistema (si usas Windows) y me apetecía usar algo LaTeX puro.

Juan Carlos Fabero me dio la idea de usar un par de ficheros envoltorio (wrappers) que simplemente definan la variable y e importen el contenido de main.tex. En cuanto al fichero principal, solo sería necesario añadir un par de líneas para comprobar si dicha variable está definida o no.

Modificación main.tex

% Usamos la variable si está definida
\ifdefined\babellang
    \usepackage[\babellang]{babel}
% Si no, usamos el por defecto (o cambiado manualmente desde el IDE)
\else
    \usepackage[english]{babel}
\fi

Fichero english.tex

\def\babellang{english}
\input{main.tex}

Fichero spanish.tex

\def\babellang{spanish}
\input{main.tex}

De esta manera, si compilamos english.tex se generará un documento en Inglés, y si compilamos spanish.tex se creará en castellano.

Automatizando con GitHub pages

No nos podemos olvidar de hacer que todo esto se haga de manera automática, sin tocar nada. Para ello, el CV está en un proyecto de GitHub, y cada vez que se hace un commit, se compila el fichero y se aloja usando GitHub pages. Así, queda el CV accesible desde github.io:

• Inglés: https://daviddavo.github.io/22CV/David_Davo_CV_English.pdf
• Castellano: https://daviddavo.github.io/22CV/David_Davo_CV_Spanish.pdf

El workflow es bastante sencillo, lo creé directamente desde la página web modificando un poco el por defecto para que compile el PDF usando latex-action, y lo suba a GitHub pages. Ya de paso comprueba que el PDF generado no tiene más de 2 páginas (un folio por las dos caras).

name: CI

# Controls when the workflow will run
on:
  # Triggers the workflow on push or pull request events but only for the "main" branch
  push:
    branches: [ "main" ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      - uses: actions/checkout@v3
      - name: Build LaTeX
        uses: xu-cheng/latex-action@v2
        with:
          latexmk_use_xelatex: true
          # Compile multiple documents
          root_file: |
            english.tex
            spanish.tex            
      - name: Assert built files are 2 pages long
        run: |
          sudo apt-get install -y poppler-utils
          [ $(pdfinfo english.pdf | awk '/^Pages:/ {print $2}') -le 2 ]
          [ $(pdfinfo spanish.pdf | awk '/^Pages:/ {print $2}') -le 2 ]          
      - name: Build Github page
        run: |
          mv english.pdf _site/David_Davo_CV_English.pdf
          mv spanish.pdf _site/David_Davo_CV_Spanish.pdf          
      - name: Upload GitHub Pages artifact
        uses: actions/upload-pages-artifact@v1.0.3
  deploy:
    needs: build
    
    # Grant GITHUB_TOKEN the permissions required to make a Pages deployment
    permissions:
      pages: write      # to deploy to Pages
      id-token: write   # to verify the deployment originates from an appropriate source

    # Deploy to the github-pages environment
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}

    # Specify runner + deployment step
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v1
        with:
          artifact-name: build

El toque final está en una pequeña página html por si alguien entra en la raíz del GitHub pages (daviddavo.github.io/22CV), que simplemente redirige a mi página web personal.

Hace un par de días decidí que ya era hora de empezar de cero y crear una página nueva, esta vez usando un generador estático. Acabé decidiéndome por Hugo.

Como la página antigua era un poco… malurria, quería sacar la nueva lo antes posible. Sin embargo, aún me faltaba un banner que dijese “eh, aún estoy trabajando en ello y seguro que faltan cosas”. Bueno, en realidad no es completamente necesario, pero queda chulo.

Mi objetivo era emular una especie de cinta de peligro, de estas negras y amarillas que te recuerdan a las obras. Hacer el fondo de rayas no fue difícil, gracias a herramientas como stripesgenerator.com, pero lo más importante es girar un poquito el componente, simulando una cinta mal colocada y cediendo ante la gravedad.

No fue tan difícil, gracias a la propiedad transform: rotate().

Al final quedó algo así:

See the Pen Untitled by David Davó (@daviddavo) on CodePen.

¿Qué opinas? Ha quedado chulo, ¿no? Si haces alguna modificación, ¡no te olvides de compartirla!

El portátil en sí no me da mucha pena, pero en el disco duro hay datos. Datos relevantes. Todos pensamos que no hemos hecho nada malo y que no tenemos nada que ocultar… –"¿por qué iba a querer encriptar cosas si no soy de la mafia?"

Pero seguro que tienes una o dos copias de tus DNIs. Tanto caducados como vigentes. Y también tendrás alguna factura con tu dirección de casa, y correos electrónicos con alguna contraseña, y papeles de la universidad/trabajo, y… Pues eso.

El robo de identidad no es una broma, Jim! – Dwight K. Schrute

Por eso vamos a aprender a encriptar TODA tu carpeta home personal, con un método que funciona en Arch Linux y otras distros derivadas como Manjaro.

¡¡ANTES DE CONTINUAR!!

Has de tener cuidado porque los datos encriptados, en caso de perder la clave o la contraseña, no podrán ser recuperados de ninguna forma (o por lo menos, esa es la idea)

Migrando el home

Es sencillo, simplemente debemos llamar, desde el usuario root, a un script que viene ya hecho y te configura todo él solito. Eso sí, vas a necesitar más o menos 2.5 veces el espacio de tu carpeta $HOME, por lo que borra primero la caché y todo lo que no te preocupe mucho borrar. Ese espacio extra podrá ser liberado después del proceso, así que en el peor de los casos puedes mover algunas cosas a otro disco duro, y luego volver a dejarlas donde estaban.

Antes de continuar, necesitarás asegurarte de que los siguientes comandos están instalados y funcionando:

• rsync
• lsof
• which

Inicia sesión con el usuario root (no vale usar tu usuario con sudo). Una vez hayas comprobado que los comandos funcionan, debemos cargar el módulo del kernel encargado de la encriptación, usando modprobe

$ modprobe ecryptfs

Finalmente, antes de comenzar con la migración, asegurate de que ningún proceso del usuario del que quieres migrar está ejecutándose, pues podría dar problemas. Puedes usar ps -U <usuario> (si la lista está vacía, es que no hay ningún proceso siendo ejecutado por ese usuario). Ahora sí, tan sólo tienes que introducir el siguiente comando y seguir las instrucciones:

$ ecryptfs-migrate-home -u <usuario>

Este comando te creará una “copia de seguridad” en /home/<usuario>.<cadena>, que deberías borrar una vez todo funcione correctamente.

Habilitando el automontaje

Para habilitar el automontaje, usaremos un “módulo de autenticación conectable” o PAM (Pluggable Authentication Module). Es básicamente una especie de plugin del sistema de inicio de sesión de Linux, que en este caso nos permitirá montar una carpeta cifrada mientras iniciamos sesión (pero antes de cargar nuestro entorno de escritorio y esas cosas).

Vamos a editar el archivo /etc/pam.d/system-auth

Después de la línea auth required pam_unix.so (o auth [default=die] pam_faillock.so authfail si existe) inserta:

auth [success=1 default=ignore] pam_succeed_if.so service = systemd-user quiet
auth required                   pam_ecryptfs.so unwrap

Sobre la línea password required pam_unix.so (o -password [success=1 default=ignore] pam_systemd_home.so si existe), añade:

password    optional    pam_ecryptfs.so

Para terminar, tras la linea session required pam_unix.so pon:

session [success=1 default=ignore] pam_succeed_if.so service = systemd-user quiet
session optional                   pam_ecryptfs.so unwrap

Ahora ya puedes cerrar tu sesión de root e iniciar sesión con tu usuario normal. Debería estar todo justo donde lo dejaste.

También puedes probar a iniciar sesión desde otro usuario (con tu sesión cerrada, claro), e intentar acceder a /home/<nombreusuarioprotegido>. ¿Que pasará?

Fuentes y más información

• eCryptfs - ArchWiki
• PAM - ArchWiki
• pam_mount - ArchWiki

Esto puede causar problemas si usas DNS para asignarle un nombre de dominio a un servicio. Pongamos que tienes un blog, y le asignas el dominio blog.example.com a la IP pública 1.2.3.4. En tu rúter mapeas los puertos a tu dirección local 192.168.1.66, pero cuando quieres acceder a blog.example.com… ¡no funciona! Te dirá que no se puede conectar al host o algo así –¿Cómo que no? ¡Si lo tengo aquí al lado!–. Lo que pasa es que tu ordenador se está intentando conectar a la dirección 1.2.3.4, cuando lo que en realidad quieres es acceder a la dirección 192.168.1.66. Una alternativa sería modificar el archivo hosts, pero si quieres modificarlo en todos los dispositivos de tu red local a la vez, existe otra solución: ¡cambiar los DNS! Pero no el DNS de todo el mundo, porque dejaría de funcionar tu web para la gente que no esté en tu red local. El truco está en cambiar únicamente los DNS dentro de tu red local.

Requisitos antes de seguir:

• Saber un poco qué es DNS y como cambiar los registros desde el panel de tu registrador de nombres de dominio.

BIND: Tu servidor DNS de confianza

Bind es un servidor DNS, al que tú le preguntas un nombre de dominio (como google.es) y este te responde su dirección IP (142.250.200.131). Lo más seguro es que ya tengas un servidor bind en casa sin que tú lo sepas: el del rúter de la compañía telefónica. Y esque tener un servidor DNS en tu red local tiene muchas ventajas, sobre todo porque las consultas se hacen a un dispositivo que está a 10 metros, y no a un servidor a 100km.

Lo de sobreescribir algunas entradas es posible gracias al mecanismo RPZ, o Políticas de Zonas de Respuesta, que nos permite establecer espacios de nombres de dominio especiales que sobreescriban a otros.

Ahora veremos como instalar y montar todo.

Instalar bind

Dependiendo tu distro de linux o tu sistema operativo, el proceso de instalación será diferente. En este caso el tutorial se ha realizado con una máquina con Debian/Ubuntu. Tan sólo es necesario instalar un par de paquetes, introducir en la terminal el siguiente comando.

sudo apt install bind9 bind9utils bind9-doc

Configurando BIND

Recuerda que para modificar estos archivos es necesario ser root o usar sudo

Lo primero es configurar una nueva zona a la que añadir nuestros subdominios, la vamos a llamar “rpz”, y estableceremos su “base de datos” en el fichero /etc/bind/db.rpz. Para ello editamos el fichero /etc/bind/named.conf.default-zones y añadimos las siguientes líneas:

zone "rpz" {
    type master;
    file "/etc/bind/db.rpz";
}

Ahora editamos la base de datos donde se encuentran nuestros dominios (/etc/bind/db.rpz), añadiendo todos los registros que queramos.

; Fichero para mi LAN (Red de Área Local)
$TTL 3600

; Estas dos entradas indican cual es el servidor DNS al que consultar (este mismo)
@		IN	SOA	localhost. root.localhost. (
			      2		; Serial
			 604800		; Refresh
			  86400		; Retry
			2419200		; Expire
			 604800 )	; Negative Cache TTL
@		IN	NS	localhost.

; Si establecemos un $ORIGIN, solo es necesario indicar el subdominio
$ORIGIN example.com

nas                  A       192.168.1.42              ; Dirección IPv4 de nas.example.com
nas                  AAAA    fe80::1ff:fe23:4567:890a  ; Dirección IPv6 de nas.example.com
ftp                  CNAME   nas                       ; Un simple alias de ftp.example.com a nas.example.com
blog.example2.org.   A       192.168.1.31              ; También podemos añadir dominios completos

Además, el objetivo también es que todas las direcciones que tu servidor no conozca, se las pregunte a otro servidor. Para ello es necesario habilitar la recursión y especificar los servidores a los que preguntar en caso de no encontrar la entrada en el rpz.

Los servidores a los que preguntar pueden ser dados por tu ISP, también puede ser tu rúter (192.168.1.1). Yo recomiendo usar los de Google/Cloudflare por su fiabilidad y rapidez.

options {
	directory "/var/cache/bind";

	recursion yes; # Habilitamos la recursión
	listen-on { 192.168.1.11; }; # La dirección IP de nuestro servidor
	allow-transfer { none; };
	response-policy { zone "rpz"; } break-dnssec yes; # La response policy zone

	forwarders {
		8.8.8.8;
		8.8.4.4;
		1.1.1.1;
	};

	dnssec-validation auto;

	listen-on-v6 { any; }; # Puedes poner "none" si no quieres que funcione por ipv6
};

Es importante decirle al servidor que ignore las peticiones “seguras”, de no ser así, podría devolver una dirección firmada, pero incorrecta.

Arrancando el servidor

Para aplicar los cambios, iniciamos el servidor con systemctl

sudo systemctl enable --now bind9

Podemos probar que funciona con el comando dig (tal vez necesites instalarlo), que nos permite hacer consultas a un servidor DNS en concreto (y no al por defecto) del Sistema Operativo.

Primero probamos que funcionen las consultas normales, como a Google

$ dig google.es
; <<>> DiG 9.16.23 <<>> google.es
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5016
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 01db1f47a27adb9e90e4c7fb61c24bc2bf8c6a88296c3923 (good)
;; QUESTION SECTION:
;google.es.			IN	A

;; ANSWER SECTION:
google.es.		300	IN	A	142.250.200.131

;; Query time: 39 msec
;; SERVER: 192.168.1.11#53(192.168.1.11)
;; WHEN: Tue Dec 21 22:48:50 CET 2021
;; MSG SIZE  rcvd: 82

Y ahora probamos que funcione nuestro RPZ

$ dig chikyuu.ddavo.me @192.168.1.11
; <<>> DiG 9.16.23 <<>> nas.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45881
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d200bc3ba9741e2ab2c8935661c24b4b401d43ae997c39de (good)
;; QUESTION SECTION:
;nas.example.com.		IN	A

;; ANSWER SECTION:
nas.example.com.	5	IN	A	192.168.1.42

;; Query time: 0 msec
;; SERVER: 192.168.1.11#53(192.168.1.11)
;; WHEN: Tue Dec 21 22:46:51 CET 2021
;; MSG SIZE  rcvd: 89

¡¡Parece que funciona!! La dirección IP que nos retorna es la dirección de área local, en lugar de la global.

Usando el servidor

Sin embargo, no funciona desde el navegador, ni desde cualquier otro programa que no sea dig…

Es necesario configurar los dispositivos de tu red para que usen la nueva dirección. Cada sistema operativo es un mundo, pero tampoco suele ser algo muy difícil.

Si te es posible, puedes cambiarlo directamente desde el rúter, para que se propague al resto de dispositivos automágicamente.

Fuentes y más información

• Serverfault.com: Overriding some DNS entries in BIND for internal networks
• Wikipedia: Response policy zone
• dnsrpz.info