By default LXD creates an internal network bridge called lxdbr0 which new containers are attached to (a network bridge in Linux is similar to a physical LAN switch). That way containers can talk to each other on the same network. Even the LXD host is connected to the same bridge. To make a service in a container reachable from the outside world, a proxy is used in most cases, e.g. Nginx for web services and HAProxy for any other services.
But what if you cannot or do not like to connect a service via a proxy? No problem! LXD can not only make use of a “host internal” network bridge, but any network bridge on your system. So let’s set up a network bridge that is linked to a public interface! The container’s network configuration will be similar to the one on your container host. A public IP address can be used directly.
Maybe some day in your Linux career you’ve heard of “tiling window managers”. I’ve (more or less) ignored them for many years, because I was happy with Gnome Shell and the “normal” way of handling applications on my screen. But when I started my new Linux job, there were no native Linux machine available for my work, so I had to use VirtualBox with its bad graphics performance. Using Gnome, KDE or any other Desktop environment was not really practical.
To get reasonable performance I needed a very lightweight windows manager with no effects and no other fancy stuff, so I ended up giving tiling window managers a try. Since then I’ve used i3 window manager at my job’s workspace. On my private laptop I chose for “Sway”, because it natively supports the Wayland window protocol (and I like Wayland ;-) ). Sway is quite similar to i3, e.g. basic window control keys are almost the same. Still there are some differences, such as configuration of keyboard and mouse.
In this article I’ll show you some parts of my personal Sway configuration and point out several tools that will be useful in your daily work. This is no complete guide which goes into details of installing every tool! Instructions for installation can be found on the projects' websites.
I’ve been using Restic backup on several servers for more than a year now. As the software turned out to be very reliable and fast I decided to give it a try on my laptop. Until now I had to trigger my backup mechanism by hand every day, but as you can image this is not a very reliable way to make backups.
Today I looked for a way to automate Restic backups on my laptop while keeping the mechanism easy and inconspicuous. In this post I’d like to introduce you to my personal backup solution.
As you might know, I’m running metalhead.club, a Mastodon instance for metalheads. Due to the increasing storage and computing demand (and because I wanted to drop my old host) I decided to move the instance to my new, more powerful host. Luckily I’ve packed the whole instance and all its dependencies into a LXC container (with LXD as container manager) a couple of months ago. Usually you would restore your Ruby / NodeJS environment on your new host, transfer database and application files as well as media files and make sure everything fits. In my case it was basically just a file system transfer and re-import on the new LXD host: Much easier and less error prone.
In this post I’ll show you the exact steps how I moved my Mastodon instance yesterday.