Slow and Steady Builds a Server

Good Morning from my Robotics Lab! This is Shadow_8472 and today I am continuing the grind on my Rocky Linux server running on my ButtonMash workstation. Let’s get started!

Quality of Life

I’ve had a single-focus mindset of getting Bitwarden/Vaultwarden working, but I’ve overlooked an important aspect of running a reliable server. One evening, any new connections to ButtonMash were failing. When I investigated the next day, the system was on and the network was connected, but when I logged in to console and pulled up the address with ip a, I found the router had incremented the IP by 1.

The task of setting up static IP’s is not alien to me. On some systems, I’ve even edited config files by hand. Cockpit has a Networking tab, though. From there, I was able to quickly worm my way into the correct network interface and configure a static IPv4 back to where it belongs. Cockpit tried to reestablish its connection with the new configuration and predictably failed. I had to make the change permanent with a follow up prompt.

Container Isolation

One of the draws of Podman over Docker is rootless containers. In the unlikely event someone hacks into Vaultwarden’s container and breaks out into the host system, he won’t be able to do as much damage if he finds himself in a non-root account – even better is if he finds himself in an account without sudo privileges.

With that, I added a user special for running Vaultwarden with sudo useradd vaultwardenUsr and I locked it with sudo usermod -L vaultwardenUsr to block any normal login attempts. sudo su vaultwardenUsr will still let me Substitute User into the account. And of course I find the tools to do all that under Cockpit tab Accounts.

From within my dedicated Vaultwarden container user, I looked for the two containers listed by the plugin. But I found nothing. From my background research I should have put together, containers are owned by users like any normal file. The two images the plugin listing their owner as “system” were actually owned and operated by root, as clarified by a test where I stepped back from Administrative access to download a new container image. Novel as it is, the plugin won’t be of much help for my use case unless Cockpit lets me access it without a password.

Bringing Vaultwarden Online

podman run -d --name vaultwarden -v /home/vaultwardenUsr/vw-data/:/data/:Z -p 44300:443 vaultwarden/server:latest

This is a long, complex command that took me while to puzzle into working order.

podman run

This is the base command. I used it to go from a container image to container.

-d

“Detach” runs containers in the background.

--name vaultwarden

By default, containers are given random pronounceable names. You can just spin up multiple copies of the same image without needing to give it much thought. Here, it’s best to have something descriptive.

-v /home/[username]/vw-data/:/data/:Z

“Volume” mounts a directory from the host into a directory in the container. This part deviates from most Vaultwarden guides the farthest. First of all, Docker installation assumes you’ll be mounting directory /vw-data/ directly from the root of your file system. However, that directory is off limits without elevated privileges, so it needs a place in the user’s home directory and a full path to that directory.

The other solved issue involves the :Z at the end. At one point, I seemingly had everything else sorted, but when ran **podman ps** to list running containers, it kept coming back empty. My online searches for Podman and Vaultwarden kept sending me back to last week’s progress-report of a post, but I eventually located a discussion on Vaultwarden’s GitHub. I didn’t do much follow up research after I got it working, but it appears to be related to SELinux (Security Enhanced Linux), a kernel level security module.

-p 44300:443

“Port” forwards ports from the host machine to individual containers: host on the left and container on the right. Recommended behavior (with Docker in mind) is to forward port 80 (HTTP), but I’d rather use HTTPS on port 443. Additionally: ports 0-1023 are reserved for system use, so I added a couple zeros on the host end.

vaultwarden/server:latest

With all the flags out of the way, this is the container image being copied into an operable format.

With the container running, all I had to do was punch a hole in the firewall and I can now have Firefox laugh at me for a failed secure connection. During assembly, I was able to make a non-secure HTTP connection with -p 8000:80 and bring up a Bitwarden login.

The next step is to obtain a security certificate, but that’s a topic for another week…

Side Project

When I walked my father through installing Debian/LXDE on his computer, he was left with a few specialty keys on the keyboard going unresponsive – particularly the volume up, down, and mute keys. The system is usable without them, but it would be nice if these keys worked. Originally, I assumed the problem would be somewhere with Debian itself, but when I tried a search targeting LXDE instead, I knew from the search results that I had today’s side project.

