Managing dotfiles using stow

One thing that’s always a bit of a pain when you use multiple computers, or when you want to reinstall your computer at some point in time is that you have to recreate your configuration files or ‘dotfiles’ to have everything back as you want again.

There are several ways of doing this, but recently I came across a little tool called GNU stow. It is a much easier way of managing dotfiles than for instance using a git bare repository.

How stow works, is you create “stow directory”, in my case dotfiles. Inside that directory you can create further directories for “packages”. For this use, a “package” is basically a collection of files that belong together. Example: a bash directory would store all your bash configuration files like .bashrc, .bash_fucntions, .profile, etc..

Once you have your “package” directory, you can move your dotfiles for that “package” into that directory. (move, so they are no longer in their normal location). If you now call stow with the package name, for instance stow bash it will create symbolic links from all files to their original location.

If you have files under ~/.config then you will need to create a .config directory under your package directory, and then move the files or directories that contain your files under there.

For instance, I have a “package” fish, which has the following structure:

~/.dotfiles/fish/.config/fish

And under ~/.config you will find a symlink called fish to that directory.

So the structure is basically this:

  • Stow directory
    • Package directory
      • files relative from your home directory, ie ~/<file>
      • directories relative from your home directory, ie ~/<dir>
        • files relative from previous directory, ie ~/<dir>/<file>
        • directories relative from previous directory, ie ~/<dir>/<dir>

Running stow on a package will link to files and / or directories starting from your home directory down. If a subdirectory is put in there, like the bottom one above, it will use the highest common directory entry to link to.

Once you have your structure set up under your stow directory, you can simply go into your stow directory and issue the command stow * or stow packagename and all links will be created.

If you then add your stow directory to a git repository, all you would have to do on a new system or when setting up after install is to clone that repository, make sure you have stow installed and issue the command above to have your setup restored.

Finally, as a little bonus, I created a little fish shell function because I am lazy and don’t want to cd back and forth all the time to make it easier for me to create the links for a “package”. I use fish shell, but the example below should be easy enough to refactor to bash or zsh functions if you use those.

function dotfiles --wraps="stow"
    if [ -z $argv ]
        echo "No argument given; exiting"
    else
        set _oldpath $PWD
        cd ~/.dotfiles
        stow $argv
        cd $_oldpath
    end
end

In conclusion, it take a little bit to set up but once that is done, it is very easy to maintain and setting up your profile configuration becomes so easy.

Example layout of my dotfiles directory:

alacritty:
Permissions Size User            Date Modified Git Name
.rw-r--r--   355 throttlemeister  2 Aug 23:26   -- .alacritty.toml

bash:
Permissions Size User            Date Modified Git Name
.rw-r--r--  1.0k throttlemeister 11 Jun  2023   -- .bash_aliases
.rw-r--r--  1.1k throttlemeister 11 Jun  2023   -- .bash_functions
.rw-r--r--   220 throttlemeister 11 Jun  2023   -- .bash_logout
.rw-r--r--    92 throttlemeister 11 Jun  2023   -- .bash_profile
.rw-r--r--  4.3k throttlemeister 11 Jun  2023   -- .bashrc
.rwxr-xr-x    30 throttlemeister 11 Jun  2023   -- .inputrc
.rw-r--r--   723 throttlemeister 11 Jun  2023   -- .profile

conky:
Permissions Size User            Date Modified Git Name
.rw-r--r--   11k throttlemeister 13 Aug 23:32   -- .conkyrc

fish:
Permissions Size User            Date Modified Git Name
drwxr-xr-x     - throttlemeister 17 Sep 14:25   -- .config

git:
Permissions Size User            Date Modified Git Name
.rw-r--r--   166 throttlemeister 17 Sep 16:48   -- .gitconfig
.rw-r--r--     4 throttlemeister 11 Jun  2023   -- .gitignore

zsh:
Permissions Size User            Date Modified Git Name
.rw-r--r--  4.6k throttlemeister  2 Aug 23:15   -- .zshrc
.rw-r--r--   374 throttlemeister  2 Aug 22:45   -- .zshrc.pre-oh-my-zsh

