Category: Red Hat Server

Posted on

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].

Posted on

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?

Posted on

Picking Out a Red Hat Style

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am reconfiguring ButtonMash to run some Red Hat family distribution. Let’s get started!

My Early Impressions of Linux

When I was taking my first deep dive into the Linux operating system, I was amazed and overwhelmed with the sheer diversity and customization to be found. Between the soup of permissive licenses and modularity of GNU/Linux (pure Linux does not a complete operating system make), Linux isn’t one operating system: it’s thousands. And if that’s not good enough, you can always make a new one.

I quickly found representations of the Linux family tree listing several popular distributions spawned over time as people forked projects, swapped code, and in some cases ceased development. And while there are several names that have stood the test of time so far, I was introduced to three branches each revolving around a particular distribution: Debian, Arch, Red Hat Enterprise Linux (RHEL). Ubuntu is large enough to receive an honorary mention within the Debian family. Most of my computers run Debian or a derivative thereof. My flagship computer runs on Manjaro of the Arch family. I would like some experience on a RHEL family branch.

The Red Hat Family

The modern Red Hat branch feel different compared to Debian and Arch. The titicular distribution, RHEL, is sold on a subscription basis. Red Hat, the company, sponsors a distinct, community supported, upstream distro called Fedora where programs can be tested before being deployed to customers’ production environments where downtime can cost a lot of money. Per the permissive licenses of software going into RHEL, anyone can view, modify, and redistribute their source code – just respect the Red Hat trademark. Do know that actually subscribing comes with technical support.

Historical and editorial note: from what I can tell, Red Hat Linux used to be the branch root, if you will. Red Hat reorganized things in 2003, adopting Fedora while discontinuing Red Hat Linux in favor of Red Hat ENTERPRISE Linux. The way these three terms are used almost interchangeably made this section very frustrating to research, but I will try and use the proper terms: Red Hat is the company, Red Hat Linux was Red Hat’s flagship product sold on store shelves sold from the mid-90’s until 2003, and Red Hat Enterprise Linux (RHEL for short) is Red Hat’s modern OS users subscribe to.

Looking deeper into different distros based off RHEL source code, you will find that 100% binary compatibility is huge. You can develop something on a RHEL downstream and it should work for a paying RHEL subscriber. If you find a clever use for a bug –it has happened before in the tech world– that bug will be there in RHEL.

CentOS

CentOS has been an important name in Linux for a while. Had I done this week’s research for a Red Hat branch distro a year ago, I have no doubt it would have been my pick for use on a home server.

Despite CentOS’s long history as the go-to RHEL downstream, the CentOS I was looking forward to getting to know has a short future. Just as Red Hat Linux was discontinued in favor of RHEL, CentOS is to be discontinued in a couple months on this coming New Year’s Eve (December 31, 2021) and repurposed. The future CentOS Stream will sit between Fedora and RHEL, making it an unsuitable distro for a server I expect to run for at least the next few years.

The niche CentOS is vacating already has new distros vying to be the de facto replacement. The leading contenders are Alma Linux and Rocky Linux. Alma Linux has the backing of a large company, while Rocky Linux is being done by the guy who originally started CentOS. So far as I can tell, they’re a coin flip away from each other. If they both work out, more power to the end-users.

Even as I write, I’m unsure what I’ll be running a year from now. For no reason in particular, I’m leaning towards Rocky Linux. I’ve already flashed a thumb drive with the install media, but setup will have to wait until next week.

Takeaway

I picked a horrible time to get into free Red Hat distros. One chapter in its history is drawing to a close and the opening of the next is still going through revisions. However, I’m not looking to wait a year for that retrospect. I’ll be re-evaluating as needed.

Final Question

Have you ever started a project during a sub-optimal time?

Privacy Policy