As we researched, I started building a system flow chart from key press to volume adjustment. The Keyboard transmits its key events to a USB receiver. The receiver communicates with some sort of keyboard driver be it discrete or compiled into the Linux kernel. The kernel then passes key events to the Xorg server. From here, we used xev (X EVent) to confirm that volume key events were all making it thus far.

At some point, PuleseAudio takes over and tells the Linux kernel what to push to the speakers and how loud to play it. While testing, we cut off a song with pulseaudio –stop / –start and had to refresh the webpage to get it back.

I personally think we’ll find the problem either within Xorg or between on a direct link between Xorg and Pulseaudio. In the meantime, the search continues.

Takeaway

For both these projects: ready-made solutions out there we could just copy, paste, and wish for luck but we’re trying to learn the innards of Linux, so it’s okay to take extra time.

Final Question

Have you ever had to program your keyboard events by hand?

I’m Learning Vaultwarden and Podman!

Good Morning from my Robotics Lab! This is Shadow_8472, and today –with a heap of luck– I’ll be putting a Bitwarden server on ButtonMash (or getting so close I can’t help but finish next week). Let’s get started.

Vaultwarden

I’ve already talked about the importance of password strength before. Longer is better, but a unique password per login is more important in case one gets compromised. But who has the attention span to remembering fifty passwords across every obscure site, app, or game he’s ever interacted with? A good password manager solves this by organizing your passwords so you can easily access them from a client, but anyone without your key can’t.

I started researching for this project by revisiting the first time I switched to using Bitwarden and I decided to self-host a server from a Raspberry Pi [1] following a straightforward tutorial by censiCLICK [2]. My SD card corrupted one day, and I’ve been out a password server ever since, despite efforts to repair it. I’ve been covering my exploration of Rocky Linux, a RHEL family OS, on my ButtonMash server/workstation, and now I’m ready to start putting it to work.

The tutorial by censiCLICK was well presented. It takes you from Raspberry Pi 3B+ and layers on Raspberry Pi OS, Docker, and finally Bitwarden_RS all while giving basic introductions to skills you’ll need along the way like SSH and security certificates. It is unfortunately out of date. Around six weeks after I started using it, the project leader announced that there was some confusion over trademark[3] so he was renaming it to Vaultwarden…

Odd… Looking through my posts shortly after the name change, I was already having issues with my Bitwarden server. It could still have been card corruption or me trying to play with Git. I guess I’ll never know…

…In any case, ButtonMash is ready for the next step.

Docker or Something Else?

Docker is a technology I still haven’t fully visualized. While researching instructions to install it on Red Hat systems, I stumbled across a mention of Podman. Online hosting solution Liquid Web provided a decently clear explanation [4]: containerization essentially makes single-purpose VM’s without the overhead of full operating systems. Docker has a master process that runs Docker containers. Podman runs containers separately, doesn’t require root, but requires a separate piece of software called Buildah to create containers to run and doesn’t have available professional support.

Further research confirms that RHEL now endorses Podman over Docker, so Podman I will use. Even so, I had to install it separately along with a Cockpit plugin to manage it. From there, I made just a few well-researched clicks to download Vaultwarden. The Docker-Podman plugin had a lot of fields I didn’t recognize, so I installed the Docker HelloWorld container to play with. I had to run it from terminal, but it appeared to work. I expect running a Vaultwarden container will be my side project next week.

Side Project

Last week for my side project, I set up a Wi-Fi gaming router to hopefully reduce downtime on my Wi-Fi catcher Pi. This week, I made the two get along. First, I thought it might be Wi-Fi drivers, so I updated, getting myself into a tedious cycle of incomplete updates failing when the file system flipped to read-only against the background of Wi-Fi dropouts. I had to flip the power switch because the reboot command broke and reconfigure packages to clean things out before continuing.

My real problem was the static IP landing outside the router’s 192.168.X.X range. Attempts to manually change IP kept failing, so I backed up a known good config file on top of the file I actually needed to go back to dynamic IP and spent many hours piecing it back together. In the end, I was finally able to connect.

