Posts tagged with “Debian”

Grand Opening: Istanza Italiana Chatmail per DeltaChat

Written by Simone

Istanza Italiana Chatmail per DeltaChat

Annunciazione, annunciazione! [cit. per i diversamente giovani]

Da qualche giorno è nata l'istanza Italiana Chatmail per DeltaChat.. Arabo?

Delta Chat è un’app di messaggistica che funziona tramite e-mail

Chatmail è un server di posta "particolare", progettato per l'utilizzo con DeltaChat

Il nostro amico Federico, in arte Fede 😀 ha deciso di sponsorizzare il progetto con un VPS dedicato, sul quale Io ho poi provveduto ad installare il servizio Chatmail, la cui componente web può essere visitata al seguente indirizzo: https://chatmail.woodpeckersnest.space/

Tramite l'appena citato sito web potete registrare il vostro account mail anonimo "chatmail" da usare in DeltaChat: è sufficiente scansionare il QR code con l'app di DeltaChat e sarete immediatamente loggati sul server. Tutte le future conversazioni saranno esclusivamente cifrate e2ee.

A questo punto dovrete aggiungere qualche amico o unirvi ad un gruppo di altre persone. Il QR è sempre la via per fare tutto ciò.. Ed a questo proposito lascio qui il link del QR ed il QR stesso, utili per entrare nel gruppo (più o meno) ufficiale dell'istanza, dove troverete me, Fede, Andrea, darhma, ndo, Mario etc..

https://i.delta.chat/#6FE1642916908F1AC9CC7557CC99CF5DDB92043C&a=groupsbot@testrun.org&g=Amici Delta Cchino δ🦃️&x=g9GMUqKwvgB&i=0qBMdsGrq7n&s=_tiLU2IcUrs

Ah, e non dimenticate di leggere anche la pagina sulla privacy Tutto il sito verrà a breve tradotto in Italiano (grazie Andrea).. Soon Done!!

Guida

Si riportano qui i comandi base per installare il proprio server chatmail autogestito. Per tutte le altre specifiche, comandi, suggerimenti e dettagli vari si prega di far riferimento alla guida ufficiale https://github.com/deltachat/chatmail/blob/main/README.md

Installazione del tuo server chatmail

Usiamo chat.esempio.org come dominio chatmail nei passi seguenti. Sostituiscilo col tuo dominio.

  1. Installa il comando cmdeploy in virtualenv:
 git clone https://github.com/deltachat/chatmail
 cd chatmail
 scripts/initenv.sh
  1. Crea il file di configurazione chatmail.ini:

scripts/cmdeploy init chat.esempio.org # <-- usa il tuo dominio

  1. Imposta prima i record DNS per il tuo dominio chatmail, secondo i suggerimenti proposti da cmdeploy init

Verifica che l'accesso SSH come root funzioni:

ssh root@chat.esempio.org # <-- usa il tuo dominio

  1. Installalo sul tuo server remoto:

scripts/cmdeploy run

Questo script inoltre ti mostrerà dei record DNS aggiuntivi che dovresti configurare sul tuo provider (potrebbe passare del tempo perché siamo resi pubblici).

Le porte da aprire sul server sono: 25, 80, 143, 443, 465, 587, 993.

Consigli per l'installazione

Bene, per finire vorrei lasciare qualche consiglio sull'installazione di Chatmail, sperando che qualcun altro decida di creare un'altra istanza in futuro.

La guida nel README del repository Github è già sufficiente, ma un paio di appunti vorrei farli:

  • Innanzi tutto in caso la cosa risultasse poco chiara, per installare Chatmail su un VPS remoto, avremo bisogno di una macchina locale dalla quale fare il "deploy".

Io ho usato una Virtual Machine Debian 12 installata in Windows 10 tramite WSL, e come destinazione per il server Chatmail abbiamo di nuovo scelto una Debian 12.. Debian rocks!

  • Seconda nota: quando comincerete a lanciare i vari script/cmdeploy verso il server remoto vi verrà chiesta una password.. e qui casca l'asino.

La password che il servizio si aspetta è la "passphrase" della chiave SSH dell'utente root sul VPS remoto E NON la password dell'utente root. Va da sè che dovrete aggiungere una chiave SSH prima di cominciare il deploy.

Ultima cosa da sapere, anche se è accennata anche nel README, è che dopo il comando scripts/cmdeploy run verranno stampati a schermo tutti i record DNS, necessari al server di posta, che andranno inseriti nel pannello di controllo del vostro registrar. Niente di nuovo direi, visto che per cominciare l'installazione viene già chiesto di registrare il dominio principale.. Tuttavia preparatevi a configurare record TXT, SRV, CAA, MX.

