Category: Command-fu

Posted on

Hey, upgrading CentOS 7 to CentOS 8 in place still works!

So I had a remote VPS in the wild giving me issues, and while addressing the issues, I decided I should update the OS. No updates available, up to date… on CentOS 7. Well, I thought it was a good time to move up to CentOS 8. Yeah, I know the whole 7 vs 8 vs stream thing is a thing, I’m not too worried about that for the moment.

Because I didn’t want to rebuild it, I searched to see if there were upgrade instructions out there for 7->8. Found some, with the usual disclaimer. “This is unsupported,” “There is no upgrade path, you must reinstall,” blah blah blah.

So I backed up what needed to be backed up in case I had to rebuild. and went for it.

I used this as the base:

https://www.howtoforge.com/how-to-upgrade-centos-7-core-to-8/

The first problem I ran into is that the version of the Centos-Release package was no longer being served. And the current release actually changed names, from CentOS-Release to CentOS-Linux-Release. “Interesting,” I thought, “I wonder if that’s going to bite me in the ass later.”

Then I ran into some issues with dependencies. gcc and annobin was the top line. A quick google revealed another user had encountered this and resolved by simply “uninstalling Perl and Python3, then reinstalling after the upgrade.”

So I tried that, and got past that little obstacle. A couple other minor dependency issues, I had to uninstall python-six and one or two obvious little interfering little noids. But it rolled through. The really scary part was the reboot, because part of the process is uninstalling ALL kernels and then reinstalling the new kernel, then making sure that grub is correct.

So I opened a serial console to it, so I could watch the boot process in case something went twisty. Double-checked that backups were thorough, and let her rip! Booted off my serial console, but opened it right back up again, and boom, everything came up. Not just the CentOS 8.3 base OS, but all my exotic internet apps. I was right back to being usable again. Why was Redis on this server again? Strange.

So that’s my story, and I’m sticking to it. Score one for the documented unsupported upgrade-in-place instruction set.

Baab out.

Posted on

Migrating YUUUGE photo galleries: exiftool FTW

Years back, I hosted several large photo galleries on a public website. Password-protected, but my family was the only consumer of the data anyway.

I decided to migrate that to my growing internal network, because I have disk space, backups, and faster networking. Plus that old gallery software was getting long in the tooth and I didn’t feel like continuing to maintain it.

Dilemma: The old gallery was one of those, like most of them, that import the files, give them a long filename and remove the uploaded copy. So there was no rhyme or reason to the 11G of photos on that server, just a single flat gigantic directory of JPG files, over 1500 of them in total.

It only took a few minutes to realize that there seemed to be three paths — (1) a fully manual path of uploading all of the files in a batch into the new photo management app (I’m using Lychee, by the way) and then sorting through them; (2) a less manual, but still involved, path of logging into the old gallery and exporting/downloading each set; or (3) finding a smarter way.

I chose (3) finding a smarter way. I realized that my photo sets were all event-based, and the date of those events are stored in the EXIF data of each individual photo file. So I wondered if there was an easy way to extract that in a useful way, and then possibly script it to segregated it by date. I quickly found something even better — the exiftool itself (installed on my macbook with Homebrew) will easily do exactly that:

exiftool '-Directory<DateTimeOriginal' -d %Y-%m-%d "$dir"

Will siphon through an entire directory, lickety-split, pull out the capture date from the EXIF data, and then file them in a directory named for the YYYY-MM-DD of the date. It will even create the directories if they don’t exist. I went in seconds from a flat directory of over 1500 files to, let’s see…. 12 individual date directories, each filled with a day of photos.

Lychee lets me import directories and will name them “[IMPORT] (directory name)” so all I have to do once they’re all imported is to log into Lychee, look into each newly-imported directory to figure out what the event was, and rename the album. Fun stuff.

Posted on

Managing changed SSH keys in CentOS 8

All these years, I’ve dealt with changed SSH keys (you know, you go to SSH into something and you get the “key has changed” error:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.

probably because you rebuilt the target server/vm, or you changed an IP somewhere, or whatever) by removing the entry from ~/.ssh/known_hosts. It’s a few annoying extra steps, but it has always worked for me. Call it “old reliable.”

With the release of CentOS 8, everything changes. Known hosts are now managed by sss. Maybe this happened somewhere else and I wasn’t aware of it, but this is how I was made aware of it:

Message as above, along with:
Offending ED25519 key in /var/lib/sss/pubconf/known_hosts:6

Well that’s new. And you can’t delete from that file, because it’s generated behind the scenes and then comes right back. Generated from ~/.ssh/known_hosts, apparently. And nobody wants to enter a new key manually as it suggests. The answer?

ssh-keyscan -t ecdsa 10.120.x.x >> ~/.ssh/known_hosts

(substituting your target IP, of course). Almost worth aliasing “whoopsienewkey” to it with a variable for the IP.

Anyhow, that’s all, I hope you’ve learned something today to make your day easier and brighter.