Like with any other of my entries I based my setup on the Arch Wiki, this install script and this profile generator script.

This will be installed and working alongside the other stuff I’ve wrote about on other posts (see the server tag). All commands here are executes as root unless specified otherwise. Also, this is intended only for IPv4 (it’s not that hard to include IPv6, but meh).

Prerequisites

Pretty simple:

• Working server with root access, and with Ufw as the firewall.
• Depending on what port you want to run the VPN on, the default 1194, or as a fallback on 443 (click here for more). I will do mine on port 1194 but it’s just a matter of changing 2 lines of configuration and one Ufw rule.

Create PKI from scratch

PKI stands for Public Key Infrastructure and basically it’s required for certificates, private keys and more. This is supposed to work between two servers and one client: a server in charge of creating, signing and verifying the certificates, a server with the OpenVPN service running and the client making the request.

This is supposed to work something like: 1) a client wants to use the VPN service, so it creates a requests and sends it to the signing server, 2) this server checks the requests and signs the request, returning the certificates to both the VPN service and the client and 3) the client can now connect to the VPN service using the signed certificate which the OpenVPN server knows about. In a nutshell, I’m no expert.

… but, to be honest, all of this is a hassle and (in my case) I want something simple to use and manage. So I’m gonna do all on one server and then just give away the configuration file for the clients, effectively generating files that anyone can run and will work, meaning that you need to be careful who you give this files (it also comes with a revoking mechanism, so no worries).

This is done with Easy-RSA.

Install the easy-rsa package:

pacman -S easy-rsa

Initialize the PKI and generate the CA keypair:

cd /etc/easy-rsa
easyrsa init-pki
easyrsa build-ca nopass

Create the server certificate and private key (while in the same directory):

EASYRSA_CERT_EXPIRE=3650 easyrsa build-server-full server nopass

Where server is just a name to identify your server certificate keypair, I just use server but could be anything (like luevano.xyz in my case).

Create the client revocation list AKA CRL (will be used later, but might as well have it now):

EASYRSA_CRL_DAYS=3650 easyrsa gen-crl

After this we should have 6 new files:

/etc/easy-rsa/pki/ca.crt
/etc/easy-rsa/pki/private/ca.key
/etc/easy-rsa/pki/issued/server.crt
/etc/easy-rsa/pki/reqs/server.req
/etc/easy-rsa/pki/private/server.key
/etc/easy-rsa/pki/crl.pem

It is recommended to copy some of these files over to the openvpn directory, but I prefer to keep them here and just change some of the permissions:

chmod o+rx pki
chmod o+rx pki/ca.crt
chmod o+rx pki/issued
chmod o+rx pki/issued/server.crt
chmod o+rx pki/private
chmod o+rx pki/private/server.key
chown nobody:nobody pki/crl.pem
chmod o+r pki/crl.pem

Now, go to the openvpn directory and create the required files there:

cd /etc/openvpn/server
openssl dhparam -out dh.pem 2048
openvpn --genkey secret ta.key

That’s it for the PKI stuff and general certificate configuration.

OpenVPN

OpenVPN is a robust and highly flexible VPN daemon, that’s pretty complete feature wise.

Install the openvpn package:

pacman -S openvpn

Now, most of the stuff is going to be handled by (each, if you have more than one) server configuration. This might be the hardest thing to configure, but I’ve used a basic configuration file that worked a lot to me, which is a compilation of stuff that I found on the internet while configuring the file a while back.

# Server ip addres (ipv4).
local 1.2.3.4 # your server public ip

# Port.
port 1194 # Might want to change it to 443

# TCP or UDP.
;proto tcp
proto udp # If ip changes to 443, you should change this to tcp, too

# "dev tun" will create a routed IP tunnel,
# "dev tap" will create an ethernet tunnel.
;dev tap
dev tun

# Server specific certificates and more.
ca /etc/easy-rsa/pki/ca.crt
cert /etc/easy-rsa/pki/issued/server.crt
key /etc/easy-rsa/pki/private/server.key  # This file should be kept secret.
dh /etc/openvpn/server/dh.pem
auth SHA512
tls-crypt /etc/openvpn/server/ta.key 0 # This file is secret.
crl-verify /etc/easy-rsa/pki/crl.pem

# Network topology.
topology subnet

# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
server 10.8.0.0 255.255.255.0

# Maintain a record of client <-> virtual IP address
# associations in this file.
ifconfig-pool-persist ipp.txt

# Push routes to the client to allow it
# to reach other private subnets behind
# the server.
;push "route 192.168.10.0 255.255.255.0"
;push "route 192.168.20.0 255.255.255.0"

# If enabled, this directive will configure
# all clients to redirect their default
# network gateway through the VPN, causing
# all IP traffic such as web browsing and
# and DNS lookups to go through the VPN
push "redirect-gateway def1 bypass-dhcp"

# Certain Windows-specific network settings
# can be pushed to clients, such as DNS
# or WINS server addresses.
# Google DNS.
;push "dhcp-option DNS 8.8.8.8"
;push "dhcp-option DNS 8.8.4.4"

# The keepalive directive causes ping-like
# messages to be sent back and forth over
# the link so that each side knows when
# the other side has gone down.
keepalive 10 120

# The maximum number of concurrently connected
# clients we want to allow.
max-clients 5

# It's a good idea to reduce the OpenVPN
# daemon's privileges after initialization.
user nobody
group nobody

# The persist options will try to avoid
# accessing certain resources on restart
# that may no longer be accessible because
# of the privilege downgrade.
persist-key
persist-tun

# Output a short status file showing
# current connections, truncated
# and rewritten every minute.
status openvpn-status.log

# Set the appropriate level of log
# file verbosity.
#
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 3

# Notify the client that when the server restarts so it
# can automatically reconnect.
# Only usable with udp.
explicit-exit-notify 1

# and ; are comments. Read each and every line, you might want to change some stuff (like the logging), specially the first line which is your server public IP.

Now, we need to enable packet forwarding (so we can access the web while connected to the VPN), which can be enabled on the interface level or globally (you can check the different options with sysctl -a | grep forward). I’ll do it globally, run:

sysctl net.ipv4.ip_forward=1

And create/edit the file /etc/sysctl.d/30-ipforward.conf:

net.ipv4.ip_forward=1

Now we need to configure ufw to forward traffic through the VPN. Append the following to /etc/default/ufw (or edit the existing line):

...
DEFAULT_FORWARD_POLICY="ACCEPT"
...

And change the /etc/ufw/before.rules, appending the following lines after the header but before the *filter line:

...
# NAT (Network Address Translation) table rules
*nat
:POSTROUTING ACCEPT [0:0]

# Allow traffic from clients to the interface
-A POSTROUTING -s 10.8.0.0/24 -o interface -j MASQUERADE

# do not delete the "COMMIT" line or the NAT table rules above will not be processed
COMMIT

# Don't delete these required lines, otherwise there will be errors
*filter
...

Where interface must be changed depending on your system (in my case it’s ens3, another common one is eth0); I always check this by running ip addr which gives you a list of interfaces (the one containing your server public IP is the one you want, or whatever interface your server uses to connect to the internet):

...
2: ens3: <SOMETHING,SOMETHING> bla bla
    link/ether bla:bla
    altname enp0s3
    inet my.public.ip.addr bla bla
...

And also make sure the 10.8.0.0/24 matches the subnet mask specified in the server.conf file (in this example it matches). You should check this very carefully, because I just spent a good 2 hours debugging why my configuration wasn’t working, and this was te reason (I could connect to the VPN, but had no external connection to the web).

Finally, allow the OpenVPN port you specified (in this example its 1194/udp) and reload ufw:

ufw allow 1194/udp comment "OpenVPN"
ufw reload

At this point, the server-side configuration is done and you can start and enable the service:

systemctl start openvpn-server@server.service
systemctl enable openvpn-server@server.service

Where the server after @ is the name of your configuration, server.conf without the .conf in my case.

Create client configurations

You might notice that I didn’t specify how to actually connect to our server. For that we need to do a few more steps. We actually need a configuration file similar to the server.conf file that we created.

The real way of doing this would be to run similar steps as the ones with easy-rsa locally, send them to the server, sign them, and retrieve them. Nah, we’ll just create all configuration files on the server as I was mentioning earlier.

Also, the client configuration file has to match the server one (to some degree), to make this easier you can create a client-common file in /etc/openvpn/server with the following content:

client
dev tun
remote 1.2.3.4 1194 udp # change this to match your ip and port
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
verb 3

Where you should make any changes necessary, depending on your configuration.

