[Server-devel] easy backup solution for Linux? (Aaron Huslage)

[John Watlington]

On Mar 18, 2008, at 11:55 PM, Bryan Berry wrote:

> Aaron wrote:
>> the server
>> should very much (to my mind) be purely an appliance (as opposed  
>> to the
>> laptop, which decidedly is not)
>> I'm really only interested in helping get the
>> product out the door with as little reinvention as possible.

I am rethinking the custom school server hardware approach.  The  
economics
are much different than the laptop, and already caused problems
with our first manufacturer.  But that doesn't impact the software  
design!

> Aaron, I completely agree that we need an appliance for the XS and we
> should avoid reinvention for the short term. It needs to be modular
> enough so that I can turn off certain services that I don't need, such
> as Squid and Dansguardian.

Right now, build 160 has neither on by default.
While turning squid on and off is not trivial, we have scripts that try
to make it so...

> In the long term, there appears to be concern that the existing
> administration interfaces for servers are not sufficient for our  
> needs.
> I personally not worked w/ webmin or the admin interface for Centos  
> SME
> Server so I cannot comment from experience.

I've worked with Webmin, and the user experience is tolerable.
Our security architect (Ivan) had less than noble things to say about
it's implementation, dissuading us from using it.

> If there are programming resources to create a better administration
> interface, maybe that should be pursued. If there aren't sufficient
> resources for this, then we should stick to existing tools like Webmin
> or Centos SME interface. We can't just spec out an idealized interface
> and expect it to materialize if there aren't resources to develop it.

I've slowly added scripts automating most of the configuration for
small systems.   We are really close to providing a file either on
disk or on USB which configures the system  --- it is a trivial  
programming
task once the user experience and configuration info have been
agreed upon.

rPath is certainly tempting, but it locks our customers into a
proprietary set of tools for maintaining their servers.  FOSS is one
of the cornerstones of OLPC...

Larger systems (NYC, Birmingham) are a different
story, as their network configuration is radically different.  We will
probably fork builds to handle their case, or move to just supporting
service packages.

wad