KDE Plasma 6: Don’t be fooled by the naysayers on the internet

About a month ago, KDE released their much anticipated next major release of the KDE desktop environment, version 6. The only distributions using it soon after were (obviously) KDE Neon – the KDE showcase / development platform, and the rolling release distributions like Arch and OpenSUSE Tumbleweed. The scheduled release distributions will only ship KDE6 in their next new release.

As it was released, obviously there were some teething problems despite a long and extensive beta test cycle and lots of bigfixing. Some of these were:

  • Upgrade being interrupted if done from the GUI, as the session was killed, halting the upgrade process. Easy fix: just restart the upgrade and it will finish. If doing a reboot, because you didn’t notice there was a problem, you would end up without a GUI. The best way to upgrade, was to switch to a TTY screen and upgade from the CLI without a GUI running.
  • Sometimes, especially with a custom SDDM theme selected, the SDDM screen would fall back to a very ugly UI and an error. This was not critical and setting SDDM to the default breeze theme typicall fixed this.
  • If you used custom themes, plasmoids, plasma addons etc, these could potentially be incompatible with KDE6 and refuse to load. This is annoying but to be expected. Just unload and remove or upgrade. Currently most have been upgraded to work with KDE6, provided they are actively maintained.
  • The default session was changed from X11 to Wayland for all users, including those with Nvidia hardware. In some cases this could cause some issues with Wayland not loading but X11 would generally still work.

For me personally, the experience has been great despite experiencing the first 3 from the above list. They were annoying when it happened but easily fixed. Since the experience has been smooth, my addons have been upgraded by their maintainers and the Wayland experience has been very smooth. I’m not the biggest fan of Wayland myself (perhaps I will write about that at some point), but it is the future and having to live with it like it is now with KDE6 is not punishment.

KDE Plasma 6 has been a great experience for me. It has sane defaults. The tweaks in certain settings and places are very good – example: the panel configuration, thank you KDE team – now you don’t need a degree to decipher what some of the things mean.

It’s more of an evolution than a revolution going from KDE5 to KDE6, but what an evolution it is. The best desktop just got better.. And smoother. And more polished.

Transactional updates on OpenSUSE Tumbleweed

It’s possible to use transactional or atomic updates on OpenSUSE Tumbleweed and leveraging the snapshot capabilities of btrfs. It’s actually quite simple; all you need to do is to install the command using zipper.

Prerequisites: the filesystem must be btrfs.
sudo zypper in transactional-update

This will install the command. Next you want to set up some, to prevent some potential issues.

# this systemd service is required to create RPM dirs in /var as TU does not mount /var in the new snapshot to maintain atomicity.
systemctl enable --now create-dirs-from-rpmdb.service

That’s basically it. Now if you run the command:

sudo transactional-update

The system will create a new snapshot, check for updates, install updates on that snapshot and set that snapshot to boot. If there are no updates, the snapshot is removed again.

Keep in mind, and this is important: any changes you make to the root filesystem will be gone after you reboot into the new snapshot.

This is expected behavior, but it does mean if you want or need to make changes you need to make sure you reboot first.

Why would you want this? If you need to apply a big update and you don’t want it to interrupt your work or avoid processes being restarted, you can apply the update on a new snapshot without it interfering or making changes in any way on the running system.

Is it necessary? Absolutely not. It is just another tool in the toolbox. It offers some of the advantages (atomic updates) of an immutable distribution, without having to have an immutable (read-only) filesystem.

OpenSUSE Tumbleweed, 6 months in

Well, here we are, 6 months after installing OpenSUSE Tumbleweed and still no urge to change. The only change I am longing for is the update to KDE Plasma 6, which should be coming soon now that it has officially been released.

Since there are basically no updates since my last post in December, there isn’t much to say. I did however made some changes. A couple of weeks ago, my GTX1080 decided to shit itself such that it triggers the short protection in the power supply so that’s out. Bit of a pain since everything is water cooled. I ended up replacing it with a Sapphire R9 390 Nitro which is an AMD based card. Raw speed is about half of that of the GTX1080, but at 50 euros it was cheap and being AMD means no more Nvidia issues on Linux as limited as they were for me. Main issue for me was that I had to manually recreate the initrd whenever a new driver version was released to make it work.

Routing of the watercooling soft tubing looks like crap now, but hey, its working again and at least I can use my machine again.

Changing from Nvidia to AMD was a bit of a pain as I had to remove all Nvidia related packages and I had to manually set the correct kernel parameters to make it work. After that it was painless and working just fine. Drivers are part of the kernel, so no more issues there. Test benchmarks suits show lower fps as to be expected, but also smoother and less jerky graphics. I don’t game that much, so I guess I’ll be fine for now. Would love me some 6700XT or something.

Tumbleweed keeps on rocking.

OpenSUSE: 4 months in

Maybe it is time for a little update, even if there is not much to say. After 4 months of running OpenSUSE Tumbleweed, I can honestly say I have not had a single moment where I’d thought I should maybe look for another distribution because XYZ is getting too annoying.

Of course it does have some annoyances. Some are with me, like running systemd-boot while it is not officially ready for primetime yet. Others are with OpenSUSE or my setup, like sometimes an update will bork the system and I have to do a snapper rollback. Fortunately, OpenSUSE makes this a 2 minute job and so far, rolling back the update and installing it again is all that is needed to fix the system and the update.

Other than that, I can’t even really think of anything. It just works. It runs, it runs fast, I have all the latest packages as you can expect using a rolling release and I just get to enjoy using my computer and play around with it. Both my desktop as well as my laptop.

It’s nice to be able to use the computers without this itch or little doubt that makes one go and look for greener pastures.

I’m still impressed, really impressed with OpenSUSE. More should be using it, it really is that good. And a bit of counterweight to the giants like Canonical and Redhat would be nice too.

Have a good one.

systemd-boot on OpenSUSE

I am weird sometimes, I know. Ever since I used Pop!OS, which uses systemd-boot as default boot manager, I have fallen in love with it. The simplicity and speed of systemd-boot versus the complexity and bulk of GRUB2 just won me over.

Mind you, GRUB2 is very good at what it does. It’s just that I don’t need all it does. All I need is to boot my machine, nothing more, nothing less. My laptop, on which I am typing this, only has OpenSUSE installed. No dual boot, nothing. My desktop boots OpenSUSE and FreeBSD at the moment, but they do so from seperate disks with their own bootloader. Nice and simple.

Neither need the features of GRUB2.

That said, changing the bootloader is tricky. It’d be nice if OpenSUSE would let you pick systemd-boot at install, so you don’t have to muck with it. However, since end of September, OpenSUSE officially supports systemd-boot.

So, I just had to have it, starting with my laptop.

HOW-TO

Note: I do not use secureboot. Do not blindly follow this tutorial if you are using secure boot: it will break your system. You can do it, but it requires more steps then I will outline here.

First, check if /usr/lib/bootloader/systemd-boot exists. If it does, you’re good.

Remove all OpenSUSE entries from the EFI boot menu, and all others you do not need:

# efibootmgr --delete --label opensuse-secureboot

Do this for each entry you do not need or want. You can see what entries there are by just typinge efibootmgr without any options.

Next we want to update the configuration, so it knows we are going to use systemd-boot.

# vi /etc/sysconfig/bootloader 

Change from (probably) LOADER_TYPE="grub2-efi" to LOADER_TYPE="systemd-boot"

Install the systemd-boot utils to add support for snapshots. We are running OpenSUSE, we do want support for our automatic btrfs snapper snapshots.

# zypper in sdbootutil-snapper sdbootutil-rpm-scriptlets

If zypper complains that it needs to remove GRUB2 to do this, confirm by choosing the solution that will do so. It will both add all the files required for systemd-boot to function and remove all grub2 related files that you will not be using anymore.

Then we want to install our kernels, including snapshots so we can actually boot as we do not have a bootmanager installed right now!

# sdbootutil install
# sdbootutil add-all-kernels

