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

[Martin Langhoff]

On Wed, Jun 17, 2009 at 5:30 PM, Daniel Drake<dsd at laptop.org> wrote:
> That might work, in a perfect world.
> Here's what happens in real life ;)

Excellent notes. Thanks! So, if I

 - leave the current machinery in place, and...

 - add the /etc/moodle/coursecreators support so that
   - if it exists, even if empty, magic "first come is CC" is disabled
   - it reads /etc/moodle/coursecreators looking for matching SNs (one
SN per line)

we'd have all the reasonable cases covered, on the assumption that on
a sizable deployment with the issues you describe people will _at
least_ know the SN of an XO in the hands of a teacher.

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

That -- in itself -- is not a major thing. The XS will DTRT w/o
internet. If it doesn't, let me know.

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

Those cases are hard. And as you say, the XOs are out-of-the-bag
without a field technician to help. When power comes, the
first-to-register rule is bad.

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

Makes sense.

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

Ok. We'll have both modes of operation then. Any other approachable improvement?

> 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

Note here that the abilities of a course creator are very limited.
They can (or will be able to):

 - create a new 'course' -- a place to share docs and organise a
lesson (see 'narratives' discussion in the archive)

 - for large schools, get the 'course membership' to drive
ejabberd-based 'neighbourhood view'

 - mark a laptop as stolen

 - alias a replacement laptop to an 'old' user

 - grant coursecreator role to another user

That's about it. Nothing destructive -- pretty much on purpose :-)

> Really the important thing would just be the avoidance of the XS
> automatically creating an admin account. That's probably easy to hack

The true admin acct is needed -- moodle assigns it as the owner for
certain internal things. Just like the XOs have a uid 0 account. The
current installation scheme creates the account with a random
password, which is written in /etc/moodle/adminpw - root-readable.

hth,


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