Re: Solution proposal for XCF-2129

On Wed, 2008-02-20 at 17:41 +0200, Andrei Cristian Niculae wrote:

> While looking at the patch posted at XCF-2129
> ( http://track.sipfoundry.org/secure/attachment/13463/sipx-mrtg.patch ), I had an idea (it was
> actually in the patch, but now it cannot work like that):
> We could the mrtg configuration private for our use, that is we could
> put mrtg.cfg in a location where it's controlled by us, for example
> /var/sipxdata/mrtg/cfg. This would have the benefit of not interfering
> with the original mrtg.cfg file. To achieve this, I thought of two
> ways:
> 
> 1. mrtg runs as a cron job. By default, mrtg creates a new file
> in /etc/cron.d/ which states that mrtg should be executed every five
> minutes.
> To achieve our goal, we could add a line to this file saying to cron
> to execute mrtg with our own config file. This would not damage the
> initial cron job.
> 
> 2. If specified in the configuration file, mrtg could run as a daemon.
> This would create somehow an advantage, because mrtg wouldn't have
> to be stopped and started every 5 minutes. Plus, we have the
> posibility to set up the interval at which mrtg collects data (the
> same could be 
> done in the first case, but only by root) and this could be made
> configurable in the GUI. Also, when we don't want to monitor anything,
> we could 
> just shut down the daemon. But there are also some disadvantages: when
> the configuration changes, the mrtg daemon needs to be restarted.
> This can be done via a script invoked by sipxconfig. Also, as a cron
> job, mrtg would run even if sipxconfig is down. If we decide to make
> it 
> a daemon, after a machine restart, the mrtg would not start
> automaticaly, unless specifically told so (probably sipxpbx startup
> would tell the
> daemon to start).
> 
> Which do you think would be better?

#2 - we could just create a wrapper for it that starts from our own
process control mechanisms.

> And there is another question:
> In the m4 files, like general.m4 from the conf dir, do we check for
> what is needed to build the product, or run it? (I think just to build
> it, but I'm not sure).

You're correct - those are run at configure time, so they need to check
for build requirements.

Runtime requirements are declared in the Requires lines in the .spec
file.

--

-- 
Scott Lawrence  tel:+1.781.229.0533;ext=162 or sip:slawrence <at> pingtel.com
  sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs
  CTO, Voice Solutions   - Bluesocket Inc. http://www.bluesocket.com/ 
                                           http://www.pingtel.com/