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 _______________________________________________ Server-devel mailing list [email protected] http://lists.laptop.org/listinfo/server-devel
