Archive of

Migrate whole system from one host to another

Written by Simone

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

Firstly, some preparations:

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

Then I switched to the OVH shell:

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

  • stopped all the running services

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

Mailing List for Delta Chat with mlmmj

Written by Simone

These days I am tinkering with a Mailing List for Delta Chat powered by mlmmj

I was able to create the list and set up Postfix correctly - instructions are quite clear even if on a couple settings I had to do some troubleshooting looking at logs.. Now I have this Mailing List called deltachat@woodpeckersnest.eu which you can subscribe to by sending an email to deltachat+subscribe@woodpeckersnest.eu and following further instructions.

Initially Delta Chat would create groups of people with the ML's address inside of it, thus splitting every conversation by users participating in it. This was later fixed by adding the following lines in list-dir/control/customheaders file:

X-Mailinglist: deltachat
Reply-To: deltachat@woodpeckersnest.space
List-ID: DC Mailing List <deltachat.woodpeckersnest.eu>
List-Post: <mailto:deltachat@woodpeckersnest.eu>

Now a proper Super Group is created and everyone¹ is able to message in it.

¹ Well, not actually everyone since a member still has issues but I'm positive that can be fixed by chatting again with the ML's address and removing all weird groups created earlier.

This ^ is how the supergroup looks in my chat window - the avatar is only local, it can't be set for every member but the name is the same for everyone.

Then someone "complained" for the lack of anonymity for users email addresses, like it's done in the "official" Delta Chat's MLs.. So I asked on codeberg but it seems to be a missing feature (I'm still waiting for replies 😬).

This is it for now, will keep you posted when/if I have news.

XMPP-IT Italian Community

Written by Simone

E' attiva da poche ore la nuova community Italiana XMPP-IT.net. Alcuni riferimenti:

Venite a trovarci se conoscete di già XMPP ma soprattutto se non lo conoscete ancora: creare un account è facile e sicuro e se avete qualsiasi dubbio scrivete pure un'email ad "admin@xmpp-it.net" o lasciate un commento nel sito!

conversejs stickers!

Written by Simone

Thanks Jc Brand (conversejs developer) for sending me these awesome stickers!!

Hats!

Written by Simone

In XMPP you can have "hats"! A hat is basically a label next to your nickname which can show maybe a role you have in a particolar MUC (e.g. "teacher" for a class, "manager" for an office, or "developer" for a software project and so on..). The relative XEP is https://xmpp.org/extensions/xep-0317.html

The only client where this XEP seems to be manageable, is conversejs: https://m.conversejs.org/docs/html/configuration.html#muc-hats but Cheogram can show hats as well in the participant list.

There are a couple modules needed in prosody and you can install them like so:

prosodyctl install --server=https://modules.prosody.im/rocks/ mod_muc_hats_api
prosodyctl install --server=https://modules.prosody.im/rocks/ mod_muc_hats_adhoc

This is the adhoc command in conversejs to set a hat:

You need to specify a user JID, a room JID (on your server), a Hat title (the actual label you want to be shown) and a Hat URI (a machine-readable unique identifier, like 1111-2222-abcd - this is something you make up yourself)

And this is the final outcome