DepUnPr

Matita

2026-03-16T00:00:00+00:00

My “homelab” at home is made up by one (1) raspberry-pi 4 which runs some services, like pi-hole, wireguard, mpd, etc etc.

It is also running collectd to “gathers metrics from various sources” (as they say). This data is stored in RRD files, for the ease of config.

May moons ago I wrote a bash script which, via the magic incantations of rrdtool graph, generated some graphs (you can read about that in this post)

Everything was nice, I was happy, my raspberry was happy. Then one sad day, someone® deleted by accident the script. The script that generated all the nice graphs. The script of which there was no other copy around.

I was at a crossroad: rewrite the script or start a new Unnecessary Project? After a quick meeting with the Department Council, a decision was reached: start a new project, obviously. This is the Department of Unnecessary Projects, after all!

This is (more or less) the true story of how Matita was born.

Matita is a dynamic dasboard for collectd/rrd. A php file serves some API to manipulate graph configurations and the data fetched from RRD to populate those graph.

An ugly html/css/js combination uses these API to show those graps on a page (using Chart.js), automatically update the data, and handle some UI to edit the graphs.

Without leaving the webpage is it possible to add, edit and remove graphs, define which data is shown and how.

There are some bugs still (eh), but it works enough well for me.

Some screenshots:

- Matita showing a dashboard

- Editing the “Memory” graph

- The Dataset Browser. Remind you of anything?

This blog should support webmentions now

2026-01-27T00:00:00+00:00

I’m looking at IndieWeb and webmentions for a while now, thinking about how to implement that on my site.

A while ago I enable IndieAuth but never got to use it really.

After stumbling upon Aks’ post “My blog has now webmention support!” I decided time is come to have a look at this.

Now this blog should receive webmentions via webmention.io (on which I logged in via IndieAuth with no problems!) and should send webmentions via webmention.app.

In the future maybe I’ll write some code to support webmentions directly.

I should also write a new post about how this blog is published, because things have changed from my first post

Auto-activate Python virtualenv in bash on directory change

2025-10-09T00:00:00+00:00

I like to develop unnecessary things, and often I like to develop them with Python.

When I can, I try to develop with current Debian Python version and packaged libraries, but sometime this is impossible. Or it would be unnecessary difficult to do.

I this cases I create a virtualenv, using Python venv module:

python3 -m venv venv

(my virtualenvs are usually in venv or .venv folders)

I know, there are n+1 programs which handle virtualenv creation and so on, but using them require to have the correct tool installed. And, anyway, I said that this is unnecessary, did I?

I also made an alias to speed up this step:

alias py='python3 -m'

so that I can condense the command as

py venv venv

But then another non-problem arisen: I need to remember to activate the virtualenv when I’m fiddling with the project and, more important, I need to remember to deactivate it when I change project.

How many time I have run commands for project_b inside the virtualenv of project_a? Once too many.

So I decided to do the only thing appropriate: an unnecessary replacement of cd which automatically activate and deactivate Python virtualenvs.

The script define a function which is then aliased to cd. After changing directory, the script search for a folder called venv or .venv in CWD or in parent directories (up to the home). If it finds one it activate it, not before deactivating the one currently active (if any).

Obviously someone immediately declared the intent to create a git repo with a malicious venv/bin/activate script and trick me to clone it.

So I had to add a approve/block list functionality. (which may sound necessary, given the threat, but as nobody should use this script, is it still unnecessary, and thus approved by this Department)

Now the script when find a virtualenv, check if it is in one of the two lists. If it is allowed, it activates it right away, if it is blocked it ignores it. If it is not either, it asks to the user what to do, and puts it in the correct list for future reference.

It works? yes.
It is necessary? no.
Should anyone really use this? no.

Anyway, here is the script:

https://paste.sr.ht/~fabrixxm/fe248f12bc7c190ddca59769e0be1f41d8f62a4e

Simulating Hand-Drawn Motion with SVG Filters Without JS

2025-07-21T00:00:00+00:00

I stumbled on this post.

It describe a nice way to add an “Hand-Drawn Motion” effect to an image using SVG filters and JavaScript to animate filter parameters.

The effect at the end is something like this:

(original image Red Apple by cyanidecupcake)

