This is a very small war story.

I've spent part of today working on generating some reports from our IPtraffic accounting system. We have multiple internal networks that getNAT'd out different gateways, and what we want is a report (or a set ofreports) of the topindividual traffic sources for each gateway that did more than a certainamount of aggregate traffic in the day.

Our traffic accounting data is held in a PostgreSQL database. Since atypical day has around six to eight million records

When you write code that deals with IPv4 addresses, every so oftenyou wind up in situations where you want to convert addresses inconventional text form to unsigned 32-bit integers and manipulatethem in various ways (and then convert the results back to normalnotation). This is something I've been dealing with recently , so I've been working on this today.

Python doesn't have any standard library functions that directly dothese conversions. You can write your own code for this (but

One of the things that I really hate about modern desktop environments,specifically their graphical system administration tools, is thatthey are increasingly completely hiding their access controls andauthorization systems. I know that they have them, because theyhave some mechanism for doing various operations that require rootpermissions without bothering to ask me for the root password. Butit's become just about impossible to find them; what was once at leastvisible in PAM configurations has vanished into what I believe is atwisty mess of Kits (PackageKit,

As mentioned earlier , we have a fileserverinfrastructure and so we need some way of propagating account andpassword information around (and letting people actually update theirpasswords). The old traditional answer is NIS, the new traditionalanswer is LDAP, and we don't really like either so we wrote our own.

Given the the Unix system UID problem , anysuch system has three parts: where each machine's account informationlives, how global account information propagates around, and how youcombine global accounts and system accounts

Once upon a time, most every Unix system (or at least most every Unixsystem descended from Berkeley Unix) had a set of system logins andgroups that looked more or less identical and had more or less identicalUIDs and GIDs. This made it possible for fileserver environments to more or less have a single, globalpassword and group file that was used on all of your machines.

Those days are long over. In fact, things have swung to drasticallydifferent system logins and groups, with complete anarchy not just

Here is something that I was surprised to discover the other day : you can nest class definitions inside otherthings. In a way this is just what I should have expected given that class is an executable statement in Python, just like def is ( cf ), but I still found it surprising to see itactually happen.

At least in the simple case, the only thing that nesting a class insideanother class does is make the first class's name harder to get to; theinner class has no special

As I sort of mentioned in an aside in the last entry , pretty much any sort of fileserverinfrastructure does a number of other things besides just servingfiles. In turn this means that hooking a machine into your fileserverenvironment generally involves a lot more than just some mount commands.

For the purposes of this entry, let's ignore all of the services thatonly care about the fileservers themselves; backup, monitoring, and soon. We'll only look at the services that a client has to be tied

Sometimes it seems that system administration goes in cycles. Right nowthe cycle is moving back towards consolidation of services on fewermachines, so I want to talk about the advantages of using separatemachines (whether virtual or physical) for different services, insteadof putting them all on the same machine with various degrees of clevertricks.

(The genesis of this entry was a comment on this entry , talking about how one could use onemachine instead of two to do the job I was tackling.)

First off, it

Here's a somewhat counterintuitive thing that I've come to believe: theconventional syndication feed reader design is the wrong thing for fast,casual skimming.

(I call this counterintuitive because feed readers were initiallypresented as a great way to deal with a a lot of feeds and feed entries,as just the thing to deal with the river of news and so on.)

With fast skimming, the goal is essentially to throw things away. Youwant to drastically limit your time consumption and limit the mentalload