When I described how I'd gotten IKE to work for my IPSec setup , I said that I was now tearingdown my GRE tunnel when the IKE daemon declared an IPSec shutdown(or negotiation failure) and that this decision has some securityimplications. Today I want to talk about those implications and why I'mcomfortable with them at the moment.

First off, lets talk about why I have security issues here and normalpeople don't. The difference is that normal people use IPSec based GREtunnels to

In reaction to my entry on why your 64-bit Go programs are going tohave a huge virtual size , sgoody on Hacker News asked why Go does this. There are two answers, depending on what 'this'you're talking about.

The reason that Go allocates all of this virtual memory address spaceis that it keeps other code from accidentally occupying some ofit. This might be C runtime libraries that Go code winds up using or it might be Go code (yours or from packages)that

When I wrote about our long road to getting 10G in production onOmniOS after our problems with it , I mentioned inan aside that the pessimistic version of when we might get ournew fileserver environment back to 10G was'never' and that that would have depressing consequences. TodayI've decided to talk about them.

From the start, one of my concerns with Illumos has been hardware support. A failure to get our OmniOS fileservers backto 10G-T would almost certainly be

Wandering Thoughts has been in operation for long enoughthat I've been able to observe a slow shift in the sources of commentspam attempts over the years. Roughly speaking (and relying on afallible memory), in the beginning much of the comment spam attemptscame from what appeared to be open proxies or otherwise compromisedmachines, to the point where I tried using DNS blocklists likethe CBL and SBL as defenses ( which didn't work out in the end ). Then, at least as I perceived it

In response to my entry on the security problem for publicclients , Jeff Kaufman suggested laptops as an option on thegrounds that they already integrate everything into one physical unit.Unfortunately, I don't think this is workable. The core problem is thatlaptops make terrible desktops, especially in a setting with relativelyuntrusted access to them. This shouldn't surprise anyone, since laptopsaren't designed to be desktops.

A typical university desktop is cheap, has a relatively large screen(17" is the

I wrote earlier about our problems withIntel 10G-T on our OmniOS fileservers andhow we've had to fall back to 1G networking. Obviously we'd liketo change that and go back to 10G-T.The obvious option was another sort of 10G-T chipset besides Intel's.Unfortunately, as far as we can see Intel's chipsets are the bestsupported option and eg Broadcom seems even less likely to workwell (or at all, and

Recently, another department asked our campus-wide sysadmin mailing listfor ideas on how to deal with keyloggers, after having found one. Theysoon clarified that they meant physical keyloggers, because that'swhat they'd found. As I read the ensuing discussion I had an increasingsinking feeling that the answer was basically 'you can't' (which waspretty much the consensus answer; no one had really good ideas andseveral people knew things that looked attractive but didn't fullywork). And

One of the reasons usually put forward for having a separate daemonmanager process (instead of having PID 1 do this work) is that doingso increases overall system resilience. As the theory goes, PID 1can be made minimal and extremely unlikely to crash ( unlike amore complex PID 1 ), while if themore complicated daemon manager does crash it can be restarted.

Well, maybe. The problem is the question of how well you can actuallytake over from a crashed daemon manager. Usually this won't

For various reasons, I build (and rebuild) my copy of the core Gosystem from the latest development source on a regular basis, andperiodically rebuild the Go programs I use from that build. RecentlyI was looking at the memory use of one of my programs with ps and noticed thatit had an absolutely huge virtual size (Linux ps's VSZ field)of around 138 GB, although it had only a moderate resident set size.This nearly gave me a heart attack, since a huge