Some thoughts on logging failed login attempts (for existing users)

When I wrote my entry on logging all successful user authentications I thought that I had strong heretical views onlogging failed authentications for existing users. Since thinking moreabout it, I have backed off on that a bit so this is somewhat moreambivalent than I was expecting.

(I've written before about why you should basically neverlog nonexistent user names for bad authentication attempts . The issue here is whether you should logfailed authentications for usernames that do exist.)

The web app world these days has the concept of


People are not ignorant (usually)

One of the eternal complaints in the computer world is, roughly, 'peopleare ignoring this marvelous thing because they are ignorant' (and itsflipside version of 'people are only using X/doing X because they don'tknow any better'). A closely related version of this (arguably the sameone) is 'people would use X if only they really understood how good itis'. You can fill in the blank here with any number of technologies,often classical ones; these days,


Solaris 11 is still closed source (and Oracle is careless with words)

In a comment on my original entry on Solaris 11 being closedsource , a commentator pointed out what lookedlike source code for Solaris 11 on Oracle's site, here .Flush with optimism, I eagerly downloaded the two large zip files,unpacked them, and dove in to take a look at things like the Solaris11 version of ZFS.

I will spare you the bother of doing this and skip to the punchline.The Oracle web page carefully says that it is for 'source code foropen


What I would like: testable mailers

Suppose that you are developing a change in your mailer's configurationfiles. There are very few 'clearly correct' changes to mailerconfigurations so of course you would like to test your change, to makesure that it does what you want and that it doesn't break anything.

If system administration worked like programming does today, you wouldfire up your suite of automated tests (they would probably be consideredfunctional tests) and check that they all passed, both the old ones thatverified existing functionality and the


A realization about one bit of test-driven development

One of the standard pieces of instruction for TDD is that when you areabout to do some coding you should not just write the tests before thecode but you should also run the tests and see them fail before startingon the real code. You can find this cycle described in a lot of places;write test, run test, see the failure, write the code, run the test,see the test pass, feel good (monkey got a pellet, yay). Running teststhat you knew were going


A small rant about looking down on Linux users

Sometimes, in some quarters, it is popular to say that the reasonpeople use Linux is that they don't know any better. If they had been(properly) exposed to the magnificence of the *BSD of your choice,Solaris, or whatever, these Linux users would immediately understandand switch. If they were exposed to these Unixes and did not switch, itwould clearly be because they had been damaged by their Linux experienceand did not understand the true appeal of Unix; they were clearly tooused


My perspective on why we do in-place reinstalls of machines

Given what I mentioned yesterday , youmight wonder why we are doing what I called 'in-place' reinstalls ofmachines, where we reinstall a machine with the name and IP address thatit will use in production. From my perspective there are two or threereasons for this.

The first reason, the big reason, is that we've run out of sparehardware. In previous upgrades we installed the new version of amachine on completely new hardware, got it running, and then switchedeverything around during


A realization: install configuration files before packages

We have what is probably a somewhat unusual problem. Every so oftenwe do what I'll call an 'in-place' reinstall of a machine, where wereinstall a machine with the name and IP address that it will use inproduction, and as part of such reinstalls we install packages forthings like mailers (if the machine is a mail machine), web servers,and so on. The problem with this is that sometimes a package will notjust install the daemon but auto-start it for


When Exim generates bounce messages

When I started looking at the numbers from our recent spam incident , an inconsistency jumped out at me: wehad significantly more bounce messages in the queue than my count ofsubmitted spam messages. Fortunately for my peace of mind, it turns outthe cause of this wasn't missing spam messages but that Exim handlesbounces differently than I was expecting.

What I was expecting is how I believe that our old mailer behaved; I wasexpecting Exim to generate a single bounce message at the end of fullyprocessing a message


You should log all successful user authentication

Here's something that I've recently had my nose smacked with :

Every place where users can authenticate over the network to yoursystems should log successful authentications, including the sourceIP address .

Every place. No exceptions. And all of the pieces (minimally user name,remote IP, and time) should be logged explicitly in one place; youshould not have to piece together this information by inference from acollection of different logs, because sooner or later you will go madfrom having to do this.