tldr: If you need shared clipboard don’t run VMs in headless-mode. During the last days at work I notices my shared clipboard in Virtualbox was not working. After checking everything I found this in the logs of the affected VM: ClipConstructX11: X11 DISPLAY variable not set -- disabling shared clipboard Why is there no DISPLAY set? Well, the VM was started in headless-mode, everything makes sense now.
ecoDMS is a very nice electronic document management server. Sadly its written in Java… It has a built-in webserver which can be configured to use HTTPS. You can use even custom certifcates, but for that you need to upload a java keystore using the client (not via webinterface). As uploading a keystore is not a good way of automation via hooks used by dehydrated (the letsencrypt-client I’m using), I was searching for a better way.
Today I realized that I forgot the password to decrypt one of my hosts encrypted using Luks. Luckily it was still running and root-access still granted. As you may know root can do anything, even reading the masterkey of your unlocked Luks-devices. By using dmsetup table /dev/mapper/supercrypt --showkeys you can get hold of the masterkey. Since you only unlock the masterkey with your password, this information can be used to modify every slot.