On Tue, Jul 21, 2009 at 9:54 AM, Daniel Drake<[email protected]> wrote: > I remember replying to your mail at > http://lists.laptop.org/pipermail/server-devel/2009-June/003590.html > but I can't find the response anywhere so maybe i was dreaming :) > The solution you propose there sounds good.
I remember it too. Perhaps 'twas in private. I'm back on deck now, and hoping to have a chance to round up 0.6, including the 'coursecreators' patch too (which is still in my TODO list). > I am now dealing with a similar situation in Nepal. In this case I > think we (initially) want a global moodle login over all the XSes, and What is the client machine for that "global login"? An XO/Sugar/Browse.xo client or something else? > again for the first-user-is-admin policy not to happen. What I'm > thinking of is creating an empty file at /etc/moodle/coursecreators > (according to the above scheme) Wait for the code :-) (or tackle it yourself -- it's in auth/olpcxs/auth.php ) > and then setting a Nepal-specific > /etc/moodle/adminpw on each XS. Does that sound workable? That already works. If you pre-create /etc/moodle/adminpw before installing the moodle package somehow (maybe from kickstart?) then Moodle will be pre-configured with the right pw. Otherwise, UPDATE mdl_user SET password='md5-of-your-password' WHERE username='admin' will do the trick. Technically it could have a different username, but in the XS it's reliably 'admin'. Slightly more portable than raw SQL -- but untested -- is the cliupgrade.php command, which I think resets the admin password if you provide one. cheers, m -- [email protected] [email protected] -- 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 [email protected] http://lists.laptop.org/listinfo/server-devel