Takeaway

PPolished computer tutorials are great for catapulting students of tech over barriers of entry, but they’re each anchored to a fixed point in time: lessons of the recent past compiled for the near future. As much of an accomplishment making a definitive guide to subject X might be, it will only be but a single focus point for future users to look back on when compiling their own procedures.

Final Question

Have you ever gone back to old project notes for insights for follow up projects?

Works Cited

[1] Shadow_8472, “BitWarden: My New Password Manager,” Let’s Build Robotics With Shadow8472, March 15, 2021. [Online]. Available: https://letsbuildroboticswithshadow8472.com/index.php/2021/03/15/bitwarden-my-new-password-manager/ [Accessed Nov. 22, 2021].

[2] censiCLICK, “Full Guide to Self-hosting Password Manager Bitwarden on Raspberry Pi,” on YouTube,Nov 15, 2020. [Online video]. Available: https://www.youtube.com/watch?v=eCJA1F72izc [Accessed Nov. 22, 2021].

[3] d. garcia, “1.21.0 release and project rename to vaultwarden #1642” on GitHub, Apr. 19, 2021. [Online forum]. Available: https://github.com/dani-garcia/vaultwarden/discussions/1642 [Accessed Nov. 22, 2021].

[4] Liquid Web, “Podman vs Docker: A Comparison,” Liquid Web, Sept. 10, 2021.[Online]. Available: https://www.liquidweb.com/kb/podman-vs-docker/ [Accessed Nov. 22, 2021].

Building A Fake Computer to Split

Good Morning from my Robotics Lab! This is Shadow_8472 and today, I am building a Linux virtual machine for my mother and sister to split. Let’s get started.

Machines Within Machines

Switching operating systems is like moving to a new house. It’s intimidating. Things are arranged in different spots. The pattern of your daily life will shift and there will be an uncomfortable adjustment period.

But at least with computers, anyone with a semi-recent CPU and enough other system resources can host a “guest” operating system for evaluation. While I previously have no experience with this method, for others, it serves as a sandbox where they can try things with Linux without the pressure of learning everything at once or else risk being out a computer if a problem commands a chunk of research time.

VirtualBox

I’ve done my share of research on Virtual Machines (VM’s) in the past. VirtualBox is a well-respected name, and I can see why. Once I installed it on my sister’s Windows machine, I didn’t have to research anything about it specifically until I was looking at a desktop and my sister wanted the VM to use both screens. Otherwise, the experience was intuitive.

PopOS is quickly becoming my go-to easy mode for Linux. Their downloads come with shasum verification hashes, which I made use of. In one way, it was even easier to install because I could just install straight from the disk image without any physical install media. I did have one problem during installation where the installer window rendered larger than the screen resolution. Instead of brute forcing a virtual screen size from VirtualBox, I just used Super (Window key)+click&drag as I learned to do while working with GIMP on a boxy tube monitor with a similarly nostalgic resolution.

Dual screens had me stumped on their instruction set. From what I can tell, I had to insert a virtual CD that came with VirtualBox and install it into PopOS’s virtual disk drive. A bit of computer wizardry happened that involved some sudo password prompts that crashed and duplicates thereof happened and I seemingly needlessly rebooted the VM several times before I unlocked the necessary options to enable dual screen. I will want to pay more attention next time.

The default desktop environment for PopOS was based on GNOME 3, but it’s not for us. System76, the makers of PopOS provided an awesome command by command guide for installing a large selection of alternate desktop environments, so I loaded a few my mother and sister should feel most comfortable with. KDE is my favorite, but Cinnamon and MATE are other names I recognize.

Speaking of KDE, If Linux is the OS of customization and decision fatigue, KDE compliments it perfectly. I spent more of my blog project time this week trying to chase down the color settings than I would have liked. I was hoping for some sort of base color picker that would then populate the rest of the theme with different shades, but I found some options to pick each shade individually. Unfortunately, you’d have to be an artist to make something that looks decent. I was able to find a user-submitted theme with an acceptable color palate.

Side Project