Now, we need a way to create and revoke new configuration files. For this I created a script, heavily based on one of the links I mentioned at the beginning, by the way. You can place these scripts anywhere you like, and you should take a look before running them because you’ll be running them as root.

In a nutshell, what it does is: generate a new client certificate keypair, update the CRL and create a new .ovpn configuration file that consists on the client-common data and all of the required certificates; or, revoke an existing client and refresh the CRL. The file is placed under ~/ovpn.

Create a new file with the following content (name it whatever you like) and don’t forget to make it executable (chmod +x vpn_script):

#!/bin/sh
# Client ovpn configuration creation and revoking.
MODE=$1
if [ ! "$MODE" = "new" -a ! "$MODE" = "rev" ]; then
    echo "$1 is not a valid mode, using default 'new'"
    MODE=new
fi

CLIENT=${2:-guest}
if [ -z $2 ];then
    echo "there was no client name passed as second argument, using 'guest' as default"
fi

# Expiration config.
EASYRSA_CERT_EXPIRE=3650
EASYRSA_CRL_DAYS=3650

# Current PWD.
CPWD=$PWD
cd /etc/easy-rsa/

if [ "$MODE" = "rev" ]; then
    easyrsa --batch revoke $CLIENT

    echo "$CLIENT revoked."
elif [ "$MODE" = "new" ]; then
    easyrsa build-client-full $CLIENT nopass

    # This is what actually generates the config file.
    {
    cat /etc/openvpn/server/client-common
    echo "<ca>"
    cat /etc/easy-rsa/pki/ca.crt
    echo "</ca>"
    echo "<cert>"
    sed -ne '/BEGIN CERTIFICATE/,$ p' /etc/easy-rsa/pki/issued/$CLIENT.crt
    echo "</cert>"
    echo "<key>"
    cat /etc/easy-rsa/pki/private/$CLIENT.key
    echo "</key>"
    echo "<tls-crypt>"
    sed -ne '/BEGIN OpenVPN Static key/,$ p' /etc/openvpn/server/ta.key
    echo "</tls-crypt>"
    } > "$(eval echo ~${SUDO_USER:-$USER}/ovpn/$CLIENT.ovpn)"

    eval echo "~${SUDO_USER:-$USER}/ovpn/$CLIENT.ovpn file generated."
fi

# Finish up, re-generates the crl
easyrsa gen-crl
chown nobody:nobody pki/crl.pem
chmod o+r pki/crl.pem
cd $CPWD

And the way to use is to run vpn_script new/rev client_name as sudo (when revoking, it doesn’t actually deletes the .ovpn file in ~/ovpn). Again, this is a little script that I put together, so you should check it out, it may need tweaks (depending on your directory structure for easy-rsa) and it could have errors.

Now, just get the .ovpn file generated, import it to OpenVPN in your client of preference and you should have a working VPN service.

Básicamente tenía que cumplir dos misiones hoy: ir al banco a un trámite y vacunarme contra el Covid-19. Muy sencillas tareas.

Primero que nada me levanté de una pesadilla horrible en la que se puede decir que se me subió el muerto al querer despertar, esperé a que fuera casi la hora de salida de mi horario de trabajo, me bañé y fui directo al banco primero. Todo bien hasta aquí.

En el camino al banco, durante la plática con el conductor del Uber salió el tema del horario del banco. Yo muy tranquilo dije “pues voy algo tarde, pero sí alcanzo, cierran a las 5, ¿no?” a lo que me respondió el conductor “nel jefe, a las 4, y se van media hora antes”; quedé. Chequé y efectivamente cerraban a las 4. Entonces le dije que le iba a cambiar la ruta directo a donde me iba a vacunar, pero ya era muy tarde y quedaba para la dirección opuesta.”Ni pedo, ahí déjame y pido otro viaje, no te apures”, le dije y como siempre pues me deseó que se compusiera mi día; afortunadamente el banco sí estaba abierto para lo que tenía que hacer, así que fue un buen giro. Me puse muy feliz y asumí que sería un buen día, como me lo dijo mi conductor; literalmente NO SABÍA.

Salí feliz de poder haber completado esa misión y poder irme a vacunar. Pedí otro Uber a donde tenía que ir y todo bien. Me tocó caminar mucho porque la entrada estaba en punta de la chingada de donde me dejó el conductor, pero no había rollo, era lo de menos. Me desanimé cuando vi que había una cantidad estúpida de gente, era una fila que abarcaba todo el estacionamiento y daba demasiadas vueltas; “ni pedo”, dije, “si mucho me estaré aquí una hora, hora y media”… otra vez, literalmente NO SABÍA.

Pasó media hora y había avanzado lo que parecía ser un cuarto de la fila, entonces todo iba bien. Pues nel, había avanzado el equivalente a un octavo de la fila, este pedo no iba a salir en una hora-hora y media. Para acabarla de chingar era todo bajo el tan amado sol de Chiwawa. “No hay pedo, me entretengo tirando chal con alguien en el wasap”, pues no, aparentemente no cargué el celular y ya tenía 15-20% de batería… volví a quedar.

Se me acabó la pila, ya había pasado una hora y parecía que la fila era infinita, simplemente avanzábamos demasiado lento, a pesar de que los que venían atrás de mí repetían una y otra vez “mira, avanza bien rápido, ya mero llegamos”, ilusos. Duré aproximadamente 3 horas formado, aguantando conversaciones estúpidas a mi alrededor, gente quejándose por estar parada (yo también me estaba quejando pero dentro de mi cabeza), y por alguna razón iban familias completas de las cuales al final del día sólo uno o dos integrantes de la familia entraban a vacunarse.

En fin que se acabó la tortura y ya tocaba irse al cantón, todo bien. “No hay pedo, no me tocó irme en Uber, aquí agarro un camíon” pensé. Pero no, ningún camión pasó durante la hora que estuve esperando y de los 5 taxis que intenté parar NINGUNO se detuvo. Decidí irme caminado, ya qué más daba, en ese punto ya nada más era hacer corajes dioquis.

En el camino vi un Oxxo y decidí desviarme para comprar algo de tomar porque andaba bien deshidratado. En el mismo segundo que volteé para ir hacia el Oxxo pasó un camión volando y lo único que pensaba era que el conductor me decía “Jeje ni pedo:)”. Exploté, me acabé, simplemente perdí, saqué el bad ending.

Ya estaba harto y hasta iba a comprar un cargador para ya irme rápido, estaba cansado del día, simplemente ahí terminó la quest, había sacado el peor final. Lo bueno es que se me ocurrió pedirle al cajero un cargador y que me tirara paro. Todo bien, pedí mi Uber y llegué a mi casa sano y a salvo, pero con la peor rabia que me había dado en mucho tiempo. Simplemente ¿mi culo? explotado. Este día me tocó un desarrollo de personaje muy cabrón, se mamó el D*****o.

Lo único rescatable fue que había una (más bien como 5) chica muy guapa en la fila, lástima que los stats de mi personaje me tienen bloqueadas las conversaciones con desconocidos.

Y pues ya, este pex ya me sirvió para desahogarme, una disculpa por la redacción tan pitera. Sobres.

Tengo unas entradas pendientes que quiero hacer del estilo de “tutorial” o “how-to”, pero me lo he estado debatiendo, porque Luke ya empezó a hacerlo más de verdad en landchad.net, lo cual recomiendo bastante pues igual yo empecé a hacer esto por él (y por lm); aunque la verdad pues es muy específico a como él hace las cosas y quizá sí puede haber diferencias, pero ya veré en estos días. La próxima que quiero hacer es sobre el VPN, porque no lo he setupeado desde que reinicié El Página Web y La Servidor, entonces acomodaré el VPN de nuevo y de pasada tiro entrada de eso.

También dejé un dibujo pendiente, que la neta lo dejé por 2 cosas: está bien cabrón (porque también lo quiero colorear) y porque estaba ocupado; de lo cuál ya sólo queda el está bien cabrón pero no he tenido el valor de retomarlo. Lo triste es que ya pasó el tiempo del hype y ya no tengo mucha motivación para terminarlo más que el hecho de que cuando lo termine empezaré a usar Clip Studio Paint en vez de Krita, porque compré una licencia ahora que estuvo en 50% de descuento (sí, me mamé).

Algo bueno es que me he estado sintiendo muy bien conmigo mismo últimamente, aunque casi no hable de eso. Sí hay una razón en específico, pero es una razón algo tonta. Espero así siga.

