Good day everyone!

This weekend I've been restructuring "woodpeckersnest's" homepage.

The move was pretty huge since I went from a static #HTML plus some #JS site to homarr; it's taking quite a lot of RAM to run now, but the outcome is nice and I like it better than the old style - on mobile, at least on my crap smartphone, doesn't look very good, it needs quite a lot of pixels to perform alright (I hate phones btw, so it's still good for me).

Everything is WIP, but you can take a look at it anyway: https://woodpeckersnest.space

Please let me know if you find anything broken or not working properly. 😍

P.S. I have also upgraded our DeltaChat "chatmail" instance to latest and greatest 1.4.1 release - Thanks Federico for the hosting and Andrea for translations.

Come join us at https://chatmail.woodpeckersnest.space/

Beszel Setup

Interesting project at https://github.com/henrygd/beszel

Collects resource statistics from one or more systems, display CPU/RAM/DISK/NET/DOCKER information and be alerted in case "event" happens.

These days I set up beszel HUB on my VPS and beszel-agent on the same VPS, on our chatmail server and even on my desktop PC at home on WSL2: so now I'm monitoring 3 systems from a web interface and I'm being notified if one of them becomes unreachable or has exceeded %resources for every type of monitor.

This is my compose.yaml for the HUB and agent on "woodpeckersnest.eu":

services:
  beszel:
    image: 'henrygd/beszel'
    container_name: 'beszel'
    networks:
      beszel:
        ipv4_address: 172.30.0.2
    restart: unless-stopped
    ports:
      - '8090:8090'
    volumes:
      - beszel_data:/beszel_data
    environment:
      DISABLE_PASSWORD_AUTH: false

  beszel-agent:
    image: "henrygd/beszel-agent"
    container_name: "beszel-agent"
    networks:
      beszel:
        ipv4_address: 172.30.0.3
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      PORT: 45876
      KEY: "SECRET"
      FILESYSTEM: /dev/sda3
      
networks:
  beszel:
    name: "beszel"
    external: true

volumes:
   beszel_data:
       external: true
       name: "beszel_data"

I created a named docker volume and a custom network beforehand:

docker volume create --name beszel_data

docker network create --subnet=172.30.0.0/16 --gateway=172.30.0.1 beszel

I didn't want to run the agent with network_mode: host, so here's a bridged setup. Network stats on my VPS won't be relevant, since the only net beszel can monitor is the docker bridged one, but I don't care very much.

For chatmail and home desktop I'm running the binary agent, respectively in a systemd unit for chatmail and with a bash script for my PC.

The systemd unit looks like this:

# /etc/systemd/system/beszel-agent.service
[Unit]
Description=Beszel Agent Service
After=network.target

[Service]
Environment="PORT=45876"
Environment="KEY=SECRET"
ExecStart=/home/chatmail/bin/beszel-agent
User=chatmail
Restart=always

[Install]
WantedBy=multi-user.target

The HUB has also got (automatic) backups, locally or on S3 - I tested both without issues. Beszel (both HUB and agent) take almost no CPU/RAM to do their job and stats are easy to read. Even the management tool is quite straightforward and has got the basic stuff right - I skipped OAUTH entirely though, while managing users manually.

Still young project but already recommended 😍

If you're interested in setting this up on WSL2, here I opened a discussion about this topic.. No need to repeat myself 😀

shout-out to "mforester@rollenspiel.social" who posted about beszel on the fediverse and gave me the idea to try it.

Continuing from the previous article..

Today while trying to install yet another plugin (Calendar this time), I had a lil incident and destroyed everything 😃

Some hours later I restored a backup and we're up again. BUT! In the process I discovered some SQL errors which I believe were there since a lot ago, always gone unseen.

To make a long story short, I had to disable the standard "Personal Address Book" for everyone, because it was impossible to save any contact in there anyway.. And we are now relying on CardDAV, which is way better.

At one point I had the Calendar plugin working too, alongside CardDAV, but I had (wrongfully) installed it as a local one, so no sync to the cloud with CalDAV; it was later that I tried the CalDAV way by changing the config and shit got me.

Now I asked the people of libera.chat about the plugin, to see if it really supports any CalDAV implementation or not - and then I'll try again :) Feel free to check it out and leave a comment if you know better than me..

https://git.kolab.org/diffusion/RPK/browse/master/plugins/calendar/

and here's the configuration: https://git.kolab.org/diffusion/RPK/browse/master/plugins/calendar/config.inc.php.dist$28

I believe I'm done for today tho.. Looked like a full day's job. Ooh, yes.. Was already forgetting. I also updated the services blob in my website with all the new stuff.

Hello o/

Just completed a new software installment for the "woodpeckers" webmail, powered by roundcube. It's a plugin to manage CardDAV address books, so you can import them in your web contacts; I've tested it with "Radicale Cal/CardDAV" server and the import to roundcube was fast and easy peasy; hopefully it'll be the same for every other compatible server 😎

https://webmail.woodpeckersnest.space/

Yeah, that was all for your local news! Until next.

Statistiche

$ uptime
 03:54:18 up 34 days,  8:19,  4 users,  load average: 0.00, 0.00, 0.00

$ free -m
               total        used        free      shared  buff/cache   available
Mem:             877         503         159           8         377         374
Swap:            499          87         412

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            428M     0  428M   0% /dev
tmpfs            88M  8.4M   80M  10% /run
/dev/vda1       9.7G  2.8G  6.6G  30% /
tmpfs           439M     0  439M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/vda15      124M   12M  113M  10% /boot/efi
tmpfs            88M     0   88M   0% /run/user/1000

$ ip -s link
2: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:   bytes  packets errors dropped  missed   mcast
     1444308867 14871375      0   32828       0       0
    TX:   bytes  packets errors dropped carrier collsns
    18414348377 21921709      0       0       0       0

$ curl https://chatmail.woodpeckersnest.space/metrics
accounts 83 1719367201634

store /etc in git, mercurial, brz or darcs

The etckeeper program is a tool to let /etc be stored in a git, mercurial, brz or darcs repository. It hooks into APT to automatically commit changes made to /etc during package upgrades. It tracks file metadata that version control systems do not normally support, but that is important for /etc, such as the permissions of /etc/shadow. It's quite modular and configurable, while also being simple to use if you understand the basics of working with version control.

https://packages.debian.org/stable/etckeeper

root@pandora:/etc# git log --oneline mumble-server.ini
c1e2238 daily autocommit
2e66cf6 daily autocommit
76fd073 daily autocommit
baaff1c saving uncommitted changes in /etc prior to apt run
9980c10 daily autocommit
830fa84 daily autocommit
0cc8fd9 saving uncommitted changes in /etc prior to apt run
4e7b545 saving uncommitted changes in /etc prior to apt run
20d692a daily autocommit
c05a405 saving uncommitted changes in /etc prior to apt run
3a00635 daily autocommit
62e0e1c Initial commit

root@pandora:/etc# git diff c1e2238 2e66cf6 mumble-server.ini
diff --git a/mumble-server.ini b/mumble-server.ini
index 3332154..d91f520 100644
--- a/mumble-server.ini
+++ b/mumble-server.ini
@@ -236,8 +236,8 @@ logdays=5
 ; If you only wish to give your "Root" channel a custom name, then only
 ; uncomment the 'registerName' parameter.
 ;
-registerName=SpaceNest
-registerPassword=sekret
+registerName=SpaceNest[EN/IT]
+registerPassword=newsekret
 registerUrl=https://woodpeckersnest.space/
 registerHostname=voice.woodpeckersnest.space
 registerLocation=IT

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 😀

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.