Posts tagged with “selfhosting”

More on WebDAV - Connecting a remote WebDAV folder in Windows

Written by Simone

After some failed attempt at this, I think I found the right way to "mount" a remote WebDAV folder under Windows' Explorer.

Initially my baby steps took me here: https://note.woodpeckersnest.space/share/0TJT81fgI8Jy

After following that tutorial I didn't succeed, so I investigated further. I can say that everythig looks correct until you get to point 9.

The address they tell you have to enter isn't correct in my experience and they aren't even using https for the URL. What worked for me was instead something like:

\\webdav.woodpeckersnest.space@SSL\folder

You have to input the network-path-stile address which is common in Windows, as in: double backslash, FQDN of your WebDAV server, "@SSL" and then the path (folder) where you have access to files in your WebDAV server, with a backslash preceding it.

That's it, a prompt will ask for username and password and then a new Network Path (WebFolder) will be connected in Explorer, just below your local drives.

You can then browse, copy, upload, delete (and so on) whatever content you like.

EDIT: Just found out I couldn't rename files/folders from Windows or Total Commander (Android)

Fixed by setting nginx virtualhost like this:

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


    # HTTPS configuration
    ssl_certificate /etc/letsencrypt/live/webdav.woodpeckersnest.space/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/webdav.woodpeckersnest.space/privkey.pem;

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

  location / {
    set $destination $http_destination;

    if ($destination ~* ^https(.+)$) {
         set $destination http$1;
    }

    proxy_set_header   Destination $destination;
    proxy_set_header   X-Real-IP $remote_addr;
    proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header   Host $host;
    proxy_pass         http://127.0.0.1:17062/;
    proxy_http_version 1.1;
    proxy_set_header   Upgrade $http_upgrade;
    proxy_set_header   Connection "upgrade";
  }

  client_max_body_size 0;

}

Now I'm quite happy 😀

Sharing big files with Thunderbird filelink on self-hosted webdav

Written by Simone

Thunderbird filelink with self-hosted webdav

Me and friends on xmpp:lozibaldone@conference.xmpp-it.net?join had a discussion about big attachments in Thunderbird and one person ("idice"), which I thank, suggested to use (long forgotten by me) Thunderbird's "filelink" functionality.

filelink lets you upload your big attachments to the cloud and send a link to download them, to your email contact. For it to work, you have to download an extension for Thunderbird and choose a cloud instance.

There are a few in the community, ranging from Dropbox, to Nectcloud and webdav. I chose webdav, because I already have a docker container with a running instance.

The tricky part in setting the extension up and working with my server was to have a private and a public URLs: you have credentials for webdav, so the private one is easily accomplished, while I had never thought about having a public site to share stuff without authentication; and in the end it was really straightforward.

What I did was basically: mount a volume in docker where I want to publish stuff to be shared. So at first when uploading I'm asked for credentials and everything just works.. files go to the volume.

Then, to have people access those files, I simlinked (ln -s) the docker volume dir to a path under my main site's virtualhost in nginx. Like:

My site is in /var/www/html/, so I changed dir to that location and:

ln -s /path/to/public-docker-volume/ public

Now I have a /public/ dir in my website with all the files that I publish in webdav and since index is off in nginx, you can't just browse it - you have to know the exact file name to access it.

And that's it.

Now for the Thunderbird setup, I'll show a few shots. For starters, this is the extension I used: https://addons.thunderbird.net/it/thunderbird/addon/filelink-provider-for-webdav/

This is the "attachments" settings in Thunderbird, the only place where you configure the extension:

As you can see it asks for a private and a public URLs, as explained before.

When you compose a new message, go to the attachments menu as always and you'll find a new item, called Filelink - WebDAV:

Click it and select your attachment from disk. It will ask for a username and password (those you set up for webdav in docker) and will begin uploading the file.

Then you'll see the message being populated like this:

It says:

I have linked 1 file to this email:

  • mibunny.png

    Size: 408 KB

    Link: the link

If you keep uploading files, the number in the first row will be automatically incremented and there will be another file section with new info about it.

And.. we're done!? 😀

If you got any question, leave a comment down below.

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

Trilium Notes

Written by Simone

A screenshot of the web app

I'm super impressed by Trilium Notes, a wonderful note-taking app and self-hostable service.

Used docker to host it and web to manage my notes. It saves instantly, no button to press, has a lot of useful functions, it's scriptable, does backups automatically and it offers extensions for chrome and firefox.

Two issue though:

  • chrome extension will become unsupported later on in 2024, because it uses manifest v2
  • developers just posted a couple days ago about putting the project into maintenance mode :(

Although this is kinda sad, I have used the app for the past 2 days and it works very well, so much that I finally ditched MS One Note (yes I use Windows on my Desktop - shame! shame! shame!)

XMPP Network Graph

Written by Simone

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>

Slixfeed RSS XMPP BoT

Written by Simone

Interesting project, features' rich and almost complete. Thanks goes to its main developer Schimon AKA "sch".

Here is the support room

Dendrite (Matrix) is live

Written by Simone

Several months ago I was running a "matrix-docker-ansible" playbook on OVH, but limited resources led me to take it down.

More than one time I thought about reliving that server (which I have backups of), but reading on the changes that the playbook got so far and the difficulties in running a Matrix environment without exposing web ports (80 and 443), I thought to better give up.

Yesterday I looked into Dendrite (a Matrix server written in GO), which looks a lot simpler than the whole lot the docker-ansible playbook offers, so I went ahead and installed it the manual way with nginx as reverse proxy. Easy peasy - documentation is quite good.

Today I also installed "Cinny" as a web client and I'm done for the moment... Federation works, registrations are closed (can invite friends though) and apart from RAM peaks and quite long waiting times when joining rooms (up to 2K members), the server is doing quite well: started with 700MB of RAM (at joining time) and went down to less than 300 in normal usage. CPU gets high spikes when sending messages but other than that is just a few points %. Just don't even think to join the official #matrix room or shit will happen 😀

My new Matrix username is: @roughnecks:woodpeckersnest.space, feel free to add me.

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/