An average guy's IT (mis)adventures

prosodyctl shell

Launch the shell:

# prosodyctl shell

Delete pubsub node (the ">" sign at the beginning is important):

>prosody.hosts["pubsub.example.tld"].modules.pubsub.service:delete("blog", true)

Delete ALL pubsub nodes

>local service = prosody.hosts["pubsub.example.tld"].modules.pubsub.service; for node in pairs(select(2, assert(service:get_nodes(true)))) do service:delete(node, true); end

Check subscription by user:

>prosody.hosts["pubsub.example.tld"].modules.pubsub.service.subscriptions["user@example.tld"]

Change affiliation on pubsub nodes (make user owner):

>prosody.hosts["pubsub.example.tld"].modules.pubsub.service:set_affiliation("blog",true,"user@example.tld","owner")

Unsubscribe from node

>prosody.hosts["pubsub.example.tld"].modules.pubsub.service:remove_subscription("blog",true,"user@example.tld")

Subscribe to node

>prosody.hosts["pubsub.example.tld"].modules.pubsub.service:add_subscription("blog",true,"user@example.tld")

prosodyctl commands

Asking for help:

# prosodyctl shell help

List registered users:

# prosodyctl shell user list example.tld

Activate a component:

# prosodyctl shell host activate some.component.example.tld

Generate Invites: create a new invite using an ad-hoc command in an XMPP client connected to your admin account, or use the command line:

# prosodyctl mod_invites generate example.tld

Automatic Certificates Import: prosodyctl has the ability to import and activate certificates in one command:

# prosodyctl --root cert import HOSTNAME /path/to/certificates

Certificates and their keys are copied to /etc/prosody/certs (can be changed with the certificates option) and then it signals Prosody to reload itself. –root lets prosodyctl write to paths that may not be writable by the prosody user, as is common with /etc/prosody. Multiple hostnames and paths can be given, as long as the hostnames are given before the paths.

This command can be put in cron or passed as a callback to automated certificate renewal programs such as certbot or other Let's Encrypt clients.

Import All:

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

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.

Here are a few tweaks that make my "converse.js" experience better:

Remove link from banner: I accidentally used to click that and be teleported to converse.js official webclient, so I thought it could be misleading for unaware users using my locally hosted version of the software.

Search and replace/remove the href bit in converse.min.js, under the dist directory:

<a class="brand-heading" href="https://conversejs.org" target="_blank" rel="noopener">

In the "converse.min.css" file, search for this string and fill it with the following code to have unread MUCs underlined and colored in red:

.list-item.unread-msgs

.list-item.unread-msgs{font-weight:700; text-decoration: underline red;}

Fix color for toolbar-utilities when in 1:1 chats: find this line in "converse.min.css"

.fas:hover svg{fill:var(--chat-head-color)}

and replace with:

.fas:hover svg{fill:var(--chat-toolbar-btn-color)}

Raise minimum chat text area: find this bit in "converse.min.css"

min-height:var(--chat-textarea-height);

and replace with custom value in pixels, e.g.

min-height:120px;

Set a smaller line height for chats list: find the first occurrence of this code in "converse.min.css"

.conversejs .items-list .list-item

and continue until you find:

height:2.5em

substitute it with something like height:2.0em

Removing a space in quoted reply for "actions" plugin: find the following string in your conversejs/dist/plugins/actions/action.js

return ">" + nick + ' : '

remove the offending space

return ">" + nick + ': '

Changing from :smiley: to :thumbsup: emoji for the "Like" actions plugin function: find the following string in your conversejs/dist/plugins/actions/action.js

actions_reactions: [
                                    {name: 'like', label: 'Like', emoji: ':smiley:', icon_class: 'fa fa-check'},

and replace with:

actions_reactions: [
                                    {name: 'like', label: 'Like', emoji: ':thumbsup:', icon_class: 'fa fa-check'},

Today I wanted to install yet another web frontend for the services I host, i.e. mumble-web

mumble-web is an HTML5 Mumble client for use in modern browsers.

I won't bore you with the install details, just know that it's basically JS and you need to install npm modules.. After some processing and a whole lot of deprecation warnings on screen, it finally failed. Then I looked at the logs it left and it was searching for python2!! Went back to the github page and found out the code is from about 3 years ago, with the latest issue being about one guy managing to build the software on Debian 11 with some old NodeJs version..

So, after a bit of disappointment, I delete the whole directory and be done with it. You know, there's no alternatives out there 😟

Now I would like to ask a question to disroot admins: how the hell are you running this junk on your server!? I believe they're using docker, still it's not safe in my opinion to run such old-unmaintained stuff.

I won't be doing that.

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 <service>

• 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 <new-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

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 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/