My Manjaro workstation has been getting its Internet through a Raspberry Pi for a while now, but lately I’ve been getting periods of having the Pi’s Wi-Fi connection drop randomly. My father picked up a special gaming Wi-Fi router and I set it up today after months of other projects constantly taking priority. Long story short: I was easily able to use my laptop to connect and arrange default configurations on the router, but I have yet to get it to agree with the Pi 4. I’ve tried looking into possible inherit compatibility issues, but all the guides for finding information on Wi-Fi from Linux assume the presence of tools that aren’t present in Raspian. I thought this was small enough for a side project, but it appears I was wrong.

Takeaway

Setting up a new computer and getting it tweaked properly takes a while and a VM is no exception. One point I didn’t go into was how our NFS drive didn’t admit the VM on account of its IP address. I also learned that one of the intended host machines sits a little too heavy on its existing RAM, so it will need an upgrade for comfortable VM operation. I expect a follow up to this project at a later date.

Final Question

Do you have any tips for working with virtual machines?

ButtonMash’s Solid Foundation on Rocky Linux

Good Morning from my Robotics Lab! This is Shadow_8472, and today I am still working on my Rocky Linux server. Let’s get started!

Project Selection

One would think it shouldn’t take a month to set up a server, but the vast bulk of that is research. What all do I want the server to do? What services do I need to set up to include it? When I know more than one way to do something, which way do I want to do it? The questions don’t end until work has progressed beyond the point of answering differently.

My goal for today is to get a few things running: I want to mount the GoldenOakLibry NFS server. I want to update-grub so I can properly dual boot with Debian. I want to install BitWarden. These three things are probably the most important end-goal tasks remaining for configuring ButtonMash’s Rocky install.

Package Managers

Before I can really work on my target goals, I need to know some of the basic specifics. Every major branch has its own compatible package managers. Debian has DPKG and Apt (Snap for the Ubuntu sub-family) while Arch has Pacman and AUR. Wrappers and cross-compatibility tools exist as a zoo of possibilities that will not be fully sorted out here, today.

My first impression as I research the Red Hat branch’s solution are the striking parallels to Debian, though it is also experiencing a stir. RPM (Redhat Package Manager) is like DPKG in that it is used for directly interfacing with the repository. YUM (Yellow dog Updater, Modified) was the package manager the likes of Apt I’ve been hearing about associated with the branch. It is now replaced by DNF (DaNdiFied YUM) for installing Package X and everything Package X needs to run (called “resolving dependencies”). Both YUM and DNF are present on my install, though.

Cockpit

I’ve had a chance to look over this web interface that came with Rocky Linux. By default, there doesn’t appear to be much to it after logging in beyond information readouts, an interactive firewall, and most importantly: an in-browser terminal. There appears to be a whole ecosystem to learn about, but it’s beyond me for now. I will want to look deeper into this subject when I move in to disable password authentication over the network.

Note about the terminal: it’s a little quirky from sharing its inputs with the browser. Nano’s save command also tells FireFox to “Open” and copy-paste commands don’t always work the same.

NFS Mount

From experience, I know that NFS is a royal pain to learn how to set up. On top of that, I know of at least two ways to automount network drives: during boot with fstab, and dynamically with systemd. Mounting it with fstab is annoying on my laptop because it halts boot for a minute and a half before giving up if GoldenOak is unreachable. More annoying is that this appears to be the more well documented method between the two. For an always-on server, though, it may not be a concern.

Not helping systemd’s case is/are the additional way/ways I’m discovering to set its automount functionality up. I don’t even know the proper name for the method I’ve used before – just that I didn’t mess with /etc/fstab whereas another systemd method does. It is a great challenge finding a source that compares more than a single mounting method. The good news is that aside from installation, I should be able to disregard what distro the tutorial was intended for.

While researching this section, I rediscovered autofs, and saw mention of still other automount methods. I’m avoiding autofs because because the more I read about it, the move complex it appears. In this instance, it would behoove me to just leave a line in /etc/fstab because I don’t expect to be booting this server outside the context of the GoldenOak NAS, but as this is more or less the centerpiece of my home’s network, I’m going with systemd mount files, as per the blog by Ray Lyon I referenced last February when I first learned about it. I’ll leave a link to his post in my Works Cited[1].

