We have a Linux login server that is our primary server basicallyby default; it's the first one in numbering and the server aconvenient alias is pointed to, so most people wind up using it.Naturally we monitor its OS level metrics as part of our Prometheussetup , and as part ofthat a graph of its load average (along with all our other interestingservers) appears on our overview Grafana dashboard. For basicallyas long as we've been doing this, we've noticed that this

Suppose, as a not entirely hypothetical case, that you want to allowsome people to run ' zfs destroy ' to delete only ZFS snapshots(since ZFS cannot delegate this through its own permission system ). You can tell ZFS snapshotsapart from other ZFS objects because ZFS snapshots all have '@' intheir names. There are two approaches to enforcing this restrictionon ' zfs destroy ' arguments. The first is to write a suitable sudoers rulethat carefully constraints the arguments to ' zfs destroy ' (seeMichael'

I was recently reading Rob Landley about the /usr split ( via , which canbe summarized as being not very enthused about the split between /bin and /usr/bin , and how long it lasted. I have some opinionson this as a whole, but today I want to note that one factor inkeeping this split going is diskless workstations and the issue of /etc .

Unix traditionally puts a number of machine specific pieces ofinformation in /etc , especially the machine's hostname and itsIP address

In Rob Landley about the /usr split , RobLandley doesn't have very good things to say about how the splitbetween /bin and /usr/bin (and various other directories) hascontinued to exist, especially in various standards. One of my viewson this is that the split continuing to exist was always inevitable,regardless of why the split existed and what reasons people mighthave for preserving it (such as diskless workstations benefitingfrom it ).

As far as standards go, Unix standards have pretty

As a system administrator, I primarily use git not to develop myown local changes but to keep track of what's going on in projectsthat we (or I) use or care about, and to pull their changes intolocal repositories. This has caused me to put together a set of gitaliases that are probably somewhat different than what programmerswind up with. For much the same reason that I periodically inventory my Firefox addons , I'm writing down mycommon aliases here today.

All of these are

ZFS has a system that lets you selectively delegate administrationpermissions from root to other users (exposed through ' zfs allow ')on a per filesystem tree basis. This led to the following interestingquestion (and answer) over on the fediverse:

@wxcafe :hey can anyone here confirm that there's no zfs permission fordestroying only snapshots?

@cks :I can confirm this based on the ZFS on Linux code. The 'can youdestroy a snapshot' code delegates to a general 'can you destroythings

Somewhat recently, the ZFS on Linux mailing list had a discussionof how frequently you should do ZFS scrubs, with a number of peoplesuggesting that modern drives only really need relatively infrequentscrubs. As I was reading through the thread as part of trying tocatch up on the list, it struck me that there is a decent reasonfor scrubbing frequently despite this. If we assume that scrubssurface existing problems that had previously been silent (insteadof creating new ones), doing frequent scrubs lowers the mean timebefore you

Perhaps unlike most people, I apply updates to my Fedora machinesthrough the command line, first with yum and now with dnf . Aspart of that, I have for a long time made a habit of trying to readthe information that Fedora theoretically publishes about everypackage update with ' dnf updateinfo info ', just in case there wasa surprise lurking in there for some particular package (this hassometimes exposed issues, such as when I discovered that Fedoramaintains separate package databases for each user ).Sadly, I

Drew DeVault recently wrote Dependencies and maintainers ,which I will summarize as both suggesting that dependencies shouldbe minimized and being a call to become involved in your dependencies.I have various thoughts on this general issue ( cf ), but perhaps I havean unusual perspective as someone who is primarily a systemadministrator instead of a developer. As part of that perspective,I think it's useful to think about two sorts of dependencies, whatI will call code dependencies and operational dependencies .

Code dependencies are the Python modules,