Re: [Perfparse-devel-int] perfparse.sh and perfparse_daemon.sh :

[Ben C. <Ben...@ro...>]

Yves,

I want to settle this before the next release.  Which is waiting for the 
'make distcheck'...

We cannot put the nagios lock file into the perfparse.cfg because this 
ties in the product with a version of Nagios which may change.  I can 
understand this.

I do not entirely agree that we are just developers.  We are also 
packagers until somebody offers to build and maintain an RPM (or 
similar).  This script is an essential wrapper if you with to use the 
'cron' method.  If we use it, we support it.  Or I support it :)

The script is based on a .in file, therefore a directory with a 
Makefile.  This will be the new 'scripts' directory.

The only problem we have is the definition of the nagios.lock.

I will set it to the likely default:

/usr/local/nagios/var/nagios.lock

A sys admin will see this I hope and edit it accordingly.

I am worried about removing options from the perfparse.cfg if they are 
at default.  These files often serve as an alternate manual, self 
explaining what options are available.  By removing most options, I 
don't think we serve the users interests at best.

There is the option used by a lot of modern systems where all options 
are commented out, but shown as default in the comments:  (Eg, Samba)

# Option for setting foo.  Default = "bar"
# foo = "bar"

The user can see the default, and edit it if they want to change it by 
uncommenting.

Removal of obsolete entries is unfortunate.  This does not occur often. 
  After version 1.0.0 I hope not at all if possible.  Maybe this is not 
so important?

Ben


Yves wrote:

>>Mail pour yves
>>==============
>>
>>Yves,
>>
>>I can read the nagios.cfg file to obtain the location of nagios.pid.  I
>>have a problem that none of the config variables tell me where this file
>>is.  I cannot assume that PP is installed into the Nagios directory
>>structure.
> 
> 
> You have to use a variable to write the file name.
> Ask yourself what filename is best : nagios config file or nagios pid file ? :)
> 
> 
>>I think this was why this was written into the perfparse.cfg.
> 
> 
> No : perfparse used to use the pid of nagios. So it had to be specified into perfparse.cfg.
> Now, perfparsed and perfparse-log2* don't use it, so it has nothing to do with
> perfparse.cfg.
> 
> 
>>The reason I didn't notice the demise of this method was that my
>>perfparse.cfg is old, I have not copied over the example for quite some
>>time.  I thank the new user for finding this.
> 
> 
> If you want to support that script, I tell you again, update your perfparse.cfg and your
> perfparse.sh script at every new version of perfparse.
> 
> 
>>Personally I would suggest just adding this option into perfparse.cfg
>>and an entry into config_file.c to match this so that every option is
>>accounted for.
> 
> 
> I would not do it. If that feature is broken in nagios (it used to be in nagios-2.0), it
> would become a bug of perfparse too. If that feature changes or is removed, it would
> become a bug of perfparse. Don't depend on nagios too much : perfparse is not a nagios
> extension but a project on its own :)
> Just put it in the script, and if that feature disappear, changes or is broken, users
> can easily change the script with no impact on perfparse binaries.
> This is also why I think that perfparse.sh should not be included in perfparse. It is
> the role of the admins to provide that script, not the role of the developers.
> 
> And because it exists and because you want to maintain it, keep it. Some users probably
> use it too.
> 
> 
> 
> 
>>I will create the new scripts directory with the database creation
>>scripts as well as perfparse.sh.  I'll edit the documentation where I
>>can find it.  I hope I do not miss any!
> 
> 
> Also check perfparse.cfg.example.
> I suggest that you remove all options that are OK as default values (check config_file.c)
> Only keep the options when perfparse cannot work if they are not edited (like the
> directory where modules are, like the mysql login parameters...)
> Remove the others : users can do perfparsed --show_config to have all :)
> If you remove them, you will have less obsolete entries in the future when you
> add/remove/change options of the config :)
> 
> Yves
>