As the article explain, the animation is the result of a chain of two effects, feTurbulence and feDisplacementMap, and a bit of js to change feTurbulence baseFrequency attribute.

While js allow maximum flexibility on the output result, the same effect can be achieved without a single line of js.

Can I Use says about SVG SMIL Animation

Since January 2020, this feature works across the latest devices and major browser versions

So we can use SMIL to animate the baseFrequency attribute directly in svg:

<svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="400" height="400" viewBox="0 0 400 400">
  <defs>
    <filter id="distortionFilter">
      <!-- Step 1: Create a turbulence field to generate noise -->
      <feTurbulence
         type="turbulence"
         baseFrequency="0.01"
         numOctaves="2"
         seed="1"
         result="noise"
         id="feTurbulence1">
         <!-- Step 2: Use SMIL animation to loop between baseFrequency values --> 
        <animate
           id="turbolente-baseFrequency-anim"
           attributeName="baseFrequency"
           values="0.01;0.025;0.015;0.03"
           calcMode="discrete"
           repeatCount="indefinite"
           dur=".9" />
      </feTurbulence>
      <!-- Step 3: Use the noise (in2) to displace the image (in) -->
      <feDisplacementMap
         in="SourceGraphic"
         in2="noise"
         scale="5"
         xChannelSelector="R"
         yChannelSelector="G"
         id="feDisplacementMap1" />
    </filter>
  </defs>
  <!-- Step 4: Apply the filter to the image -->
  <image
    x="0" y="0" width="400" height="400"
    href="cherry.png"
    filter="url(#distortionFilter)" />
</svg>

MPD su RPI II : Bluetooth

2025-01-21T18:11:00+00:00

Seconda parte della serie “MPD su RaspberryPI”.

Avevo concluso la prima parte con una serie di cose da provare, tra cui l’idea di recuperare un dongle usb e provare a collegare una cassa bluetooth.

Mi è poi venuto in mente che è un Raspberry4, e che il bluetooth lo ha a bordo! E a casa ho una (brutta) lampada led multicolore con integrata cassa bluetooth!

Collegamela

Prima cosa, collegare il raspberry alla cassa. Il raspberry gira Debian headless: non ho schermo collegato, non ho un desktop. E quindi di base non ho installato quello che serve per il bluetooth. Installiamolo e verifichiamo che sia in escuzione

# apt install bluetooth
# systemctl status bluetoothd

Ora possiamo provare a collegare la cassa:

# bluetoothctl
Agent registered
[CHG] Controller AA:AA:AA:AA:AA:AA Pairable: yes
[bluetooth]# scan on
Discovery started
[CHG] Controller AA:AA:AA:AA:AA:AA Discovering: yes
[bluetooth]#

E aspettiamo. Quando viene rilevata la cassa, viene stampato il nome e l’indirizzo bt (6 gruppi di due cifre esadecimali separati da :, come l’indirizzo del controller qui è AA:AA:AA:AA:AA:AA)

Una volta che abbiamo l’indirizzo possiamo collegarci:

[bluetooth]# connect <indirizzo>

Il sistema darà una serie di messaggi, probabilmente qualche errore, e si collegherà.

La cassa in questione non ha nessun tipo di autenticazione per il collegamento, non ho esperienze altrimenti.

Ora la cassa è connessa, ma come ci mando l’audio? Avendo un ambiente desktop completo solitamente c’è in esecuzione PulseAudio o PipeWire che si occupano di gestire i device audio, anche bluethoot, ma in questo caso non ci sono e non ho intenzione di installare e configurare uno dei due solo per questo.

Una ricerca sull’internet mi porta a trovare bluez-alsa. Il README spiega bene cosa fa e come configurarlo. Vediamo cosa ho fatto io.

Installiamo:

# apt install bluez-alsa-utils

Questo installa le utility per bluez-alsa e automaticamente tutti quello che serve.

Verifichiamo che sia in esecuzione

# systemctl status bluealsa

Se è tutto ok, scolleghiamo e ricolleghiamo la cassa bluetooth

# bluetoothctl
[...]
[bluetooth]# disconnect <indirizzo>
[bluetooth]# connect <indirizzo>

