Ranga recently reported
http://track.sipfoundry.org/browse/XECS-1803
sipx proxy server refuses to start ... (fails configtest)
His immediate problem is that the configtest is trying to verify that
DNS and the IP address is correctly configured. I'll go into the
details of his system with him elsewhere, but there's a general issue
that's all tied up with getting rid of config.defs :
How should sipXecs services decide what interface to bind to?
Important Note:
The sipXtackLib (and therefor all the stuff built on top of it)
expects to be using just one IP interface (or, put another way,
just one IP address). It doesn't matter if there are multiple
interfaces so long as anything reachable through any of them
knows how to route back to any other network, but that is often
not the case these days. In particular, you cannot (now) put
one interface of your proxy on a public network and one on a
private network and have it work reliably for things on both.
Fixing this is not simple and won't happen this cycle, and I
won't go further into why: for now just accept it. If you're
not a developer, stop here... just don't try to do multiple
interfaces now: it won't work reliably.
How we pick the interface now:
Most services have a configuration directive that tells them what
interface to bind to: in the case of sipXproxy, for example, it's
.../etc/sipxpbx/sipXproxy-config: SIPX_PROXY_BIND_IP
That (and probably all the similar directives for other services)
are (or were) set from the .../etc/sipxpbx/config.defs variable
MY_IP_ADDR.
The current default way to set MY_IP_ADDR is the output of the
script .../bin/get_def_addr, which relies on being able to parse the
output from the 'ifconfig' and 'route' commands. The get_def_addr
script is a really really bad idea for two important reasons:
- Humans should choose the interface because they know why there
is more than one and what is where. Right now, the script tries
to pick the interface that leads to the default (0.0.0.0) route;
this may or may not be the right answer.
- The output of those commands is not in an easily parsed format.
So... what would be better?
We want sipXconfig to generate all the configuration files, but how
should it get the addresses for each system and decide which one the
services should use?
Should we just have the sipx-setup script ask and stick the answer
in a well known place for sipXconfig to read?
Please don't say "let's just keep config.defs".
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
