fogbound.net




Tue, 10 Oct 2023

Which files are dupes

— SjG @ 4:56 pm

Over the past six months, I’d copied a set of files down from a network drive, then new ones were added to the network drive, and I’d copied some of the new ones down but maybe not all? How could I possibly clean up this mess?

Easily, it turns out!

$ diff -srq /mnt/Volumes/2023/Bank_Statements/ /local/receipts/2023/

This will list all the files, and mark if they’re only in the /mnt/Volumes/2023/Bank_Statements/ directory, only in the /local/receipts/2023/ directory, if the file exists in both places but is different, or if the file exists in both places and is identical. The -s flag means “report identical files,” the -r flag is to go recursively, and the -q flag just announces the files are the same/different rather than showing their differences.

This’ll work as long as the file names have not been changed. If file names have changed, it’ll require a more robust utility.


Mon, 21 Aug 2023

Another “sed” one-liner

— SjG @ 1:22 pm

I needed to generate a comma-delimited, quoted list of all the .svg image files in a directory, but without the extension.

This worked:

ls -1 ./svgs | sed 's/.*/"&"/' | sed 's/\.svg//' | paste -sd, -

Hooray for the command-line!

(coming soon, why I needed that list…)

Filed in:

Wed, 14 Jun 2023

pamd running out of sessions for cron

— SjG @ 6:51 am

I manage a very busy Rocky Linux test-server. For one staging environment, cron is already running five or six maintenance scripts every minute. But when the tests run, the system has to do a lot of additional permissions fixes and filesystem adjustments. I’ve started seeing in the logs the following error message:

pam_systemd(sudo:session): Failed to create session: Maximum number of sessions (8192) reached, refusing further sessions

Now, there is a known older problem with systemd and dbus, that comes up when you search for this error message. I couldn’t find any concrete actions I could take to fix the issue. The other major search results are RedHat pages behind their subscription wall, and, at this point I’m apparently too dumb and out of date to even be able to figure out how to pay for a RedHat subscription.

I think I’ve found at least a temporary solution, however. In /etc/systemd/logind.conf there is the SessionsMax field where you can override the default. I doubled it to 16384, then ran systemctl restart systemd-logind

I’ll have to see if that’s a viable long-term fix rather than just treating the symptoms of a bigger issue.


Thu, 20 Apr 2023

Taming logwatch on Linux*

— SjG @ 6:59 am

*This is actually on Rocky Linux / CENTOS / RHEL, but will likely work on others.

Logwatch can be a nice tool for keeping an eye on your servers. It goes through your logs and creates a nightly aggregate email containing information to keep you apprised of various important details. It can be good to bring things to the attention of lazy / overwhelmed sysadmins like me.

Where it fails, though, is where it overwhelms you with useless information. There are different output level settings, and if you turn the detail levels down far enough, it helps a lot. However, with certain configs and certain OSes, you still get overwhelmed with non-actionable information. Here’s how to fix a few of those.

Crontabs. In Rocky Linux, cron logs a success message that contains a process number, which means the default log is filled with lots and lots of lines like session-685197.scope: Succeeded.: 1 Time(s) which logwatch happily throws into the nightly email. Most searches tell you to edit your /etc/logwatch/conf/ignore.conf file and add the following line:

session-.*scope: Succeeded

This doesn’t work for me. Further research indicates that the ignore.conf file wants a Perl-style regular expression. The recommendation above is sort-of-Perlish, but what ended up working correctly for me was putting the following line in my ignore.conf:

\s*session-(.*?)\.scope: Succeeded\.(.*)

HTTP. For some reason, someone thought having a long list of hostile IP addresses would be helpful. Maybe to manually block them? Seems like a hopeless task. Check out /usr/share/logwatch/scripts/services/http around line 596… and un-comment out the conditional.

$flag = 1;
foreach my $i (sort keys %ban_ip) {
   if ($flag) {
      print "\nA total of ".scalar(keys %ban_ip)." sites probed the server \n";
      $flag = 0;
   }
   #if ($detail > 4) {
      print "   $i\n";
   #}
} 

sshd. I know there are a lot of hackers, script kiddies, and bots out there. I don’t need to see the long list of people who tried and failed to log in with ssh. Unfortunately, the detail level setting for sshd aren’t very helpful. I ended up editing /usr/share/logwatch/scripts/services/sshd and liberally sprinkling my own if ($Detail > 4) {} barriers starting around line 500. Hacky, I know. Also will be clobbered with the next logwatch update. Yuck.

Maybe it’s time for me to submit a bunch of pull requests.


Sun, 1 Jan 2023

New Year New Fear

— SjG @ 11:03 am

I thought I’d update this VPS from Ubuntu 20.04.5 LTS to Ubuntu 22.04.1 LTS. I ran do-release-upgrade which gave all the appropriate warnings and stuff, and proceeded to upgrade. This VPS is hosted on Linode, so there’s a local Ubuntu mirror — the download is blindingly fast.

The do-release-upgrade process appears to run in a Unix screen window. Unfortunately, that interacted poorly with the terminal I was using, so any time I moved my mouse, it spewed control characters as input. That was bad when it was prompting … something? … probably about my nonstandard sshd configuration.

Anyway, Linode provides a web-based console access, so I was eventually able to fix the broken sshd, PHP, and Apache configurations. Only about two hours of downtime. Not bad for New Year’s Day.