At some point we all want to store Docker images and volumes on a different drive, to avoid the system drive being filled up as the volumes grow. Here’s how.
For a while now Google has been collaborating with SkyWater Technology to create what many refer to as free and open source silicon (FOSSi). The project gained traction in 2020 and is continuing to gain momentum.
The proclaimed goal is to bring chip design to the masses and enable everyone from academia, industry and makers to create their own computer chips. If this plan succeeds it would mean a considerable shift in the chip industry which traditionally is very secretive and dominated by just a few big corporations and their partners, connected by a opaque web of interdependencies. (Surely Google counts as the underdog in comparison *cough*)
For a long time now I run an AWS Lightsail VPS serving as a wireguard gateway to my home server. Since recently connecting to the Lightsail instance via wireguard is no longer possible.
When I took a look with SSH I got
$> sudo wg-quick up wg0 [#] ip link add wg0 type wireguard RTNETLINK answers: Operation not supported Unable to access interface: Protocol not supported [#] ip link delete dev wg0 Cannot find device "wg0"
To be sure I updated all packages, but the problem still persisted.
The port used by wireguard had not changed and still was accessible according to the network settings of Lightsail.
What change in the Lightsail VPS or network settings could cause an issue like this? It literally just stopped working over night.
This is a very brief article or rather a reminder to myself, about how to install MiniDLNA on Ubuntu Server 20.04. I always knew this piece of software by it’s old name MiniDLNA, but apparently it was renamed and is now called ReadyMedia. There don’t seem to be many changes below the hood though.
MiniDLNA is a light-weight media server using the DLNA protocol. Through MiniDLNA a library of media files is created which allows a user to very conveniently browse through the files and start audio and video playback. Most SmartTVs and Android phones support DLNA out of the box.
It is sometimes desirable to bring a Wireguard interface up each time the system boots. Using
wg-quick it is dead easy to create a service which takes care of the required steps. In case wg0 is already up and running, it must be taken down before the service can start successfully.
$> sudo systemctl enable email@example.com $> sudo systemctl daemon-reload $> sudo wg-quick down wg0 $> sudo systemctl start wg-quick@wg0
Since Windows 10 version 1709 (“Fall Creators Update”) neither SMB1 nor NetBios device discovery is supported anymore.
Due to this change a Samba share which is hosted on a Linux machine may no longer show up in the Network view of Windows Explorer.
Although the Samba share can still be reached by it’s hostname or IP address (and share name) this is a slight inconvenience.
Luckily there is a small Python tool called wsdd which provides a Web Service Discovery (host) daemon. What follows is a short guide on how to install and use wsdd on Ubuntu Server 20.04 (works similar for other Debian based distributions).
Recently I migrated my home NAS from OpenMediaVault to Ubuntu Server.
The reason for this was some major issues after upgrading from OMV4 to OMV5. After spending a lot of time to figure out what’s wrong with my NAS after the upgrade, I figured that the main advantage of using OMV (less maintenance) had become an disappointment. So the decision to migrate to Ubuntu Server was made.
Wireguard is a modern VPN protocol allowing secure and confidential communication between a network of peers. Wireguard is based on the concept of private-public key cryptography and a number of other modern cryptographic algorithms. Have a look at the wireguard white paper for more details.
Since Linux kernel version 5.6 (late March 2020) wireguard is an integral part of the Linux kernel. That means Linux distributions using a kernel >= 5.6 do not need to install any additional packages in order to support wireguard.
So my OpenMediaVault (OMV) NAS did reboot today for some reason. It didn’t manage to boot up successfully again, however, but entered “emergency mode” instead.
After some digging around it seems this is related to the combination of LUKS drive encryption and MergerFS (same with UnionFS).
For normal operation, first the LUKS drives need to be decrypted. Then the decrypted drives can be pooled together with MergerFS.
Some changes in OMV 5 (as compared to OMV 4) cause the boot sequence to enter emergency mode if not all drives in
/etc/fstab can be mounted while booting. Since the LUKS drives are still encrypted when booting, mounting those drives obviously fails. And consequently mounting the MergerFS filesystem also cannot succeed.
The issue can be patched by adding the
nofail option to all LUKS drives in
/etc/fstab and also adding the
noauto option to the MergerFS entry in
/etc/fstab. It may only be a matter of time until OMV decides to rewrite
/etc/fstab, thus nullifying the changes described above.
But since I do not reboot my NAS that often, the above patch works fine for now.