[Server-devel] Collaboration server for existing network

[Jerry Vonau]

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
> > <martin.langhoff at gmail.com> wrote:
> > > On Sat, Mar 27, 2010 at 4:36 PM, Jerry Vonau <jvonau at shaw.ca> 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