Vi lascio con un paio di comandi utili a fine installazione:

journalctl -u postfix.service (leggere i log del server di posta)

Sostituite il servizio per leggere ad esempio i log degli accessi SSH

journalctl -u ssh.service

mailq (leggere la coda dei messaggi non ancora recapitati - per qualsiasi motivo)

La configurazione del webserver sta dentro /etc/nginx/nginx.conf La directory dove sono ospitati i file veri e proprio è la classica /var/www/html/

Ultima cosa: verificate che il vostro gestore VPS lasci aperta la porta 25, o se vada richiesto espressamente, come ad esempio succede per IONOS e Digital Oceans.

Si ringraziano tutti i DeltaCchini 😘

FIN!

self-hosting di ente (photos)

Written by Simone

L'applicazione "photos" della società "ente" è una alternativa alla più rinomata Google Foto, ossia un'app che conserva le vostre immagini (anche chiamate "memories", ricordi) sul cloud. A seconda del profilo scelto potrete immagazzinare tot dati a determinati prezzi - a dire il vero esiste anche un piano di prova per un anno con 1GB di spazio, che naturalmente non soddisferà nessuno.

Da qualche settimana però ente ha deciso di rilasciare come codice aperto la sua versione del server, che può essere liberamente fatto girare sulla propria macchina insieme alle relative app (photos per Android, web app), tramite alcune modifiche alle stesse.