Ah, y también quería acomodarme una sección de comentarios, pero como siempre, todas las opciones están bien bloated, entonces pues me voy a hacer una en corto seguramente en Python para el back, MySQL para la base de datos y Javascript para la conexión acá en el front, algo tranqui.

Sobres pues.

One of the best resources I found that helped me a lot was Installing and Configuring Prosody XMPP Server on Debian 9, and of course the Arch Wiki and the oficial documentation.

As with my other entries, this is under a server running Arch Linux, with the Nginx web server and Certbot certificates. And all commands here are executed as root (unless specified otherwise)

Prerequisites

Same as with my other entries (website, mail and git) plus:

• A and (optionally) AAA DNS records for:
  • xmpp: the actual XMPP server and the file upload service.
  • muc (or conference): for multi-user chats.
  • pubsub: the publish-subscribe service.
  • proxy: a proxy in case one of the users needs it.
  • vjud: user directory.
• (Optionally, but recommended) the following SRV DNS records; make sure it is pointing to an A or AAA record (matching the records from the last point, for example):
  • _xmpp-client._tcp.**your.domain**. for port 5222 pointing to xmpp.**your.domain**.
  • _xmpp-server._tcp.**your.domain**. for port 5269 pointing to xmpp.**your.domain**.
  • _xmpp-server._tcp.muc.**your.domain**. for port 5269 pointing to xmpp.**your.domain**.
• SSL certificates for the previous subdomains; similar that with my other entries just create the appropriate prosody.conf (where server_name will be all the subdomains defined above) file and run certbot --nginx. You can find the example configuration file almost at the end of this entry.
• Email addresses for admin, abuse, contact, security, etc. Or use your own email for all of them, doesn’t really matter much as long as you define them in the configuration and are valid, I have aliases so those emails are forwarded to me.
• Allow ports 5000, 5222, 5269, 5280 and 5281 for Prosody and, 3478 and 5349 for Turnserver which are the defaults for coturn.

Prosody

Prosody is an implementation of the XMPP protocol that is flexible and extensible.

Install the prosody package (with optional dependencies) and the mercurial package:

pacman -S prosody, mercurial, lua52-sec, lua52-dbi, lua52-zlib

We need mercurial to be able to download and update the extra modules needed to make the server compliant with conversations.im and mov.im. Go to /var/lib/prosody, clone the latest Prosody modules repository and prepare the directories:

cd /var/lib/prosody
hg clone https://hg.prosody.im/prosody-modules modules-available
mkdir modules-enabled

You can see that I follow a similar approach that I used with Nginx and the server configuration, where I have all the modules available in a directory, and make a symlink to another to keep track of what is being used. You can update the repository by running hg pull --update while inside the modules-available directory (similar to Git).

Make symbolic links to the following modules:

ln -s /var/lib/prosody/modules-available/MODULE_NAME /var/lib/prosody/modules-enabled/
...

• Modules:
  • mod_bookmarks
  • mod_cache_c2s_caps
  • mod_checkcerts
  • mod_cloud_notify
  • mod_csi_battery_saver
  • mod_default_bookmarks
  • mod_external_services
  • mod_http_avatar
  • mod_http_pep_avatar
  • mod_http_upload
  • mod_http_upload_external
  • mod_idlecompat
  • mod_muc_limits
  • mod_muc_mam_hints
  • mod_muc_mention_notifications
  • mod_presence_cache
  • mod_pubsub_feeds
  • mod_pubsub_text_interface
  • mod_smacks
  • mod_strict_https
  • mod_vcard_muc
  • mod_vjud
  • mod_watchuntrusted

And add other modules if needed, but these work for the apps that I mentioned. You should also change the permissions for these files:

chown -R prosody:prosody /var/lib/prosody

Now, configure the server by editing the /etc/prosody/prosody.cfg.lua file. It’s a bit tricky to configure, so here is my configuration file (lines starting with -- are comments). Make sure to change according to your domain, and maybe preferences. Read each line and each comment to know what’s going on, It’s easier to explain it with comments in the file itself than strip it in a lot of pieces.

And also, note that the configuration file has a “global” section and a per “virtual server”/”component” section, basically everything above all the VirtualServer/Component sections are global, and bellow each VirtualServer/Component, corresponds to that section.

-- important for systemd
daemonize = true
pidfile = "/run/prosody/prosody.pid"

-- or your account, not that this is an xmpp jid, not email
admins = { "admin@your.domain" }

contact_info = {
    abuse = { "mailto:abuse@your.domain", "xmpp:abuse@your.domain" };
    admin = { "mailto:admin@your.domain", "xmpp:admin@your.domain" };
    admin = { "mailto:feedback@your.domain", "xmpp:feedback@your.domain" };
    security = { "mailto:security@your.domain" };
    support = { "mailto:support@your.domain", "xmpp:support@muc.your.domain" };
}

-- so prosody look up the plugins we added
plugin_paths = { "/var/lib/prosody/modules-enabled" }

modules_enabled = {
    -- Generally required
        "roster"; -- Allow users to have a roster. Recommended ;)
        "saslauth"; -- Authentication for clients and servers. Recommended if you want to log in.
        "tls"; -- Add support for secure TLS on c2s/s2s connections
        "dialback"; -- s2s dialback support
        "disco"; -- Service discovery
    -- Not essential, but recommended
        "carbons"; -- Keep multiple clients in sync
        "pep"; -- Enables users to publish their avatar, mood, activity, playing music and more
        "private"; -- Private XML storage (for room bookmarks, etc.)
        "blocklist"; -- Allow users to block communications with other users
        "vcard4"; -- User profiles (stored in PEP)
        "vcard_legacy"; -- Conversion between legacy vCard and PEP Avatar, vcard
        "limits"; -- Enable bandwidth limiting for XMPP connections
    -- Nice to have
        "version"; -- Replies to server version requests
        "uptime"; -- Report how long server has been running
        "time"; -- Let others know the time here on this server
        "ping"; -- Replies to XMPP pings with pongs
        "register"; -- Allow users to register on this server using a client and change passwords
        "mam"; -- Store messages in an archive and allow users to access it
        "csi_simple"; -- Simple Mobile optimizations
    -- Admin interfaces
        "admin_adhoc"; -- Allows administration via an XMPP client that supports ad-hoc commands
        --"admin_telnet"; -- Opens telnet console interface on localhost port 5582
    -- HTTP modules
        "http"; -- Explicitly enable http server.
        "bosh"; -- Enable BOSH clients, aka "Jabber over HTTP"
        "websocket"; -- XMPP over WebSockets
        "http_files"; -- Serve static files from a directory over HTTP
    -- Other specific functionality
        "groups"; -- Shared roster support
        "server_contact_info"; -- Publish contact information for this service
        "announce"; -- Send announcement to all online users
        "welcome"; -- Welcome users who register accounts
        "watchregistrations"; -- Alert admins of registrations
        "motd"; -- Send a message to users when they log in
        --"legacyauth"; -- Legacy authentication. Only used by some old clients and bots.
        --"s2s_bidi"; -- not yet implemented, have to wait for v0.12
        "bookmarks";
        "checkcerts";
        "cloud_notify";
        "csi_battery_saver";
        "default_bookmarks";
        "http_avatar";
        "idlecompat";
        "presence_cache";
        "smacks";
        "strict_https";
        --"pep_vcard_avatar"; -- not compatible with this version of pep, wait for v0.12
        "watchuntrusted";
        "webpresence";
        "external_services";
    }

-- only if you want to disable some modules
modules_disabled = {
    -- "offline"; -- Store offline messages
    -- "c2s"; -- Handle client connections
    -- "s2s"; -- Handle server-to-server connections
    -- "posix"; -- POSIX functionality, sends server to background, enables syslog, etc.
}

external_services = {
    {
        type = "stun",
        transport = "udp",
        host = "proxy.your.domain",
        port = 3478
    }, {
        type = "turn",
        transport = "udp",
        host = "proxy.your.domain",
        port = 3478,
        -- you could decide this now or come back later when you install coturn
        secret = "YOUR SUPER SECRET TURN PASSWORD"
    }
}

--- general global configuration
http_ports = { 5280 }
http_interfaces = { "*", "::" }

https_ports = { 5281 }
https_interfaces = { "*", "::" }

proxy65_ports = { 5000 }
proxy65_interfaces = { "*", "::" }

http_default_host = "xmpp.your.domain"
http_external_url = "https://xmpp.your.domain/"
-- or if you want to have it somewhere else, change this
https_certificate = "/etc/prosody/certs/xmpp.your.domain.crt"

hsts_header = "max-age=31556952"

