Kevin Thorley wrote:
On Tue, 2008-09-16 at 17:19 +0000, Scott Lawrence wrote:
On Tue, 2008-09-16 at 17:26 +0300, Andrei Cristian Niculae wrote:
Hi all,
There is a problem with the sipxconfig-mrtg rpm. It is configured
without the --enable-mrtg options, which makes it include a
sipxconfig.properties.in file in which
monitoringContextImpl.enabled=false and it should be true.
When XCF-2400 was commited, I made the sipxconfig-mrtg rpm include the
sipxconfig.properties.in file which must have the
monitoringContexImpl.enabled=true .
I don't know if it can be made so that sipxconfig-mrtg includes a
sipxconfig.properties.in which has monitoringContexImpl.enabled=true and
sipxconfig rpm includes a sipxconfig.properties.in which has
monitoringContexImpl.enabled=false.
No - it is not possible. Any given file must be "owned" by exactly one
rpm.
Is the change to that file the only effect of --enable-mrtg (probably
not)?
When mrtg was initially implemented it was not considered to be a
standard part of the sipx installation. For this reason, support for it
was optional and it needed to be explicitly enabled. This was to shield
sipXconfig developers from needing to install and configure it in order
to do mainstream sipXconfig work. However, it seems that mrtg is now
being considered a standard sipx service, on a par with sipxbridge,
sipxrelay, etc. There are also Jira issues open to integrate mrtg with
the sipx services framework in sipXconfig. My vote is to fully
integrate mrtg at build time. This means that sipXconfig developers
will need to install the mrtg packages (along with any dependencies).
Actually, right now, I think you can do without mrtg/mrtg dependencies
if you don't use the statistics page.
Right now, mrtg is not started unless you explicitly say you want
statistics.
It also means that we can do away with the "enabled" flag in
sipxconfig.properties.in.
I think we need to open a new JIRA issue for this.
If there are cases in the future where mrtg is not desired for whatever
reason, this can be handled in the same way that we would handle not
installing other services (this is not yet implemented, but would most
likely involve sipXsupervisor providing a way for sipXconfig to query
whether a specific package is installed on a host).
Kevin
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