Now we’re done. Systemd-boot is installed, GRUB2 is removed and we can reboot our system and enjoy a fast and less bloated setup. If you want to get to the boot menu to boot from a snapshot, just hold the spacebar while booting and it will pop up.

Issues / challenges

  • Initrd / ramdisk does not get updated after installation / update of kernel drivers, ie NVIDIA graphics drivers. This can be solved by manually generating a new initrd file and copying it to the appropiate location, replacing the old one but should really be done automatically. Bug is filed.

Interesting (or: first tiling windows manager experience)

The other night, I was playing around watching YouTube videos and was watching this one video from Brodie Robertson on how he was now using Hyprland as his daily driver. Usually, I just zone out to other tasks when the topic gets to a tiling window manager, as it is not for me: I have a ultrawide screen on my desktop, with a 3440×1440 resolution and trust me, you do not want to run console fullscreen.

But, as I was sitting with my laptop in my lap which obviously has a more common resolution display, I thought what the heck. Let’s see if OpenSUSE offers Hyprland in its repos and see what it’s all about.

Well, it was in the repos and to my suprise it didn’t suck. I mean, I still prefer a normal desktop for desktop tasks, but for managing my network and homelab from my laptop, where I pretty much live in (multiple) terminal sessions and a some of browser tabs on a different workspace, this works. And pretty good too, with great focus on what you need to achieve.

I like, again to my suprise

On a sidenote: does anyone know how to use tiling window manager on a ultrawide screen, where you do not want a single application to go fullscreen, but remain restricted to just part of the screen – let’s say a third of the screen. Or top/bottom half vertically and a third horizontally. Having essentially two screens side by side in a single panel is a dream from a screen real estate point of view, but its a nightmare for using a tiling window manager imo, especially if you take care organizing your windows.

The end to distro-hopping?

Since I have moved to running Linux basically full time, I have ran Pop!OS, Fedora, Nobara, back to Fedora KDE Spin and now OpenSUSE Tumbleweed. All of them are good distributions and none have any real deal-breakers for me not to want to use them.

The fact that I really, really like Tumbleweed was not a given. Quite the contrary. OpenSUSE does it’s own thing, so it is a bit of a learning curve if you are used to Debian-based or RedHat-based distributions. It is one of the oldest distributions still operating today, which puts it in the same company as Debian and Slackware. The latter actually being the initial origins for (then) SUSE Linux.

But I digress. My experience with SUSE in the past (=20 odd years ago) was less than favorable to the point that I abandoned it and never really looked at it again until now. Installation was painless and it let you choose your desired desktop environment as part of the installation procedure. I run KDE, which is the first option and let it do its thing.

After install I was back in business. Mind you: I have /home on a seperate disk, so all I have to do when reinstalling or using a new distribution is to make sure that drive is mounted on /home and I have all my (program) settings back and my desktop just looks the same as before. Saves me time to set everything up the way I want again and no data loss when doing a reinstall.

Some observations after installing OpenSUSE Tumbleweed:

  • Using OpenSUSE means using BTRFS right: proper subvolumes upon install, snapper configured out of the box to create snapshots when installing software and updates and grub configured to be able to boot from previously created snapshots so you can rollback if something happens to go wrong. No more worried about effing up your system
  • YaST2 is a very useful tool. It let me configure and add my iscsi targets in 2 minutes tops and it connects automatically on boot again, whereas most other distributions make that a painful, manual task that requires workarounds to mount your drives after a reboot. I don’t really need a GUI tool to configure my systems, but this tool lets you configure all aspects of the system and sometimes it is just faster doing it once in the GUI than to do it manually.
    Note: the original YaST is the reason I quite SUSE years ago and never came back. Different story.
  • It has a huge repository of programs, including non-FOSS if you add the packman repos. And if you install opi (openSUSE Package Installer) you have the entire OBS (OpenBuild System) at your finger tips, including user repositories. Basically you have the OpenSUSE equivalent of Arch’s AUR.
  • Installation of proprietary drivers and codecs is easy and painless, as with most distributions. That said, I think OpenSUSE is the only distro where the Nvidia drivers come straight from a repo at Nvidia.
  • It’s (Tumbleweed) a rolling distribution, so always the latest software but it is better tested than something like Arch. This means less issues are likely to arise.

