An average guy's IT (mis)adventures

ntfy service

ntfy

ntfy lets you send push notifications to your phone or desktop via scripts from any computer, using simple HTTP PUT or POST requests. I use it to notify myself when scripts fail, or long-running commands complete.

With the newly installed “ntfy” service, You, as a @wpn user, have access to any topic you may need, with read and write permissions. I am going to send an email to each (shell/email) user account soon, with credentials. “xmpp” users feel free to request access to me, personally or by writing a message here.

For all other interested people, we have set a public topic up, which you can subscribe to, if you like, to be notified about @wpn services status: wpn-status, precisely 😀  and also another topic, to follow xmpp-it services status: xmpp-it-net

What can I do with it?

Usage examples are all explained in the doc. In short, you currently can:

1. Send only text (anyone said emotes!?)
2. Send text and attachments (like images)
3. Send a notification to an email address
4. Use it as your UnifiedPush service

I have tested all of the above and they are supposed to be working.. If you have any problem, please let me know (a comment here would also be okay).

Here's SchildiChatNext notifications troubleshooter:

**rsnapshot** is a filesystem backup utility for Unix-like systems that uses rsync and hard links to efficiently create incremental snapshots. It stores backups in dated directories, minimizing disk usage by linking unchanged files. Designed for automation, it supports local and remote backups via SSH.

apt install rsnapshot

/etc/rsnapshot.conf

config_version  1.2
# executables paths on your system
cmd_cp          /bin/cp
cmd_rm          /bin/rm
cmd_rsync       /usr/bin/rsync
cmd_ssh 		/usr/bin/ssh
cmd_du          /usr/bin/du
# type and number of snapshots to execute
retain  alpha   7       #7 snaps, one per day
retain  beta    2       #2 snaps, one per week
retain  gamma   1       #1 snap montly
verbose         2
loglevel        3
logfile 		/var/log/rsnapshot.log
lockfile        /home/roughnecks/rsnapshot.pid
# where to save your snapshots
snapshot_root   /mnt/backup/
# rsnapshot won't create the "root" folder of your backups. Create it yourself
no_create_root  1
# global short rsync args (feel free to adjust)
rsync_short_args        -avz
# uses hard links (keep this)
link_dest       1

# what, where and how to backup
# --rsync-path="sudo rsync" is only needed if you're backing up directories which need root access on the remote host
# --exclude-from=/etc/rsnapshot/exclude_path.list is a list of paths never to be backed up, relative to this backup only

backup  		debian@remote_host:/path/   local_path/   +rsync_long_args=--rsync-path="sudo rsync" --exclude-from=/etc/rsnapshot/exclude_path.list

# global exclusion list (directories never to be backed up)

exclude /proc/
exclude /sys/
exclude /dev/
exclude /run/
exclude /tmp/

First things first: I suggest to always use a non-root user (not even sudo, because that would be the same, right?) to execute rsnaspshot.

Make sure your user can write the lockfile and also the logfile (create paths where necessary)

Create the root dir (where to store your snapshots) with root, if necessary - (maybe inside /mnt/ ) - but give your user permissions to read and write afterwards.

Decide the number and frequency of your backups (daily, weekly and monthly is a sane default) - don't change the names “alpha, beta and gamma” in the config, because, as it is written in the comments: “Must be unique and in ascending order”

A simple backup line would be like:

backup  /var/www/       local_path/

• “backup” is the logical name
• “/var/www” is the source directory
• “local_path/” is the destination directory inside your snapshot_root

If you're backing up a direcory on a remote host, use the same syntax as the one for rsync. I also suggest making use of the ~/.ssh/config file to configure and shorten your ssh destinations (name, ports, keys).

Last piece I added in the backup line above in configuration file is used when you need to backup a directory with root permission. You can give the “normal” user “sudo” rights to use rsync command without entering a password on the remote host and then you can keep running rsnapshot locally without root