E se tutto va bene, possiamo riprodurre un wave sulla cassa bluetooth usando aplay:

# aplay -D bluealsa /usr/share/sounds/alsa/Front_Center.wav

l’opzione -D indica il nome del device alsa da usare, che sarà appunto bluealsa

Viene creato anche un controllo mixer sul device per regolare il volume, il cui nome dipende dall’aggeggio bluetooth a cui siamo collegati. Per vedere come si chiama usiamo amixer , che si trova nel pacchetto alsa-utils:

# apt install alsa-utils
# amixer -D bluealsa
ALSA lib bluealsa-ctl.c:205:(bluealsa_dev_fetch_battery) Couldn't get device battery status: Object does not exist at path “/org/bluealsa/hci0/dev_BB_BB_BB_BB_BB_BB/rfcomm”
Simple mixer control 'SUPREMA-SKP - A2DP',0
  Capabilities: pvolume pswitch
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 127
  Mono:
  Front Left: Playback 127 [100%] [0.00dB] [on]
  Front Right: Playback 127 [100%] [0.00dB] [on]

La mia si chiama SUPREMA-SKP - A2DP .

Segniamoci il nome, che ci serve per il prossimo passaggio.

Prima di continuare, però, facciamo in modo che la cassa sia ricollegata in automatico:

# bluetoothctl
[bluetooth]# trust <indirizzo>
[bluetooth]# pair <indirizzo>

Output MPD

Ora che abbiamo un device alsa, possiamo dire a MPD di usarlo come output.

Questa è la configurazione dell’output in /etc/mpd.conf

audio_output {
        type            "alsa"
        name            "Cassa BT"  # qui mettete quello che volete 
        device          "bluealsa" 
        mixer_type      "software"
        mixer_device    "bluealsa"
        mixer_control   "<nome controllo mixer>"
#       mixer_index     "0"             # optional
}

Il <nome controllo mixer> è quello che abbiamo trovato prima con amixer.

Riavviamo MPD e colleghiamoci con un client, vedremo l’output disponibile. Possiamo mandare in play un brano e regolare anche il volume d’uscita 👍

Possiamo abilitare solo un output o più di uno, MPD invierà l’audio a tutti gli output abilitati.

Cose da provare

bluez-alsa permette anche il flusso inverso dell’audio, da un dispositivo remoto al device alsa di default. Non mi serve nella mia configurazione, ma è da provare!

DIY RaspberryPI homeserver dashboard - part 1

2025-01-16T00:00:00+00:00

Some back story

I have a little server at home. It’s a RaspberryPI 4, with an m.2 SSD disk in an USB enclosure as system disk and two mechanical SSD laptop disks as data store, connected via an USB SATA dock.

It’s not much, but it’s enough for me. It runs Debian 12 and it runs some services on my home network:

samba, to share files on data disks
pi-hole, configured as DNS for my LAN
wireguard and wireguard-ui , to get to my server from outside
syncthing to sync files around my devices.
restic to backup important data (most of which comes in via syncthing)
an home-grown web-based media management system, to manage my photos, videos and other things ⁰
transmission daemon to download and seed those distro ISOs
MPD , which I’m writting about (in italian)
navidrome
minidlna (I’m looking for the perfect way to listen to my music. I’m testing various alternatives…)

Most of this services have a web interface which in my network are served on dedicated subdomains of casa.rpi . All of those are resolved by pi-hole to my RPI.

How it started

I had lighttpd doing his job as proxy to serve services subdomains, but main domain was sitting here, empty.

I then thought I could write a simple html page with links to various services, as an entry point.

It was a quick page to build: a icon (service favicon linked directly) and a link for each services, some quick css and it was done.

And I didn’t touch it for some years.

The rewrite

As usual, things starts with a simple need.

The page color scheme was fixed and dark, and I wanted it to follow system preferences for light/dark scheme.

So I replaced most of the CSS of the page with picocss , a simple CSS framework which comes with dark/light color scheme in a 81K minified css file.

After some fiddling with html and some custom css this is how it become:

Same overall layout, better visual outcome (imho) and dark/light support.

Links animate on mouseover/click, and gets focus outline.

I like it 🙂

