[Server-devel] accounts & backups

Holger Levsen holger at layer-acht.org
Mon Apr 23 16:32:36 EDT 2007


Hi,

again, please treat most of this a summary of my understanding and comment.

"Originally" (that is, after the just mentioned telefoneconference) I thought 
LDAP would be used, to store account data. After some mail exchange with 
Martin Langhoff, I'm not convinced anymore. Or rather I think, we should 
start with a non LDAP-setup (keep it simple, for us and the teachers/schools) 
and provide a LDAP-setup as a 2nd step (for those who want/need it).

Martin suggests to use PAM-*sql to store the authentication and tweak moodles 
management UI for user management. Martin, is this ready to be used and just 
needs tweaking for layout or does it need more serious tweaking?

To me this approach looks the most promising currently: we want moodle on the 
server anyway (right?) and it's ready to be used. And it's simple.

Martin also suggested Centre-SIS and Focus-SIS, a fork of the former. To me 
they look more targetted at higher grades (due to advanced reporting 
features) than the XO laptop is currently targetted at, and therefore less 
useful (than moodle), and also less commonly used.

Debian-Edu stores account data in LDAP. In the sarge version we 
(another "we" - I'm quite heavily involved in Debian-Edu/Skolelinux) used 
wlus and webmin, for etch we'll have two tools: lwat (http://bzz.no/lwat/) 
and CipUX (http://doc.cipux.org/) - Both are PHP webfrontends targetted at 
teachers administrating schools. From what I've seen, lwat is cleaner and 
CipUX has more useful features (as opposed to feature bloat, lwat is a bit 
sparse).

Whichever road we take, the we need two scripts:
- one for the backup, see below.
- another one for account creation on the server, after the initial boot of 
the XO.

For both, we need to (securly) access the server from the laptop. How will we 
do this? Ignore ssh-fingerprint checks? (As I guess we dont want 4 years olds 
to compare them :) But every server will come with different ssh-keys and the 
laptops are not tied to the server... the other option would be a 
ssh-host-key which is the same for all servers (possible for a dedicated ssh 
server running on another port, only for initial account creation and 
transmission of the real ssh-host key.)

The account creation script will then transmit the unique name of the laptop 
(which AIUI should be something like $country_city_school_laptopname as the 
laptops name is the kids name) and the ssh-pubkey of the olpc-user from the 
laptop to the server, where then an account will be created with a simple 
shell script. Login to this account is then possible with that pubkey.

The backup script... a principal question first: should it be possible for the 
pupils to independently get back files from their backups? I guess it would 
be nice, but IMHO not strictly needed in the beginning aka now. (So we could 
schedule this feature later in time, if we dont have enough ressources.)

The backup itself should be done with rsync and include the complete /home 
directory (and nothing more?). Should the backup be run from cron or also 
optionally on demand? I think it would be worthwhile to consider something 
like duplicity (http://www.nongnu.org/duplicity/)

Quote from there: Duplicity backs directories by producing encrypted 
tar-format volumes and uploading them to a remote or local file server. 
Because duplicity uses librsync, the incremental archives are space efficient 
and only record the parts of files that have changed since the last backup. 
Because duplicity uses GnuPG to encrypt and/or sign these archives, they will 
be safe from spying and/or modification by the server.

I guess a GUI for sugar (if needed) will/needs to be written...


So far for now,

regards,
	Holger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.laptop.org/pipermail/server-devel/attachments/20070423/19f360cb/attachment.pgp 


More information about the Server-devel mailing list