[Server-devel] Collaboration server for existing network
Hi there, OLPC Australia is working with the Northern Territory Department of Education to deploy XOs to a number of schools. We are having issues with the XS because there is an existing school network that has its own DHCP, DNS, wi-fi and so on. This was outlined by Ian Cunningham in January[0]. The XS appears to have assumptions in its design that it be the gateway to the network, supplying its own network services. In contrast, we would like to leverage existing infrastructure as much as possible. Martin Langhoff mentioned in response[1] that a team in New York has already tried something like this, but I haven't been able to find anything about it. A solution we are thinking of is to run a copy of ejabberd on a more standard distribution of Linux, such as CentOS or Fedora. I understand that I'll have to add patches to the ejabberd source[2]. What we hope to get from this is: * if we use CentOS, a solid RHEL base * a simple, easy to maintain server * a server integrated into the existing network, using existing services * the best part of the XS: collaboration Does anyone know how well this would work? I realise that we'll lose a lot of the functionality of the XS, but if we have collaboration then we already have a strong selling point to focus on. 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 we can solve this problem, that will open doors for OLPC Australia across the country. This is a really important one for us to solve, so any help would be greatly appreciated. Regards, Sridhar [0] http://lists.laptop.org/pipermail/server-devel/2010-January/004564.html [1] http://lists.laptop.org/pipermail/server-devel/2010-January/004565.html [2] http://wiki.laptop.org/go/Installing_ejabberd Sridhar Dhanapalan Technical Coordinator OLPC Australia p: +61 425 239 701 w: http://laptop.org.au ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Collaboration server for existing network
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
Re: [Server-devel] Collaboration server for existing network
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 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 -
Re: [Server-devel] Collaboration server for existing network
I don't know XS very well, but if ejabberd is all you need why not take the ejabberd configuration from XS sources and deploy that on an otherwise vanilla instance? (I second your comment about technology in Australian schools ... plenty of equipment, usually centrally managed, and often a teaching staff who haven't enough time to use it ... except via telephone to the technology shamans at head office). -- James Cameron http://quozl.linux.org.au/ ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Collaboration server for existing network
On Mar 15, 2010, at 12:06 AM, James Cameron wrote: > I don't know XS very well, but if ejabberd is all you need why not > take > the ejabberd configuration from XS sources and deploy that on an > otherwise vanilla instance? And indeed, the XS services are intended for such reuse. I'm not sure how many patches to the stock ejabberd are still needed... The main hook needed in the existing infrastructure is a DNS entry for the machine running the school server services. Those services can either be easily grafted on top of a Fedora server using the school server packages, or supported on another Linux distro with some hand tweaking. wad ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Collaboration server for existing network
On Mon, 2010-03-15 at 14:49 +1100, Sridhar Dhanapalan wrote: > 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. > Yea, that is true, we would need to identify all the config file that have hard-coded network information, such as httpd-xs.conf. > 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. > All the custom xs-server config files are contained in the xs-config rpm package. Most services are setup binding only to the internal interface as to minimize external exposure of services. The all config .in files are listed in the .spec file: http://dev.laptop.org/git/projects/xs-config/tree/xs-config.spec.in You'd have to check/edit all the config files for the services that you wish to offer on the XS and disabling the un-wanted services. > 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. > That is not too hard to do, disable all the *bond*, msh*, wmesh*, eth1 interface files in /etc/sysconfig/network-scripts/ and edit /etc/dhclient-exit-hooks, disabling the resolve.conf re-write. then setup eth0. Having the local changes respected upon updating, is something that would need to be tested. The biggest issue, I think would be to have the dns/dhcp setup right for the schoolserver, once that is in place, things should go ok. > 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. > Think we can do up a howto, I just need to do a fresh install on a test box, and see what I have to edit on a bone stock install. Jerry ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Collaboration server for existing network
On Mar 15, 2010, at 1:18 PM, Martin Langhoff wrote: > On Mon, Mar 15, 2010 at 12:09 AM, John Watlington > wrote: >> And indeed, the XS services are intended for such reuse. I'm not >> sure >> how many patches to the stock ejabberd are still needed... > > It's not so much the patches (you can grab the ejabberd-xs rpm from > our repo), but the integration with other aspects. > > ejabberd is integrated with moodle which is integrated with > registration. The basics are registration + moodle + ejabberd. Less > than that and you really don't have the goods. I expected that you would have to grab other parts as well. But most of the underlying tools are relatively distro-independent. > (Yes, you can get just get our patched ejabberd, but configuring it is > messy, and it'll only work nicely with a small school, say less than > 50~60 users.) Yep. Configuring everything to interoperate is the special sauce! Cheers, wad ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Collaboration server for existing network
On 16 March 2010 02:15, Martin Langhoff wrote: > On Sun, Mar 14, 2010 at 10:49 PM, Sridhar Dhanapalan >> 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. > > That was the design brief when I joined OLPC, and continues to be. > Locations with existing networks have existing software expertise (you > ;-) ) that can self-help on this track. > > You are not the first to ask for this, and I recognize it's an > interesting use case. > > (And you cannot imagine how snowed under I am with other stuff. I'd > love to help, and I _can_ help with if someone else -- you? -- takes > ownership of it.) I totally empathise. I'm trying to work out a solution, but like you I've got other tasks as well. It's tricky for me as I'm new to this OLPC stuff, having only started with OLPC Australia a couple of weeks ago (and there's a lot for me to learn outside of the XS sphere as well!). Good times :) >> 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. > > Your conclusion is skipping some key facts -- the nice collaboration > experience you expect _depends on the integration with registration > and, in schools with more than ~50 users, on the Moodle integration_. I'm not clear why Moodle is needed for for the collaboration. Is that to segregate the children so that the Neighbourhood View doesn't become too cluttered? So far we aren't using Moodle at our deployments (it would be nice, but we haven't got to it yet). As an alternative, we were thinking of having multiple ejabberd servers going. The children can then connect to the server appropriate for the class. It's not the most elegant solution, but possibly simpler to implement. We can get more servers if we need them. > Maybe my earlier email wasn't clear enough... the kiwi thing of > understatement sticks to me. In brief: I don't make those > recommendations lightly. > > You will need all the services I outlined for a satisfactory outcome. > Maybe backup isn't strictly needed, but once you've done the other > services, you get backup "for free". Feel free to admonish me for my naiveity :) > I will be more than happy to review the shell script, advise, and keep > an eye out for corner cases, gotchas and problems. It's on you to > write it and test it. > >> 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. > > Agreed. In other words -- solve it, and you'll be a hero for the other > deployments that need it! :-) Indeed, I'm working on it now. I'm finding it somewhat tricky understanding everything that's going on underneath, so that's why I'm asking the list for advice. Thanks, Sridhar Sridhar Dhanapalan Technical Co-ordinator OLPC Australia p: +61 425 239 701 w: http://laptop.org.au ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Collaboration server for existing network
On 15 March 2010 16:38, Jerry Vonau wrote: > On Mon, 2010-03-15 at 14:49 +1100, Sridhar Dhanapalan wrote: >> 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. >> > > That is not too hard to do, disable all the *bond*, msh*, wmesh*, eth1 > interface files in /etc/sysconfig/network-scripts/ and edit > /etc/dhclient-exit-hooks, disabling the resolve.conf re-write. > then setup eth0. Having the local changes respected upon updating, is > something that would need to be tested. > > The biggest issue, I think would be to have the dns/dhcp setup right for > the schoolserver, once that is in place, things should go ok. Nice one. I'll give that a go. >> 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. >> > Think we can do up a howto, I just need to do a fresh install on a test > box, and see what I have to edit on a bone stock install. If you could do that, you would be our hero. I'm working on it on our end, but I'm new to the XS and a lot of the OLPC stuff, so it's a bit tough. Cheers, Sridhar Sridhar Dhanapalan Technical Co-ordinator OLPC Australia p: +61 425 239 701 w: http://laptop.org.au ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Collaboration server for existing network
On Mon, Mar 15, 2010 at 9:15 PM, Sridhar Dhanapalan wrote: > I totally empathise. I'm trying to work out a solution, but like you > I've got other tasks as well. It's tricky for me as I'm new to this > OLPC stuff, having only started with OLPC Australia a couple of weeks > ago (and there's a lot for me to learn outside of the XS sphere as > well!). Good times :) Welcome to the Jungle! ;-) > I'm not clear why Moodle is needed for for the collaboration. Is that > to segregate the children so that the Neighbourhood View doesn't > become too cluttered? Exactly. It offers other goodies, but from a "let's enable collaboration in a school" PoV, that's the aspect where you'll need it. > So far we aren't using Moodle at our deployments > (it would be nice, but we haven't got to it yet). It's a great tool. > As an alternative, we were thinking of having multiple ejabberd > servers going. The children can then connect to the server appropriate That will be positively 200 times harder! Flesh out my how to, it will be a reasonable effort. Try to setup one ejabberd per classroom and you'll be in the madhouse for life. > We can get more servers if we need them. How can "buy-and-configure one server per classroom" be harder than running moodle? I wrote a how to for you, and I honestly put a serious effort in finding the most reasonable, least complicated, least-likely-to-explode path. I cannot formally support it, but it's a _good_ plan of action, just needs you to try it out and there may be some detail to iron out. Instead of looking into it, you are proposing some very crazy plans. Please -- please, assume those plans come from the architect of the thing, he might know a thing or two, and that they are the easiest, shortest path to your destination. Even the one labelled "hard" is _not_ hard compared to some of the stuff being discussed here. If in doubt, trust me a bit :-) > Indeed, I'm working on it now. I'm finding it somewhat tricky > understanding everything that's going on underneath, so that's why I'm > asking the list for advice. Which you got. Top quality advice. Don't ignore it :-) 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
Re: [Server-devel] Collaboration server for existing network
On 16 March 2010 13:35, Martin Langhoff wrote: > On Mon, Mar 15, 2010 at 9:15 PM, Sridhar Dhanapalan > wrote: >> Indeed, I'm working on it now. I'm finding it somewhat tricky >> understanding everything that's going on underneath, so that's why I'm >> asking the list for advice. > > Which you got. Top quality advice. Don't ignore it :-) Which I greatly appreciate. I'm still in an experimental phase, so I'm investigating different avenues just to see what happens. In no way am I disregarding your (or anyone else on the list's) advice. In fact, I'm finding this discussion to be extraordinarily helpful. Thanks to everyone. Sridhar Dhanapalan Technical Co-ordinator OLPC Australia p: +61 425 239 701 w: http://laptop.org.au ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Collaboration server for existing network
On Mon, 2010-03-15 at 21:35 -0500, Martin Langhoff wrote: > On Mon, Mar 15, 2010 at 9:15 PM, Sridhar Dhanapalan > wrote: > > I totally empathise. I'm trying to work out a solution, but like you > > I've got other tasks as well. It's tricky for me as I'm new to this > > OLPC stuff, having only started with OLPC Australia a couple of weeks > > ago (and there's a lot for me to learn outside of the XS sphere as > > well!). Good times :) > > Welcome to the Jungle! ;-) > I wrote a how to for you, and I honestly put a serious effort in > finding the most reasonable, least complicated, > least-likely-to-explode path. I cannot formally support it, but it's a > _good_ plan of action, just needs you to try it out and there may be > some detail to iron out. > > Instead of looking into it, you are proposing some very crazy plans. > > Please -- please, assume those plans come from the architect of the > thing, he might know a thing or two, and that they are the easiest, > shortest path to your destination. Even the one labelled "hard" is > _not_ hard compared to some of the stuff being discussed here. > > If in doubt, trust me a bit :-) > > > Indeed, I'm working on it now. I'm finding it somewhat tricky > > understanding everything that's going on underneath, so that's why I'm > > asking the list for advice. > > Which you got. Top quality advice. Don't ignore it :-) > Think I've got the details little ironed out, with one little wrinkle, idmgr looks like its ignoring it's idmgr.conf file, because BIND_DOMAIN s/b BIND_ADDRESS. I had to # the BIND_ADDRESS in idmanager.py to get it to respect the config file. Should I file a ticket for this? Jerry ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Collaboration server for existing network
On Sat, Mar 27, 2010 at 4:36 PM, Jerry Vonau wrote: > Think I've got the details little ironed out, with one little wrinkle, > idmgr looks like its ignoring it's idmgr.conf file, because BIND_DOMAIN > s/b BIND_ADDRESS. I had to # the BIND_ADDRESS in idmanager.py to get it > to respect the config file. Should I file a ticket for this? Sure. The patch is trivial. 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
Re: [Server-devel] Collaboration server for existing network
On Sat, Mar 27, 2010 at 6:12 PM, Martin Langhoff wrote: > On Sat, Mar 27, 2010 at 4:36 PM, Jerry Vonau wrote: >> Think I've got the details little ironed out, with one little wrinkle, >> idmgr looks like its ignoring it's idmgr.conf file, because BIND_DOMAIN >> s/b BIND_ADDRESS. I had to # the BIND_ADDRESS in idmanager.py to get it >> to respect the config file. Should I file a ticket for this? > > Sure. The patch is trivial. I am re-visiting this. Jerry emailed some patches privately and... I think we misdiagnosed the problem. To get this out of the way: we should not bind to 0.0.0.0 by default, ever. The XS is normally a multihomed box, and one of those NICs opens to a rough neighbourhood known as the open internet. Now, the real issue seems to be that xs-config has the config name wrong. I have fixed it in xs-config and rolled a new xs-config. The olpcxs-testing repo has it ;-) Jerry - can you confirm that that's the issue? Maybe your patches to idmgr itself aren't needed? 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
Re: [Server-devel] Collaboration server for existing network
On Wed, 2010-04-21 at 18:42 +0200, Martin Langhoff wrote: > On Sat, Mar 27, 2010 at 6:12 PM, Martin Langhoff > wrote: > > On Sat, Mar 27, 2010 at 4:36 PM, Jerry Vonau wrote: > >> Think I've got the details little ironed out, with one little wrinkle, > >> idmgr looks like its ignoring it's idmgr.conf file, because BIND_DOMAIN > >> s/b BIND_ADDRESS. I had to # the BIND_ADDRESS in idmanager.py to get it > >> to respect the config file. Should I file a ticket for this? > > > > Sure. The patch is trivial. > > I am re-visiting this. Jerry emailed some patches privately and... I > think we misdiagnosed the problem. > No, we have it right. > To get this out of the way: we should not bind to 0.0.0.0 by default, > ever. The XS is normally a multihomed box, and one of those NICs opens > to a rough neighbourhood known as the open internet. > That is correct, the 0.0.0.0 is part of the revision for a single interface xs-server. > Now, the real issue seems to be that xs-config has the config name > wrong. I have fixed it in xs-config and rolled a new xs-config. The > olpcxs-testing repo has it ;-) > > Jerry - can you confirm that that's the issue? Maybe your patches to > idmgr itself aren't needed? > Yes, just the config name was wrong, I needed to change the address that the service was bound to, and I couldn't via the config file. Jerry ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Collaboration server for existing network
On Wed, 2010-04-21 at 12:00 -0500, Jerry Vonau wrote: > On Wed, 2010-04-21 at 18:42 +0200, Martin Langhoff wrote: > > On Sat, Mar 27, 2010 at 6:12 PM, Martin Langhoff > > wrote: > > > On Sat, Mar 27, 2010 at 4:36 PM, Jerry Vonau wrote: > > >> Think I've got the details little ironed out, with one little wrinkle, > > >> idmgr looks like its ignoring it's idmgr.conf file, because BIND_DOMAIN > > >> s/b BIND_ADDRESS. I had to # the BIND_ADDRESS in idmanager.py to get it > > >> to respect the config file. Should I file a ticket for this? > > > > > > Sure. The patch is trivial. > > > > I am re-visiting this. Jerry emailed some patches privately and... I > > think we misdiagnosed the problem. > > > No, we have it right. > > > To get this out of the way: we should not bind to 0.0.0.0 by default, > > ever. The XS is normally a multihomed box, and one of those NICs opens > > to a rough neighbourhood known as the open internet. > > > That is correct, the 0.0.0.0 is part of the revision for a single > interface xs-server. > > > Now, the real issue seems to be that xs-config has the config name > > wrong. I have fixed it in xs-config and rolled a new xs-config. The > > olpcxs-testing repo has it ;-) > > > > Jerry - can you confirm that that's the issue? Maybe your patches to > > idmgr itself aren't needed? > > > Yes, just the config name was wrong, I needed to change the address that > the service was bound to, and I couldn't via the config file. > Just checked git, I had to touch also idmanager.py in order to have it respect the variable in the config file. /BIND_ADDRESS/#BIND_ADDRESS Jerry ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Collaboration server for existing network
On Wed, Apr 21, 2010 at 2:14 PM, Martin Langhoff wrote: > On Wed, Apr 21, 2010 at 1:20 PM, Jerry Vonau wrote: >> Just checked git, I had to touch also idmanager.py in order to have it >> respect the variable in the config file. >> /BIND_ADDRESS/#BIND_ADDRESS > > Ok. So you had to unset the default value... then the code block below > that (Config.__init__()), which reads /etc/idmgr.conf to read in > overrides is failing to override it. Actually, you may have had a misconfiguration. If you set BIND_ADDRESS in /etc/idmgr.conf, there is no need to touch idmanager.py -- it reads the value properly from the config file. I've just tested such override, and it worked correctlyfor me. No patching (to idmanager code) needed. Of course the /etc/idmgr.conf we ship in xs-config is buggy, but the program itself reads and obeys its configuration AFAICS... 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
Re: [Server-devel] Collaboration server for existing network
One can of course run just ejabberd on pretty much any distro, though I'm not sure if that is what he is looking for. kind regards, David On Thu, Apr 22, 2010 at 10:17 PM, Martin Langhoff wrote: > On Wed, Apr 21, 2010 at 2:14 PM, Martin Langhoff > wrote: > > On Wed, Apr 21, 2010 at 1:20 PM, Jerry Vonau wrote: > >> Just checked git, I had to touch also idmanager.py in order to have it > >> respect the variable in the config file. > >> /BIND_ADDRESS/#BIND_ADDRESS > > > > Ok. So you had to unset the default value... then the code block below > > that (Config.__init__()), which reads /etc/idmgr.conf to read in > > overrides is failing to override it. > > Actually, you may have had a misconfiguration. If you set BIND_ADDRESS > in /etc/idmgr.conf, there is no need to touch idmanager.py -- it reads > the value properly from the config file. > > I've just tested such override, and it worked correctlyfor me. No > patching (to idmanager code) needed. > > Of course the /etc/idmgr.conf we ship in xs-config is buggy, but the > program itself reads and obeys its configuration AFAICS... > > 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 > ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Collaboration server for existing network
On Thu, Apr 22, 2010 at 4:46 PM, David Van Assche wrote: > One can of course run just ejabberd on pretty much any distro, though I'm > not sure if that is what he is looking for. Apples and oranges ;-) This is about idmanager, and whether it's buggy or not when reading its configuration. And yes, most distros have ejabberd, but ours has important patches nobody else has ;-) 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
Re: [Server-devel] Collaboration server for existing network
Just out of curiosity... could those patches be added to other distros? Its just a question... not trying to imply a switch or anything... kind regards, David On Thu, Apr 22, 2010 at 10:58 PM, Martin Langhoff wrote: > On Thu, Apr 22, 2010 at 4:46 PM, David Van Assche > wrote: > > One can of course run just ejabberd on pretty much any distro, though I'm > > not sure if that is what he is looking for. > > Apples and oranges ;-) > > This is about idmanager, and whether it's buggy or not when reading > its configuration. > > And yes, most distros have ejabberd, but ours has important patches > nobody else has ;-) > > > > 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
Re: [Server-devel] Collaboration server for existing network
On Thu, 2010-04-22 at 16:17 -0400, Martin Langhoff wrote: > On Wed, Apr 21, 2010 at 2:14 PM, Martin Langhoff > wrote: > > On Wed, Apr 21, 2010 at 1:20 PM, Jerry Vonau wrote: > >> Just checked git, I had to touch also idmanager.py in order to have it > >> respect the variable in the config file. > >> /BIND_ADDRESS/#BIND_ADDRESS > > > > Ok. So you had to unset the default value... then the code block below > > that (Config.__init__()), which reads /etc/idmgr.conf to read in > > overrides is failing to override it. > > Actually, you may have had a misconfiguration. If you set BIND_ADDRESS > in /etc/idmgr.conf, there is no need to touch idmanager.py -- it reads > the value properly from the config file. > > I've just tested such override, and it worked correctlyfor me. No > patching (to idmanager code) needed. > > Of course the /etc/idmgr.conf we ship in xs-config is buggy, but the > program itself reads and obeys its configuration AFAICS... Your right, changed the variable present in /etc/idmgr.conf first, saw no change. Then I saw the hardcoded ip in idmanager.py second, I just #'d that one out but changed the address to be 0.0.0.0 like the default for any other normal service, that was the change I was referring to. That lead to the idmgr not starting, then I realized that the mis-named variable in idmgr.conf was the real issue. Jerry ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