Io e lorenzo (@lorenzo@fedi.bobadin.icu) ci siamo allora messi in gioco per avere delle istanze personali di ente server ed uno spazio in cloud dove poter caricare il materiale (l'Object Storage S3 che abbiamo utilizzato è totalmente sponsorizzato da lorenzo, il quale ringrazio)

Sin da subito abbiamo avuto diverse difficoltà, perché la documentazione, ahimè, è divisa tra blog e repository github, con molte incosistenze e diverse lacune. Al momento però siamo riusciti ad avere un servizio funzionante con l'app photos; per la parte web invece ci sono ancora alcuni problemi.

In questo post riassumerò le operazioni effettuate.

Lo stack docker per i servizi ente è costituito da:

  • server (museum)
  • database pgsql
  • minio (object storage locale)
  • socat

Per utilizzare un S3 locale alla vostra macchina avete bisogno di tutti questi componenti, mentre utilizzando uno storage S3 esterno, basteranno solamente il server museum ed un database (docker o di sistema) Nella seguente guida parlerò solo di un sistema Debian con database installato localmente (quindi niente immagine docker) e S3 esterno (quindi niente minio/socat)

La guida di riferimento seguita è questa: https://github.com/ente-io/ente/blob/main/server/docs/docker.md e di seguito elencherò solo le modifiche apportate.

Utilizzeremo solo 3 file: compose.yaml e museum.yaml che andranno creati nella directory "ente", come da guida linkata sopra, mentre il percorso per credentials.yaml sarà scripts/compose/credentials.yaml, sempre all'interno della dir base "ente".

compose.yaml

Il file compose.yaml sarà il seguente:

services:
  museum:
    image: ghcr.io/ente-io/server
    restart: always
    network_mode: "host"
    environment:
      # Pass-in the config to connect to the DB and MinIO
      ENTE_CREDENTIALS_FILE: /credentials.yaml
    volumes:
      - custom-logs:/var/logs
      - ./museum.yaml:/museum.yaml:ro
      - ./scripts/compose/credentials.yaml:/credentials.yaml:ro
      - ./data:/data:ro

volumes:
  custom-logs:

Il network è stato cambiato da "internal" ad "host" per permettere al server ente nel contenitore docker di dialogare col database in localhost sul sistema operativo. La porta esposta sul sistema operativo non può essere modificata con network=host (se avviate il container con qualsiasi porta specificata otterrete un warning - Published ports are discarded when using host network mode), quindi è stata rimossa dal compose. Assicuratevi che la "8080" non sia già in uso da altri applicativi:

sudo netstat -lnp | grep 8080

museum.yaml

Il file museum.yaml, ridotto all'essenziale (più commenti), sarà il seguente:

# Configuring museum
# ------------------
#
#
# By default, museum logs to stdout when running locally. Specify this path to
# get it to log to a file instead.
#
# It must be specified if running in a non-local environment.
log-file: ""

# HTTP connection parameters
http:
    # If true, bind to 443 and use TLS.
    # By default, this is false, and museum will bind to 8080 without TLS.
    # use-tls: true

# Key used for encrypting customer emails before storing them in DB
#
# To make it easy to get started, some randomly generated values are provided
# here. But if you're really going to be using museum, please generate new keys.
# You can use `go run tools/gen-random-keys/main.go` for that.
key:
    encryption: <chiave>
    hash: <chiave>
    
# JWT secrets
#
# To make it easy to get started, a randomly generated values is provided here.
# But if you're really going to be using museum, please generate new keys. You
# can use `go run tools/gen-random-keys/main.go` for that.
jwt:
    secret: <chiave>

# SMTP configuration (optional)
#
# Configure credentials here for sending mails from museum (e.g. OTP emails).
#
# The smtp credentials will be used if the host is specified. Otherwise it will
# try to use the transmail credentials. Ideally, one of smtp or transmail should
# be configured for a production instance.
smtp:
    host:
    port:
    username:
    password:

# Various low-level configuration options
internal:
    # If false (the default), then museum will notify the external world of
    # various events. E.g, email users about their storage being full, send
    # alerts to Discord, etc.
    #
    # It can be set to true when running a "read only" instance like a backup
    # restoration test, where we want to be able to access data but otherwise
    # minimize external side effects.
    silent: false
    # If provided, this external healthcheck url is periodically pinged.
    health-check-url:
    # Hardcoded verification codes, useful for logging in when developing.
    #
    # Uncomment this and set these to your email ID or domain so that you don't
    # need to peek into the server logs for obtaining the OTP when trying to log
    # into an instance you're developing on.
    #hardcoded-ott:
    #     emails:
    #         - "example@example.org,123456"
    #     # When running in a local environment, hardcode the verification code to
    #     # 123456 for email addresses ending with @example.org
    #     local-domain-suffix: "@example.org"
    #     local-domain-value: 123456
    # List of user IDs that can use the admin API endpoints.
    admins: []

# Replication config
#
# If enabled, replicate each file to 2 other data centers after it gets
# successfully uploaded to the primary hot storage.
replication:
    enabled: false
    # The Cloudflare worker to use to download files from the primary hot
    # bucket. Must be specified if replication is enabled.
    worker-url:
    # Number of go routines to spawn for replication
    # This is not related to the worker-url above.
    # Optional, default value is indicated here.
    worker-count: 6
    # Where to store temporary objects during replication v3
    # Optional, default value is indicated here.
    tmp-storage: tmp/replication

# Configuration for various background / cron jobs.
jobs:
    cron:
        # Instances run various cleanup, sending emails and other cron jobs. Use
        # this flag to disable all these cron jobs.
        skip: false
    remove-unreported-objects:
        # Number of go routines to spawn for object cleanup
        # Optional, default value is indicated here.
        worker-count: 1
    clear-orphan-objects:
        # By default, this job is disabled.
        enabled: false
        # If provided, only objects that begin with this prefix are pruned.
        prefix: ""
        
stripe:
    path:
        success: ?status=success&session_id={CHECKOUT_SESSION_ID}
        cancel: ?status=fail&reason=canceled

Come (quasi) scritto nel commento, per generare chiavi e segreto jwt bisognerà clonare in una directory a piacere il server ente, entrare nella directory "server" e semplicemente digitare il comando:

go run tools/gen-random-keys/main.go

La configurazione di queste chiavi, come pure tutta la sezione SMTP è opzionale; se decidete di compilare i campi per smtp, la vostra istanza sarà di fatto aperta alle registrazioni utente, cosa che probabilmente non vorrete fare.

Se decidete di continuare, avrete bisogno di installare "go" in Debian; oppure se siete in fase di test utilizzate le chiavi di default presenti nel file: https://github.com/ente-io/ente/blob/main/server/configurations/local.yaml#L151-L161

sudo apt install golang-1.19-go

Altra dipendenza prima di eseguire il comando è: libsodium

sudo apt install libsodium23:amd64 libsodium-dev:amd64

credentials.yaml

Ultimo file di configurazione è credentials.yaml

db:
    host: localhost
    port: 5432
    name: ente_db
    user: ente
    password: password
    
s3:
    are_local_buckets: false
    use_path_style_urls: true
    b2-eu-cen:
        key: <key>
        secret: <secret>
        endpoint: link_allo_storage
        region: eu-central-2
        bucket: <bucket_name>

Questo file si compone dei dati del database postgres e dello storage esterno S3: la modifica essenziale per il databse è "host", che andrà impostato su "localhost"; per S3 è importante cambiare solamente "key", "secret", "endpoint" e "bucket"; lasciate gli altri valori intatti o avrete problemi di connessione; da quello che ho capito sono hard-coded.

E' giunta l'ora di creare il database:

sudo su - postgres

psql

CREATE DATABASE ente_db;
CREATE USER ente WITH PASSWORD 'sekret';
GRANT ALL PRIVILEGES ON DATABASE ente_db TO ente;
ALTER DATABASE ente_db OWNER TO ente;

Modificate i nome di db, user e password a piacere (basta che siano uguali a quelli specificati in crednetials.yaml). Battete "enter" ad ogni riga. Postgres risponderà ad ogni comando con una conferma circa le operazioni eseguite.

Per uscire dalla cli di pg:

\quit

Per tornare al vostro utente:

exit

E lanciamo docker:

sudo docker compose up

Controllate i log, l'importante è che il database sia correttamente connesso; comparirà qualche errore in seguito, ma se il server rimane in esecuzione senza fermarsi dovrebbe essere tutto a posto.

Il server rimane in ascolto su localhost, porta 8080. Per poter raggiungerlo dall'esterno bisognerà configurare un reverse proxy nel vostro web server - Apache, nginx o caddy.

Lascio qui una configurazione di esempio per nginx:

map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
}
server {
    server_name sottodominio.dominio.tld;

    access_log /var/log/nginx/sottodominio/access.log;
    error_log /var/log/nginx/sottodominio/error.log;

    location / {
           proxy_pass http://[::1]:8080;
           proxy_set_header Host $host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
    }

    listen [::]:443 ssl http2;
    listen 443 ssl http2;
    ssl_certificate /etc/letsencrypt/live/sottodominio.dominio.tld/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/sottodominio.dominio.tld/privkey.pem;
}

