Wandering Thoughts archives

2012-09-02

What I would like: testable mailers

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

If system administration worked like programming does today, you would fire up your suite of automated tests (they would probably be considered functional tests) and check that they all passed, both the old ones that verified existing functionality and the new tests you added to verify the change you're making. When your tests came up all green, you would have a pretty solid assurance that everything was good.

(Certainly you'd know that you weren't going to mangle email in any of the ways you've done it in the past, because you'd have tests to check for all of those.)

In today's world, well, this doesn't happen. The major reason it doesn't happen is that very few mailers are testable. Testability isn't just being able to test a program (you can always run the program by hand to test it that way); instead, it's the property of being easily tested by automated tests. To be easily tested, you need to expose the ability to ask the program questions and get answers that you can easily automate.

Today, a great deal of mailer functionality is not exposed this way at all and can only be tested through end to end tests where you set up a mailer, run messages through it, and examine the logs and the message deliveries to see what happened to them. When mailers let you ask them limited questions (such as 'what does this address expand to?'), the interfaces for doing this are usually intended for debugging mailer problems instead of verifying mailer functionality. As a result, the output is generally verbose, hard to parse, and not necessarily stable; after all, it was intended to be read by humans (who want a bunch of information and can sort it out themselves) rather than by programs.

A testable mailer would have interfaces that are explicitly designed to be used for automated tests. These interfaces would have stable and minimal output that directly answered your questions and let you control all of the context (in a sophisticated mailer, any number of decisions can depend on things like the source IP). This sort of testability would go well with a true programmable mailer, should we ever get one.

sysadmin/TestableMailers written at 23:25:20; Add Comment

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

In a comment on my original entry on Solaris 11 being closed source, a commentator pointed out what looked like 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 Solaris 11 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 for open source software components'. What they really mean, at least for Solaris, is third party open source software. The zipfiles contain nothing more than the source code for things like Perl, Python, all of the Gnome desktop code, and so on. There is no Solaris kernel source, no DTrace, no anything that belongs to Oracle itself.

If you want to, you can argue that Oracle's omission of the crucial words 'third party' from the description of stuff on this web page is technically not misleading. After all, Solaris was never open source; what was open source was OpenSolaris, which was close to but not identical to Solaris itself, and there is no mention of OpenSolaris on that web page. It is mere optimism for people to see 'open source software components' and 'Solaris' on the same page and jump to the unwarranted conclusion that Oracle is including updated OpenSolaris code that corresponds to Solaris 11.

In practice, this page is quite misleading. I think that most people seeing it are likely to make the same assumption that my commentator made, that the 'Solaris 11' stuff actually includes real Solaris 11 or OpenSolaris source code. I have no idea if Oracle was deliberately misleading when they wrote the text for this web page, or if it just happened by accident and because the people doing it didn't care enough to think about how outside people would read the text. Either case would be perfectly typical of Oracle and their attitude towards the open source world.

Really, it doesn't matter which is true. We still don't have any OpenSolaris or Solaris code update; it is still closed source.

(If you want to slice things finely you can argue that this page's omission of 'third party' in its description plus the omission of OpenSolaris source code is a clear message that Oracle no longer considers Solaris to be open source. While I expect that the conclusion is right, I don't think this page's text had that much thought and care put into it. I also suspect that Oracle is avoiding saying anything definite about Solaris' closed source status; to put it one way, there isn't much upside to Oracle making a definite statement about it.)

solaris/ClosedSourceSolarisII written at 00:35:14; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.