[Server-devel] Regarding my OLPC XS Wishlist

[Tony Anderson]

Hi,

My most important wish on the list has been fulfilled, the developers 
are talking to each other on the same list!

My own two cents. OLE Nepal has been very successful in dividing the 
server into two components:

XS - the base server (Sugar server) and
XC - the content install.

The XC install uses Daniel Drake's usbmount and is made from an external 
hard drive (the size of the content is too large for a usb stick to be 
economical).

The concept is that XS provides the basic LAMP stack plus the Sugar 
specific needs (ejabberd, lease-activation, XO registration, and so on). 
Once XS is installed, there is enough functionality to install the 
packages and associated content (e.g. mediawiki, Java, and so on).

XC is an appropriate time and place to provide the optional packages. 
For example, Dan's Guardian and Moodle are currently in the OLE Nepal XS 
but could be installed as part of XS. An important factor in XC is to 
ensure that all content be in the /library partition (directly or be 
symbolic link).

Earlier versions of NEXS included the netsetup.sh script on the XS 
drive. This had the advantage of being easier to edit (if necessary) 
since placing it in the XS build means a new build just to change the 
script. The NEXS build configured the baseboard (RJ45) port for the LAN 
(router with network 172.18.0.) and the second port (usb-ethernet) to 
connect to an XO by cross-over patch for SSH admin. The netsetup.sh 
script was needed only when the schoolserver was to be connected to a 
WAN (internet) and re-configured the second port accordingly.

So my next wish on the wishlist is that it be separated into an XS and 
XC component.

Some minor additions on my wishlist:

1. Try to make the XS install 'headless'. This should be possible if the 
server firmware supports configuring a boot from the usb drive ahead of 
the hard drive. It requires the XS-Au fix to the 'race' condition in 
Kickstart. Currently, a support technician (in principle) needs to carry 
an lcd monitor and usb keyboard to a school to be able to deal with 
server problems. If the XS install could be done without a reformat to 
/library (and all of the content were there), it would be possible to 
re-install XS and, if ssh were then working, deal with the problem.

2. Try to fix the mkusbinstall script so that it works with a 
'store-bought' usb drive - setting up the partition, label, boot flag.

3. Provide a generic install script from usbmount so that the XC install 
scripts can be on the XC drive. Again, this makes it possible for a 
deployment to reconfigure XC without rebuilding or updating XS. For 
example, the XC drive could have a root folder IXC (install XC). If 
usbmount finds this folder, it invokes a script 
/media/usb0/IXC/xcInstall.sh (for example). This way, an XC drive could 
have other files (e.g. development folders with install scripts) and be 
mounted without reinstalling XC itself (Just mv IXC to XC, for example, 
would cause usbmount to not see it as an XC disk).

Tony

On 06/02/2011 10:29 AM, Sridhar Dhanapalan wrote:
> On 28 May 2011 08:31, Aleksey Lim<alsroot at activitycentral.org>  wrote:
>> On Fri, May 27, 2011 at 11:39:54AM -0400, Bernie Innocenti wrote:
>>> On Fri, 2011-05-27 at 21:14 +0545, Abhishek Singh wrote:
>>>> Dear All,
>>>> I've put down my OLPC XS wishlist at
>>>> http://asingh.com.np/blog/olpc-xs-my-wishlist/ . Please comment upon it.
>>>>
>>>> Thank You.
>>> Thank you! Forwarding this to the Dextrose list as well.
>> I've also CCed guys who do XS work in .au
>>
>> Abhishek: thanks for sharing your wishlist.
>>
>>  From my side, I see the whole picture in case of school server like having:
>>
>> * sugar-server[1], the base of any school server. it doesn't provide
>>   stuff like moodle (too complicated to be basic) or puppet (useless on
>>   this level, since configuring sugar-server should be just install
>>   packages/iso and do some automatic work, the higher levels might user
>>   puppet or so)
>> * any additional services that might be useful in some deployments but
>>   are not basic, eg, moodle or wiki.
>>   sugar-server should provide needed info via reliable API for these
>>   services.
>>   in my mind, such services might be formed as separate projects (like
>>   sugar-server-moodle) to make it possible to attach it on purpose
>>   (there might be useful configuration tool that is being used in
>>   sugar-server, mace[2]).
>> * final products that include components on purpose (but sugar-server is
>>   a required one). It is entirely depends on local needs.
> We are looking to make our XS-AU[0] more modular to suit different use
> cases. Our initial goal (completed over a year ago) was to make it
> work on a single interface to integrate well into existing networks.
> Installation is via USB and fully scriptable via kickstart files.
>
> The current XS is very monolithic and bureaucratic. It requires
> moderate sysadmin skills to install and maintain. Maintaining the
> presence service is cumbersome and impractical in our schools. The
> turnover of teachers and students is far too high to ensure that
> anything gets managed properly.
>
> We're looking to slim down the XS-AU such that we can have a simple
> collaboration server (which we currently call "XS Lite") that is
> installable in a classroom as a drop-in appliance. All we really need
> is an ejabberd. Registration, Moodle, Squid, backups and so on are
> unnecessary. Each teacher can run their own server for their own
> class. Conveniently, this could easily run on an XO (XS-on-XO).
>
>> My own running though your wishlist keeping in mind sugar-server plans:
>>
>> 1) Porting XS to new version of Fedora
>>    sugar-server will be build on OBS[3] for distros that are being used
>>    in the field (deb or/and rpm based).
>>    So, downstream can just use these packages, add new one and create
>>    the final product (there is an idea to teach OBS to create isos for
>>    not only SUSE, obs is designed originally)
> You're using SuSE as a base? That sounds like an awful lot of work
> porting to a distribution that isn't widely used. Why not stick with
> the current platform, which benefits from Red Hat engineering and has
> a much larger developer, installation and user base? Not to mention
> that the XOs use the same platform, meaning that skills can be shared
> across client and server.
>
> The XS-AU has been working pretty well on Fedora 11 for quite some
> time. We've reconfigured it so that it runs as a set of packages on
> top of Fedora 11[1] rather than being a fork. We're quire confident
> that it'll work on Fedora 13 without much effort. Fedora 14 will need
> a bit of work since it has a newer version of Python.
>
>
> Sridhar
>
>
> [0] http://dev.laptop.org.au/projects/xs-au/wiki
> [1] http://dev.laptop.org.au/projects/xs-au/wiki/Install_on_an_existing_Fedora_installation
>
>
>
> Sridhar Dhanapalan
> Technical Manager
> One Laptop per Child Australia
> M: +61 425 239 701
> E: sridhar at laptop.org.au
> A: G.P.O. Box 731
>       Sydney, NSW 2001
> W: www.laptop.org.au
>