Tuesday, 6 August 2013

Higher level sysadmin

I've been interested in the genealogy and hierarchy of computer languages ever since I bumped into the conundrum, "If C is a higher level language than ALGOL or assembly, what is Perl?" Obviously there are many humorous responses to this question, but I want to answer it more philosophically.

The perfect language has yet to evolve, and like insect species, computer languages will evolve to eventually perfectly fit their niche.

Linux seems to have come out on top of the OS world, just as C seems to be the higher level language. My first problem is that higher and lower were fine when there were two levels, but now we have a whole mess of branches and directions. It is better to think of C as a rung on a ladder or the 2nd floor of a building. (Floor can be ambiguous, so I would suggest the word ├ętage from French. Again you can argue that the first element of an array is a[0] or a[1] so lets call binary etage[1] and assembler as etage[10]; leaving C as etage[15].)

[So what is this all leading up to?]

Today I was asked by a friend, "I'm thinking of replacing my mail server with something more modern. I have been looking at ATMail, do you have any takes on it?" He went on, "I want a mail server where, ideally, caldav+cardav+webmail+imap are all synchronized."

Well that seems logical. So what did I say?

"In my (*nix) world, there is eventually a default solution to each protocol. 2013:
webmail: roundcube
SMTP: exim (though if I had to start again I might pick postfix)
IMAP: dovecot
caldav: I've written my own, but http://radicale.org/ seems very interesting, but DAVIcal is _the_ one for now."

This leaves a large hole. "synchronised".  I wrote Notice to try and do just that. It was a clunky collection of casually connected CGI that was unmaintainable, (except by me) and 100% dependent upon mySQL.

Then I met DBIx::Class, (I was introduced by a huge(ly) popular guy, and when I looked under his frame I found CGI::Application.)

Notice version 3.0 was database agnostic. It does not, (for the most part) care if you MUST use postgreSQL or SQLite, (it could almost use CDB - the greatest of DJB's inventions, (actually the only one that I understand enough to fully support.))

This abstraction made me realise that we need emsg_service. emsg_service is the 100% agnostic electronic message platform. It does not care if you use exim or postfix. It does not mind if you want flat-file configuration or direct DB config, (so that dovecot has instant updates.) It does not mind if you want to replace exim with sendmail.

But wait,...

... there is more. emsg_service is also language agnostic. It can be implemented in perl or python or haskel. emsg_service is the idea of distributed performance with centralised control of digital communications. It should have an API, a command line interface and a GUI via HTTPs. It can scale from one server to perform all services to as many clusters for each function, as you need.

 It MUST implement its own pocket Certificate Authority, OR accept a certificate to enable it to hang off an existing company hierarchy. (So that internal security may be freely implemented.)

It must let users store data: IMAPs calDAV cardDAV PGP&SSH keys and transmit data SMTPs. (It should have a quota for each. Any quota MUST have at least per-user granularity.)

I would suggest that it link in with cfEngine and FAI/KS so that it can configure a bare metal machine with an OS just by knowing its MAC.

To that end it will need an asset management system to track the physical machines, their locations and the intended configuration. (And a tftp server.)

While you are tracking users you might as well have a dynamic SSH key distribution and user configuration for each server.

The two things that you do NOT HAVE TO WRITE is the MTA or the IMAP server.

Get to it Internet, (feel free to fork Notice). Integration WITHOUT conglomeration. And when you aren't making bricks, add in fax and SMS support.

 Or you could cop out and just use ATmail, (or mailpile if that becomes what I expect that it will.)

No comments:

Post a Comment

About this blog

Sort of a test blog... until it isn't