[Server-devel] Git checkouts for the XS

[John Watlington]

On Feb 7, 2008, at 5:46 PM, Martin Langhoff wrote:

> Cloned some key git checkouts and have been reading through the recent
> changelogs last night -
>
>   xs-callhome/
A crusty turd best ignored (tunelling over ssh to allow access to  
servers behind NATs)

>   xs-config/
>   xs-livecd/
>   xs-pkgs/

These are the core of the schoolserver build.  One to gather the  
packages, one
to configure them, and one to package them onto a self-installing CD.

>   security/

Currently not used on the schoolserver.  I was letting the security  
implementation
mature on the laptop before stealing it for the school server.   I  
think it is still
maturing too quickly.

>   ds-backup/

Let Ivan finish this before reviewing/using.

> is there anything I am missing? Initially, am looking at
>
>  - adding the relevant dependencies for moodle and mediawiki
To xs-pkgs

>  - some postinst scripts or "configuration" packages to edit apache's
> configuration for tuning to the available resources
To xs-config

>  - a basic moodle package and mediawiki package (more work on moodle
> and mw to follow)

These can be added to the repositories on xs-dev.  We can exchange  
account
info in separate email.  In the meantime, you can redirect the  
kickstart script in
xs-livecd to include your own repositories, or to a local mirror of  
ours which includes
your new packages.

>  - trying to understand where the security infrastructure is at, and
> how can apache of the XS get some identity information from the XO
> clients, the bitfrost way if possible, kludging it somehow if not...

The school server's current identity model is that a child is  
represented by their laptop.
The username is the laptop serial number (guaranteed unique), the  
password is the
laptop UUID (large, random, and never exposed).   Authentications  
other than disaster
recovery use a public/private key pair, which is generated when a  
user first opens a laptop.
Other IDs include a hash of the public key (IIRC) used by the  
presence (ejabberd) service
to represent a user.  There is also a nickname, which is not  
guaranteed to be unique
within a school but is nonetheless used in our UI.

There is no security infrastructure currently.   Even SELinux is  
turned off in the interest
of making things work.   A student could theoretically access a  
school server, but
they would have to know to use their serial number as the username.

wad