cross_domain_bosh = true
--consider_bosh_secure = true
cross_domain_websocket = true
--consider_websocket_secure = true

trusted_proxies = { "127.0.0.1", "::1", "192.169.1.1" }

pep_max_items = 10000

-- this is disabled by default, and I keep it like this, depends on you
--allow_registration = true

-- you might want this options as they are
c2s_require_encryption = true
s2s_require_encryption = true
s2s_secure_auth = false
--s2s_insecure_domains = { "insecure.example" }
--s2s_secure_domains = { "jabber.org" }

-- where the certificates are stored (/etc/prosody/certs by default)
certificates = "certs"
checkcerts_notify = 7 -- ( in days )

-- rate limits on connections to the server, these are my personal settings, because by default they were limited to something like 30kb/s
limits = {
    c2s = {
        rate = "2000kb/s";
    };
    s2sin = {
        rate = "5000kb/s";
    };
    s2sout = {
        rate = "5000kb/s";
    };
}

-- again, this could be yourself, it is a jid
unlimited_jids = { "admin@your.domain" }

authentication = "internal_hashed"

-- if you don't want to use sql, change it to internal and comment the second line
-- since this is optional, i won't describe how to setup mysql or setup the user/database, that would be out of the scope for this entry
storage = "sql"
sql = { driver = "MySQL", database = "prosody", username = "prosody", password = "PROSODY USER SECRET PASSWORD", host = "localhost" }

archive_expires_after = "4w" -- configure message archive
max_archive_query_results = 20;
mam_smart_enable = true
default_archive_policy = "roster" -- archive only messages from users who are in your roster

-- normally you would like at least one log file of certain level, but I keep all of them, the default is only the info = "*syslog" one
log = {
    info = "*syslog";
    warn = "prosody.warn";
    error = "prosody.err";
    debug = "prosody.debug";
    -- "*console"; -- Needs daemonize=false
}

-- cloud_notify
push_notification_with_body = false -- Whether or not to send the message body to remote pubsub node
push_notification_with_sender = false -- Whether or not to send the message sender to remote pubsub node
push_max_errors = 5 -- persistent push errors are tolerated before notifications for the identifier in question are disabled
push_max_devices = 5 -- number of allowed devices per user

-- by default every user on this server will join these muc rooms
default_bookmarks = {
    { jid = "room@muc.your.domain", name = "The Room" };
    { jid = "support@muc.your.domain", name = "Support Room" };
}

-- could be your jid
untrusted_fail_watchers = { "admin@your.domain" }
untrusted_fail_notification = "Establishing a secure connection from $from_host to $to_host failed. Certificate hash: $sha1. $errors"

----------- Virtual hosts -----------
VirtualHost "your.domain"
    name = "Prosody"
    http_host = "xmpp.your.domain"

disco_items = {
    { "your.domain", "Prosody" };
    { "muc.your.domain", "MUC Service" };
    { "pubsub.your.domain", "Pubsub Service" };
    { "proxy.your.domain", "SOCKS5 Bytestreams Service" };
    { "vjud.your.domain", "User Directory" };
}


-- Multi-user chat
Component "muc.your.domain" "muc"
    name = "MUC Service"
    modules_enabled = {
        --"bob"; -- not compatible with this version of Prosody
        "muc_limits";
        "muc_mam"; -- message archive in muc, again, a placeholder
        "muc_mam_hints";
        "muc_mention_notifications";
        "vcard_muc";
    }

    restrict_room_creation = false

    muc_log_by_default = true
    muc_log_presences = false
    log_all_rooms = false
    muc_log_expires_after = "1w"
    muc_log_cleanup_interval = 4 * 60 * 60


-- Upload
Component "xmpp.your.domain" "http_upload"
    name = "Upload Service"
    http_host= "xmpp.your.domain"
    -- you might want to change this, these are numbers in bytes, so 10MB and 100MB respectively
    http_upload_file_size_limit = 1024*1024*10
    http_upload_quota = 1024*1024*100


-- Pubsub
Component "pubsub.your.domain" "pubsub"
    name = "Pubsub Service"
    pubsub_max_items = 10000
    modules_enabled = {
        "pubsub_feeds";
        "pubsub_text_interface";
    }

    -- personally i don't have any feeds configured
    feeds = {
        -- The part before = is used as PubSub node
        --planet_jabber = "http://planet.jabber.org/atom.xml";
        --prosody_blog = "http://blog.prosody.im/feed/atom.xml";
    }


-- Proxy
Component "proxy.your.domain" "proxy65"
    name = "SOCKS5 Bytestreams Service"
    proxy65_address = "proxy.your.domain"


-- Vjud, user directory
Component "vjud.your.domain" "vjud"
    name = "User Directory"
    vjud_mode = "opt-in"

You HAVE to read all of the configuration file, because there are a lot of things that you need to change to make it work with your server/domain. Test the configuration file with:

luac5.2 -p /etc/prosody/prosody.cfg.lua

Notice that by default prosody will look up certificates that look like sub.your.domain, but if you get the certificates like I do, you’ll have a single certificate for all subdomains, and by default it is in /etc/letsencrypt/live, which has some strict permissions. So, to import it you can run:

prosodyctl --root cert import /etc/letsencrypt/live

Ignore the complaining about not finding the subdomain certificates and note that you will have to run that command on each certificate renewal, to automate this, add the --deploy-hook flag to your automated Certbot renewal system; for me it’s a systemd timer with the following certbot.service:

[Unit]
Description=Let's Encrypt renewal

[Service]
Type=oneshot
ExecStart=/usr/bin/certbot renew --quiet --agree-tos --deploy-hook "systemctl reload nginx.service && prosodyctl --root cert import /etc/letsencrypt/live"

And if you don’t have it already, the certbot.timer:

[Unit]
Description=Twice daily renewal of Let's Encrypt's certificates

[Timer]
OnCalendar=0/12:00:00
RandomizedDelaySec=1h
Persistent=true

[Install]
WantedBy=timers.target

Also, go to the certs directory and make the appropriate symbolic links:

cd /etc/prosody/certs
ln -s your.domain.crt SUBDOMAIN.your.domain.crt
ln -s your.domain.key SUBDOMAIN.your.domain.key
...

That’s basically all the configuration that needs Prosody itself, but we still have to configure Nginx and Coturn before starting/enabling the prosody service.

Nginx configuration file

Since this is not an ordinary configuration file I’m going to describe this too. Your prosody.conf file should have the following location blocks under the main server block (the one that listens to HTTPS):

# HTTPS server block
server {
    root /var/www/prosody/;
    server_name xmpp.luevano.xyz muc.luevano.xyz pubsub.luevano.xyz vjud.luevano.xyz proxy.luevano.xyz;
    index index.html;

    # for extra https discovery (XEP-0256)
    location /.well-known/acme-challenge {
        allow all;
    }

    # bosh specific
    location /http-bind {
        proxy_pass  https://localhost:5281/http-bind;

        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_buffering off;
        tcp_nodelay on;
    }

    # websocket specific
    location /xmpp-websocket {
        proxy_pass https://localhost:5281/xmpp-websocket;

        proxy_http_version 1.1;
        proxy_set_header Connection "Upgrade";
        proxy_set_header Upgrade $http_upgrade;

        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 900s;
    }

    # general proxy
    location / {
        proxy_pass https://localhost:5281;

        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
    }
    ...
    # Certbot stuff
}
# HTTP server block (the one that certbot creates)
server {
    ...
}

Also, you need to add the following to your actual your.domain (this cannot be a subdomain) configuration file:

server {
    ...
    location /.well-known/host-meta {
        default_type 'application/xrd+xml';
        add_header Access-Control-Allow-Origin '*' always;
    }

    location /.well-known/host-meta.json {
        default_type 'application/jrd+json';
        add_header Access-Control-Allow-Origin '*' always;
    }
    ...
}

And you will need the following host-meta and host-meta.json files inside the .well-known/acme-challenge directory for your.domain (following my nomenclature: /var/www/yourdomaindir/.well-known/acme-challenge/).

For host-meta file:

<?xml version='1.0' encoding='utf-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
    <Link rel="urn:xmpp:alt-connections:xbosh"
        href="https://xmpp.your.domain:5281/http-bind" />
    <Link rel="urn:xmpp:alt-connections:websocket"
        href="wss://xmpp.your.domain:5281/xmpp-websocket" />
</XRD>

And host-meta.json file:

{
    "links": [
        {
            "rel": "urn:xmpp:alt-connections:xbosh",
                "href": "https://xmpp.your.domain:5281/http-bind"
        },
        {
            "rel": "urn:xmpp:alt-connections:websocket",
                "href": "wss://xmpp.your.domain:5281/xmpp-websocket"
        }
    ]
}

