Our program for logging email attachment type information looks inside .zip and .jar archives, including one level of nesting . Often what we see in this is routine, withbasically the sort of content you'd expect from either routine stuffor malware, but recently we've been seeing zip archives that arejust stuffed with at least one of almost any file extension you canthink of. A few days ago we logged an extreme example:

1fnnAC-0003dZ-EP attachment application/zip

One of the things about system administration automation is thatits evolution often follows the path of least resistance. This canleave you with interesting and peculiar historical remnants, andit can also create situations where it takes a relatively long timebefore a system does the obvious thing. As it happens, I have astory about this.

To go with our account request system , which handles people requestingnew accounts and authorizing requested accounts, we have an actualscript that we run to actually create Unix accounts. Until relativelyrecently that

Normal Fedora updates that have been fully released are availablethrough the regular updates repository, which is (or should be)already configured into dnf on your Fedora system. More recent(and less well tested) updates are available through the updates-testing repository, which you can selectively enable in order to see ifwhat you're looking for is there. Right now I'm interested in Rust1.28, because it's now required to build the latest Firefox fromsource ,so:

# dnf

In light of our problem with timesyncd , we needed a different (and working)solution for time synchronization on our Ubuntu 18.04 machines. Theobvious solution would have been to switch over to chrony ; Ubuntu even has chrony set up so that if you runit, timesyncd is automatically blocked. I like chrony so I wastempted by this idea briefly, but then I realized that using chronywould mean having yet another daemon that we have to care about.Instead, our replacement for timesyncd is running

One perpetual problem in system monitoring is detecting when somethinggoes away. Detecting the presence of something is often easy becauseit reports itself, but detecting absence is usually harder. Forexample, it generally doesn't work well to have some software systememail you when it completes its once a day task, because the oddsare only so-so that you'll actually notice on the day when theexpected email isn't there in your mailbox.

One general pattern for dealing with this is what I'll

Yesterday I described how timesynd couldn't be restarted on oneof our Ubuntu 18.04 machines , where thespecific thing that caused the failure was timesyncd attempting toaccess /var/lib/private/systemd/timesync and failing because/var/lib/private is only accessible by root, not the UID thattimesyncd was running as. My diagnostic efforts left me puzzled asto how this was supposed to work at all, but Trent Lloyd (@lathiat)pointed me to the answer , which

Last November, I wrote an entry about how we were switching tousing systemd's timesyncd on our Ubuntu machines .Ubuntu 18.04 defaults to using timesyncd just as 16.04 does, andwhen we set up our standard Ubuntu 18.04 environment we stuck withthat default behavior (although we customize the list of NTP servers).Then today I discovered that timesyncd had silently died on one ofour 18.04 servers back on July 20th, and

Where Vim Came From ( via ) is aninteresting and thorough overview of the history of vim, vi, ed,and other predecessors (with copious footnotes). It's nice to seeall of the pieces laid out this way, and I learned of some historicallinks that I hadn't already known.

(I do wonder what vi would have been like if ed had kept QED'smultiple buffer support.)

Update, the next day: See also Dennis Ritchie's An incompletehistory of

I have in the past written about the many names of SATA disks and on the names of SAS drives ,and in both cases one of the sorts of names I talked about was the /dev/disk/by-path names. Unlike the various other names of disks,which are generally kernel based, these names come from the inscrutabledepths of udev . It willprobably not surprise you to hear that udev periodically changes itsmind about what to call things (or, sometimes, has problems figuringthings out )