Some inconveniences I ran into:

  • Both my laptop and desktop were unable to load Wayland and had to use Xorg. This is not a big thing. This was caused by a SDDM bug where the SHELL variable got messed up if you use the fish shell as you login shell. This has been fixed by the KDE team in ’21/’22, but the fix was never backported to OpenSUSE by the OpenSUSE team. Workaround was to change the login shell to standard bash, and just tell the terminal app to start with the fish shell. Now I can run Wayland on my laptop, while still using Xorg on my desktop as it work just works better with Nvidia graphics. But it will run Wayland if I want to.

Other things I did after installing Tumbleweed are not OpenSUSE specific things, but more generic Linux optimizations I have made.

  • I used tuned with tuned-adm to select and set an appropriate tuning profile for my systems.
  • I have set up a couple scripts for my laptop to switch profiles and CPU modes depending on if the laptop is running on AC power, or battery.

When running on AC power:

#!/bin/bash
#
# Set CPU governor to powersave
if [ -e /usr/bin/cpupower ]; then
	sudo cpupower frequency-set --governor performance
    sudo tuned-adm profile latency-performance
else
    echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
    sudo tuned-adm profile latency-performance
fi
# EOF

When running on battery power:

#!/bin/bash
#
# Set CPU governor to powersave
if [ -e /usr/bin/cpupower ]; then
	sudo cpupower frequency-set --governor powersave
	sudo tuned-adm profile powersave
else
	echo powersave | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
	sudo tuned-adm profile powersave
fi
# EOF

These are set in KDE settings under power management, see screenshot:

  • On the desktop, I just set the tuned profile to latency-performance using tuned-adm. This is a profile that aims to prioritize latency over throughput, which is great for desktop use with a GUI.
  • I also set some sysctl parameters as outlined in another post.

Like I said, these are not Tumbleweed or OpenSUSE specific optimizations or even necessary, but it is how I prefer to set up my systems. I feel it helps me to squeeze out the most performance out of my systems, and in the case of the laptop, preserve battery life when needed.

When all is said and done, I really like OpenSUSE Tumbleweed. I like the bootable snapshots. I like having the latest versions of different software without having to wait for a next release. I like the tools provided to admin the system. It’s a good’un. I think I’ll keep it. Then again, I said that of Fedora. And Nobara. But I do think it is true this time.

Running redundant AdGuard@Home DNS servers on Synology

This is a quick post on how to run multiple instances of AdGuard@Home on a single Synology host using Docker.

Problem: you cannot easily, using Docker, run multiple instances of the same program - or different program - while listening on the same port.

Solution: do not use host or bridge networking, but put the container on the same network as the host using macvlan.

To achieve this, we need to do the following:

Prerequisites

  1. Find the name of the network interface your Synology is using to connect to the network you want your Docker containers to be running on. This can be for instance eth0 for a single interface, or bond0 for when you use channel bonding. You can find this under Control Panel > Network > Network interface. In my case, this is bond0 which is what I will use in the examples below.

Configuring the interface

Now we have to configure the interface Docker can use. We do this by adding a bridge on top of the existing physical interface you use on your network.

  1. ip link add macvlan-br0 link bond0 type macvlan mode bridge
    This adds a bridge device on top of the physical interface with the name macvlan-br0
  2. ip addr add 192.168.0.254/32 dev macvlan-br0
    This adds an IP address on the bridge device so the host has an IP address in the range will give to Docker
  3. ip link set macvlan-br0 up
    This will activate the virtual bridge device
  4. ip route add 192.168.0.192/26 dev macvlan-br0
    This will add a route to the Docker network so it can be reached

You will have to put this in a script you can run at boot of your Synology device, as these settings will not retain over a reboot as we have to make them on the commandline and cannot make them in the Synology DSM.

