[Server-devel] Installation workflow - lowering barriers of entry.

[Martin Langhoff]

As we are shifting the control of ejabberd to Moodle, it turns out we
can streamline the setup process significantly.

Right now the installation+configuration process of the XS is daunting
-- commandline, misterious even to linux oldtimers and errorprone. If
we simplify it significantly -- and pair it with pre-installed SD
images for XOs :-) -- so that using the XS is an approachable
exercise, we expand the userbase.

So here is my mini plan. Not sure if I'll be able to implement this
for 0.6 - but the motivation is definitely there even if the calendar
days aren't.

At firstboot time

1 - The domain is not set -- or rather, it is set to its default value
-- in this state...
   • idmanager refuses to start - so as to block XO registrations.
This avoids getting the XOs registered to the wrong domain, which is
hard for endusers to fix afterwards.
   • ejabberd should not start -- same reasons as idmanager, and
avoiding the creation of a bogus mnesia DB..
   • access to moodle is redirected to a "set domain" page

2 - The "set domain" page has the following workflow:

2a - if the root password is set (would have been set in anaconda, or
via the OTP scripts -- it just asks for the domain and sets it.

2b - if the root password is _not_ set (for example, SD card installations):
    2b.1: asks for the domain
    2b.2: presents the domain, and a generated password for the root
user, for the user to copy
     2b.3 asks for the root password to be re-entered - if that is successful
     2b.4 - domain and root password are set

Once the domain is set:
   -  (re)starts dhcp, ejabberd, idmgr
   - instructs user to restart laptop (to get the new searchdomain, etc).

This is normally a one-time operation. However, the same facility is
accessible from Moodle's 'coursecreators' admin screen to change the
domain. It sports a huge warning if laptops are already registed in
idmanager (meaning they'll have to be reset and re-registered)..

Security considerations

Naturally, #2 uses the "first user to register and/or get to moodle is
magicaly granted a pseudo-admin role" logic. At the recent moodlemoot
someone related this to the baby bird getting imprinted by the first
large bird it sees. Mommy!

Naturally, there's a race condition there. The newborn baby XS is
naive, and can be fooled in a nasty neighbourhood.

For XS servers without an built-in AP/AA, the easiest way to do a
secure bringup is to avoid plugging in any AP or AA, and use a
crossover cable, or the commandline.

For an XO or any other machine with an integrated AP/AA, the race
condition is harder to avoid. If the HW has a physical switch to
disable wireless, use it :-)

A software-implemented "disable wireless" could be implemented for XOs
and other switch-less machines -- perhaps via grub.conf and olpc.fth
passing a parameter to init (that we can read from /proc/cmdline ).

Root password security

Where possible, I want pilot installs to get a workflow that sets a
good quality generated root password, rather than a "myschool"
password;   large deployments I want to steer towards one based on the
OTP scheme.

Result

the end result is an XS that gets installed via Anaconda (or dd'd to
an SD card), and on first boot needs only 1 bit of configuration via
the webbrowser:

• provide the dns name for the server
• write down the root password (if needed)
• confirm --> voila!

Most of these things are relatively easy now that Moodle is in place
-- one of the design criteria is that it has to be a light workload to
implement.

Notes? Ideas? Who's ready to lend a hand? ;-)

cheers,



martin
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff