[Server-devel] Git checkouts for the XS

John Watlington wad at laptop.org
Fri Feb 8 00:32:46 EST 2008


You forgot the idmgr package.  See:
http://wiki.laptop.org/go/XS_Software_Repositories

wad

On Feb 7, 2008, at 10:07 PM, John Watlington wrote:

> 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
>



More information about the Server-devel mailing list