On Wed, Jun 17, 2009 at 5:30 PM, Daniel Drake<d...@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.langh...@gmail.com mar...@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 _______________________________________________ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel