20 Feb 16:41
Re: Solution proposal for XCF-2129
From: Andrei Cristian Niculae <aniculae <at> itcnetworks.ro>
Subject: Re: Solution proposal for XCF-2129
Newsgroups: gmane.comp.voip.sipx.devel
Date: 2008-02-20 15:41:33 GMT
Subject: Re: Solution proposal for XCF-2129
Newsgroups: gmane.comp.voip.sipx.devel
Date: 2008-02-20 15:41:33 GMT
Hi again,
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?
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).
I'm asking this because I was wandering if I should check for the mrtg/snmp executable? These are needed just for running sipx, not for
building it.
Any comments welcomed.
Regards,
Andrei
Andrei Cristian Niculae wrote:
Hi all,
Regarding XCF-2129 ( http://track.sipfoundry.org/browse/XCF-2129 ), I have the following proposals:
1. Make sipx-mrtg-init script accept an extra parameter : --mrtgPrefix PATH. If this option is not present,
the script will suppose that MRTG is installed in the default location.
Also, in the mrtg configuration template, there is a referece to the SNMP directory, so the script
should also accept the --snmpPrefix PATH option. Again, if this is not present, the script will suppose that SNMP
is installed in the default location.
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?
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).
I'm asking this because I was wandering if I should check for the mrtg/snmp executable? These are needed just for running sipx, not for
building it.
Any comments welcomed.
Regards,
Andrei
<div> Hi again,<br> Andrei Cristian Niculae wrote: <blockquote cite="mid:479DFCA5.7080107 <at> itcnetworks.ro" type="cite">Hi all, <br><br> Regarding XCF-2129 ( <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://track.sipfoundry.org/browse/XCF-2129">http://track.sipfoundry.org/browse/XCF-2129</a> ), I have the following proposals: <br><br> 1. Make sipx-mrtg-init script accept an extra parameter : --mrtgPrefix PATH. If this option is not present, <br> the script will suppose that MRTG is installed in the default location. <br> Also, in the mrtg configuration template, there is a referece to the SNMP directory, so the script <br> should also accept the --snmpPrefix PATH option. Again, if this is not present, the script will suppose that SNMP <br> is installed in the default location. <br> </blockquote> <br> While looking at the patch posted at XCF-2129 ( <a class="moz-txt-link-freetext" href="http://track.sipfoundry.org/secure/attachment/13463/sipx-mrtg.patch">http://track.sipfoundry.org/secure/attachment/13463/sipx-mrtg.patch</a> ), I had an idea (it was<br> actually in the patch, but now it cannot work like that):<br> 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<br> /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<br> ways:<br><br> 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.<br> 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<br> initial cron job.<br><br> 2. If specified in the configuration file, mrtg could run as a daemon. This would create somehow an advantage, because mrtg wouldn't have<br> 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 <br> 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 <br> just shut down the daemon. But there are also some disadvantages: when the configuration changes, the mrtg daemon needs to be restarted.<br> 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 <br> a daemon, after a machine restart, the mrtg would not start automaticaly, unless specifically told so (probably sipxpbx startup would tell the<br> daemon to start).<br><br> Which do you think would be better?<br><br> And there is another question:<br> 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).<br> I'm asking this because I was wandering if I should check for the mrtg/snmp executable? These are needed just for running sipx, not for<br> building it.<br><br> Any comments welcomed.<br><br> Regards,<br> Andrei<br> </div>
RSS Feed