backupuser ALL=(ALL) NOPASSWD: /usr/bin/rsync

One big advice, if I may. Be sure to make an exclusion for the following directories when backing up a /home/user dir

*/go
*/node_modules
*/.cache
*/.npm
*/.nvm
*/.rustup

especially go/pkg directory creates a big mess because all of the files of the modules have no “write” (+w) permission set - for whatever reason they did it (I really don't understand this choice).. So after the first successful snap, on the second one, when the software will move e.g. alpha.0 to alpha.1, it won't have the permission to do so. It will fail and you'll need to fix it.

Useful commands

rsnapshot help

rsnapshot <alpha | beta | gamma> # manually execute one of the rsnapshots

rsnapshot configtest # syntax check

rsnapshot du # show disk usage for your backups

scheduling

I'm using crontab to schedule rsnapshot, like this:

# Run rsnapshot alpha every day at 2:00 PM
0 14 * * * /home/roughnecks/scripts/rsnapshot-alpha.sh

# Run rsnapshot beta every monday at 3:00 PM
0 15 * * 1 /home/roughnecks/scripts/rsnapshot-beta.sh

# Run rsnapshot gamma the first of every month at 4:00 PM
0 16 1 * * /home/roughnecks/scripts/rsnapshot-gamma.sh

I actually run those mini shell scripts because I'm also sending notifications about successful/failed backups via ntfy

Here's one of them, the other ones are copy-pasted with different frequency:

#!/bin/bash

rsnapshot alpha

if [ $? -eq 0 ]; then
    curl -d "rsnapshot alpha successful! 😀" ntfy.myserver.tld:port/tag
else
    curl -d "rsnapshot alpha failed?! 🤔" ntfy.myserver.tld:port/tag
fi

That would be all. Hope it's been useful

gemlog

I've had my hands full in the last few weeks.. let's see what's new for @wpn

1. First of all, I removed some #DNS records (and related services), namely:

laltrowiki (our (me and old friends) wiki didn't really fit with @wpn - I'm keeping it for myself)

trilium (note-taking app which I kept on @wpn, but was only personal.. Now it's hosted at home)

grocy (pantry/shopping aid app, same as trilium above)

2. Have upgraded plugins for roundcube #webmail and FreshRSS, #RSS reader. Main services are always up-to-date, while these were some additions due from time to time.

3. Have done some tinkering with this blog's and xmpp-it homepage's #sqlite DBs: if you're interested, follow here

4. Have installed and then removed 2 #gemini to #html #proxies, because I believe the one I've been (and still am) using so far, is the best one. I also tweaked its stylesheet a bit. The two proxies I tried are september and kineto, while the one currently in use is loxy

5. I have first upgraded uptime-kuma to V2 Beta but then backed it up and moved to gatus, which lacks some features but it's also lightweight and straightforward. During the process we lost webhooks live notifications (about services status) for XMPP chatroom, so I have also installed ntfy server and related Android app, but, obviously, I'm currently the only one to see those. If any of @wpn users is interested, I can share info about the "topic", server's "address:port" and such. For the time being everything is in plain and without authentication.. Don't think that @wpn's services status notifications are so "sensible" info to require encryption, so I didn't even bother 😀

6. It's "6" already.. wow!

transmission-daemon was replaced by good-old rtorrent and that also got a web-ui, which only myself can access so far.

All of the aforementioned changes and fixes were mainly meant to reduce the load on the machine, in order to provide a better experience for everyone. Things still look complicated though, because even if there was a significant decrease in RAM usage, CPU, on the other side, seems almost worsened - and I still can't explain that, apart from thinking contabo maybe doing oversubscription of resources on their host.

Last 2 things, then I'll shut-up! 😁

• Some of the users' home directories (only the ones which belongs to me or are system-related users account) are now backed-up via rsnapshot to my #homelab. I intend to write an how-to on that topic, further ahead in time, because I'm still testing/figuring it out.

• The onboarding tool has got a new checkbox for (legal) age verification.

That's it. Feel free to tale a "tour" if you're new or haven't had the chance yet: https://woodpeckersnest.space/

See you soon!

Hello,

this is going to be a little how-to configure aerc (a console mail client) in your @wpn shell - applies to other shells / mail servers as well, but it will be tailored for @wpn users.

aerc configuration is interactive as soon as you start it for the first time, but it will store your mail password in clear text inside ~/.config/aerc/accounts.conf file. We want instead to use the standard Unix password manager, pass, to encrypt it.

First you need a GPG key, which will be used to encrypt imap/smtp passwords. There are 2 ways:

1. Import an existing private key
2. Create a new keypair on @wpn and use that

Let's start:

$ gpg-connect-agent /bye # initializes the gpg-agent 

If you see the following lines (you should), everything is good.

gpg-connect-agent: no running gpg-agent - starting '/usr/bin/gpg-agent'
gpg-connect-agent: waiting for the agent to come up ... (5s)
gpg-connect-agent: connection to agent established

GOTO 1) to import an existing key

GOTO 2) to create a new key