#!/bin/bash
#
# Set timeout to wait host network is up and running
sleep 60
#
# Recreate the host macvlan bridge
ip link add macvlan-br0 link bond0 type macvlan mode bridge
ip addr add 192.168.0.254/32 dev macvlan-br0
ip link set macvlan-br0 up
ip route add 192.168.0.192/26 dev macvlan-br0

Docker

Now that we have set up the host, we can continue creating a new network in Docker that can be used by our containers. To do this, type:

docker network create -d macvlan \
  --subnet=192.168.0.0/24 \
  --gateway=192.168.0.1 \
  --ip-range=192.168.0.192/26 \
  --aux-address 'host=192.168.0.50' \
  -o parent=bond0 macvlan-br0

This will create a network in Docker on the subnet of your network in a dedicated range of IP addresses using your physical interface and virtual bridge device.

Do make sure the IP range you specify for Docker is not part of your DHCP scope, if you are also running DHCP or you will get IP conflicts. Docker does not use DHCP, and instead will just hand out IP addresses from this range in order to each container.

Now you can create your Docker containers as usual and configure them to use this network, instead of the standard host or bridge networks Docker uses by default. You can also assign this network to existing containers if you want.

Install container

To install AdGuard@Home on your Synology, open Docker, go to “Registry” and search for “adguard”

Double click to download the latest version.

When it is done downloading, you can go to the “Container” section, and hit create. A window will popup where you can select your freshly downloaded image.

Select it and click next to follow the instructions. Configure what you want, but make sure to select the macvlan network when you get to the screen to pick the network.

Congratulations! Test your new container that is now present on your local network.

Important note: if you are running the DNS server on your Synology for your local network, and you want to keep using that, make sure you configure your AdGuard as DNS for your clients, and add the following to your AdGuard DNS configuration under upstream servers:

[/domain.local/]192.168.0.254:53

This will instruct AdGuard to use the IP address you added to your bridge device at the beginning as the source for resolving domain.local hosts. 

The complete upstream section for me looks something like (I use Cloudfare DNS for internet, and Synology DNS for local addresses):
tls://1.1.1.1
tls://1.0.0.1
[/domain.local/]192.168.0.254:53

Do not use the real IP address of your Synology host; this is not reachable for Docker and will not work! Use the bridge device address instead.

New laptop, new Linux distro

I finally got fed up with my Macbook Pro as a Linux laptop. It was a 2012 model, no longer supported by Apple. But the quirky implementation of Nvidia discrete graphics on the Macbook wasn’t the best for reliable Linux operation. Mind you, Nvidia is always a bit of a challenge, but Apple being Apple certainly does not help in that regard.

Anyway, I am currently sporting a Lenovo T460 from 2016. Still not really a new laptop, but fast enough for Linux and most things I do with it. It has a i5 6300U from the Skylake family of processors, 8GB memory (for now, supports up to 32GB) and a 1TB SSD. For graphics it used the Intel 520

For the OS, I am now running Nobara Linux 37. This is a Fedora derivative with tweaks for performance and gaming. While I am not a gamer, the improvements do help making it a snappy experience. Contrary to my desktop computer, I am now using the KDE version.

Current Nobara 37 desktop on my laptop

Getting used to KDE after having used Gnome for a long time can cause some frustrations. Not because what you want isn’t possible (typically quite the opposite) but because you cannot find it or know where to look. Where Gnome is has more of a ‘our way or the highway’ mentality and is more concerned with their vision than how the users are perceiving or using it, KDE is all about customization and providing the user with the ultimate choice. If you can dream it, KDE can probably be configured to do it. And that can be a bit overwhelming. It has so many options, sometimes you just have no idea where to look to achieve something.

So far, I am very happy. Both with the laptop, as well as Nobara Linux and KDE. I may have to switch my desktop to the same configuration soon… Now that I am getting the hang of KDE again, I remember why it was my default and go to desktop environment in the past, and the quirks and annoyances from Gnome seem to be more and more stuff I don’t really want to deal with no more. You shouldn’t have to hack together your environment around the limitations imposed by its maintainers. It’s Linux, not Windows or MacOS…

Powered by atecplugins.com