Skip to main content

ToBlog Dump – Time to Clean House

Geeze – Even after periodic culling, I still have twenty+ notes in Google Notebook, fifty-odd notes in Ubernote, and a whole bunch of Google Reader starred items, all waiting to be turned into blog posts.

Ain’t gonna happen. Time to clean house. I’ll dump the most interesting ones into a few posts & cull the rest.

Obviously tracking this sort of thing would be better served by a bookmarking service, but I’ve decided that my professional Internet presence will be Google and Google related apps. I use a combination of Yahoo & for things that I don’t want associated with my professional presence, and I try hard not to mix them. The only interesting bookmark service is a Yahoo property (for now, at least) so I don’t have a public bookmarking service. Lame? Yes. I don’t have Twitter or Facebook accounts either. Really lame. Maybe even lame2. I still would rather read blogs posts than tweets. Is that lame3 ?

Disclaimer – most of these links are more than a year old, but they’ve survived periodic culling, so maybe they are good links?

Here goes:

A read-once-for-sure and re-read-once-a-year post on the Anatomy of Security Disasters [Edit:2019-01-04 broken link] by Marcus Ranum describing …ummmm… the anatomy of security disasters, I guess. Good read.

I saved this DailyWTF post because it shows a bad security device implementation (and what I believe is a bad choice of identifiers). My luck the clowns would store my fingerprint un-hashed. One revocation down, nine to go.

Here’s a good ‘Sysadmin Principles’ list from Steve Stady and Seth Vidal [Edit:2019-01-04 broken link]. It’s in plain text, so those of you who surf the web with curl and less can read it too. I like reading what others think are the core system administration principles. To me, doing it ‘right’ has value, and I don’t appreciate people who shortcut just because they are lazy or in a hurry. They get by today, but someone else (probably me) will have to clean up after them later.

It’s possible that we’ll eventually end up migrating from Solaris to Linux. This post [Edit:2019-01-04 broken link] by ‘The Unix Blog’ reminded my why I like Solaris. Until Oracle fscks it up anyway.

I read and bookmarked a whole lot of articles about the Heartland breech. The most interesting one is Heartland Sniffer Hid in Unallocated Portion of Disk [Edit:2019-01-04 broken link]. Cool, unless you are Heartland or one of it’s victims. I’m a fan of network segmentation and bi-directional default deny firewall rules. I hope it makes a difference, ‘cause it sure is a lot of work to maintain.

A saved a few snarky anti-windows links, mostly written by the blind [Edit:2019-01-04 broken link] for the purpose of feeding the trolls. I don’t think that Unix is superior to Windows in every way. In some ways, like patching, I’d much rather have Windows/SQL than Solaris/Linux + Oracle. Microsoft has an really good patch management suite. And no, I don’t think Open Source is automatically bug free, cheaper, faster, easier to manage. My Firefox is on .13 right now. That’s not impressive. It’s annoying.

Speaking of the Microsoft stack, Todd Hoff’s High Scalability blog had a post on scaling StackOverflow.  Buy vs. rent, scale up vs. scale out, all the good stuff.

Here’s a couple more related links:

On a slightly different theme, Michael Nygards Why Do Enterprise Applications Suck [Edit:2019-01-04 broken link] was a good read. It’s hard to keep up the energy on backend apps.

I’ll close with a quote from the comment section of this InfoQ post on scalability worst practices:

Marcos Santos:

The Great Knuth said:

Early Optimization is the root of all evil

But Marcos Eliziario, who is a poor programmer, known of no one, said at 2 AM after two sleepless days:

Reckless regard for optimization is the cube of an even greater evil

Don’t worry, there will be more.


Popular posts from this blog

Cargo Cult System Administration

“imitate the superficial exterior of a process or system without having any understanding of the underlying substance” --Wikipedia During and after WWII, some native south pacific islanders erroneously associated the presence of war related technology with the delivery of highly desirable cargo. When the war ended and the cargo stopped showing up, they built crude facsimiles of runways, control towers, and airplanes in the belief that the presence of war technology caused the delivery of desirable cargo. From our point of view, it looks pretty amusing to see people build fake airplanes, runways and control towers  and wait for cargo to fall from the sky.The question is, how amusing are we?We have cargo cult science[1], cargo cult management[2], cargo cult programming[3], how about cargo cult system management?Here’s some common system administration failures that might be ‘cargo cult’:Failing to understand the difference between necessary and sufficient. A daily backup is necessary, b…

Ad-Hoc Versus Structured System Management

Structured system management is a concept that covers the fundamentals of building, securing, deploying, monitoring, logging, alerting, and documenting networks, servers and applications. Structured system management implies that you have those fundamentals in place, you execute them consistently, and you know all cases where you are inconsistent. The converse of structured system management is what I call ad hoc system management, where every system has it own plan, undocumented and inconsistent, and you don't know how inconsistent they are, because you've never looked.

In previous posts (here and here) I implied that structured system management was an integral part of improving system availability. Having inherited several platforms that had, at best, ad hoc system management, and having moved the platforms to something resembling structured system management, I've concluded that implementing basic structure around system management will be the best and fastest path to…

The Cloud – Provider Failure Modes

In The Cloud - Outsourcing Moved up the Stack[1] I compared the outsourcing that we do routinely (wide area networks) with the outsourcing of the higher layers of the application stack (processor, memory, storage). Conceptually they are similar:
In both cases you’ve entrusted your bits to someone else, you’ve shared physical and logical resources with others, you’ve disassociated physical devices (circuits or servers) from logical devices (virtual circuits, virtual severs), and in exchange for what is hopefully better, faster, cheaper service, you give up visibility, manageability and control to a provider. There are differences though. In the case of networking, your cloud provider is only entrusted with your bits for the time it takes for those bits to cross the providers network, and the loss of a few bits is not catastrophic. For providers of higher layer services, the bits are entrusted to the provider for the life of the bits, and the loss of a few bits is a major problem. The…