Remember to have your prosody.conf file symlinked (or discoverable by Nginx) to the sites-enabled directory. You can now restart your nginx service (and test the configuration, optionally):

nginx -t
systemctl restart nginx.service

Coturn

Coturn is the implementation of TURN and STUN server, which in general is for (at least in the XMPP world) voice support and external service discovery.

Install the coturn package:

pacman -S coturn

You can modify the configuration file (located at /etc/turnserver/turnserver.conf) as desired, but at least you need to make the following changes (uncomment or edit):

use-auth-secret
realm=proxy.your.domain
static-auth-secret=YOUR SUPER SECRET TURN PASSWORD

I’m sure there is more configuration to be made, like using SQL to store data and whatnot, but for now this is enough for me. Note that you may not have some functionality that’s needed to create dynamic users to use the TURN server, and to be honest I haven’t tested this since I don’t use this feature in my XMPP clients, but if it doesn’t work, or you know of an error or missing configuration don’t hesitate to contact me.

Start/enable the turnserver service:

systemctl start turnserver.service
systemctl enable turnserver.service

You can test if your TURN server works at Trickle ICE. You may need to add a user in the turnserver.conf to test this.

Wrapping up

At this point you should have a working XMPP server, start/enable the prosody service now:

systemctl start prosody.service
systemctl enable prosody.service

And you can add your first user with the prosodyctl command (it will prompt you to add a password):

prosodyctl adduser user@your.domain

You may want to add a compliance user, so you can check if your server is set up correctly. To do so, go to XMPP Compliance Tester and enter the compliance user credentials. It should have similar compliance score to mine:

Additionally, you can test the security of your server in IM Observatory, here you only need to specify your domain.name (not xmpp.domain.name, if you set up the SRV DNS records correctly). Again, it should have a similar score to mine:

You can now log in into your XMPP client of choice, if it asks for the server it should be xmpp.your.domain (or your.domain for some clients) and your login credentials you@your.domain and the password you chose (which you can change in most clients).

That’s it, send me a message david@luevano.xyz if you were able to set up the server successfully.

Este pedo fue gracias a que me reescribí la forma en la que pyssg maneja los templates, ahora uso el sistema de jinja en vez del cochinero que hacía antes.

Y pues nada más eso, aquí está el primer post y por supuesto acá está el link del RSS https://art.luevano.xyz/rss.xml.

También me puse a acomodar un servidor de XMPP el cual, en pocas palabras, es un protocolo de mensajería instantánea (y más) descentralizado, por lo cual cada quien puede hacer una cuenta en el servidor que quiera y conectarse con cuentas creadas en otro servidor… exacto, como con los correos electrónicos. Y esto está perro porque si tú tienes tu propio server, así como con uno de correo electrónico, puedes controlar qué características tiene, quiénes pueden hacer cuenta, si hay end-to-end encryption (o mínimo end-to-server), entre un montón de otras cosas.

Ahorita este server es SUMISO (compliant en español, jeje) para jalar con la app conversations y con la red social movim, pero realmente funcionaría con casi cualquier cliente de XMPP, amenos que ese cliente implemente algo que no tiene mi server. Y también acomodé un server de Matrix que es muy similar pero es bajo otro protocolo y se siente más como un discord/slack (al menos en el element), muy chingón también.

Si bien aún quedan cosas por hacer sobre estos dos servers que me acomodé (además de hacerles unas entradas para documentar cómo lo hice), quiero moverme a otra cosa que sería acomodar una sección de dibujos, lo cual en teoría es bien sencillo, pero como quiero poder automatizar la publicación de estos, quiero modificar un poco el pyssg para que jale chido para este pex.

Ya por último también quiero moverle un poco al CSS, porque lo dejé en un estado muy culerón y quiero meterle/ajustar unas cosas para que quede más limpio y medianamente bonito… dentro de lo que cabe porque evidentemente me vale verga si se ve como una página del 2000.

The solution? Write a new program “from scratch” in pYtHoN. Yes it is bloated, yes it is in its early stages, but it works just as I want it to work, and I’m pretty happy so far with the results and have with even more ideas in mind to “optimize” and generally clean my wOrKfLoW to post new blog entries. I even thought of using it for posting into a “feed” like gallery for drawings or pictures in general.

I called it pyssg, because it sounds nice and it wasn’t taken in the PyPi. It is just a terminal program that reads either a configuration file or the options passed as flags when calling the program.

It still uses Markdown files because I find them very easy to work with. And instead of just having a “header” and a “footer” applied to each parsed entry, you will have templates (generated with the program) for each piece that I thought made sense (idea taken from blogit): the common header and footer, the common header and footer for each entry and, header, footer and list elements for articles and tags. When parsing the Markdown file these templates are applied and stitched together to make a single HTML file. Also generates an RSS feed and the sitemap.xml file, which is nice.

It might sound convoluted, but it works pretty well, with of course room to improve; I’m open to suggestions, issue reporting or direct contributions here. BTW, it only works on Linux for now (and don’t think on making it work on windows, but feel free to do PR for the compatibility).

That’s it for now, the new RSS feed is available here: https://blog.luevano.xyz/rss.xml.

Note that this is mostly for personal use, so there’s no user/authentication control other than that of SSH. Also, most if not all commands here are run as root.

Prerequisites

I might get tired of saying this (it’s just copy paste, basically)… but you will need the same prerequisites as before (check my website and mail entries), with the extras:

• (Optional, if you want a “front-end”) A CNAME for “git” and (optionally) “www.git”, or some other name for your sub-domains.
• An SSL certificate, if you’re following the other entries, add a git.conf and run certbot --nginx to extend the certificate.

Git

Git is a version control system.

If not installed already, install the git package:

pacman -S git

On Arch Linux, when you install the git package, a git user is automatically created, so all you have to do is decide where you want to store the repositories, for me, I like them to be on /home/git like if git was a “normal” user. So, create the git folder (with corresponding permissions) under /home and set the git user’s home to /home/git:

mkdir /home/git
chown git:git /home/git
usermod -d /home/git git

Also, the git user is “expired” by default and will be locked (needs a password), change that with:

chage -E -1 git
passwd git

Give it a strong one and remember to use PasswordAuthentication no for ssh (as you should). Create the .ssh/authorized_keys for the git user and set the permissions accordingly:

mkdir /home/git/.ssh
chmod 700 /home/git/.ssh
touch /home/git/.ssh/authorized_keys
chmod 600 /home/git/.ssh/authorized_keys
chown -R git:git /home/git

Now is a good idea to copy over your local SSH public keys to this file, to be able to push/pull to the repositories. Do it by either manually copying it or using ssh‘s built in ssh-copy-id (for that you may want to check your ssh configuration in case you don’t let people access your server with user/password).

Next, and almost finally, we need to edit the git-daemon service, located at /usr/lib/systemd/system/ (called git-daemon@.service):

...
ExecStart=-/usr/lib/git-core/git-daemon --inetd --export-all --base-path=/home/git --enable=receive-pack
...

I just appended --enable=receive-pack and note that I also changed the --base-path to reflect where I want to serve my repositories from (has to match what you set when changing git user’s home).

Now, go ahead and start and enable the git-daemon socket:

systemctl start git-daemon.socket
systemctl enable git-daemon.socket

You’re basically done. Now you should be able to push/pull repositories to your server… except, you haven’t created any repository in your server, that’s right, they’re not created automatically when trying to push. To do so, you have to run (while inside /home/git):

git init --bare {repo_name}.git
chown -R git:git repo_name.git

Those two lines above will need to be run each time you want to add a new repository to your server (yeah, kinda lame… although there are options to “automate” this, I like it this way).

After that you can already push/pull to your repository. I have my repositories (locally) set up so I can push to more than one remote at the same time (my server, GitHub, GitLab, etc.); to do so, check this gist.

Cgit

Cgit is a fast web interface for git.

This is optionally since it’s only for the web application.

Install the cgit and fcgiwrap packages:

pacman -S cgit fcgiwrap

Now, just start and enable the fcgiwrap socket:

systemctl start fcgiwrap.socket
systemctl enable fcgiwrap.socket

Next, create the git.conf as stated in my nginx setup entry. Add the following lines to your git.conf file:

server {
    listen 80;
    listen [::]:80;
    root /usr/share/webapps/cgit;
    server_name {yoursubdomain}.{yourdomain};
    try_files $uri @cgit;

    location @cgit {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root/cgit.cgi;
        fastcgi_param PATH_INFO $uri;
        fastcgi_param QUERY_STRING $args;
        fastcgi_param HTTP_HOST $server_name;
        fastcgi_pass unix:/run/fcgiwrap.sock;
    }
}

Where the server_name line depends on you, I have mine setup to git.luevano.xyz and www.git.luevano.xyz. Optionally run certbot --nginx to get a certificate for those domains if you don’t have already.

Now, all that’s left is to configure cgit. Create the configuration file /etc/cgitrc with the following content (my personal options, pretty much the default):

css=/cgit.css
logo=/cgit.png

enable-http-clone=1
# robots=noindex, nofollow
virtual-root=/

repo.url={url}
repo.path={dir_path}
repo.owner={owner}
repo.desc={short_description}

...

Where you can uncomment the robots line to let web crawlers (like Google’s) to index your git web app. And at the end keep all your repositories (the ones you want to make public), for example for my dotfiles I have:

...
repo.url=.dots
repo.path=/home/git/.dots.git
repo.owner=luevano
repo.desc=These are my personal dotfiles.
...

Otherwise you could let cgit to automatically detect your repositories (you have to be careful if you want to keep “private” repos) using the option scan-path and setup .git/description for each repository. For more, you can check cgitrc(5).

By default you can’t see the files on the site, you need a highlighter to render the files, I use highlight. Install the highlight package:

pacman -S highlight

Copy the syntax-highlighting.sh script to the corresponding location (basically adding -edited to the file):

cp /usr/lib/cgit/filters/syntax-highlighting.sh /usr/lib/cgit/filters/syntax-highlighting-edited.sh

And edit it to use the version 3 and add --inline-css for more options without editing cgit‘s CSS file:

...
# This is for version 2
# exec highlight --force -f -I -X -S "$EXTENSION" 2>/dev/null

# This is for version 3
exec highlight --force --inline-css -f -I -O xhtml -S "$EXTENSION" 2>/dev/null
...

Finally, enable the filter in /etc/cgitrc configuration:

source-filter=/usr/lib/cgit/filters/syntax-highlighting-edited.sh

That would be everything. If you need support for more stuff like compressed snapshots or support for markdown, check the optional dependencies for cgit.

This configuration works for local users (users that appear in /etc/passwd), and does not use any type of SQL Database. And note that most if not all commands executed here are run with root privileges.

Prerequisites

Basically the same as with the website with Nginx and Certbot, with the extras:

• You will need a CNAME for “mail” and (optionally) “www.mail”, or whatever you want to call the sub-domains (although the RFC 2181 states that it NEEDS to be an A record, fuck the police).
• An SSL certificate. You can use the SSL certificate obtained following my last post using certbot (just create a mail.conf and run certbot --nginx again).
• Ports 25, 587 (SMTP), 465 (SMTPS), 143 (IMAP) and 993 (IMAPS) open on the firewall.

Postfix

Postfix is a “mail transfer agent” which is the component of the mail server that receives and sends emails via SMTP.

Install the postfix package:

pacman -S postfix

We have two main files to configure (inside /etc/postfix): master.cf (master(5)) and main.cf (postconf(5)). We’re going to edit main.cf first either by using the command postconf -e 'setting' or by editing the file itself (I prefer to edit the file).

Note that the default file itself has a lot of comments with description on what each thing does (or you can look up the manual, linked above), I used what Luke’s script did plus some other settings that worked for me.

Now, first locate where your website cert is, mine is at the default location /etc/letsencrypt/live/, so my certdir is /etc/letsencrypt/live/luevano.xyz. Given this information, change {yourcertdir} on the corresponding lines. The configuration described below has to be appended in the main.cf configuration file.

Certificates and ciphers to use for authentication and security:

smtpd_tls_key_file = {yourcertdir}/privkey.pem
smtpd_tls_cert_file = {yourcertdir}/fullchain.pem
smtpd_use_tls = yes
smtpd_tls_auth_only = yes
smtp_tls_security_level = may
smtp_tls_loglevel = 1
smtp_tls_CAfile = {yourcertdir}/cert.pem
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
tls_preempt_cipherlist = yes
smtpd_tls_exclude_ciphers = aNULL, LOW, EXP, MEDIUM, ADH, AECDH, MD5,
                DSS, ECDSA, CAMELLIA128, 3DES, CAMELLIA256,
                RSA+AES, eNULL

smtp_tls_CApath = /etc/ssl/certs
smtpd_tls_CApath = /etc/ssl/certs

smtpd_relay_restrictions = permit_sasl_authenticated, permit_mynetworks, defer_unauth_destination

Also, for the connection with dovecot, append the next few lines (telling postfix that dovecot will use user/password for authentication):

smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous

Specify the mailbox home (this is going to be a directory inside your user’s home containing the actual mail files):

home_mailbox = Mail/Inbox/

Pre-configuration to work seamlessly with dovecot and opendkim:

myhostname = {yourdomainname}
mydomain = localdomain
mydestination = $myhostname, localhost.$mydomain, localhost

milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = inet:127.0.0.1:8891
mailbox_command = /usr/lib/dovecot/deliver

Where {yourdomainname} is luevano.xyz in my case, or if you have localhost configured to your domain, then use localhost for myhostname (myhostname = localhost).

Lastly, if you don’t want the sender’s IP and user agent (application used to send the mail), add the following line:

smtp_header_checks = regexp:/etc/postfix/smtp_header_checks

And create the /etc/postfix/smtp_header_checks file with the following content:

/^Received: .*/     IGNORE
/^User-Agent: .*/   IGNORE

That’s it for main.cf, now we have to configure master.cf. This one is a bit more tricky.

First look up lines (they’re uncommented) smtp inet n - n - - smtpd, smtp unix - - n - - smtp and -o syslog_name=postfix/$service_name and either delete or uncomment them… or just run sed -i "/^\s*-o/d;/^\s*submission/d;/\s*smtp/d" /etc/postfix/master.cf as stated in Luke’s script.

Lastly, append the following lines to complete postfix setup and pre-configure for spamassassin.

smtp unix - - n - - smtp
smtp inet n - y - - smtpd
    -o content_filter=spamassassin
submission inet n - y - - smtpd
    -o syslog_name=postfix/submission
    -o smtpd_tls_security_level=encrypt
    -o smtpd_sasl_auth_enable=yes
    -o smtpd_tls_auth_only=yes
smtps inet n - y - - smtpd
    -o syslog_name=postfix/smtps
    -o smtpd_tls_wrappermode=yes
    -o smtpd_sasl_auth_enable=yes
spamassassin unix - n n - - pipe
    user=spamd argv=/usr/bin/vendor_perl/spamc -f -e /usr/sbin/sendmail -oi -f \${sender} \${recipient}

Now, I ran into some problems with postfix, one being smtps: Servname not supported for ai_socktype, to fix it, as Till posted in that site, edit /etc/services and add:

smtps 465/tcp
smtps 465/udp

Before starting the postfix service, you need to run newaliases first, but you can do a bit of configuration beforehand editing the file /etc/postfix/aliases. I only change the root: you line (where you is the account that will be receiving “root” mail). After you’re done, run:

postalias /etc/postfix/aliases
newaliases

At this point you’re done configuring postfix and you can already start/enable the postfix service:

systemctl start postfix.service
systemctl enable postfix.service

Dovecot

Dovecot is an IMAP and POP3 server, which is what lets an email application retrieve the mail.

Install the dovecot and pigeonhole (sieve for dovecot) packages:

pacman -S dovecot pigeonhole

On arch, by default, there is no /etc/dovecot directory with default configurations set in place, but the package does provide the example configuration files. Create the dovecot directory under /etc and, optionally, copy the dovecot.conf file and conf.d directory under the just created dovecot directory:

mkdir /etc/dovecot
cp /usr/share/doc/dovecot/example-config/dovecot.conf /etc/dovecot/dovecot.conf
cp -r /usr/share/doc/dovecot/example-config/conf.d /etc/dovecot

As Luke stated, dovecot comes with a lot of “modules” (under /etc/dovecot/conf.d/ if you copied that folder) for all sorts of configurations that you can include, but I do as he does and just edit/create the whole dovecot.conf file; although, I would like to check each of the separate configuration files dovecot provides I think the options Luke provides are more than good enough.

I’m working with an empty dovecot.conf file. Add the following lines for SSL and login configuration (also replace {yourcertdir} with the same certificate directory described in the Postfix section above, note that the < is required):

ssl = required
ssl_cert = <{yourcertdir}/fullchain.pem
ssl_key = <{yourcertdir}/privkey.pem
ssl_min_protocol = TLSv1.2
ssl_cipher_list = ALL:!RSA:!CAMELLIA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SHA1:!SHA256:!SHA384:!LOW@STRENGTH
ssl_prefer_server_ciphers = yes
ssl_dh = </etc/dovecot/dh.pem

auth_mechanisms = plain login
auth_username_format = %n
protocols = $protocols imap

You may notice we specify a file we don’t have under /etc/dovecot: dh.pem. We need to create it with openssl (you should already have it installed if you’ve been following this entry and the one for nginx). Just run (might take a few minutes):

openssl dhparam -out /etc/dovecot/dh.pem 4096

After that, the next lines define what a “valid user is” (really just sets the database for users and passwords to be the local users with their password):

userdb {
    driver = passwd
}

passdb {
    driver = pam
}

Next, comes the mail directory structure (has to match the one described in the Postfix section). Here, the LAYOUT option is important so the boxes are .Sent instead of Sent. Add the next lines (plus any you like):

mail_location = maildir:~/Mail:INBOX=~/Mail/Inbox:LAYOUT=fs
namespace inbox {
    inbox = yes

    mailbox Drafts {
        special_use = \Drafts
        auto = subscribe
        }

    mailbox Junk {
        special_use = \Junk
        auto = subscribe
        autoexpunge = 30d
        }

    mailbox Sent {
        special_use = \Sent
        auto = subscribe
        }

    mailbox Trash {
        special_use = \Trash
        }

    mailbox Archive {
        special_use = \Archive
        }
}

Also include this so Postfix can use Dovecot’s authentication system:

service auth {
    unix_listener /var/spool/postfix/private/auth {
        mode = 0660
        user = postfix
        group = postfix
        }
}

Lastly (for Dovecot at least), the plugin configuration for sieve (pigeonhole):

protocol lda {
    mail_plugins = $mail_plugins sieve
}

protocol lmtp {
    mail_plugins = $mail_plugins sieve
}

