Hi Martin, Thank you very much for that explanation. It certainly helps to keep everything in perspective.
What I think we really need is a turn-key ejabberd solution that integrates with existing network services. If you or anyone else can assist we'd be immensely grateful. I'll explain... There appears to be some a difference in the design assumptions for the XS versus what we see in Australian schools. The XS works great where no other network exists, or where it is acceptable to establish a separate subnet and wireless infrastructure. Schools in remote Australia are attended by children who literally live in third-world conditions (making them good candidates for XOs), but the schools themselves are generally well-funded and have great network connectivity. Buildings are networked together, wireless points are mounted around the place, and so on. If we can harness this existing infrastructure, we can make our jobs easier and more cost-effective. It will also give us considerably greater buy-in from stakeholders. We are also constrained by the remoteness of these schools. Take a look at a map of Australia and you'll see why. Settlements are very far apart and it is a very expensive exercise sending a team out to one. The deployment needs to work the first time, as it is difficult to return to the location. The 'Easy' method you outline (i.e. what the XS is designed to do) is what we have been doing so far. I like how the XS automagically handles much of the complexity for this. However, because it is self-contained we need to also deploy our own wireless points and so on. The 'Hard' method is too difficult to expect a volunteer to perform, and there are too many things that could go wrong either during setup or afterwards. Long-term, I'd like to see us using the XS as our primary platform. At the moment, however, it doesn't integrate into existing networks and therefore can unfortunately be perceived as a burden. Shorter-term, we have identified that the key feature we need is the collaboration. Schools would be very happy if they just had that. It seems like a way forwards is to have a more 'standard' Linux server (running something like CentOS or Fedora). It would run ejabberd to manage the collaboration. There should only be a need for one network interface, eth0, which would get its DHCP, DNS and other network services from the LAN. The XOs can connect to existing wireless points. A key design goal is that this needs to be easy to set up and maintain, so that a volunteer can do it in the field. So far I've found ejabberd to be extraordinary fiddly to set up, which has given me an appreciation for the good work done on making the XS easy to deploy. I'm sure that a solution to this problem would be of great use in many locations worldwide. I don't believe that our use case is particularly unique. I'd love to hear the list's opinion on this. Even better, we'd love to hear from anyone who can help us out. Cheers, Sridhar Sridhar Dhanapalan Technical Co-ordinator OLPC Australia p: +61 425 239 701 w: http://laptop.org.au On 12 March 2010 02:46, Martin Langhoff <martin.langh...@gmail.com> wrote: > Hi Sridhar! > > you are right, for some reason, I find various emails from Andrew > Berkowics but not the discussion about fitting an XS in an existing > network. > > There are two main paths you can follow --one easy, one hard. For the > hard one, I can give you high level pointers -- you'll have to DIY > (and hopefully document it in the wiki ;-) ). > > =Easy= > > Run the XS as intended -- hook up the WAN port to the existing School > LAN (we'll call it SLAN here) and let the XS run its own LAN ("XLAN" > ;-) ). > > From the PoV of the XS, the SLAN is its WAN. > > You will need then to have 2 network infrastructures -- this could be > awkward at the wiring and AP setup level. But it's guaranteed to be > easy on the XS configuration side and future upgrades. > > =Hard= > > You will need to tweak the XS to disable all the "base network > services" (routing, DNS, DHCP), use only the "LAN" NIC, and disable > un-needed services. This is rather involved and unsupported: some > services (notably some aspects of antitheft) won't work and will most > likely break on upgrade. > > Outline of how to do it > > - Install the XS with only one NIC, and use xs-swapnics to make that NIC eth1 > - Change all the eth1 configuration -- note that it has various IP > addresses and odd routing tables -- to fit your LAN. > - Disable and stop dhcpd and named services. > - Use domain_config to set the FQDN > - Look at the BIND zone files, and make sure the "local" names > ("schoolserver", etc) _and_ the FQDN are published by your DNS server. > - Set resolv.conf on the XS -- can the XS itself resolve all its > local aliases, as well as its FQDN? > - Check that any conffiles in /etc referring to the hardcoded eth1 IP > address are changed to use the IP address you use on your LAN for the > XS. > - the xinetd "xs-activation" service won't work - you can disable it > > That should be about it -- how to know if you've made it? > > - Can XOs resolve "schoolserver"? > - Can they register? > - After registration & restart... > - Do they connect via Gabble? - see > http://wiki.laptop.org/go/XS_Techniques_and_Configuration#Troubleshooting > - Do they run backups? > - Can they access Moodle with auto-login? > > This should work for XS-0.6 -- upgrades are guaranteed to be a pain if > you follow this path, and this guide will probably not work on XO-0.7. > > A few more comments... > >> * if we use CentOS, a solid RHEL base > > Not yet. My plan is that XS-0.7 will be based on F11 but easily > upgraded to the next RHEL/CentOS release once it's out. > >> Alternatively, I'm open to other suggestions. A key criterion here is >> that it be easy for a volunteer to deploy in the field, and for >> someone to troubleshoot issues as required. > > If easy is your goal, follow my "easy" plan ;-) > > cheers, > > > > 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