La mia configurazione prevede supporto a IPv6; in caso voleste usare solamente IPv4, cambiate l'host in proxy_pass e togliete il listen [::]:443 ssl http2;

Ora, scaricate l'app ente photos dal loro repository github, poiché quella sul Play Store non è stata ancora aggiornata coi cambiamenti necessari al funzionamento su server self-hosted.

Avviata l'app sul telefono, tappate 7 o più volte in rapida successione sulla schermata di avvio finché non apparirà un campo di testo: riempitelo con l'indirizzo che avete configurato per il reverse proxy:

https://sottodominio.dominio.tld

Connettete e dovreste vedere un messaggio di conferma se tutto è andato bene, con sotto scritto l'indirizzo a cui siete collegati.

Una volta nell'app dovrete registrare un account. Inserite email e password ed alla schermata successiva vi verrà chiesto un codice OTP di conferma. L'app vi dirà che il codice è stato inviato alla vostra casella email, ma questo è vero solo nel caso abbiate impostato i campi per SMTP, come spiegato sopra (altra cosa da sapere è che il mittente delle email è ente <verification@ente.io>, quindi non vi spaventate). In caso contrario il codice OTP può essere recuperato facilmente dai log docker che staranno scorrendo nel terminale. verrà scritto qualcosa come "OTT per id sfilza di caratteri: e qui un codice di 6 cifre". Ricopiatelo nell'app e proseguite.

Dopo alcuni istanti per il setup della crittografia arriverà una schermata con una passphrase che dovrete conservare in luogo sicuro, per il ripristino dell'account in caso di perdita della password di accesso.

Scegliete ora le cartelle sul vostro telefono di cui fare backup e cominciate!

Se lo storage è connesso correttamente vedrete i vostri ricordi in caricamento con un numero progressivo; in caso contario, se qualcosa non sta funzionando, sulle vostre foto rimarrà una nuvoletta barrata, che indica il mancato caricamento. Se questo fosse il caso, andate di nuovo a leggere i log del container per eventuali errori.

Sbloccare il limite di 1GB su profilo di prova

Nonostante stiamo usando un server personale, noterete che l'app photos mostra ancora i profili/sottoscrizioni a pagamento dell'app originale.

Per poter sbloccare lo storage pressoché infinito, dopo aver selezionato il profilo di prova ad 1GB, bisognerà utilizzare uno strumento a riga di comando - ente cli.

E' necessario installare alcuni pacchetti, generalmente utilizzati in versione Linux Desktop e lanciare alcuni comandi per attivare la "secret service dbus interface", necessaria alla cli ente.

sudo apt install gnome-keyring libsecret dbus-x11

Eseguite questi comandi, copio incollo perché è inutile soffermarsi oltre:

eval "$(dbus-launch --sh-syntax)"

mkdir -p ~/.cache
mkdir -p ~/.local/share/keyrings # where the automatic keyring is created

# 1. Create the keyring manually with a dummy password in stdin
eval "$(printf '\n' | gnome-keyring-daemon --unlock)"

# 2. Start the daemon, using the password to unlock the just-created keyring:
eval "$(printf '\n' | /usr/bin/gnome-keyring-daemon --start)"

A questo punto l'ambiente è pronto. Scaricate ente cli dal repository github: https://github.com/ente-io/ente/releases/tag/cli-v0.1.13

