RTFM
last update: 02/28 @ 18:29

Well, that’s likely something I should have done but didn’t in the last few weeks.

As noted earlier, I had a power supply fail and the server was old enough it was not clear I could replace it. Also, I’d had a hard drive fail on the same server a few months back. Both have been through a remodel at the house and so it was time to replace them.

For the first server, I was really under the gun: I wanted to get our internal network back up and running quickly. Clearly no time for manual reading.

For the second server, just recently “Completed,” I was not under quite as much personal pressure. But I still just installed the OS (yes, two major versions more recent than what I had), installed the software and laid down my configurations. It likely would have been a good idea to read the release notes to understand what all had changed, but I was too lazy or thought I could figure it out as I went.

Which, I’m happy to say, I could (thank you Internet).

If you happen to be jumping from RHEL 7 (or, more likely CentOS 7) to RHEL 9 (or, more likely Rocky 9), here are the final couple gotchas I ran into:

External FirewallD forwarding/routing change

With the changes to FirewallD and the underlying firewall layer, my old forwarding didn’t work. I saw a lot of this in the logs, “filter_FWD_internal_REJECT: IN=eno1 OUT=eno2” The fix, thanks to Internet searches:
firewall-cmd —permanent —new-policy allowForward
firewall-cmd —permanent —policy allowForward —set-target ACCEPT
firewall-cmd —permanent —policy allowForward —add-ingress-zone internal
firewall-cmd —permanent —policy allowForward —add-egress-zone public
firewall-cmd —reload

Some updates needed for ruby scripts

The new, modern Ruby doesn’t like instance variables (for good reasons). The quick (but perhaps less than ideal) fix was to make them global variables. My scripts run one at a time, no worry about race conditions so likely that’s OK.

Testing red network with only default route

I thought I was being smart, I added my public IP addresses to the new server while I was building it and then went to test by plugging it into a switch that only had my laptop connected. I gave my laptop an IP in the same class C network and started testing. And nothing worked. I had the server’s default route set up to go out the internal side so I could use the current Internet connection to get updated software. Once I added a route to that class C on the NIC, I could test and see traffic flowing.

My new servers have redundent power supplies now — I learned that lesson. But maybe I didn’t learn the hard disk lesson: I’m not doing any sort of RAID, just frequent backups. And, thanks to the new servers and new disks, I have my old disks as spares should I need them.

Now I can say I’m finishing up some post migration work; prepping for Ting as our new ISP, and getting on with life.

(1) Comments -- permanent link
Edit this (owner only)

Add new entry (owner only)