GOTO 3) when 1) or 2) are done

1. To import your secret key you have to first copy it from your PC to the server. Use FTP/WEBDAV or SCP: all of them are supported, suit yourself.

$ gpg --import roughnecks_SECRET.asc # import the key named, in this case, "roughnecks_SECRET.asc"
$ gpg --list-secret-keys # verify that your key is there and copy its ID (needed later)
$ gpg --edit-key [key-ID] # see previous step. You have to manage key's trust

type: "trust" # without the quotes
type: "5" # for ultimate trust
type: "save" # to save and exit

Now you can delete your file key, since it's not needed anymore

$ shred -u roughnecks_SECRET.asc # securely delete key file

2. To create a new GPG key follow these steps:

$ gpg --full-generate-key

Specify parameters for your key (default are ok); for key expiration date I would recommend from 1 to 2 years, so you'll have to type respectively "1y" or "2y", but feel free to choose by yourself. Next, enter your information: name, email and comment (optional). Last step is to create a passphrase and then the system will generate the keys. List them when done and copy the ID (for later use):

$ gpg --list-keys # list your newly created keys

3. Now that GPG keys are set up, we will store our mail password and proceed to configure and start aerc

$ pass init [your-gpg-ID] # the one you copied earlier in any of the steps, 1) or 2)
$ pass insert email/woodpeckersnest.eu/imap # don't modify anything, enter your email password
$ pass insert email/woodpeckersnest.eu/smtp # same as above, don't modify anything, enter your email password

We're going to create aerc's account configuration file now, bear with me.

This is a sample config, for you to edit:

[@wpn]
source   = imaps://username@woodpeckersnest.eu
source-cred-cmd =       pass show email/woodpeckersnest.eu/imap
outgoing = smtps://username@woodpeckersnest.eu
outgoing-cred-cmd =     pass show email/woodpeckersnest.eu/smtp
default  = INBOX
from     = username <username@woodpeckersnest.eu>
copy-to  = Sent

You can personalize [@wpn] with anything you like inside the square brackets (it's your aerc profile's name)

You MUST change every "username" occurrence with your actual email localpart (the part the comes before the @ symbol in your email address, actually the username you registered at @wpn); the first "username" occurrence in the "from" line can be your real name or whatever you want to show to your correspondents, for your contact name, e.g. from = Simone <roughnecks@woodpeckersnest.eu>.

Copy the config you just edited and..

$ mkdir ~/.config/aerc # create a directory for aerc
$ nano ~/.config/aerc/accounts.conf # paste the snippet you copied above to this file, save and exit
$ chmod 600 ~/.config/aerc/accounts.conf # set correct permissions for your accounts file

Now you can finally launch "aerc" and type your GPG passphrase:

$ aerc

YAY, email! 😍