Nel nostro caso, per Debian x64, scaricheremo: https://github.com/ente-io/ente/releases/download/cli-v0.1.13/ente-cli-v0.1.13-linux-amd64.tar.gz

Estraete il contenuto della "tarpalla" in una directory a piacere, magari in ~/bin Dentro alla stessa directory, create un file chiamato config.yaml, contenente le seguenti righe:

endpoint:
    api: "http://localhost:8080"

Dalla stessa directory, lanciamo ./ente help per verificarne il corretto funzionamento e.. leggere l'help 😀

Per prima cosa aggiungiamo il nostro utente creato precedentemente:

./ente account add

Vi verrano chieste alcune info, in particolare indirizzo email con cui vi siete registrati su photos, relativa password e una dir dove poter esportare le vostre immagini (la dir deve esistere prima di poterla specificare).

Una volta aggiunto l'account, digitate:

./ente account list

E dovreste vedere le info del vostro account, tra le quali un "ID". Copiatelo ed aprite nuovamente il file "museum.yaml" visto in precedenza. In questa sezione modificate la voce "admins" inserendo tra le parentesi quadre l'ID utente copiato. Salvate e riavviate il contenitore docker; da questo momento siete admin dell'istanza.

internal:
    # If false (the default), then museum will notify the external world of
    # various events. E.g, email users about their storage being full, send
    # alerts to Discord, etc.
    #
    # It can be set to true when running a "read only" instance like a backup
    # restoration test, where we want to be able to access data but otherwise
    # minimize external side effects.
    silent: false
    # If provided, this external healthcheck url is periodically pinged.
    health-check-url:
    # Hardcoded verification codes, useful for logging in when developing.
    #
    # Uncomment this and set these to your email ID or domain so that you don't
    # need to peek into the server logs for obtaining the OTP when trying to log
    # into an instance you're developing on.
    #hardcoded-ott:
    #     emails:
    #         - "example@example.org,123456"
    #     # When running in a local environment, hardcode the verification code to
    #     # 123456 for email addresses ending with @example.org
    #     local-domain-suffix: "@example.org"
    #     local-domain-value: 123456
    # List of user IDs that can use the admin API endpoints.
    admins: []

Torniamo alla cli:

./ente admin list-users

Dovreste vedere voi stessi e leggere che siete effettivamente admin.

Ultimo comando per sbloccare lo storage da 100TB e abbiamo finito:

./ente admin update-subscription -u email@vostrodominio.tld --no-limit true

Obsolete major version 13 (uh oh!)

Written by Simone

A package configuration text screen by Debian apt which is informing the user that postgresql packages are old and need to be upgraded.

Yesterday after installing some new packages I was greeted by this kind reminder 😀

I began stopping services which use a Postgresql database and even forgot about Dendrite.. Nothing so bad as I imagined, tho, just run the suggested commands and everything got up and running in a few minutes.

Debian rocks! 😍

Notes

Written by Simone

I'll update this post whenever I see fits, A.K.A. when I have other bits of information which don't require a whole post.

Operations on files and directories

Move files and directories to the current/parent directory in Linux

Current dir

find . -type f -exec mv {} . \;

Parent dir

find . -type f -exec mv {} .. \;

Recursive chmod on files and dirs

To change all the directories to 755 (-rwxr-xr-x):

find /var/www/blog -type d -exec chmod 755 {} \;

To change all the files to 644 (-rw-r--r--):

find /var/www/blog -type f -exec chmod 644 {} \;

Certbot common commands

Register single domain:

certbot certonly --standalone -d domain.tld --dry-run

Renew single domain:

certbot renew --cert-name domain.tld --dry-run
  • Remove “–dry-run” when ok.

Revoke certificate:

certbot revoke --cert-path /etc/letsencrypt/archive/${YOUR_DOMAIN}/cert1.pem

Check certificate's expiry date:

cat /etc/letsencrypt/live/domain.tld/cert.pem | openssl x509 -noout -enddate

GIT

To reset your git repository to given commit id, do:

git reset --hard <commit-id>
git push origin master --force

Ignoring files that are already tracked

git update-index --assume-unchanged <your file here>

Delta Chat Mail sieve

require ["fileinto"];
# rule:[DeltaChat]
if header :contains "Chat-Version" "1.0"
{
	fileinto "DeltaChat";
	stop;
}

Postfix mail queue

To view postfix mail queue in case of problems and remove a particular message from it, do as follows:

# mailq

-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
6DCF32201B*    4824 Thu Oct 19 22:54:44  roughnecks@woodpeckersnest.eu
                                         debian@spacenet.it

-- 4 Kbytes in 1 Request.
# postsuper -d 6DCF32201B