NFS Automount is tricky stuff, but each time I study it, I retain a little more. I can barely remember how to mount a share manually – let alone configure systemd automounts. It took me several days to find a copy of the files I needed, even after looking back at my above mentioned post from February[2]. My best guess is that I got lost in my own filesystem. I’m taking notes and organizing them in my home directory on this new install.

Update-Grub

When I installed Rocky Linux, I was all nice and safe by not letting it see any drives it wasn’t installing over, but the host machine still has a job to do on the photo trunk project; I need it to dual boot. I read up on a command called update-grub I could just run once everything was installed and physically reconnected. First of all, update-grub is a script, and second of all, it’s notoriously absent.

A variety of help topics exist on what command to run on RHEL instead of update-grub. From what I can tell, it’s pretty universally present on Debian-based systems and when I checked Manjaro (Arch family) just now, it was there too.

Update-grub itself is pretty simple. It’s three lines long, and serves as an easy-to-remember proxy command to actually update your Grub boot loader. The exact command may differ between computers depending on if they’re using BIOS or a newer, less common equivalent called UEFI. I assume it is generally generated during package installation.

Once I had my bearings, it was fairly easy to update grub on my own. I found my configuration file at /boot/grub2/grub.cfg because I am using BIOS. An effectively empty directory stump existed for the UEFI branch, cluing me in that this operation is one you should understand before using copy-paste into terminal. This StackExchange forum has several individual explanations, including reference to what I take to be a catch-all I am not using. Link[3]

So… I go to verify everything is working, and it’s not. A simple reboot loaded Rocky’s GRUB, but the Debian kernel refused to load over the USB 3 PCI card. So much for that idea. I moved the Debian drive to a motherboard USB port and BIOS found it and loaded Debian’s GRUB, which doesn’t know about Rocky Linux. I tried running update-grub in Debian and… it didn’t work. I wasn’t looking to spend even more time on this part of the project, so after confirming that Rocky’s GRUB could boot Debian, I got into BIOS and told them to prefer the internal Rocky drive over anything on USB.

BitWarden False Alarm

I’m super-excited about putting my self-hosted BitWarden server back up. I’ve already started researching, but the topic still feels like it’s expanding when I need to be getting ready for publishing this already lengthy post full of amazing progress. BitWarden will need to wait until I can better teach myself how to properly take care of it.

Takeaway

The Red Hat branch of Linux is in a notable state of flux. Key fundamentals elements of the family like CentOS and YUM are everywhere in old tutorials, and that is bound to make for a frustrating time trying to learn Red Hat for a while to come – especially if you’re new to Linux. Here, more than anywhere else, learning the history of the branch is vital to teaching yourself how to sysadmin.

Side Project

A while ago, I thought Derpy’s RAM was failing because Kerbal Space Program kept crashing the whole system. I’ve been running the three 4 gigabyte sticks on my Manjaro workstation for a month or two, and they appear fine. In the meantime, my father ordered up a pair of 8gb sticks. This week, I installed them, displacing one of the 4gb sticks. Passive testing will now commence.

Final Question

Have you ever had a project take a discouragingly large amount of research time then suddenly come into focus in a single day?

Works Cited

[1] R. Lyon, “On-Demand NFS and Samba Connections in Linux with Systemd Automount,” Ray Against the Machine, Oct. 7, 2020. (Edited Aug. 8, 2021). [Online]. Available: https://rayagainstthemachine.net/linux%20administration/systemd-automount/. [Accessed Nov. 7, 2021].

[2] Shadow_8472, “Stabilizing Derpy Chips at Last,” Let’s Build Robotics With Shadow8472, Feb. 22, 2021. [Online]. Available:https://letsbuildroboticswithshadow8472.com/index.php/2021/02/22/stabilizing-derpy-chips-at-last/. [Accessed Nov. 7, 2021].

[3] “Equivalent of update-grub for RHEL/Fedora/CentOS systems,”StackExchange, Aug. 26, 2014-Oct. 10, 2021 [Online]. Available:https://unix.stackexchange.com/questions/152222/equivalent-of-update-grub-for-rhel-fedora-centos-systems. [Accessed Nov. 7, 2021].

Rocky Linux: Looking Around

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am installing Rocky Linux on ButtonMash. There’s a lot to learn and a bit more to do, so let’s get started!

Checklists and Notepads

A home server is useful. However, if you ask me what one is good for, and I’ll struggle to come up with an answer before the conversation stalls. I’ll come across as simply begging for another expensive toy, and you’re even less interested in one than before.

To remedy the stress of the moment, I opened a text buffer and slapped in a few uses I had in mind. Over the next several days, I added some more for a total of seven or eight so far. None of them were new per se, but it was the first time I had them all in the same place at once.

On the topic of brainstorming, I’m considering developing my own checklist for installing Linux no matter the distro. Watch for it in a future topic once I’m half-satisfied with it.

I left a document open for several days to add ideas for running on server

I am developing a personal Linux Install checklist

Installation

As stated in my last post, I already flashed a thumb drive with Rocky Linux. I was considering using optical media this time because of the expected long term support for this install, but even the minimal option I ended up downloading was too large for CD and we’re seemingly out of blank DVD’s. When I did make my download, I accepted Firefox’s offer to open it with Popsicle, a USB flasher utility that came with either PopOS or KDE (I have reasons to think either is likely). I overwrote the Debian install media from my Laptop.

Slated for overwriting was a previous ButtonMash SSD (Solid State Drive) with MineOS on it. I had already cleared stuff out from it, but after working on the family’s Minecraft server on Apex, I started having second thoughts. I sought out and found an even older and smaller MineOS SSD originally from DerpyChips. My father and I connected it up and booted to the install media.

By this point, I knew this Linux installation will be provisional at best – to my relief. Without the pressure of getting a “forever server” going, I can further refine my approach until I’m satisfied. In the meantime, I can load up some lightweight services.

The installer was one of the smoothest I’ve ever seen. All the usual elements like time zone, user accounts/passwords, and partitioning were linked from a main menu. My one complaint is the full screen slide animation blasting my eyes whenever I clicked on something. It’s not worth my time to recompile the installer, though.

There were a couple unfamiliar panels from the installer menu. One appeared to be some sort of privacy policy configuration screen. I had no idea what most of the options were about, but I could still recognize the value in it. The other screen had options for a selection of software to install. We read through each option, deciding weather or not I wanted each piece. Stuff like networking tools for SSH or NFS were included. Stuff a headless workstation doesn’t need, like GNOME, stayed off. If I didn’t recognize something, I left it alone. Some of the stuff I opted to include with installation were things I knew I’d be installing anyway, so that’s a little time and effort saved.

Configuration

SSH is an easy skill to learn, but difficult to master; I’ve poked at it this week, but I’ll need more time with it before I can consider myself safe using it on an unsecured line. I had a little trouble matching key fingerprints when SSH’ing into ButtonMash from my Manjaro workstation vs having the later SSH into itself with localhost. I quickly realized they were using different hash algorithms, but I had to give up on forcing them into alignment for now. I was able to verify the code on DerpyChips, though.

As soon as I got myself SSH’ed into ButtonMash, I received a prompt to launch a webUI called Cockpit. I don’t know much about it, but I recognized the name from my research last week and the interface feels familiar from some of my previous experiences with server management over browser. The interface came back online after a reboot, so there’s that. I will note that Firefox wasn’t happy about its self-signed security certificate. I have fixed that in the past, but I’m ignoring it for now.

Takeaway

I can feel like I’ve come a long way since when I first started Linux. Each major jump feels like I’m landing in a less unfamiliar place, though there are still surprises. To answer one of my own early “Final Questions:” results are not as important as learning why you got the results in the first place. Though there are plenty of places that make no assumptions about prior skill, general experience will still be of benefit when working with such systems.

Side Note

After I was done with last week’s post, I poked around a bit more at my Manjaro workstation’s spell check for LibreOffice Writer. I was able to get it working by installing a package called hunspell-en_us, as no language libraries were included by default.

Final Question

What would you do with a home server?