Some thoughts on e-smith's Purpose and Architecture

I'm going to take a shot at identifying a few things that we all agree 
on (or at least that I think we *should* agree on), and one or two that 
are not so consensual.

1. E-smith is a *server* distribution
No X, dev tools, etc. in the default distro, nor should there be.  One 
thing that has attracted many of us to e-smith as opposed to other 
distros is its server focus and the simple fact that it is *not* a 
developer distro.  As we pick up the mantle of developers, it's 
important to keep that in mind.

2. E-Smith is consistent and *easy-to-use*
Kind of like the above, it's important to remember what e-smith is 
supposed to be all about - the easiest, fastest, and most robust and 
reliable way to build a modern server.  One thing that is VITAL to 
putting this feature back on track is an open replacement for the blades 
function that Mitel promised to open up to third party developers, but 
never did.  With Contribs.org beginning to look like the rallying point 
for the community, I would like to suggest the following as the first 
major upgrade in e-smith functionality:  Implement something that works 
just about like the blades mechanism to present the user of a particular 
e-smith 6.x version with an option to automagically download, install, 
and configure with sane defaults some of the more popular packages.  (In 
a nutshell, this new "panel" would connect to contribs.org, see what's 
available for the local version and architecture, and provide 
"single-click" installs for things like ClamAV, say, or maybe POPfile or 
SpamAssassin.)  A large part of the value of e-smith is it's utility 
out-of-the-box and its ease of use.  Personally, the biggest reasons I 
(and I'm sure others) use E-smith are because 1) it's way easier than 
setting up all those services on any other distro, and 2) it just flat 
works.  Let's not blow that, whatever we do...

3. E-smith is flexible
Although (IMO) e-smith needs more work here, it's still very good.  I 
would like to see a bit more in the way of high-level abstractions for 
various functional services.  E-smith users don't (and with few 
exceptions shouldn't) care about, say, what particular package sends or 
delivers mail.  They should, however, be able to turn mail services on 
or off on an e-smith server with a single click.  I personally would 
like to see the concept of local/remote and hierarchy embedded in the 
e-smith configuration.  For instance, it would be really nice to build 
one-click configurations for "Corporate" servers (DNS master, a mail 
master, and a domain  master, etc.) and  "Remote Office Server" (DNS 
subzone (maybe)  and secondary for DNS master, mail secondary, and 
domain secondary).  I think this flexibilty is ulitmately tied to doing 
the blade sorts of things well - In cases where users just want a 
firewall, install e-smith, and uncheck everything but firewall/gateway 
in a config panel.  Need a file server only?  Just check the "File 
Server" box to enable Samba.  Ultimately, it would be nice for that 
master/slave setup to use a designated set of LDAP masters and slaves to 
manage multiple servers and sites as a resonably coherent whole.  (Yes, 
I know how hard that is, I did it at Chevron over 10 years ago.  We did 
it then with YP, bind, and hesiod, and there's much more and better 
stuff to work with today.)

4. E-Smith should *not* try to include all functionality and applications
Gee, Im starting to sound like a broken record about this blades thing, 
but this is the key to giving flexibility to all without negatively 
impacting ease-of-use or cluttering up the distro with a bunch of 
seldom-used trash.  The core e-smith distro should be exactly that, a 
core.  It should *not* inlcude content management systems, groupware 
platforms, or alternative MTAs or mail handlers.  There should be one 
good, solid default for the major functions, and if others want choices 
for thier own reasons, make them available through the new 
whatever-replaces-blades mechanism.

5. E-smith is (or at least should be) secure.
Here's where I may be at odds with many, but I believe that this is 
actually one of the most important aspects of  e-smith.  Unfortunately, 
being based on Red Hat  is not exactly conducive to security.  There is 
no doubt that replacing the current Red Hat core is going to be a huge 
undertaking, no matter what replaces it.  Given that changing is a major 
PITA anyhow, why not take this possibly once-in-a-lifetime opportunity 
to do it right and go with the only core that is both really secure and 
as resistant as possible to the sort of core platform trauma we now 
face:  Go OpenBSD.  There is no Linux even close to being in the same 
league for either security or stability - that's no slam on Linux, but a 
statement of OpenBSD's well-proven excellence in this field.  OpenBSD is 
the ideal platform for a server distro like e-smith, and it addresses a 
huge problem that they have, too:  thier system is technically 
second-to-none, but it really lacks a friendly and easy-to-use face to 
make it usable by non-propellerheads.  I also think that the BSD license 
improves the chances of building a vibrant community where commercial 
and open source parties can work together rather than somewhat at odds 
as we've seen with e-smith and many other GPL'ed projects.  I know 
e-smith is tightly tied to Linux, but more than that,even,  it's tightly 
tied to one particular Linux flavor - given the difficulties in changing 
at all, it may be worth looking at a jump to OpenBSD when a jump is 
indeed warranted.  (That's not now, fortunately...)  Aside:  To be fair, 
I'm on record as being opposed to the GPL on principle, but that's not 
the issue here, the issue is what works and what has synergy - I think 
e-smith and OpenBSD are a great fit for each other, and we should at 
least seriously weigh an OpenBSD core as an option when the time comes 
to deal with replacing the Red Hat underpinnings. Note that I am *not* 
proposing that the e-smith bits be placed under a BSD license - that's 
probably impossible or at least impractical, although I'd love to see 
it, somehow...

The most important thing is to not lose the spirit of those things above 
that have made e-smith uniquely useful among all the distros out there.  
If we all pitch in to do what we can, we can not only save e-smith, but 
give it considerably more vitality than it has today.   I'm a good 
system and application architect, but I am *not* a coder (programmers 
look at my code and supress a shudder, when they can avoid verbalizing 
something like "yick..." :-) )  I'd be happy to contribute in other 
ways, though, including possibly coordinating documentation, which I 
think is in need of some cleaning up and freshening.

Finally, despite my harsh words now and then over the years, I'd like to 
extend a thank-you to the crew at Mitel and E-smith for thier support 
and hard work over the years.  Well done, guys, you're leaving things 
better than you found them...

Dub


--
Please report bugs to [email protected]
Please mail [email protected] (only) to discuss security issues
Support for registered customers and partners to [email protected]
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Searchable archive at http://www.mail-archive.com/devinfo%40lists.e-smith.org