Re: [Server-devel] fresh XS 0.6 install
So I abandoned qemu and moved to soas under vbox with bridged networking. Now soas gets an ip from the xs and I can reach the moodle login page (and also the external internet) But, I can not register the soas. I get 'can not obtain data needed to register'. I read http://dev.sugarlabs.org/ticket/916, but I'm not clear if this is already in soas and anyway the patch seems to expect the xs to listen on 8080, which I don't think it does. Help appreciated. - Original Message - From: Martin Langhoff martin.langh...@gmail.com To: Tim Moody timmo...@sympatico.ca Cc: server-devel@lists.laptop.org Sent: Saturday, October 10, 2009 4:52 AM Subject: Re: [Server-devel] fresh XS 0.6 install On Sat, Oct 10, 2009 at 1:06 AM, Tim Moody timmo...@sympatico.ca wrote: OK, so the message is don't worry about first boot. /var/log/moodle-instupg.log ends in success. Good! the next problem is that when I try to register the qemu emulated xo 8.2.0 it fails, probably because qemu has a built in dhcp server and nat firewall, so the xo never gets it address, dns, and domain from the xs and therefore can't find the xs. Very likely correct. Maybe you can run qemu without dhcp nat? 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
[Server-devel] Initial Feedback
Martin, Performed some basic testing today with the XS. Quite impressive. SPECS: 1 x Linksys WRT54GL - DDWRT v24 DELL Optiplex 755 - 160 GB, 2Gb Ram(that's all the specs I have for now) 30 XO laptops Below is a summary of different things I tested to see how they worked - no science to what I did. 1. PASS - Registered each XO and then hit ctrl-alt-erase to reboot sugar. All registered OK. 2. PASS - Checked to see each XO was recognised in the neighbourhood view. Spot tests consistently re-affirmed this. 3. PASS - Shared an activity and then had other XOs join. Includes accurate 'huddling' around each activity. Spot check around room to confirm. 4. PASS - Switched between activities whilst sharing. E.g. One person who was on Record, joined Jigsaw and this change was accurately reflected. 5. PASS - When a person switched away from an activity (as opposed to exiting it) this was reflected in the neighbourhood view. Spot check around room to confirm. 6. FAIL - Simulate dead battery - but cold shutting off a machine. Neighbourhood did not reflect this, showed they were still online. Had to restart, connect back to school server and shutdown properly to leave neighbourhood view. They way some of the kids are out in the deployment, they are still learning the whole shutdown/exit activity procedure, so this could pose a problem - though I understand how this could be hard to implement. 7. FAIL - a reboot (full restart or ctrl-alt-erase) causes the rebooted machines not to accurately reflect who is part of a shared activity. Some rebooted machines reflected a more accurate picture than others, but none had the full picture. Kids will be going offline and online all the time in deployments so I can see how this could become a problem. Though this will be somewhat tempered by the ability to still share and view other XOs. Thank you, Rangan ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Initial Feedback
Rangan, This is really helpful. I have been seeing the same things you saw in items 6 and 7: shutdown/disconnected XOs still show in Neighborhood view. Gerald On Sun, Oct 11, 2009 at 7:06 AM, Rangan Srikhanta ran...@laptop.org.auwrote: Martin, Performed some basic testing today with the XS. Quite impressive. SPECS: 1 x Linksys WRT54GL - DDWRT v24 DELL Optiplex 755 - 160 GB, 2Gb Ram(that's all the specs I have for now) 30 XO laptops Below is a summary of different things I tested to see how they worked - no science to what I did. 1. PASS - Registered each XO and then hit ctrl-alt-erase to reboot sugar. All registered OK. 2. PASS - Checked to see each XO was recognised in the neighbourhood view. Spot tests consistently re-affirmed this. 3. PASS - Shared an activity and then had other XOs join. Includes accurate 'huddling' around each activity. Spot check around room to confirm. 4. PASS - Switched between activities whilst sharing. E.g. One person who was on Record, joined Jigsaw and this change was accurately reflected. 5. PASS - When a person switched away from an activity (as opposed to exiting it) this was reflected in the neighbourhood view. Spot check around room to confirm. 6. FAIL - Simulate dead battery - but cold shutting off a machine. Neighbourhood did not reflect this, showed they were still online. Had to restart, connect back to school server and shutdown properly to leave neighbourhood view. They way some of the kids are out in the deployment, they are still learning the whole shutdown/exit activity procedure, so this could pose a problem - though I understand how this could be hard to implement. 7. FAIL - a reboot (full restart or ctrl-alt-erase) causes the rebooted machines not to accurately reflect who is part of a shared activity. Some rebooted machines reflected a more accurate picture than others, but none had the full picture. Kids will be going offline and online all the time in deployments so I can see how this could become a problem. Though this will be somewhat tempered by the ability to still share and view other XOs. Thank you, Rangan ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] CCCS XS deployment
On Thu, 2009-10-08 at 15:23 -0400, Josh Totoro wrote: Hey all, We currently have 350 xo’s on our network and 1 xs server running. How well does the XS fair when fully loaded? What specs? We just purchased 300 more xo’s and will purchase 300 more in a month or so. Yea, more fun for you. ;) When I set up the first XS server back in march (0.5.1) there was a lot more info on the Wiki about setting up multiple XS servers in one network. Does anyone have any of this info available still or does it no longer apply? As network_config is used for the setup for the server's role, only role 1 provides internet access, and a large netblock on eth1, while role 1 assumes that you have only one nic and are using AA to contact the XO's. So we are really in uncharted waters here.. Think the easiest way would to have the wired lan on role 1 handle less of the netblock and allocate the addresses across the XS server farm in the form of a new lanbond0 file that would take into account the fact that the role other that 1 should create the needed network configuration. I'm thinking a /23 for each XS's wired nic here. Anybody running more that 500 clients off a single XS? Of course you would have to change the bind/dhcp config to match... Martin, what do you think? Should we set up all XS servers the same way and let them run individually from each other? I am worried about conflicts with using the same name schoolserver.cccs.org, should the next one be schoolserver2.cccs.org or will that prevent things like ejabberd from working. Until the above issue is addressed, that might get a bit out of hand with 2 lans sharing the same address space. Just tossing around ideas... Jerry ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] CCCS XS deployment
On Sun, 2009-10-11 at 19:50 -0500, Jerry Vonau wrote: On Thu, 2009-10-08 at 15:23 -0400, Josh Totoro wrote: snip When I set up the first XS server back in march (0.5.1) there was a lot more info on the Wiki about setting up multiple XS servers in one network. Does anyone have any of this info available still or does it no longer apply? As network_config is used for the setup for the server's role, only role 1 provides internet access, and a large netblock on eth1, while role 1 assumes that you have only one nic and are using AA to contact the XO's. So we are really in uncharted waters here.. Think the easiest way would to have the wired lan on role 1 handle less of the netblock and allocate the addresses across the XS server farm in the form of a new lanbond0 file that would take into account the fact that the role other that 1 should create the needed network configuration. I'm thinking a /23 for each XS's wired nic here. Anybody running more that 500 clients off a single XS? Of course you would have to change the bind/dhcp config to match... Better plan, just make eth1,2,3 be slaves of mshbond0,1,2. on the additional XSes, No need to change the network layout, ~500 clients per nic. We just have to edit the ifcfg-ethX file and add MASTER=mshbondX SLAVE=yes. Martin, what do you think? Cleaner? Should we set up all XS servers the same way and let them run individually from each other? I am worried about conflicts with using the same name schoolserver.cccs.org, should the next one be schoolserver2.cccs.org or will that prevent things like ejabberd from working. Until the above issue is addressed, that might get a bit out of hand with 2 lans sharing the same address space. The issue now is that hostname is set to HOSTNAME=schoolserver.@@BASEDNSNAME@@ in /etc/sysconfig/network which would apply to both XS servers. The quick workaround would be to use a subdomain for each XS when you run domain_config, eg: lan1.cccs.org for the first XS, then change lan1 for the second XS. Just tossing around ideas... Jerry ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
