Why we're almost certainly staying with ZFS
A commentator on my last entry asked:
i think the implicit ZFS requirement is far too constraining. have youconsidered giving it up?
The short answer is no. But the long answer is more interesting.
ZFS has a number of advantages, but as far as I'm concerned the bigfeature for us is ZFS's flexible management of space. How we useZFS here ( also ) is thatprofessors or groups buy space in fixed chunks and then create howevermany filesystems (in whatever configuration) they want
What we (probably) want in a future version of Solaris
We're starting to be vaguely in sight of the point at wherewe'll have to consider alternatives to our current fileservers . While the software environment hasn't changed,our fileserver infrastructure is built on SunFire X2200s and X2100s andwe've already had two hardware failures in our X2100 pool. We have somenumber of spare X2200s and of course there's more modern hardware, butthe problem is Solaris
Packaging in compiled versus interpreted languages
As a result of reading this , I wound up thinkingabout my different feelings about packaging in Go and Python. In the process I realized that it came down to a relativelyfundamental difference in what packaging needs in compiled languagesversus interpreted languages.
Let me put it this way:
In compiled languages you only need outside packages at buildtime .
The great problem of packaging in interpreted languages is thatyour program needs whatever packages it depends on to be around andfindable at runtime. This drastically complicates packaging and systemdesign,
Version control comes first
A commentator on my last entry wrote(in part):
I also find that sometimes [version control] can fall short inproviding context to a change. Good living documentation (wiki,OneNote, etc.) makes up for the area that strict version controlcannot; providing the reader with some understanding on context, and"why."
It is my position that most organization can benefit most from a goodwiki (or something to that affect), then introduce opportunities forfile based version control at a later
Sysadmins should pretty much version control everything
Today's Sysadvent contained a casual, matter of fact bit:
This code [for deployment scripts] has probably never beenthreatened with version control.
At work, we are not quite hep to all the current DevOps coolness. Wedon't have metrics and dashboards, we don't have everything automatedwith things like Puppet, Chef, or Cfengine, and so on. But even in ourlow state of evolution, we do version control pretty much everythingthat moves.
Part of good awk programming is getting the clause order right
Today I wanted to extract IP addresses from a recording file thathad them in a particular format, in repeated stanzas that lookedlike:
---HTTP--- [...]---SOMETHING---[possibly other IPs] I wanted all the HTTP IPs. I'm sure that somewhere there is a convenientmultiline grep but since I didn't have one handy, I reached for awk. Asit turns out, solving this problem concisely in
Why I'm still using VMware
As I've mentioned before , in theory I should hate VMwarebecause it involves more or less binary kernel modules and I've usuallyavoided that sort of thing like the plague. These days Linux has plentyof virtualization alternatives, ranging from somewhat more open togenuinely open source. Yet I still keep using VMware.
The short answer is that for me it remains the best of a bad lot ofchoices. Everything else is some combination of less convenient tointeract with , more obnoxious (yes, I'm
Should you alert on the glaringly obvious?
First off, I will say that part of this question is due to a peculiarityof the academic environment that I work in; we don't (at leastofficially) do anything outside of the working day. This creates acategory of system problems that are glaringly obvious. If we're at ourcomputers at all, we're going to notice when they happen.
(All of these are actionable alerts , things thatwe need to act on.)
Which brings me around to the question of whether
Alerts should be actionable (and the three sorts of 'alerts')
One of my pet peeves with alerting systems which I've touched onbefore is bad alerts, or more exactly a specificsort of bad alerts. It's my very strong opinion that all of your alertsshould be actionable .
In fact, let's split alerts up into three categories:
- alerts that your sysadmins can and should take immediate action on;these are actionable alerts .There is something to do right away in response to them.
- alerts where the sysadmins need to think about and plan out whatthey
A few small notes about OpenBSD PF (as of 4.4 and 5.1)
Suppose that you read the
pf.confmanpage (in OpenBSD 4.4 or 5.1) andstumble across the following:
max-src-conn- Limits the maximum number of simultaneousTCP connections which have completed the 3-way handshake thata single host can make.
Great, you say, this is just what you need to make sure that bad peopleare not holding too many connections to your web server open at once. Soyou write a PF rule more or less like this:
Menu
![]()