[Server-devel] the "first user is admin" moodle policy

Daniel Drake dsd at laptop.org
Wed Jun 17 11:30:45 EDT 2009

On Wed, 2009-06-17 at 15:45 +0200, Martin Langhoff wrote:
> On Wed, Jun 17, 2009 at 3:02 PM, Daniel Drake<dsd at laptop.org> wrote:
> > The teachers already had their XOs at this point
> The teachers have XOs and the kids don't yet. Correct?
> > I think this is basically a conflict between the case when you are
> > installing 1 XS (in which case what you are describing is perfect) vs
> > 10+ of them.
> I am still wrapping my head around the workflows applied in each
> school to deploy 10+ schools...
> > Having to connect up other computers and open web browsers
> But... but... OK, these are my assumptions:
> 1 - You do send a technician (or more) with the XS + AP plus some cabling
> 2 - The technician will have to open a browser, assoc to the AP, open
> Browse.xo and visit the XS homepage as a basic QA step. A technician
> cannot leave a school without having tested the connection to the XS
> at least _once_.
>  3 - As part of #2, the technician registers the XO that will be the
> head teacher's machine. If the head teacher already has an XO, the
> technician borrows it. Otherwise, the technician grabs a random XO,
> registers it, and hands it over with a bit of ceremony to the head.
> This is a social thing: the technician should do something to stress
> that the XO is special.

That might work, in a perfect world.
Here's what happens in real life ;)

The internet gear is installed at all the schools in advance of most
things, but it doesn't get activated when the ISP tell us it will be.
So we end up installing school servers before internet access is
available. We configure everything so that it will 'just work' when the
ISP activates, whenever that will be.

In 1 school, the power socket for the XS doesn't work, so we install it
anyway, without testing, and leave the school to sort out the

In another school, the network switch we have doesn't work, so we
install everything else but can't do any testing.

In other schools, the cages for the access points aren't installed on
their schedule so we leave network work for later.

Time passes and we get drowned in other things and fixing the above..

Oh no, where did the time go? It's deployment day and we haven't tested
any of the networks and some aren't even installed. Alright, let's get
up at 4am and go around the schools to do our network testing. The
schools will be closed at 4am but we can test from the roadside.

And actually not all of the schools were ready for day 1 of the
deployment, we had to leave their installation/testing for later. And
due to that schedule, in a couple of schools we simply didn't have any
time for testing in advance, in 1 we then accidently gave out loads of
laptops before realising that the server was off. *That's* why the
laptops weren't activating. Oops!

I think you have a good answer for my question, it just makes the field
work harder, something that we worked very hard to simplify. Namely it
requires things like the headteacher being in the right place at the
right time, with his laptop.. and things that you were told actually
being true, and things actually going to plan, equipment working, and
the thunderstorms holding off enough not to disrupt your schedule, etc.

We saw these unplanned difficulties coming and this is why we prepared
as much as possible in the office and in the warehouse, under our
control. I wouldn't change that if I had to do it again.

> Except that you don't know what to automate. As you said, you don't
> know what XO will the head teacher get. What's the SN? UUID?

We had that on file, but you're right, it's not safe to assume that it
is available. It also makes the process simpler if you don't require
that being known.

But actually in the deployment in Paraguay I think we'd have chosen not
to give any admin rights initially, to anyone. The headteacher would not
really be the appropriate person, rather we would give that
responsibility to one of the support teachers (and it takes a few weeks
to figure out who the support teachers are -- the ones that emerge as
being more capable and hence can be given support roles).

Or, we'd have scripted the creation of a secret, global login/password
for all the school servers for the admin account.

Really the important thing would just be the avoidance of the XS
automatically creating an admin account. That's probably easy to hack
out anyway, a similar amount of effort needed as to tweaking a
configuration option. I just felt I should attempt to communicate my
concerns about this plan given that I see myself ripping out the
functionality in any large-scale field environment.


More information about the Server-devel mailing list