As said, icons comes from service web interface favicon. This has the nice side effect that if the service is down, icon can’t be load and become a quick visual clue that something doesn’t work.

A nice touch is the logo image: it’s an SVG directly embedded into the page inside the <h1>, without any fill color defined, which is then set by picocss. This way the logo follows the color scheme!

I could have stopped here, but if I had, you wouldn’t be reading this post.

Stats!

So I looked at this page and I thought: wouldn’t be nice to have some insight on how the system is doing just in this page?

So here we go collecting stats!

The idea is to install collectd and use rrdtool to generate some graphs and then show the grap in the page.

# apt install collectd
# apd install rrdtool
# systemctl status collectd

By default collectd collect more stats than we need, but for now we leave the configuration as it is.

To create the graph I’m using rrdtool graph command. It’s not easy to use, but with some tutorials and the documentation, I ended up with some nice results.

My page is /var/www/html/index.html. I will put my graphs in subfolder stats/ , with a bash script to generate them.

NOTE

yes, the script will be readable via webserver, but this web server is not on the internet. Everything I’m doing here should not be done on a public-facing server

rrdtool reads data from .rrd files. collectd write collected data to .rrd files in /var/lib/collectd/rrd/localhost. Here there is a folder for each plugins, and inside those an .rrd folder for each metric.

# ls /var/lib/collectd/rrd/localhost
cpu-0
cpu-1
cpu-2
cpu-3
cpufreq-0
cpufreq-1
cpufreq-2
cpufreq-3
cpusleep
df-boot-firmware
df-media-sda1
df-media-sdb1
df-root
[...]
interface-eth0
interface-lo
interface-wg0
interface-wlan0
irq
load
memory
[...]
# ls /var/lib/collectd/rrd/localhost/cpu-0
cpu-idle.rrd
cpu-interrupt.rrd
cpu-nice.rrd
cpu-softirq.rrd
cpu-steal.rrd
cpu-system.rrd
cpu-user.rrd
cpu-wait.rrd

Each .rrd file contains timestamped data for one or more values. We can inspect them with rrdtool info <file.rrd>`

# cd /var/lib/collectd/rrd/localhost
# rrdtool info cpu-0/cpu-user.rrd
filename = "cpu-0/cpu-user.rrd"
rrd_version = "0003"
step = 10
last_update = 1737033603
header_size = 3496
ds[value].index = 0
ds[value].type = "DERIVE"
ds[value].minimal_heartbeat = 20
ds[value].min = 0,0000000000e+00
ds[value].max = NaN
ds[value].last_ds = "832605"
ds[value].value = 2,1000000000e+00
ds[value].unknown_sec = 0
rra[0].cf = "AVERAGE"
rra[0].rows = 1200
rra[0].cur_row = 258
rra[0].pdp_per_row = 1
rra[0].xff = 1,0000000000e-01
rra[0].cdp_prep[0].value = NaN
rra[0].cdp_prep[0].unknown_datapoints = 0
rra[1].cf = "MIN"
rra[1].rows = 1200
rra[1].cur_row = 177
rra[1].pdp_per_row = 1
rra[1].xff = 1,0000000000e-01
rra[1].cdp_prep[0].value = NaN
rra[1].cdp_prep[0].unknown_datapoints = 0
rra[2].cf = "MAX"
rra[2].rows = 1200
rra[2].cur_row = 456
rra[2].pdp_per_row = 1
rra[2].xff = 1,0000000000e-01
rra[2].cdp_prep[0].value = NaN
rra[2].cdp_prep[0].unknown_datapoints = 0
[...]

… and many more lines. What we are looking for here is ds[value]. This file has one variable, named value.

# rrdtool info interface-eth0/if_packets.rrd
filename = "interface-eth0/if_packets.rrd"
rrd_version = "0003"
step = 10
last_update = 1737034003
header_size = 4928
ds[rx].index = 0
ds[rx].type = "DERIVE"
ds[rx].minimal_heartbeat = 20
ds[rx].min = 0,0000000000e+00
ds[rx].max = NaN
ds[rx].last_ds = "40872202"
ds[rx].value = 1,0290000000e+02
ds[rx].unknown_sec = 0
ds[tx].index = 1
ds[tx].type = "DERIVE"
ds[tx].minimal_heartbeat = 20
ds[tx].min = 0,0000000000e+00
ds[tx].max = NaN
ds[tx].last_ds = "73397119"
ds[tx].value = 9,1800000000e+01
ds[tx].unknown_sec = 0
rra[0].cf = "AVERAGE"
rra[0].rows = 1200

Here we have two variables: tx and rx

Graphs!

Let’s graph our stats. We start with some basic data: system load, memory usage and number of processes.

We create the script /var/www/html/stats/makegraphs.sh, and make it executable.

#!/bin/bash
BASERRD="/var/lib/collectd/rrd/localhost"

# system load:
# we want three lines for short / mid / long term load
rrdtool graph load.png \
        --lazy \
        --title="Load" \
        "DEF:s=$BASERRD/load/load.rrd:shortterm:AVERAGE" \
            "LINE1:s#1a5fb4:Short term" \
            "GPRINT:s:LAST:%5.2lf" \
        "DEF:m=$BASERRD/load/load.rrd:midterm:AVERAGE" \
            "LINE2:m#e5a50a:Mid term" \
            "GPRINT:m:LAST:%5.2lf" \
        "DEF:l=$BASERRD/load/load.rrd:longterm:AVERAGE" \
            "LINE1:l#9141ac:Long term" \
            "GPRINT:l:LAST:%5.2lf"

I will let you read the documentation for the juicy details of this command, but in short: we ask rrdtool to create a graph with titled “Load”, with data from load/load.rrd, first from variable shortterm. We then ask to draw it as a line, with color #1a5fb4 and label “Short term”. A legend entry will be added automatically. Then we write the last value registered for the variable, with a format string: %5.2lf will print the number with a width of 5 digits and a precision of 2. We repeat the code for the other variables, changing the color the label and the reference name (here s for short , m for mid and l for long). We ask rrdtool to save the result as load.png.

This is the result:

Colors are chosen from the GNOME HIG palette . Easy 🙂

Next we draw the memory usage:

rrdtool graph memory.png \
        --lazy \
        --lower-limit 0 \
        --title="Memory" \
        "DEF:umem=$BASERRD/memory/memory-used.rrd:value:AVERAGE" \
            "AREA:umem#e01b24:Used" \
            "GPRINT:umem:LAST:%5.2lf%s" \
        "DEF:fmem=$BASERRD/memory/memory-free.rrd:value:AVERAGE" \
            "STACK:fmem#33d17a:Free" \
            "GPRINT:fmem:LAST:%5.2lf%s"

Basically it’s the same, here we draw used memory and free memory, whose data came from two different files, both with variable named value .

Two main differences here:

the format in GPRINT command has a %s added at the end. This will make rrdtool to print the vaule with the appropriate SI magnitude unit and the value will be scaled accordingly (123456 becomes 123.47 k).
Instead of lines, we plot stacked areas. This will show better visually how much of the total is taken by the values
a new option --lower-limit 0 to tell rrdtool to start the Y axis from 0 instead of automatically choose a lower limit based on the data. Again, this will show better how much memory the two areas are covering.

(I’m not plotting all the memory-related values, so the total area is not at 100%)

Last is a graph with processes. Which data to plot has been choose at random, I’m sure there are more useful things to know, but here it is:

rrdtool graph processes.png \
        --lazy \
        --title="Processes" \
        "DEF:r=$BASERRD/processes/ps_state-running.rrd:value:AVERAGE" \
            "LINE1:r#33d17a:Running" \
            "GPRINT:r:LAST:%5.2lf" \
        "DEF:s=$BASERRD/processes/ps_state-sleeping.rrd:value:AVERAGE" \
            "LINE2:s#3584e4:Sleeping" \
            "GPRINT:s:LAST:%5.2lf" \
        "DEF:z=$BASERRD/processes/ps_state-zombies.rrd:value:AVERAGE" \
            "LINE1:z#e01b24:Zombies" \
            "GPRINT:z:LAST:%5.2lf"

This is just like the load graph, nothing too fancy.

We run the script from the folder, it generates the images. Then we add the images to the page.

For a clean look, I decided to put the graphs inside a <details> element, which is collapsed by default:

<details>
    <summary>stats</summary>
    <section>
        <header><h2>System</h2></header>
        <div>
            <img src="stats/load.png">
            <img src="stats/memory.png">
            <img src="stats/processes.png">
        </div>
    </section>
</details>

A bit of css will position the images nicely on the page.

With the same process I’ve added also graphs for disks space usage and network packets count.

The result is this page:

Nice!

With this we end the first part about my DIY homeserver dashboard.

Next up: auto-update the graphs and moar stats!!!1!

Footnotes

^0: Code is available, but I’m not linking it because it’s not really ready to be used

MPD su RaspberryPI

2025-01-10T00:00:00+00:00

Cosa serve

un raspberrypi (testato su 4)
debian (testato con debian 12 aarch64
podman (opzionale)

Podman per l’interfaccia web. Si puo’ fare senza, ma non l’ho testato.

MPD

Installazione

# apt install mpd

Configurazione

editiamo /etc/mpd.conf

Ecco cosa ho modificato nel mio file di configurazione. Se erano commentati (la riga cominciava con #), sono stati decommentati

music_directory     "/media/sda1/Musica"

questa è la cartella che contiene la mia musica

bind_to_address         "0.0.0.0"
bind_to_address         "/run/mpd/socket"

Il primo è l’indirizzo di rete su cui risponderà mpd, 0.0.0.0 per rispondere su tutte le interfacce di rete.

Il secondo per potersi collegare via socket locale. Servirà per l’interfaccia web.

zeroconf_enabled        "yes"
zeroconf_name           "Music Player @ %h"

Sul mio raspberry ho installato Avahi, quindi ho abilitato le opzioni. Non ho ancora visto se funziona

audio_output {
    type        "httpd"
    name        "My HTTP Stream"
    encoder     "lame"          # optional, vorbis or lame
    port        "8000"
    bind_to_address "0.0.0.0"       # optional, IPv4 or IPv6
##  quality     "5.0"           # do not define if bitrate is defined
    bitrate     "128"           # do not define if quality is defined
#   format      "44100:16:1"
#   max_clients "0"         # optional 0=no limit
}

Qui abilito l’output via stream http, usando il server di streaming http integrato in mpd.

L’encoder è impostato a “lame” per avere lo stream in mp3. Dai miei test, il client per android malp funziona molto meglio con lo stream in mp3. Io ho deciso di impostare il bitrate a 128, vedete voi.

Non ho impostato una password nel file di configurazione perché il mio mpd sarà raggiungibile solo in rete locale a casa.

Avvio

Configurato, non resta che avviare il servizio

# systemctl enable --now mpd

A questo punto dovreste potervi collegare all’indirizzo di controllo:

http://vostroserver:6600

che dovrebbe rispondere qualcosa tipo

OK MPD 0.23.5

e anche all’indirizzo dello streaming

http://vostroserver:8000

che non risponde perché non c’è nessun brano in esecuzione.

Client android malp

mapl è installabile da f-droid.

Per prima chiede di creare il profilo.

Nome profilo: quello che volete
Hostname or ip: indirizzo del vostro server
Port: 6600
Password: vuoto, non ho impostato una password
Enable streaming from serve: abilitato
Streaming url: http://vostroserver:8000

A questo punto si può andare su Library, cercare una canzone, selezionarla pigiare “play”. Dovrebbe partire l’indicatore di avanzamento ma non si sente nulla.

Aprendo il player, menu ⋮ si seleziona “star streaming” e si aspetta. dopo una decina di secondi dovrebbe partire l’audio. Si, bisogna farlo ogni volta.

Client web

Come client web usiamo myMPD, la documentazione è qui: https://jcorporation.github.io/myMPD/

Per l’installazione ci sono tre opzioni:

Docker/Podman
Loro repository Debian
Compilazione da sorgente

La compilazione non sembra complicata, ma per questa volta ho scelto di usare Podman, che ho già installato sul raspino per altre cose (pihole).

L’interfaccia web sarà raggiungibile all’indirizzo

htttp://vostroserver:6680/

installazione

Per tenere le cose in ordine, creo una cartella /opt/mympd dove ci metto quello che serve

Creo lo script bash che avvierà il container: /opt/mympd/run.sh

#!/bin/bash
set -e

NAME="${1:-mympd}"

# girerà come utente pi:pi, che è il mio utente sul raspi
# e che ha accesso alla cartella musica
RUNAS="1000:1000"

# creo le due cartelle per salvare configurazione e cache tra i riavvi
# del container
MYMPD_BASE="${MYMPD_BASE:-$(dirname "$0")}"
[[ -d "$MYMPD_BASE" ]] || mkdir -p "$MYMPD_BASE" || { echo "Couldn't create storage directory: $MYMPD_BASE"; exit 1; }
mkdir -p "${MYMPD_BASE}/workdir"
mkdir -p "${MYMPD_BASE}/cachedir"

chown -R "$RUNAS" "${MYMPD_BASE}/workdir" "${MYMPD_BASE}/cachedir"

# avvio il container
podman run \
    --rm \
    --name "$NAME" \
    -p 6680:8080 \
    -u 1000:1000 \
    -e UMASK_SET=022 \
    -e MYMPD_SSL=false \
    -e MYMPD_HTTP_PORT=8080 \
    -v /run/mpd:/run/mpd \
    -v "${MYMPD_BASE}/workdir:/var/lib/mympd" \
    -v "${MYMPD_BASE}/cachedir:/var/cache/mympd" \
    \
    -v "/media/sda1/Musica:/media/sda1/Musica:ro" \
    -v "/var/lib/mpd/playlists:/var/lib/mpd/playlists:ro" \
    \
    ghcr.io/jcorporation/mympd/mympd

⚠ OCCHIO!

Ricodarsi di modificare "/media/sda1/Musica":/media/sda1/Musica:ro" con il percorso alla giusta cartella musica

rendo lo script eseguibile

# chmod +x run.sh

creo il service unit per systemd: /opt/mympd/mympd.service

[Unit]
Description=Web-based MPD client
After=network-online.target mpd.service

[Service]
TimeoutStartSec=0
Restart=always
ExecStart=/bin/bash /opt/mympd/run.sh %n

[Install]
WantedBy=multi-user.target

Lo installo nel sistema e lo avvio

# ln -s /opt/opt/mympd/mympd.service /etc/systemd/system/
# systemctl daemon-reload
# systemctl start mympd

Ora la vostra interfaccia dovrebbe essere raggiungibile su

http://vostroserver:6680

Configurazione

myMPD si collega a mpd via socket unix, quindi non c’è bisogno di dirgli dove trovare mpd, pero’ possiamo dirgli dove trovare lo stream e di farlo partire in automatico quando c’è qualche brano in esecuzione

Facciamo: menu (icona in alto a sx) -> Impostazioni -> Caratteristiche

Riproduzione locale
- Abilita: check
- Porta del flusso: 8000
- URI del flusso: http://vostroserver:8000/
- Riproduzione automatica: check

Poi pigiamo “Salva” in fondo alla finestra.

Il resto delle impostazioni a discrezione.

Cose da provare

installare l’interfaccia web da sorgente
configurare un secondo stream con un bitrate minore, potrebbe essere utile per quando sono collegato via VPN su rete cellulare. C’è da dire che non ho trovato un client che permetta di eseguire uno stream semplicemente scegliendolo come output
recuperare un dongle bluetooth usb, collegare il raspino alla cassa bluetooth e configurarla come output di mpd

Not-so-static blogging with blag, Nextcloud and systemd

2025-01-10T00:00:00+00:00

NOTE
Very outdated post!

I always wanted to write a blog, but I never really know what about to write. But most importantly, I never wanted to manage Wordpress or whatever on this machine.

I like the idea of static blogging, but yet, I like also to have a more friendly editor than a plain text editor.

During the years I created some stupid project that I worte about on my fediverse page under the title of “Departement of Unnecessary Projects”. Why don’t write about that on the blog?

And what’s better than a Unnecessary Project for the blog?

Stack

I’m already running Nextcloud on this same vps. I found myself sharing a quick “howto” via Nextcloud Notes. It was easy to write, easy to share and good looking.

So I thought: won’t be nice to have something which get markdown files from Notes and build a blog out of them?

Here is what I come up with:

blag as static site generator

It’s the first thing came up searching for static site generators packaged in debian. It’s python (which is a plus) and is very simple. I know Pelican, but for a quick hack blag is more than enough.

Nextcloud Notes

Markdown with preview, each note in a .md file, categories as folder on disk, upload an insert images and save while typing. I mean, what do you want more?

systemd

For that added magic

a web server

It’s a “web log” after all. Nginx here, but not so important. Everything was already configured, it’s just a subfolder in webroot

How things are connected

blag reads content in markdown from folder /Notes/blog of my Nextcloud account, directly from disk and write output to /var/www/html/blog.

In Nextcloud I created two categories, blog for live articles and pages, and blog-drafts for things I’m still writting.

I like to keep things (almost) tidy, so I created /opt/blag to put everything related to this thing.

First, I installed blag

# apt install blag

then, as per documentation:

# cd /opt/blag
# blag quickstart

This asked me some questions and created config.ini file

I then created a bash script /opt/blag/build.sh

#!/bin/bash
set -e

HERE="$(dirname "$0")"
cd "$HERE"

rm -r /var/www/kirgroup.net/blog/*

blag build -i /path/to/nextcloud/fabrixxm/files/Notes/blog -o /var/www/html/blog/ || true

The script first cds into the folder, to allow blag to find its configuration, then cleanup output folder (it’s the fastest way to remove deleted pages/articles)

Now if I create a note in blog category (with required metadata) and I run /opt/blag/build.sh I get my blog.

But running build via ssh after editing is not what I want. So, let’s…

Automate the thing

Systemd can be configured to watch a folder or a file and start a service if something changes.

We need a path unit. So we now write /opt/blag/blag-rebuild.path:

[Unit]
Description=Watch blog source for changes

[Path]
PathModified=/path/to/nextcloud/fabrixxm/files/Notes/blog

[Install]
WantedBy=multi-user.target

Now we need a service to run build.sh. If a .service has the same name as the .path unit, systemd knows what to do.

Here is /opt/blag/blag-rebuild.service

[Unit]
Description=Rebuild blog
After=network.target

[Service]
Type=oneshot
ExecStart=/opt/blag/build.sh

[Install]
RequiredBy=blag-rebuild.path

Eeasy-peasy.

Now we install the units and start the watching

# ln -s /opt/blag/blag-rebuild.service /etc/systemd/system
# ln -s /opt/blag/blag-rebuild.path /etc/systemd/system
# systemctl enable --now blag-rebuild.path

The attentive reader will have noticed that the blag build command in the build.sh script ends with || true. That is because if build is triggered while we are editing something in Notes and it fails, the unit will be in ‘failed’ state and will not be triggered anymore. Could be this configured in the unit file? Maybe. It was faster just to swallow any error return value in the script. Output logs will be registered anyway by journald.

Conclusion

That’s it. Now I can write a Note and have it published in this blog. This is exactly how this post has been written:

I can also directly upload images!

Note

Some things weren’t so straight to set up:

blag package in Debian 12 is a little old and doesn’t work correctly and doesn’t come with default theme templates and static files. So I downloaded latest source code and run that instead.

I also copied out static files and templates into /opt/blag/static and /opt/blag/templates (as expected by the code) to fix some issues in templates (most of the links were absolute which is not good when your blog is in a subdirectory) and customize things around.

Sometimes Nextclouds saves the note too fast and the service unit fails with Failed with result 'start-limit-hit'.. I need to find a fix for this.

I’m quite pleased with the results. Now I need to write more 😁

Update

2025-01-21 The build script has been updated

As someone noticed, the build script as it is will delete the blog before building it. But if the build fails, no more blog! Here is the updated version:

#!/bin/bash
set -e

SOURCE="/decrypted/nextclouddata/fabrixxm/files/Notes/blog"
DEST="/var/www/kirgroup.net/blog"
BUILDDIR="/tmp/blog"

HERE="$(dirname "$0")"
cd "$HERE"

rm -fr "$BUILDDIR"

if blag build -i "$SOURCE" -o "$BUILDDIR"
then
    rm -fr "$DEST"
    mv "$BUILDDIR" "$DEST"
fi

This will build the blog in a temp folder, and only if it builds successfully the blog folder is removed and replaced by the new version.