postsuper: 6DCF32201B: removed
postsuper: Deleted: 1 message

Check Preferred Outgoing IP (when multiple are set on <interface>)

curl ifconfig.me

The correct command to add a new Linux user (in this case without a shell)

adduser --shell /usr/sbin/nologin <username>

I always forget which command is the complete one, useradd or adduser

Thunderbird Autoconfiguration

Written by Simone

Set up Thunderbird autoconfiguration for my lil mail server. Working good.

nginx config:

server {
        listen [::]:443 ssl http2;
        server_name woodpeckersnest.eu;

        ssl_certificate /etc/letsencrypt/live/woodpeckersnest.eu/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/woodpeckersnest.eu/privkey.pem;

        root /var/www/mail/;
        location / {
                try_files /.well-known/autoconfig/mail/config-v1.1.xml =404;
        }

    access_log /var/log/nginx/autoconfig.log;
    error_log /var/log/nginx/autoconfig_error.log;
}

config-v1.1.xml

<?xml version="1.0"?>
<clientConfig version="1.1">
    <emailProvider id="woodpeckersnest.eu">
      <domain>woodpeckersnest.eu</domain>

      <displayName>Woodpeckers Mail</displayName>
      <displayShortName>woodpeckers</displayShortName>

      <!-- type=
           "imap": IMAP
           "pop3": POP3
           -->

      <incomingServer type="imap">
         <hostname>woodpeckersnest.eu</hostname>
         <port>993</port>
           <!-- "plain": no encryption
                "SSL": SSL 3 or TLS 1 on SSL-specific port
                "STARTTLS": on normal plain port and mandatory upgrade to TLS via STARTTLS
                -->
         <socketType>SSL</socketType>
         <username>%EMAILLOCALPART%</username>
            <!-- Authentication methods:
                 "password-cleartext",
                          Send password in the clear
                          (dangerous, if SSL isn't used either).
                          AUTH PLAIN, LOGIN or protocol-native login.
                 "password-encrypted",
                           A secure encrypted password mechanism.
                           Can be CRAM-MD5 or DIGEST-MD5. Not NTLM.
                 "NTLM":
                           Use NTLM (or NTLMv2 or successors),
                           the Windows login mechanism.
                 "GSSAPI":
                           Use Kerberos / GSSAPI,
                           a single-signon mechanism used for big sites.
                 "client-IP-address":
                           The server recognizes this user based on the IP address.
                           No authentication needed, the server will require no username nor password.
                 "TLS-client-cert":
                           On the SSL/TLS layer, the server requests a client certificate and the client sends one (possibly after letting the user select/confirm one), if available. (Not yet supported by Thunderbird)
                 "OAuth2":
                           OAuth2. Works only on specific hardcoded servers, please see below. Should be added only as second alternative.
                 "none":
                           No authentication
                 -->
         <authentication>password-cleartext</authentication>
      </incomingServer>


		   
      <outgoingServer type="smtp">
         <hostname>woodpeckersnest.eu</hostname>
         <port>587</port>
         <socketType>STARTTLS</socketType> <!-- see <incomingServer> -->
         <username>%EMAILLOCALPART%</username> <!-- if smtp-auth -->
            <!-- smtp-auth (RFC 2554, 4954) or other auth mechanism.
                 For values, see incoming.
                 Additional options here:
                 "SMTP-after-POP":
                     authenticate to incoming mail server first
                     before contacting the smtp server.
                  Compatibility note: Thunderbird 3.0 accepts only "plain",
                  "secure", "none", and "smtp-after-pop".
                  It will ignore the whole XML file, if other values are given.
            -->
         <authentication>password-cleartext</authentication>
            <!-- If the server makes some additional requirements beyond
                 <authentication>.
                 "client-IP-address": The server is only reachable or works,
                     if the user is in a certain IP network, e.g.
                     the dialed into the ISP's network (DSL, cable, modem) or
                     connected to a company network.
                     Note: <authentication>client-IP-address</>
                     means that you may use the server without any auth.
                     <authentication>password-cleartext</> *and*
                     <restriction>client-IP-address</> means that you need to
                     be in the correct IP network *and* (should) authenticate.
                     Servers which do that are highly discouraged and
                     should be avoided, see {{bug|556267}}.
                Not yet implemented. Spec (element name?) up to change.
            -->
         <!-- remove the following and leave to client/user? -->
         <addThisServer>true</addThisServer>
         <useGlobalPreferredServer>true</useGlobalPreferredServer>
      </outgoingServer>

    </emailProvider>

    <!-- This allows to access the webmail service of the provider.
         The URLs are loaded into a standard webbrowser for the user.
         Specifying this is optional. -->
    <webMail>
      <!-- Webpage where the user has to log in manually by entering username
           and password himself.
           HTTPS required. -->
      <loginPage url="https://webmail.woodpeckersnest.space/" />

      <!-- Same as loginAutomaticDOM, but the website makes checks that
           the user comes from the login page. So, open the login page
           in the browser, get the page's DOM, fill out name and password
           fields for the user, and trigger the login button.
           The login button might not be an HTML button, just a div, so
           to trigger it, send a click event to it.
           HTTPS is required for the URL. -->
      <loginPageInfo url="https://webmail.woodpeckersnest.space">
        <!-- What to fill into the usernameField.
             Format is the same as for <username> within <incomingServer>,
             including placeholders. See below for valid placeholders. -->
        <username>%EMAILLOCALPART%</username>
      </loginPageInfo>
    </webMail>

    <clientConfigUpdate url="https://woodpeckersnest.eu/.well-known/autoconfig/mail/config-v1.1.xml" />

</clientConfig>

Migrate whole system from one host to another

Written by Simone

I recently moved from OVH to Contabo for my VPS: since setting up everything from scratch looked like a hard challenge, I moved everything using rsync.

Firstly, some preparations:

  • installed the same kernel I had on OVH
  • rebooted Contabo
  • installed rsync on Contabo

Then I switched to the OVH shell:

  • created a exclude.txt file with all the directory and file I didn't want to move:
/boot/
/etc/modules
/etc/fstab
/etc/mtab
/etc/netconfig
/etc/networks
/etc/network/
/etc/ssh/
/etc/cloud/
/etc/cloud-release
/etc/grub.d/
/etc/host.conf
/etc/hostname
/etc/hosts
/etc/hosts.allow
/etc/hosts.deny
/etc/init.d/cloud-config
/etc/init.d/cloud-final
/etc/init.d/cloud-init
/etc/init.d/cloud-init-local
/etc/initramfs-tools/
/etc/default/grub
/etc/default/grub.d/
/etc/kernel/
/etc/kernel-img.conf
/lib/modules/
/lost+found/
/sys/
/proc/
/dev/
/tmp/
/var/cache/
/var/log/journal/
/mnt/
/root/.ssh/
  • moved it to /root/exclude.txt

  • stopped all the running services

    systemctl stop

  • now we can begin rsync-ing: you have to have access to the root user on destination VPS

    rsync -avzP --exclude-from=/root/exclude.txt / root@CONTABO_IP:/

  • after that, I edited /etc/fstab to add support for quota, like I had on OVH

  • then I searched and grepped /etc for my OVH IP address, because I knew it was set somewhere on some config file

    grep -r “OVH IP” /etc/*

  • and substituted it with the new Contabo IP, where necessary.

Finally, I could reboot Contabo:

reboot

Once up & running again, I changed all DNS entries from OVH to Contabo IP.. And waited 😀

  • Last but not least, I edited etc/hosts manually to reflect the new Domain Name address and also set up the hostname

    hostnamectl set-hostname

Done!

EDIT! A detail I missed to mention is that your destination host's root password will be changed, after rsync-ing, to the one of the source host!!

Radicale Cal/Card DAV

Written by Simone

Radicale

Descrizione

Radicale è un piccolo ma potente server CalDAV (calendari, elenchi di cose da fare) e CardDAV (contatti), che:

  • Condivide calendari ed elenchi di contatti tramite CalDAV, CardDAV e HTTP.
  • Supporta eventi, todos, voci del diario e biglietti da visita.
  • Funziona subito, senza bisogno di complicate impostazioni o configurazioni.
  • Può limitare l'accesso tramite autenticazione.
  • Può proteggere le connessioni con TLS.
  • Funziona con molti client CalDAV e CardDAV.
  • Memorizza tutti i dati sul file system in una semplice struttura di cartelle.
  • Può essere esteso con plugin.
  • È un software libero con licenza GPLv3.

Requisiti/Installazione

Innanzitutto, assicurarsi che python 3.5 o successivo (si consiglia python ≥ 3.6) sia installato. Sarà poi necessario un web server come Apache o nginx; in questa guida verrà usato nginx e verranno installati pacchetti presenti in Debian, anziché usare "pip".

Documentazione Ufficiale

Installazione

# apt install radicale apache2-utils python3-passlib

Configurazione

# nano /etc/radicale/config

Cambiare le linee seguenti:

 [server]
 hosts = 127.0.0.1:5232
 
 [auth]
 type = http_x_remote_user

 [rights]
 type = owner_only
 file = /etc/radicale/rights

 [storage]
 type = multifilesystem_nolock

 [logging]
 level = info
 mask_passwords = True

 [headers]
 Access-Control-Allow-Origin = *

Ora possiamo avviare il servizio:

# systemctl start radicale.service
# systemctl status radicale.service

Per leggere i log, digitare:

# journalctl -xe -u radicale.service

Quando avremo sistemato tutto e Radicale funzionerà correttamente, potremo abilitare il servizio al boot:

# systemctl enable radicale.service

Reverse proxy

Esempio di configurazione di nginx:

server {
    listen 443 ssl http2;
    server_name cal.woodpeckersnest.space;

    ssl_certificate /etc/letsencrypt/live/cal.woodpeckersnest.space/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/cal.woodpeckersnest.space/privkey.pem;

        error_log /var/log/nginx/radicale.err;
        access_log /var/log/nginx/radicale.log;

        add_header "X-XSS-Protection" "0";

    location / {
        return 301  /radicale/;
    }

    location /radicale/ { # The trailing / is important!
        proxy_pass        http://localhost:5232/; # The / is important!
        proxy_set_header  X-Script-Name /radicale;
        proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header  X-Remote-User $remote_user;
        proxy_set_header  Host $http_host;
        proxy_pass_header Authorization;
        auth_basic        "Radicale - Password Required";
        auth_basic_user_file /etc/nginx/radicale-users;
        }
}

server {
    listen 0.0.0.0:80;
    server_name cal.woodpeckersnest.space;

    location / {
        return 301  /radicale/;
    }

    location /radicale/ {
        return 301 https://$host$request_uri;
    }
}

la riga che recita:

auth_basic_user_file /etc/nginx/radicale-users;

ci indica che dovremmo creare il file a quel percorso con le credenziali degli utenti che vorranno usare il servizio.

Il comando per fare ciò è "htpasswd"

$ htpasswd -c /etc/nginx/radicale-users <nome_utente>

Una volta battuto enter vi verrà chiesta la password per l'utente <nome_utente> che avrete scelto ed il tutto verrà salvato nel file "/etc/nginx/radicale-users". Riavviate nginx per terminare.

Come potete vedere dal file di configurazione nginx, avrete bisogno di un sottodominio DNS e del relativo certificato (tutto ciò non è scopo di questa guida).

Abbiamo terminato: connettetevi al vostro sottodominio e dovreste poter accedere alla pagina di login di Radicale. Seguendo il file di configurazione nginx, per il mio caso il link sarà il seguente:

https://cal.woodpeckersnest.space/

Special characters in DBs are a no-go

Written by Simone

Remember: don't ever use special characters in your DB's users password!!

I have been troubleshooting a migration from mariadbd to pgsql for several hours, until I tried changing my password, which, weirdly enough, was working to connect roundcube but gave errors with pgloader. Once I successfully migrated using the same password with those special characters, roundcube wouldn't connect with pgsql, so I made another fighting round! Finally changed my pgsql password to some letters and numbers only and BAM!, it worked.

Then I stopped mariadbd and disabled the service; now I have more than 200MB RAM freed¹.

¹ See previous post.

mariadbd is a memory hog

Written by Simone

A fat pig eating with its mouth and nose all dirty

I'm still struggling to understand why mariadbd uses so much memory for just 1 DB and 1 application, which in this case is roundcube.

I tried changing this value to no avail.. If anyone wants to share some thoughts I would appreciate:

[mariadb]
innodb_buffer_pool_size=128M

Leave a comment if you know shit. Thanks

EDIT: some details

OVH VPS, 1 core, 2GB, 20 GB SSD. mariadb-server 1:10.11.4-1deb12u1. roundcube DB size 2.41MB, 17 tables. RAM taken at process restart 240MB.

Unauthenticated email from [DOMAIN] is not accepted due to 550-5.7.26 domain's DMARC policy.

Written by Simone

I was enabling Exim on my IONOS VPS to deliver email through a smarthost and encountered the error message in this post's title (unable to send to Gmail users.. It's always them!)

After fiddling a while with DMARK and SPF I reconfigured Exim itself to rewrite sender address, so that emails coming from "spacenest.it" (IONOS domain) were sent as coming from "woodpeckersnest.eu", the smarthost and real email server.

Everything is done via this command:

# dpkg-reconfigure exim4-config

And the resulting configuration in /etc/exim4/update-exim4.conf is:

dc_eximconfig_configtype='smarthost'
dc_other_hostnames='cassandra.spacenest.it;spacenest.it'
dc_local_interfaces='127.0.0.1'
dc_readhost='woodpeckersnest.eu'
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='pandora.woodpeckersnest.space::587'
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname='true'
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'

On OVH's postfix I just had to modify this line in /etc/postfix/main.cf:

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 94.143.138.27/32

where that last IP is the IP Address of my IONOS server.