plugin {
    sieve = ~/.dovecot.sieve
    sieve_default = /var/lib/dovecot/sieve/default.sieve
    sieve_dir = ~/.sieve
    sieve_global_dir = /var/lib/dovecot/sieve/

Where /var/lib/dovecot/sieve/default.sieve doesn’t exist yet. Create the folders:

mkdir -p /var/lib/dovecot/sieve

And create the file default.sieve inside that just created folder with the content:

require ["fileinto", "mailbox"];
if header :contains "X-Spam-Flag" "YES" {
    fileinto "Junk";
}

Now, if you don’t have a vmail (virtual mail) user, create one and change the ownership of the /var/lib/dovecot directory to this user:

grep -q "^vmail:" /etc/passwd || useradd -m vmail -s /usr/bin/nologin
chown -R vmail:vmail /var/lib/dovecot

Note that I also changed the shell for vmail to be /usr/bin/nologin. After that, to compile the configuration file run:

sievec /var/lib/dovecot/sieve/default.sieve

A default.svbin file will be created next to default.sieve.

Next, add the following lines to /etc/pam.d/dovecot if not already present (shouldn’t be there if you’ve been following these notes):

auth required pam_unix.so nullok
account required pam_unix.so

That’s it for Dovecot, at this point you can start/enable the dovecot service:

systemctl start dovecot.service
systemctl enable dovecot.service

OpenDKIM

OpenDKIM is needed so services like G**gle (we don’t mention that name here [[[this is a meme]]]) don’t throw the mail to the trash. DKIM stands for “DomainKeys Identified Mail”.

Install the opendkim package:

pacman -S opendkim

Generate the keys for your domain:

opendkim-genkey -D /etc/opendkim -d {yourdomain} -s {yoursubdomain} -r -b 2048

Where you need to change {yourdomain} and {yoursubdomain} (doesn’t really need to be the sub-domain, could be anything that describes your key) accordingly, for me it’s luevano.xyz and mail, respectively. After that, we need to create some files inside the /etc/opendkim directory. First, create the file KeyTable with the content:

{yoursubdomain}._domainkey.{yourdomain} {yourdomain}:{yoursubdomain}:/etc/opendkim/{yoursubdomain}.private

So, for me it would be:

mail._domainkey.luevano.xyz luevano.xyz:mail:/etc/opendkim/mail.private

Next, create the file SigningTable with the content:

*@{yourdomain} {yoursubdomain}._domainkey.{yourdomain}

Again, for me it would be:

*@luevano.xyz mail._domainkey.luevano.xyz

And, lastly create the file TrustedHosts with the content:

127.0.0.1
::1
10.1.0.0/16
1.2.3.4/24
localhost
{yourserverip}
...

And more, make sure to include your server IP and something like subdomain.domainname.

Next, edit /etc/opendkim/opendkim.conf to reflect the changes (or rather, addition) of these files, as well as some other configuration. You can look up the example configuration file located at /usr/share/doc/opendkim/opendkim.conf.sample, but I’m creating a blank one with the contents:

Domain {yourdomain}
Selector {yoursubdomain}

Syslog Yes
UserID opendkim

KeyFile /etc/opendkim/{yoursubdomain}.private
Socket inet:8891@localhost

Now, change the permissions for all the files inside /etc/opendkim:

chown -R root:opendkim /etc/opendkim
chmod g+r /etc/postfix/dkim/*

I’m using root:opendkim so opendkim doesn’t complain about the {yoursubdomani}.private being insecure (you can change that by using the option RequireSafeKeys False in the opendkim.conf file, as stated here).

That’s it for the general configuration, but you could go more in depth and be more secure with some extra configuration.

Now, just start/enable the opendkim service:

systemctl start opendkim.service
systemctl enable opendkim.service

And don’t forget to add the following TXT records on your domain registrar (these examples are for Epik):

1. DKIM entry: look up your {yoursubdomain}.txt file, it should look something like:

{yoursubdomain}._domainkey IN TXT ( "v=DKIM1; k=rsa; s=email; "
    "p=..."
    "..." )  ; ----- DKIM key mail for {yourdomain}

In the TXT record you will place {yoursubdomain}._domainkey as the “Host” and "v=DKIM1; k=rsa; s=email; " "p=..." "..." in the “TXT Value” (replace the dots with the actual value you see in your file).

2. DMARC entry: just _dmarc.{yourdomain} as the “Host” and "v=DMARC1; p=reject; rua=mailto:dmarc@{yourdomain}; fo=1" as the “TXT Value”.

3. SPF entry: just @ as the “Host” and "v=spf1 mx a:{yoursubdomain}.{yourdomain} - all" as the “TXT Value”.

And at this point you could test your mail for spoofing and more.

SpamAssassin

SpamAssassin is just a mail filter to identify spam.

Install the spamassassin package (which will install a bunch of ugly perl packages…):

pacman -S spamassassin

For some reason, the permissions on all spamassassin stuff are all over the place. First, change owner of the executables, and directories:

chown spamd:spamd /usr/bin/vendor_perl/sa-*
chown spamd:spamd /usr/bin/vendor_perl/spam*
chwown -R spamd:spamd /etc/mail/spamassassin

Then, you can edit local.cf (located in /etc/mail/spamassassin) to fit your needs (I only uncommented the rewrite_header Subject ... line). And then you can run the following command to update the patterns and compile them:

sudo -u spamd sa-update
sudo -u spamd sa-compile

And since this should be run periodically, create the service spamassassin-update.service under /etc/systemd/system with the following content:

[Unit]
Description=SpamAssassin housekeeping
After=network.target

[Service]
User=spamd
Group=spamd
Type=oneshot

ExecStart=/usr/bin/vendor_perl/sa-update --allowplugins
SuccessExitStatus=1
ExecStart=/usr/bin/vendor_perl/sa-compile
ExecStart=/usr/bin/systemctl -q --no-block try-restart spamassassin.service

And you could also execute sa-learn to train spamassassin‘s bayes filter, but this works for me. Then create the timer spamassassin-update.timer under the same directory, with the content:

[Unit]
Description=SpamAssassin housekeeping

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

You can now start/enable the spamassassin-update timer:

systemctl start spamassassin-update.timer
systemctl enable spamassassin-update.timer

Next, you may want to edit the spamassassin service before starting and enabling it, because by default, it could spawn a lot of “childs” eating a lot of resources and you really only need one child. Append --max-children=1 to the line ExecStart=... in /usr/bin/systemd/system/spamassassin.service:

...
ExecStart=/usr/bin/vendor_perl/spamd -x -u spamd -g spamd --listen=/run/spamd/spamd.sock --listen=localhost --max-children=1
...

Finally, start and enable the spamassassin service:

systemctl start spamassassin.service
systemctl enable spamassassin.service

Wrapping up

We should have a working mail server by now. Before continuing check your journal logs (journalctl -xe --unit={unit}, where {unit} could be spamassassin.service for example) to see if there was any error whatsoever and try to debug it, it should be a typo somewhere (the logs are generally really descriptive) because all the settings and steps detailed here just (literally just finished doing everything on a new server as of the writing of this text) worked (((it just werks on my machine))).

Now, to actually use the mail service: first of all, you need a normal account (don’t use root) that belongs to the mail group (gpasswd -a user group to add a user user to group group) and that has a password.

Next, to actually login into a mail app/program/whateveryouwanttocallit, you will use the following settings, at least for thunderdbird(I tested in windows default mail app and you don’t need a lot of settings):

• * server: subdomain.domain (mail.luevano.xyz in my case)
• SMTP port: 587
• SMTPS port: 465 (I use this one)
• IMAP port: 143
• IMAPS port: 993 (again, I use this one)
• Connection/security: SSL/TLS
• Authentication method: Normal password
• Username: just your user, not the whole email (david in my case)
• Password: your user password (as in the password you use to login to the server with that user)

All that’s left to do is test your mail server for spoofing, and to see if everything is setup correctly. Go to DKIM Test and follow the instructions (basically click next, and send an email with whatever content to the email that they provide). After you send the email, you should see something like:

Finally, that’s actually it for this entry, if you have any problem whatsoever you can contact me.

As a side note, (((i use arch btw))) so everything here es aimed at an Arch Linux distro, and I’m doing everything on a VPS. Also note that most if not all commands here are executed with root privileges.

Prerequisites

You will need two things:

• A domain name (duh!). I got mine on Epik (affiliate link, btw).
  • With the corresponding A and AAA records pointing to the VPS’ IPs (“A” record points to the ipv4 address and “AAA” to the ipv6, basically). I have three records for each type: empty one, “www” and “*” for a wildcard, that way “domain.name”, “www.domain.name”, “anythingelse.domain.name” point to the same VPS (meaning that you can have several VPS for different sub-domains).
• A VPS or somewhere else to host it. I’m using Vultr (also an affiliate link).
  • With ssh already configured both on the local machine and on the remote machine.
  • Firewall already configured to allow ports 80 (HTTP) and 443 (HTTPS). I use ufw so it’s just a matter of doing ufw allow 80,443/tcp as root and you’re golden.
  • cron installed if you follow along (you could use systemd timers, or some other method you prefer to automate running commands every X time).

Nginx

Nginx is a web (HTTP) server and reverse proxy server.

You have two options: nginx and nginx-mainline. I prefer nginx-mainline because it’s the “up to date” package even though nginx is labeled to be the “stable” version. Install the package and enable/start the service:

pacman -S nginx-mainline
systemctl enable nginx.service
systemctl start nginx.service

And that’s it, at this point you can already look at the default initial page of Nginx if you enter the IP of your server in a web browser. You should see something like this:

As stated in the welcome page, configuration is needed, head to the directory of Nginx:

cd /etc/nginx

Here you have several files, the important one is nginx.conf, which as its name implies, contains general configuration of the web server. If you peek into the file, you will see that it contains around 120 lines, most of which are commented out and contains the welcome page server block. While you can configure a website in this file, it’s common practice to do it on a separate file (so you can scale really easily if needed for mor websites or sub-domains).

Inside the nginx.conf file, delete the server blocks and add the lines include sites-enabled/*; (to look into individual server configuration files) and types_hash_max_size 4096; (to get rid of an ugly warning that will keep appearing) somewhere inside the http block. The final nginx.conf file would look something like (ignoring the comments just for clarity, but you can keep them as side notes):

worker_processes 1;

events {
    worker_connections 1024;
}

http {
    include sites-enabled/*;
    include mime.types;
    default_type application/octet-stream;

    sendfile on;

    keepalive_timeout 65;

    types_hash_max_size 4096;
}

Next, inside the directory /etc/nginx/ create the sites-available and sites-enabled directories, and go into the sites-available one:

mkdir sites-available
mkdir sites-enabled
cd sites-available

Here, create a new .conf file for your website and add the following lines (this is just the sample content more or less):

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

    root /path/to/root/directory;
    server_name domain.name another.domain.name;
    index index.html anotherindex.otherextension;

    location /{
        try_files $uri $uri/ =404;
    }
}

That could serve as a template if you intend to add more domains.

Note some things:

• listen: we’re telling Nginx which port to listen to (IPv4 and IPv6, respectively).
• root: the root directory of where the website files (.html, .css, .js, etc. files) are located. I followed Luke’s directory path /var/www/some_folder.
• server_name: the actual domain to “listen” to (for my website it is: server_name luevano.xyz www.luevano.xyz; and for this blog is: server_name blog.luevano.xyz www.blog.luevano.xyz;).
• index: what file to serve as the index (could be any .html, .htm, .php, etc. file) when just entering the website.
• location: what goes after domain.name, used in case of different configurations depending on the URL paths (deny access on /private, make a proxy on /proxy, etc).
  • try_files: tells what files to look for.

Then, make a symbolic link from this configuration file to the sites-enabled directory:

ln -s /etc/nginx/sites-available/your_config_file.conf /etc/nginx/sites-enabled

This is so the nginx.conf file can look up the newly created server configuration. With this method of having each server configuration file separate you can easily “deactivate” any website by just deleting the symbolic link in sites-enabled and you’re good, or just add new configuration files and keep everything nice and tidy.

All you have to do now is restart (or enable and start if you haven’t already) the Nginx service (and optionally test the configuration):

nginx -t
systemctl restart nginx

If everything goes correctly, you can now go to your website by typing domain.name on a web browser. But you will see a “404 Not Found” page like the following (maybe with different Nginx version):

That’s no problem, because it means that the web server it’s actually working. Just add an index.html file with something simple to see it in action (in the /var/www/some_folder that you decided upon). If you keep seeing the 404 page make sure your root line is correct and that the directory/index file exists.

I like to remove the .html and trailing / on the URLs of my website, for that you need to add the following rewrite lines and modify the try_files line (for more: Sean C. Davis: Remove HTML Extension And Trailing Slash In Nginx Config):

server {
    ...
    rewrite ^(/.*)\.html(\?.*)?$ $1$2 permanent;
    rewrite ^/(.*)/$ /$1 permanent;
    ...
    try_files $uri/index.html $uri.html $uri/ $uri =404;
    ...

Certbot

Certbot is what provides the SSL certificates via Let’s Encrypt.

The only “bad” (bloated) thing about Certbot, is that it uses python, but for me it doesn’t matter too much. You may want to look up another alternative if you prefer. Install the packages certbot and certbot-nginx:

pacman -S certbot certbot-nginx

After that, all you have to do now is run certbot and follow the instructions given by the tool:

certbot --nginx

It will ask you for some information, for you to accept some agreements and the names to activate HTTPS for. Also, you will want to “say yes” to the redirection from HTTP to HTTPS. And that’s it, you can now go to your website and see that you have HTTPS active.

Now, the certificate given by certbot expires every 3 months or something like that, so you want to renew this certificate every once in a while. Using cron, you can do this by running:

crontab -e

And a file will be opened where you need to add a new rule for Certbot, just append the line: 1 1 1 * * certbot renew (renew on the first day of every month) and you’re good. Alternatively use systemd timers as stated in the Arch Linux Wiki.

That’s it, you now have a website with SSL certificate.

Ya lo único que queda es cambiar un poco el formato del blog (y de la página en general), porque en un momento de desesperación puse todo el texto en justificado y pues no se ve chido siempre, entonces queda corregir eso. Y aunque me tomó más tiempo del que quisiera, así nomás quedó, diría un cierto personaje.

El ssg modificado está en mis dotfiles (o directamente aquí).

Por último, también quité las extensiones .html de las URLs, porque se veía bien pitero, pero igual los links con .html al final redirigen a su link sin .html, así que no hay rollo alguno.

At the moment, I’m not satisfied because there’s no automatic date insertion into the 1) html file, 2) the blog post itself and 3) the listing system in the blog homepage (and there’s also the problem with the ordering of the entries…). And all of this just because I didn’t want to use Luke’s solution (don’t really like that much how he handles the scripts… but they just work).

Hopefully, for tomorrow all of this will be sorted out and I’ll have a working blog system.