Knowing when to go your own way with open source programs
Dmenu has become one of the core partsof my custom environment. The other day I finally got around toadding a feature to it that I've been wanting for a while, one thatopens the door for making my environment subtly nicer. Given that dmenu is an open source program, theresponsible thing to do would be to go the extra distance to updatethe manpage and so on then submit the change upstream.
I'm not going to do that, but not for the reason that you mightexpect
How we want to recover our ZFS pools from SAN outages
Last night I wrote about how I decided to sit on my hands afterwe had a SAN backend failure ,rather than spring into sleepy action to swap in our hot sparebackend. This turned out to be exactly the right decision for morethan the obvious reasons.
In a SAN environment like ours it's quitepossible to lose access to a whole bunch of disks without losing thedisks themselves. This is what happened to us last night; the powersupply on one disk shelf appears to have flaked out. We
Sometimes the right thing to do is nothing (at least right then)
As system administrators we tend to have a tropism towards heroism. Ifthere is a problem and something that can be done, then by gum we feelthat we should do it. No matter what the exact circumstances, sittingon our hands feels very wrong.
We just lost an entire iSCSI backend for one of our fileservers . This has happened before and it took only a brief amount of sysadmin workto deal with, but this time around there are three things different.First, this happened at 11pm on
A mistake to avoid with summer interns
If you're part of a university and you have both some spare money andsome work that you'd like to get done but don't have the time and energyfor with your existing staff, one traditional solution is to hire astudent or two for the summer. We've done this in the past and inretrospect we made a mistake or two in the process. Today I want towrite about it, partly so that I can hopefully avoid mistakes in thefuture.
The big mistake to
Is it particularly useful to have old Unix source sitting around?
Over the years, the university collectivelyhas acquired and accumulated quite a lot of Unix source code (bythis I mean the copyright-restricted stuff from Unix vendors). Wecame by this source code not through any large deliberate actionbut instead because for a long time it was routine for us to askvendors for system source and for vendors to give it to us for anominal sum . In the early days peoplemade significant use of the source code, modifying it to fix bugsand customize things that we needed
ZFS deduplication is terribly documented
One of the things that makes ZFS deduplication so dangerous and soinfuriating is that it is terribly documented. My example today iswhat should be a simple question: does turning ZFS deduplication onirreversibly taint the pool and/or filesystem(s) involved such thatyou'll have performance issues even if you deleted all data, or can youlater turn ZFS deduplication off and return the pool to its pre-dedupstate of good performance with enough work?
You can find sources on the Internet that will give you both
My version of the story of universities and Unix source code
In the beginning there was Research Unix Version 7 from Bell Labs (apart of AT&T). AT&T gave V7 away basically for free to universities andV7 didn't so much come with source code as intrinsically require thatsource code in order for you to install and operate it sensibly. On topof that V7 needed plenty of hacking to add features to it, so peopledid. As a result of this, plenty of universities acquired AT&T licensesfor V7 (
You can re-connect() UDP sockets (portably)
A commentator on my entry on UDP sockets and sendto() noted:
You can disconnect or re-connect a UDP socket, at least underLinux. The man page says:
"If address is a null address for the protocol, the socket's peeraddress shall be reset."
They are absolutely correct. More than that, this is a portable socketfeature; you can find similar wording in the manpages for FreeBSDand even Solaris 10, to name two Unixes that I checked manpages for.Everyone
Today's question: are anti-spam statistics useful for us?
In the postscript of my recent DNS blocklist stats I basically raised a question in passing:are anti-spam stats I can general here actually useful, or they justvaguely interesting? In the jargon, are they actionable information ?
When I put it this way, the answer is pretty much no. As I see it,there are two possible reasons anti-spam stats could be actionablehere: they could point out some problem in our anti-spam filteringor they could help us allocate limited system resources to anti
Some very basic DNS blocklist hit information for the last 30 days
Our inbound mail gateway anti-spam stuff logs when a connection is from something listed in theCBL or in zen.spamhaus.org (and yes, we know that that's sortof redundant, it's a long story). Because of how it's implemented,we only check zen.spamhaus.org if we don't find the IP in the CBL.
(It turns out that the log message I'm looking at only fires when weaccept an RCPT TO from such an