You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(9) |
Feb
(11) |
Mar
(37) |
Apr
(50) |
May
(51) |
Jun
(31) |
Jul
(35) |
Aug
(30) |
Sep
(39) |
Oct
(85) |
Nov
(91) |
Dec
(30) |
2003 |
Jan
(65) |
Feb
(56) |
Mar
(80) |
Apr
(73) |
May
(84) |
Jun
(108) |
Jul
(62) |
Aug
(53) |
Sep
(46) |
Oct
(44) |
Nov
(59) |
Dec
(91) |
2004 |
Jan
(71) |
Feb
(25) |
Mar
(87) |
Apr
(67) |
May
(65) |
Jun
(60) |
Jul
(31) |
Aug
(100) |
Sep
(97) |
Oct
(133) |
Nov
(87) |
Dec
(65) |
2005 |
Jan
(84) |
Feb
(133) |
Mar
(67) |
Apr
(74) |
May
(108) |
Jun
(92) |
Jul
(54) |
Aug
(82) |
Sep
(22) |
Oct
(10) |
Nov
(69) |
Dec
(65) |
2006 |
Jan
(89) |
Feb
(133) |
Mar
(100) |
Apr
(69) |
May
(138) |
Jun
(85) |
Jul
(45) |
Aug
(56) |
Sep
(33) |
Oct
(69) |
Nov
(33) |
Dec
(78) |
2007 |
Jan
(120) |
Feb
(120) |
Mar
(136) |
Apr
(153) |
May
(75) |
Jun
(65) |
Jul
(64) |
Aug
(129) |
Sep
(122) |
Oct
(231) |
Nov
(145) |
Dec
(93) |
2008 |
Jan
(163) |
Feb
(157) |
Mar
(60) |
Apr
(96) |
May
(92) |
Jun
(67) |
Jul
(90) |
Aug
(75) |
Sep
(87) |
Oct
(81) |
Nov
(158) |
Dec
(71) |
2009 |
Jan
(83) |
Feb
(77) |
Mar
(94) |
Apr
(78) |
May
(210) |
Jun
(146) |
Jul
(104) |
Aug
(208) |
Sep
(80) |
Oct
(54) |
Nov
(55) |
Dec
(84) |
2010 |
Jan
(21) |
Feb
(67) |
Mar
(85) |
Apr
(20) |
May
(29) |
Jun
(11) |
Jul
(13) |
Aug
(48) |
Sep
(56) |
Oct
(70) |
Nov
(100) |
Dec
(83) |
2011 |
Jan
(59) |
Feb
(36) |
Mar
(59) |
Apr
(21) |
May
(96) |
Jun
(27) |
Jul
(17) |
Aug
(58) |
Sep
(12) |
Oct
(15) |
Nov
(27) |
Dec
(20) |
2012 |
Jan
(36) |
Feb
(3) |
Mar
(19) |
Apr
(9) |
May
(22) |
Jun
(34) |
Jul
(7) |
Aug
(31) |
Sep
(65) |
Oct
(18) |
Nov
(78) |
Dec
(24) |
2013 |
Jan
(46) |
Feb
(73) |
Mar
(50) |
Apr
(11) |
May
(32) |
Jun
(10) |
Jul
(6) |
Aug
(18) |
Sep
(36) |
Oct
|
Nov
|
Dec
|
From: Ethan G. <ega...@na...> - 2013-09-27 19:58:38
|
Hi Everyone - In an effort to centralize resources and make the most efficient use of support and developer time, we're moving away from the old mailing lists on SourceForge to our online support forums at: http://support.nagios.com/forum The first list to move to the forum is the nagios-devel mailing list, which is primarily used for patches, ideas, and general development discussion. A new board has been setup on the forum specifically for Nagios Core development. Historical emails from the nagios-devel mailing list have been imported to the board for reference. You can access the new development forum using this direct link: http://support.nagios.com/forum/viewforum.php?f=34 If you'd like to duplicate the feel of mailing lists, you can opt to receive emails whenever new posts are made to the forum by clicking the "Subscribe forum" link in the footer of the page. You'll have to create a forum account in order to do this, as well as to post messages to the forum. In order to prevent messages being split between two venues (forum and mailing list), we've enabled a global moderation flag that will prevent new messages from being sent to the old nagios-devel list. For those of you attending next week's Nagios Conferece in Saint Paul, MN, we look forward to seeing you. If you've attended the conference in the past you know its a great time, and we're sure to have another great event this year. Ethan Galstad Email: ega...@na... Web: www.nagios.com |
From: Anton L. <alo...@op...> - 2013-09-26 06:58:52
|
We recently had a problem with a buggy glibc implementation of dlclose causing module unloading to misbehave. Chances are having been informed of the result of the dlclose() call would've been helpful in debugging that. Signed-off-by: Anton Lofgren <alo...@op...> --- base/nebmods.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/base/nebmods.c b/base/nebmods.c index f6489f8..d98e412 100644 --- a/base/nebmods.c +++ b/base/nebmods.c @@ -303,6 +303,11 @@ int neb_unload_module(nebmodule *mod, int flags, int reason) { /* unload the module */ result = dlclose(mod->module_handle); + + if (result != 0) { + logit(NSLOG_RUNTIME_ERROR, TRUE, "Error: Could not unload module '%s' -> %s\n", mod->filename, dlerror()); + return ERROR; + } } /* mark the module as being unloaded */ -- 1.8.4 |
From: Ton V. <ton...@op...> - 2013-09-24 09:00:58
|
Hi, Looking at the latest Nagios code, our automated tests have picked up that if a host or a service's check_interval is set to 0, it is changed to 1.0. This appears to be from commit f99a9a7b which says: ---- commit f99a9a7b09e5253d5442115ae687066a5658fda6 Author: Andreas Ericsson <ae...@op...> Date: Wed Aug 14 01:35:19 2013 +0200 core: Disallow zero retry- or check-intervals If we *do* have zero retry or check-intervals and happen to disable checks of the type that we have zero intervals for, we'll keep on scheduling and rescheduling the same checks over and over to run at the exact same timestamp, which will only cause us to peg the cpu at 100% and log insane amounts of data to the debug log. Not so hot, so let's avoid it whenever possible. Signed-off-by: Andreas Ericsson <ae...@op...> ---- For hosts, check_interval=0 with active_checks_enabled=1 means "do not regularly check this host but check on demand", this change suggests this is no longer possible. Is this deliberate? If so, is this behaviour supported in a different way or is it recommended to not use have check_interval=0 anymore. Ton |
From: AL13N <al...@rm...> - 2013-09-20 07:06:16
|
>>-----Original Message----- >>From: Andreas Ericsson [mailto:ae...@op...] >>Sent: Wednesday, September 04, 2013 6:33 AM >>To: AL13N >>Cc: Nagios Developers List >>Subject: Re: [Nagios-devel] configuration directory >> >>On 2013-09-04 12:51, AL13N wrote: >>> would this mean that if you have >>> >>> setting1=value >>> >>> setting2=value >>> >>> include=/path/to/foo >>> >>> setting3=value >>> >>> that being parsed would: >>> 1) setting1 >>> 2) setting2 >>> 3) all from /path/to/foo if it's a file or directory >>> 4) setting3 >>> >>> >>> is this the priority that you aim for? >>> >> >>No. All variables from one file should be parsed before any >>variables >>from a different file, but the include-files from one file get >>parsed >>before we move along to the next file in that directory. > > I know I'm late to this discussion, but please don't do this. If you > insist, please don't use the word "include", as the behavior you describe > is not the behavior one expects from the word "include". Perhaps "append"? iinm there's already include_cfg for host configs... which is similar in functionality... |
From: Gaspar, C. <Car...@gs...> - 2013-09-19 20:04:16
|
>-----Original Message----- >From: Andreas Ericsson [mailto:ae...@op...] >Sent: Wednesday, September 04, 2013 6:33 AM >To: AL13N >Cc: Nagios Developers List >Subject: Re: [Nagios-devel] configuration directory > >On 2013-09-04 12:51, AL13N wrote: >> would this mean that if you have >> >> setting1=value >> >> setting2=value >> >> include=/path/to/foo >> >> setting3=value >> >> that being parsed would: >> 1) setting1 >> 2) setting2 >> 3) all from /path/to/foo if it's a file or directory >> 4) setting3 >> >> >> is this the priority that you aim for? >> > >No. All variables from one file should be parsed before any >variables >from a different file, but the include-files from one file get >parsed >before we move along to the next file in that directory. I know I'm late to this discussion, but please don't do this. If you insist, please don't use the word "include", as the behavior you describe is not the behavior one expects from the word "include". Perhaps "append"? -- Carson Gaspar |
From: Andreas E. <ae...@op...> - 2013-09-13 15:39:34
|
On 2013-09-13 12:44, AL13N wrote: >> On 2013-09-13 12:07, AL13N wrote: >>>> On 2013-09-13 11:15, AL13N wrote: >>>>>> On 2013-09-12 13:33, AL13N wrote: >>>>>>> This should be a patch for >>>>>>> A) allowing multiple main config files >>>>>>> >>>>>>> i haven't compiled/run/tested this yet, but this is the kind of >>>>>>> thing >>>>>>> i >>>>>>> thought would be good. >>>>>>> >>>>>>> can someone please tell me if i'm working in the right direction or >>>>>>> not? >>>>>>> >>>>>> >>>>>> Sort of, and then again, no. It would be good if, as a first step, we >>>>>> read all main-config-parameters from read_main_config_file() (or some >>>>>> other function which just groks key/value pairs that gets fed by one >>>>>> or more invocations of read_main_config_file()). >>>>>> >>>>>> That way the patch wouldn't have to fiddle with object config >>>>>> reading, >>>>>> which won't work properly unless you also add multi-config support to >>>>>> read_object_config_files(). >>>>> >>>>> but, that's the way it's written now... we'd have to refactor the way >>>>> the >>>>> config files are read, and then the patch would be quite invasive, >>>>> wouldn't it? >>>>> >>>>> did you see the 2nd patch? where i added multi-config support for >>>>> read_object_config_files? (or at least very basic, i didn't check if >>>>> these >>>>> functions reset some internal variables at the start of their call) >>>>> >>>> >>>> Ah, no, I didn't. >>>> >>>>> >>>>> what exactly are you thinking of doing? >>>>> >>>> >>>> All the "initialize this" and "read_object_config_data()" only parse >>>> a few variables out of the main config file(s) and then set a few >>>> variables based on values found there. I would much prefer to have >>>> config variables read in a single place, all the variables properly >>>> set based on the latest parsed value (last in wins the race, >>>> basically), >>>> and then calling the init functions while removing the config file >>>> argument to them completely. >>> >>> yes, that does seem better, but that's quite some refactoring... i guess >>> if you insist, we'll have to do this one first... >>> >> >> I've been meaning to do that for some time anyway, and I actually >> started it with bf64caf4f2876b1377df08e9fa4c439d5562fdbb. The code >> that remains is the one I couldn't convert in a lunchbreak. At least >> if I wanted to eat something as well. > > haha, i did my code in 2 lunchbreaks too :-). i suppose it's some kind of > git branch, i'll look into it. > >>> combined with that, there's the added problem of config_file_dir where >>> the >>> dir of the main config file is used for whatever default directory. >>> >>> i had to have a main config file and extra config files, if we get to >>> directories, the first main config will not be able to be used... >>> >> >> Well, paths found in config files should be relative to the config file >> the path was parsed from. Adding a helper to lib/nspath.c to get that >> based on a full path to a file would probably be the best solution. > > ah, so that's the point... even more refactor work :-) > > > the problem we're gonna face here is that > > char *config_file; > char *config_file_dir; > > are exported symbols... > > how are we gonna make this work without changing those exported symbols? > so that nagios addons will still work? > They can remain as is, and point to the first config file (which will remain the "main" config file). I doubt very many use them though, and the parsed variables (such as object config files) should be kept as an array for modules that want to do something with them. Currently only Merlin does, and I'm the maintainer there, so I'll make sure I can check for it somehow. -- Andreas Ericsson and...@op... OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. |
From: Andreas E. <ae...@op...> - 2013-09-13 14:33:48
|
On 2013-09-13 13:07, Robin Sonefors wrote: > When debugging why a check timed out, this might give you additional > clues. > I'll take this with the amendment that in case we get zero output, we print "no output" instead of "got output". The other one is already applied, but with a twist. Thanks. -- Andreas Ericsson and...@op... OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. |
From: Robin S. <rob...@op...> - 2013-09-13 11:07:54
|
When debugging why a check timed out, this might give you additional clues. Signed-off-by: Robin Sonefors <rob...@op...> --- base/checks.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/base/checks.c b/base/checks.c index 04cd3ec..356098f 100644 --- a/base/checks.c +++ b/base/checks.c @@ -417,7 +417,10 @@ int handle_async_service_check_result(service *temp_service, check_result *queue if(queued_check_result->early_timeout == TRUE) { logit(NSLOG_RUNTIME_WARNING, TRUE, "Warning: Check of service '%s' on host '%s' timed out after %.3fs!\n", temp_service->description, temp_service->host_name, temp_service->execution_time); - asprintf(&temp_service->plugin_output, "(Service check timed out after %.2lf seconds)\n", temp_service->execution_time); + asprintf(&temp_service->plugin_output, + "(Service check timed out after %.2lf seconds, got output: %s)\n", + temp_service->execution_time, + queued_check_result->output ? queued_check_result->output : "(NULL)"); temp_service->current_state = service_check_timeout_state; } /* if there was some error running the command, just skip it (this shouldn't be happening) */ @@ -2237,7 +2240,10 @@ int handle_async_host_check_result(host *temp_host, check_result *queued_check_r my_free(temp_host->plugin_output); my_free(temp_host->long_plugin_output); my_free(temp_host->perf_data); - asprintf(&temp_host->plugin_output, "(Host check timed out after %.2lf seconds)", temp_host->execution_time); + asprintf(&temp_host->plugin_output, + "(Host check timed out after %.2lf seconds, got output: %s)", + temp_host->execution_time, + queued_check_result->output ? queued_check_result->output : "(NULL)"); result = STATE_UNKNOWN; } -- 1.8.3.1 |
From: Robin S. <rob...@op...> - 2013-09-13 11:07:54
|
When a service times out, it's supposed to set its check output to service_check_timeout_state. This does just that. Signed-off-by: Robin Sonefors <rob...@op...> --- base/checks.c | 1 + 1 file changed, 1 insertion(+) diff --git a/base/checks.c b/base/checks.c index 84a31c8..04cd3ec 100644 --- a/base/checks.c +++ b/base/checks.c @@ -418,6 +418,7 @@ int handle_async_service_check_result(service *temp_service, check_result *queue if(queued_check_result->early_timeout == TRUE) { logit(NSLOG_RUNTIME_WARNING, TRUE, "Warning: Check of service '%s' on host '%s' timed out after %.3fs!\n", temp_service->description, temp_service->host_name, temp_service->execution_time); asprintf(&temp_service->plugin_output, "(Service check timed out after %.2lf seconds)\n", temp_service->execution_time); + temp_service->current_state = service_check_timeout_state; } /* if there was some error running the command, just skip it (this shouldn't be happening) */ else if(queued_check_result->exited_ok == FALSE) { -- 1.8.3.1 |
From: Robin S. <rob...@op...> - 2013-09-13 11:07:50
|
Alright, here is - finally! - another attempt. |
From: AL13N <al...@rm...> - 2013-09-13 10:44:50
|
> On 2013-09-13 12:07, AL13N wrote: >>> On 2013-09-13 11:15, AL13N wrote: >>>>> On 2013-09-12 13:33, AL13N wrote: >>>>>> This should be a patch for >>>>>> A) allowing multiple main config files >>>>>> >>>>>> i haven't compiled/run/tested this yet, but this is the kind of >>>>>> thing >>>>>> i >>>>>> thought would be good. >>>>>> >>>>>> can someone please tell me if i'm working in the right direction or >>>>>> not? >>>>>> >>>>> >>>>> Sort of, and then again, no. It would be good if, as a first step, we >>>>> read all main-config-parameters from read_main_config_file() (or some >>>>> other function which just groks key/value pairs that gets fed by one >>>>> or more invocations of read_main_config_file()). >>>>> >>>>> That way the patch wouldn't have to fiddle with object config >>>>> reading, >>>>> which won't work properly unless you also add multi-config support to >>>>> read_object_config_files(). >>>> >>>> but, that's the way it's written now... we'd have to refactor the way >>>> the >>>> config files are read, and then the patch would be quite invasive, >>>> wouldn't it? >>>> >>>> did you see the 2nd patch? where i added multi-config support for >>>> read_object_config_files? (or at least very basic, i didn't check if >>>> these >>>> functions reset some internal variables at the start of their call) >>>> >>> >>> Ah, no, I didn't. >>> >>>> >>>> what exactly are you thinking of doing? >>>> >>> >>> All the "initialize this" and "read_object_config_data()" only parse >>> a few variables out of the main config file(s) and then set a few >>> variables based on values found there. I would much prefer to have >>> config variables read in a single place, all the variables properly >>> set based on the latest parsed value (last in wins the race, >>> basically), >>> and then calling the init functions while removing the config file >>> argument to them completely. >> >> yes, that does seem better, but that's quite some refactoring... i guess >> if you insist, we'll have to do this one first... >> > > I've been meaning to do that for some time anyway, and I actually > started it with bf64caf4f2876b1377df08e9fa4c439d5562fdbb. The code > that remains is the one I couldn't convert in a lunchbreak. At least > if I wanted to eat something as well. haha, i did my code in 2 lunchbreaks too :-). i suppose it's some kind of git branch, i'll look into it. >> combined with that, there's the added problem of config_file_dir where >> the >> dir of the main config file is used for whatever default directory. >> >> i had to have a main config file and extra config files, if we get to >> directories, the first main config will not be able to be used... >> > > Well, paths found in config files should be relative to the config file > the path was parsed from. Adding a helper to lib/nspath.c to get that > based on a full path to a file would probably be the best solution. ah, so that's the point... even more refactor work :-) the problem we're gonna face here is that char *config_file; char *config_file_dir; are exported symbols... how are we gonna make this work without changing those exported symbols? so that nagios addons will still work? |
From: Andreas E. <ae...@op...> - 2013-09-13 10:37:01
|
On 2013-09-13 12:07, AL13N wrote: >> On 2013-09-13 11:15, AL13N wrote: >>>> On 2013-09-12 13:33, AL13N wrote: >>>>> This should be a patch for >>>>> A) allowing multiple main config files >>>>> >>>>> i haven't compiled/run/tested this yet, but this is the kind of thing >>>>> i >>>>> thought would be good. >>>>> >>>>> can someone please tell me if i'm working in the right direction or >>>>> not? >>>>> >>>> >>>> Sort of, and then again, no. It would be good if, as a first step, we >>>> read all main-config-parameters from read_main_config_file() (or some >>>> other function which just groks key/value pairs that gets fed by one >>>> or more invocations of read_main_config_file()). >>>> >>>> That way the patch wouldn't have to fiddle with object config reading, >>>> which won't work properly unless you also add multi-config support to >>>> read_object_config_files(). >>> >>> but, that's the way it's written now... we'd have to refactor the way >>> the >>> config files are read, and then the patch would be quite invasive, >>> wouldn't it? >>> >>> did you see the 2nd patch? where i added multi-config support for >>> read_object_config_files? (or at least very basic, i didn't check if >>> these >>> functions reset some internal variables at the start of their call) >>> >> >> Ah, no, I didn't. >> >>> >>> what exactly are you thinking of doing? >>> >> >> All the "initialize this" and "read_object_config_data()" only parse >> a few variables out of the main config file(s) and then set a few >> variables based on values found there. I would much prefer to have >> config variables read in a single place, all the variables properly >> set based on the latest parsed value (last in wins the race, basically), >> and then calling the init functions while removing the config file >> argument to them completely. > > yes, that does seem better, but that's quite some refactoring... i guess > if you insist, we'll have to do this one first... > I've been meaning to do that for some time anyway, and I actually started it with bf64caf4f2876b1377df08e9fa4c439d5562fdbb. The code that remains is the one I couldn't convert in a lunchbreak. At least if I wanted to eat something as well. > combined with that, there's the added problem of config_file_dir where the > dir of the main config file is used for whatever default directory. > > i had to have a main config file and extra config files, if we get to > directories, the first main config will not be able to be used... > Well, paths found in config files should be relative to the config file the path was parsed from. Adding a helper to lib/nspath.c to get that based on a full path to a file would probably be the best solution. -- Andreas Ericsson and...@op... OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. |
From: AL13N <al...@rm...> - 2013-09-13 10:07:19
|
> On 2013-09-13 11:15, AL13N wrote: >>> On 2013-09-12 13:33, AL13N wrote: >>>> This should be a patch for >>>> A) allowing multiple main config files >>>> >>>> i haven't compiled/run/tested this yet, but this is the kind of thing >>>> i >>>> thought would be good. >>>> >>>> can someone please tell me if i'm working in the right direction or >>>> not? >>>> >>> >>> Sort of, and then again, no. It would be good if, as a first step, we >>> read all main-config-parameters from read_main_config_file() (or some >>> other function which just groks key/value pairs that gets fed by one >>> or more invocations of read_main_config_file()). >>> >>> That way the patch wouldn't have to fiddle with object config reading, >>> which won't work properly unless you also add multi-config support to >>> read_object_config_files(). >> >> but, that's the way it's written now... we'd have to refactor the way >> the >> config files are read, and then the patch would be quite invasive, >> wouldn't it? >> >> did you see the 2nd patch? where i added multi-config support for >> read_object_config_files? (or at least very basic, i didn't check if >> these >> functions reset some internal variables at the start of their call) >> > > Ah, no, I didn't. > >> >> what exactly are you thinking of doing? >> > > All the "initialize this" and "read_object_config_data()" only parse > a few variables out of the main config file(s) and then set a few > variables based on values found there. I would much prefer to have > config variables read in a single place, all the variables properly > set based on the latest parsed value (last in wins the race, basically), > and then calling the init functions while removing the config file > argument to them completely. yes, that does seem better, but that's quite some refactoring... i guess if you insist, we'll have to do this one first... combined with that, there's the added problem of config_file_dir where the dir of the main config file is used for whatever default directory. i had to have a main config file and extra config files, if we get to directories, the first main config will not be able to be used... |
From: Andreas E. <ae...@op...> - 2013-09-13 09:44:28
|
On 2013-09-13 11:15, AL13N wrote: >> On 2013-09-12 13:33, AL13N wrote: >>> This should be a patch for >>> A) allowing multiple main config files >>> >>> i haven't compiled/run/tested this yet, but this is the kind of thing i >>> thought would be good. >>> >>> can someone please tell me if i'm working in the right direction or not? >>> >> >> Sort of, and then again, no. It would be good if, as a first step, we >> read all main-config-parameters from read_main_config_file() (or some >> other function which just groks key/value pairs that gets fed by one >> or more invocations of read_main_config_file()). >> >> That way the patch wouldn't have to fiddle with object config reading, >> which won't work properly unless you also add multi-config support to >> read_object_config_files(). > > but, that's the way it's written now... we'd have to refactor the way the > config files are read, and then the patch would be quite invasive, > wouldn't it? > > did you see the 2nd patch? where i added multi-config support for > read_object_config_files? (or at least very basic, i didn't check if these > functions reset some internal variables at the start of their call) > Ah, no, I didn't. > > what exactly are you thinking of doing? > All the "initialize this" and "read_object_config_data()" only parse a few variables out of the main config file(s) and then set a few variables based on values found there. I would much prefer to have config variables read in a single place, all the variables properly set based on the latest parsed value (last in wins the race, basically), and then calling the init functions while removing the config file argument to them completely. -- Andreas Ericsson and...@op... OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. |
From: AL13N <al...@rm...> - 2013-09-13 09:15:27
|
> On 2013-09-12 13:33, AL13N wrote: >> This should be a patch for >> A) allowing multiple main config files >> >> i haven't compiled/run/tested this yet, but this is the kind of thing i >> thought would be good. >> >> can someone please tell me if i'm working in the right direction or not? >> > > Sort of, and then again, no. It would be good if, as a first step, we > read all main-config-parameters from read_main_config_file() (or some > other function which just groks key/value pairs that gets fed by one > or more invocations of read_main_config_file()). > > That way the patch wouldn't have to fiddle with object config reading, > which won't work properly unless you also add multi-config support to > read_object_config_files(). but, that's the way it's written now... we'd have to refactor the way the config files are read, and then the patch would be quite invasive, wouldn't it? did you see the 2nd patch? where i added multi-config support for read_object_config_files? (or at least very basic, i didn't check if these functions reset some internal variables at the start of their call) what exactly are you thinking of doing? |
From: Andreas E. <ae...@op...> - 2013-09-13 08:19:54
|
On 2013-09-12 13:33, AL13N wrote: > This should be a patch for > A) allowing multiple main config files > > i haven't compiled/run/tested this yet, but this is the kind of thing i > thought would be good. > > can someone please tell me if i'm working in the right direction or not? > Sort of, and then again, no. It would be good if, as a first step, we read all main-config-parameters from read_main_config_file() (or some other function which just groks key/value pairs that gets fed by one or more invocations of read_main_config_file()). That way the patch wouldn't have to fiddle with object config reading, which won't work properly unless you also add multi-config support to read_object_config_files(). -- Andreas Ericsson and...@op... OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. |
From: AL13N <al...@rm...> - 2013-09-12 11:33:19
|
This should be a patch for A) allowing multiple main config files i haven't compiled/run/tested this yet, but this is the kind of thing i thought would be good. can someone please tell me if i'm working in the right direction or not? |
From: Daniel W. <dwi...@gm...> - 2013-09-11 14:07:13
|
On Sep 11, 2013, at 5:43 AM, "AL13N" <al...@rm...> wrote: >> > B) allow files to be directories (empty directories are ok, but > nonexistant directories are not) and implement code to parse files in the > directories I would vote this be just a warning and non-fatal as long as it doesn't generate any other errors, who cares really. Dan |
From: AL13N <al...@rm...> - 2013-09-11 12:07:53
|
Ok, i got an initial partial start, and i was interested if you feel i was going in the right direction: i noticed that there were external symbols on both the primary main config file and the config directory. i kept that, so that it wouldn't break other stuff. the plan is to use config_files instead of config_file to read the objects file below that. then also the real part needs to read the config_files and also, i'll need to review what happens when someone reloads the nagios daemon. PS: i added a patch to presumably fix the optind issue |
From: AL13N <al...@rm...> - 2013-09-11 10:43:34
|
> On 2013-09-04 17:23, AL13N wrote: >>> On 2013-09-04 12:51, AL13N wrote: >> [...] >>> No. All variables from one file should be parsed before any variables >>> from a different file, but the include-files from one file get parsed >>> before we move along to the next file in that directory. >>> >>> If we pretend that /etc/nagios/conf.d contains two files, named A.cfg >>> and B.cfg, where A.cfg has "include=/etc/nagios/perfdata.cfg" and the >>> main nagios config file is /etc/nagios/nagios.cfg, but one also wants >>> to oneshot parse /etc/nagios/debug.cfg, then one would execute Nagios >>> like so: >>> >>> nagios -d /etc/nagios/nagios.cfg /etc/nagios/debug.cfg >>> >>> and with the above settings we would parse >>> /etc/nagios/nagios.cfg nagios.cfg (all settings) >>> /etc/nagios/conf.d/A.cfg (all settings) >>> /etc/nagios/perfdata.cfg (all settings) >>> /etc/nagios/conf.d/B.cfg (all settings) >>> /etc/nagios/debug.cfg (all settings) >>> >>> In practice though, I expect the default settings will be so that >>> /etc/nagios/nagios.cfg contains this: >>> include=/etc/nagios/defaults.cfg >>> include=/etc/nagios/conf.d >>> >>> Btw, we shouldn't error out when encountering an empty directory, >>> but rather just print a warning about it. Or even have "include_dir" >>> and "include_file", where both cause an error if the targeted path >>> doesn't exist, although we allow empty directories. >> >> i think there's a include_dir for hosts and such? or it might be named >> differently. >> > > There's "cfg_dir". > >> i think one include= setting is enough to check file and dir, and empty >> dir shouldn't get an error... i don't think it needs a warning, since it >> will often be used in this way, where the user can add stuff in an empty >> directory. >> > > True that. Nonexisting path should be an error though. > >>> I just realized that this includes the "parse multiple config files >>> from command-line", but since that's hardly a difficult issue once >>> we can parse multiple config files, I doubt that's a problem. >> >> this is what i figured first, so i thought it would not be needed to >> have >> an extra setting that includes other files/dirs. >> >> my original thought was to: >> A) allow multiple files on command line >> B) allow them to be directories too (expanding to multiple files) >> >> then there would be no real need for include= statement, and it would be >> a >> less intrusive (and less work) patch. >> > > True that. And I supposed adding the include statements later wouldn't > be that much work, so whatever you're comfortable implementing would be > great. > >> the distro will likely choose what files/dirs to be used in what order >> (and put this in the initscript/service file), so i figured that this >> would be enough. >> > > Yea, probably. ok so: A) allow multiple config files B) allow files to be directories (empty directories are ok, but nonexistant directories are not) and implement code to parse files in the directories C) allow include= config statements to have files/directories to be parsed immediately after completion of current file. I got started on A) and came upon: http://sourceforge.net/p/nagios/nagioscore/ci/master/tree/base/nagios.c#l378 where optind seems to be undefined in the whole file. (i did see an option_index variable initialized at 0). this seems like an oversight... is it? |
From: Andreas E. <ae...@op...> - 2013-09-10 12:29:28
|
On 2013-09-04 17:23, AL13N wrote: >> On 2013-09-04 12:51, AL13N wrote: > [...] >> No. All variables from one file should be parsed before any variables >> from a different file, but the include-files from one file get parsed >> before we move along to the next file in that directory. >> >> If we pretend that /etc/nagios/conf.d contains two files, named A.cfg >> and B.cfg, where A.cfg has "include=/etc/nagios/perfdata.cfg" and the >> main nagios config file is /etc/nagios/nagios.cfg, but one also wants >> to oneshot parse /etc/nagios/debug.cfg, then one would execute Nagios >> like so: >> >> nagios -d /etc/nagios/nagios.cfg /etc/nagios/debug.cfg >> >> and with the above settings we would parse >> /etc/nagios/nagios.cfg nagios.cfg (all settings) >> /etc/nagios/conf.d/A.cfg (all settings) >> /etc/nagios/perfdata.cfg (all settings) >> /etc/nagios/conf.d/B.cfg (all settings) >> /etc/nagios/debug.cfg (all settings) >> >> In practice though, I expect the default settings will be so that >> /etc/nagios/nagios.cfg contains this: >> include=/etc/nagios/defaults.cfg >> include=/etc/nagios/conf.d >> >> Btw, we shouldn't error out when encountering an empty directory, >> but rather just print a warning about it. Or even have "include_dir" >> and "include_file", where both cause an error if the targeted path >> doesn't exist, although we allow empty directories. > > i think there's a include_dir for hosts and such? or it might be named > differently. > There's "cfg_dir". > i think one include= setting is enough to check file and dir, and empty > dir shouldn't get an error... i don't think it needs a warning, since it > will often be used in this way, where the user can add stuff in an empty > directory. > True that. Nonexisting path should be an error though. >> I just realized that this includes the "parse multiple config files >> from command-line", but since that's hardly a difficult issue once >> we can parse multiple config files, I doubt that's a problem. > > this is what i figured first, so i thought it would not be needed to have > an extra setting that includes other files/dirs. > > my original thought was to: > A) allow multiple files on command line > B) allow them to be directories too (expanding to multiple files) > > then there would be no real need for include= statement, and it would be a > less intrusive (and less work) patch. > True that. And I supposed adding the include statements later wouldn't be that much work, so whatever you're comfortable implementing would be great. > the distro will likely choose what files/dirs to be used in what order > (and put this in the initscript/service file), so i figured that this > would be enough. > Yea, probably. -- Andreas Ericsson and...@op... OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. |
For the record: Nagios developers finally accepted the patch into nagios 3.5 and 4.0 repository: http://sourceforge.net/p/nagios/nagioscore/ci/1ffe547925a8b90b8d35ea96d6ca92b489178982/ http://sourceforge.net/p/nagios/nagioscore/ci/f36ef53a9771d7f89d1f0810228eafc0c0f49036/ Here's the relevant comments by Andreas Ericcson: http://tracker.nagios.org/view.php?id=456#c795 http://tracker.nagios.org/view.php?id=456#c796 Kind regards, jonas Am 2013-09-04 11:03, schrieb Andreas Ericsson: > On 2013-09-04 10:31, Jonas Meurer wrote: >> Hey list and fellow Nagios developers, >> >> as you might have noticed, there's a discussion ongoing on >> oss-security[1] >> regarding bug report #456[2]. >> >> I'm the one who discovered the described issue, and I still believe >> that >> it's a bug with security implications, even though not everyone seems >> to >> be convinced. >> >> I'll try to give a brief description of the issue: >> >> The Nagios status.cgi (at all 3.4* and 4.0* versions I checked) leaks >> hostnames to unauthorized users as part of servicegroups. All of >> servicegroup overview, summary and grid list each and every hostname >> that >> is part of a servicegroup, regardless whether the HTTP user is listed >> in >> contacts/contactgroups for this host. >> >> In my opinion this is a security issue - at least on multi-user (e.g. >> multi-customer) Nagios-setups. I guess that most ISPs which give their >> customers access to the Nagios CGIs don't want to provide a full list >> of monitored hosts to their customers as a side-effect. >> >> One reason for confusion is the following entry from Nagios3 >> changelog[3]: >> >> 3.4.0 - 05/04/2012 >> ENHANCEMENTS >> [...] >> - Users can now see hostgroups and servicegroups that contain at least >> one host or service they are authorized for, instead of having to >> be authorized for them all (Ethan Galstad) >> >> >> The indisputable part of this change is, that users are allowed to see >> hostgroups and servicegroups with at least one authorized host or >> service. Unclear is, whether this means "group and all its group >> members", or "group and only authorized group members". >> > > It should mean "group and only authorized group members, except also > hosts for services where one is authorized to see the service". > >> Unfortunately, no Nagios developer speaked up yet about this issue. >> Thus >> there's still a lot confusion about it. >> > > Well, now I have, so confusion dispelled. > >> You can find my patch at the Nagios Issue Tracker. > > Ah, right. Care to provide a link? Mostly, I prefer to get patches to > this mailing list, since I don't spend a lot of time hunting them down > from the (underused) tracker. > >> This patch changes >> status.cgi behaviour to show only group members (hosts/services) that >> the user is authorized to see. >> >> A comment about this issue by the Nagios Developers whould be highly >> appreciated. In case that the described (and critizised) behaviour of >> status.cgi is intended, the distribution security teams can move on. >> > > Well, it *was* by design, but now I'm changing the design. It's a good > time for it, since 4.0 is about to come out. I think the security teams > can move on and we'll consider this "changed" rather than "fixed" for > 4.0, where we do some security tightening. > >> If on the other hand you agree with me, that this issue should be >> fixed, I'll continue to work with the security teams in order to >> provide patched Nagios packages for their distributions. >> >> Thanks for your work on Nagios, it's a very valuable piece of >> software! >> > > Thanks for enjoying it. |
From: AL13N <al...@rm...> - 2013-09-04 15:23:32
|
> On 2013-09-04 12:51, AL13N wrote: [...] > No. All variables from one file should be parsed before any variables > from a different file, but the include-files from one file get parsed > before we move along to the next file in that directory. > > If we pretend that /etc/nagios/conf.d contains two files, named A.cfg > and B.cfg, where A.cfg has "include=/etc/nagios/perfdata.cfg" and the > main nagios config file is /etc/nagios/nagios.cfg, but one also wants > to oneshot parse /etc/nagios/debug.cfg, then one would execute Nagios > like so: > > nagios -d /etc/nagios/nagios.cfg /etc/nagios/debug.cfg > > and with the above settings we would parse > /etc/nagios/nagios.cfg nagios.cfg (all settings) > /etc/nagios/conf.d/A.cfg (all settings) > /etc/nagios/perfdata.cfg (all settings) > /etc/nagios/conf.d/B.cfg (all settings) > /etc/nagios/debug.cfg (all settings) > > In practice though, I expect the default settings will be so that > /etc/nagios/nagios.cfg contains this: > include=/etc/nagios/defaults.cfg > include=/etc/nagios/conf.d > > Btw, we shouldn't error out when encountering an empty directory, > but rather just print a warning about it. Or even have "include_dir" > and "include_file", where both cause an error if the targeted path > doesn't exist, although we allow empty directories. i think there's a include_dir for hosts and such? or it might be named differently. i think one include= setting is enough to check file and dir, and empty dir shouldn't get an error... i don't think it needs a warning, since it will often be used in this way, where the user can add stuff in an empty directory. > I just realized that this includes the "parse multiple config files > from command-line", but since that's hardly a difficult issue once > we can parse multiple config files, I doubt that's a problem. this is what i figured first, so i thought it would not be needed to have an extra setting that includes other files/dirs. my original thought was to: A) allow multiple files on command line B) allow them to be directories too (expanding to multiple files) then there would be no real need for include= statement, and it would be a less intrusive (and less work) patch. the distro will likely choose what files/dirs to be used in what order (and put this in the initscript/service file), so i figured that this would be enough. |
From: Andreas E. <ae...@op...> - 2013-09-04 13:32:54
|
On 2013-09-04 12:51, AL13N wrote: >> On 2013-09-04 00:34, AL13N wrote: >>> Op dinsdag 3 september 2013 17:22:32 schreef Andreas Ericsson: >>>> On 2013-09-02 21:20, AL13N wrote: >>>>> Hi, >>>>> >>>>> i'm a Mageia distribution packager, and i'm maintaining some event >>>>> broker >>>>> modules. >>>>> >>>>> since these are packaged seperately we're trying to get things to work >>>>> out-of- the-box for our users, specifically adding event brokers in >>>>> the >>>>> configuration file for nagios. >>>>> >>>>> the problem we're facing is that: We don't want a nagios addon package >>>>> to >>>>> rewrite the configuration file itself. however, we would like to add >>>>> the >>>>> event broker (or other settings) and then reload/restart nagios. >>>>> >>>>> a beneficial thing would be a configuration directory (much like it >>>>> exists >>>>> with hosts and commands and stuff like that) but for the main nagios >>>>> configuration file. >>>>> >>>>> and if while we're at it, to have multiple directories, where >>>>> /usr/share/nagios/nagios.d/ has the "defaults" which can be overridden >>>>> in >>>>> /etc/nagios.d/ (for instance) (this is a convention that's growing in >>>>> use) >>>>> >>>>> I can try to start making a patch for this, but i'm asking about this >>>>> first, in order to find out if it makes a chance of getting accepted. >>>> >>>> Not only does it stand a chance of getting accepted; It's on the >>>> roadmap. If you start working on it I'll help as much as I can and >>>> I'm willing to accept less-than-awesome quality code, although I'll >>>> polish such later if it turns out to be an issue. >>>> >>>> The only real requirement is that any "main" config file option >>>> should be settable from any file in the dropdir. >>> >>> >>> the idea i thought might be doable, would be to allow multiple -d >>> options to >>> nagios, and allow those to be a file or a directory. >>> >> >> I'd much rather see this as "include=/some/path.d" where we read all >> files ending with .cfg and .conf if it's a directory, or the file if >> it's a fail, and then parse each include'd file in order of >> include-statement -> lexicographical order >> so that >> >> include=/etc/nagios.conf.d/ >> include=/etc/nagios.perfdata.d/ >> >> would cause all files from /etc/nagios.conf.d to be parsed before all >> files from /etc/nagios.perfdata.d. >> >> The included files can include other files, if they're so inclined. > > so, you mean to keep one nagios.cfg file and have include=/path/to/foo. > > would this mean that if you have > > setting1=value > > setting2=value > > include=/path/to/foo > > setting3=value > > that being parsed would: > 1) setting1 > 2) setting2 > 3) all from /path/to/foo if it's a file or directory > 4) setting3 > > > is this the priority that you aim for? > No. All variables from one file should be parsed before any variables from a different file, but the include-files from one file get parsed before we move along to the next file in that directory. If we pretend that /etc/nagios/conf.d contains two files, named A.cfg and B.cfg, where A.cfg has "include=/etc/nagios/perfdata.cfg" and the main nagios config file is /etc/nagios/nagios.cfg, but one also wants to oneshot parse /etc/nagios/debug.cfg, then one would execute Nagios like so: nagios -d /etc/nagios/nagios.cfg /etc/nagios/debug.cfg and with the above settings we would parse /etc/nagios/nagios.cfg nagios.cfg (all settings) /etc/nagios/conf.d/A.cfg (all settings) /etc/nagios/perfdata.cfg (all settings) /etc/nagios/conf.d/B.cfg (all settings) /etc/nagios/debug.cfg (all settings) In practice though, I expect the default settings will be so that /etc/nagios/nagios.cfg contains this: include=/etc/nagios/defaults.cfg include=/etc/nagios/conf.d Btw, we shouldn't error out when encountering an empty directory, but rather just print a warning about it. Or even have "include_dir" and "include_file", where both cause an error if the targeted path doesn't exist, although we allow empty directories. I just realized that this includes the "parse multiple config files from command-line", but since that's hardly a difficult issue once we can parse multiple config files, I doubt that's a problem. -- Andreas Ericsson and...@op... OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. |
Am 2013-09-04 11:03, schrieb Andreas Ericsson: > On 2013-09-04 10:31, Jonas Meurer wrote: >> Hey list and fellow Nagios developers, >> >> as you might have noticed, there's a discussion ongoing on >> oss-security[1] >> regarding bug report #456[2]. >> >> I'm the one who discovered the described issue, and I still believe >> that >> it's a bug with security implications, even though not everyone seems >> to >> be convinced. >> >> I'll try to give a brief description of the issue: >> >> The Nagios status.cgi (at all 3.4* and 4.0* versions I checked) leaks >> hostnames to unauthorized users as part of servicegroups. All of >> servicegroup overview, summary and grid list each and every hostname >> that >> is part of a servicegroup, regardless whether the HTTP user is listed >> in >> contacts/contactgroups for this host. >> >> In my opinion this is a security issue - at least on multi-user (e.g. >> multi-customer) Nagios-setups. I guess that most ISPs which give their >> customers access to the Nagios CGIs don't want to provide a full list >> of monitored hosts to their customers as a side-effect. >> >> One reason for confusion is the following entry from Nagios3 >> changelog[3]: >> >> 3.4.0 - 05/04/2012 >> ENHANCEMENTS >> [...] >> - Users can now see hostgroups and servicegroups that contain at least >> one host or service they are authorized for, instead of having to >> be authorized for them all (Ethan Galstad) >> >> >> The indisputable part of this change is, that users are allowed to see >> hostgroups and servicegroups with at least one authorized host or >> service. Unclear is, whether this means "group and all its group >> members", or "group and only authorized group members". >> > > It should mean "group and only authorized group members, except also > hosts for services where one is authorized to see the service". Ok, so if this was intended, then there indeed is a bug. >> You can find my patch at the Nagios Issue Tracker. > > Ah, right. Care to provide a link? Mostly, I prefer to get patches to > this mailing list, since I don't spend a lot of time hunting them down > from the (underused) tracker. Sure, my original mail already had it as footnote. Here you find patches for Nagios 3.4.4 and 4 (master from 26.06.2013): http://tracker.nagios.org/view.php?id=456 >> A comment about this issue by the Nagios Developers whould be highly >> appreciated. In case that the described (and critizised) behaviour of >> status.cgi is intended, the distribution security teams can move on. >> > > Well, it *was* by design, but now I'm changing the design. It's a good > time for it, since 4.0 is about to come out. I think the security teams > can move on and we'll consider this "changed" rather than "fixed" for > 4.0, where we do some security tightening. At least when I checked last (26.06.2013), Nagios 4 was still affected by the bug. Did you change the way status.cgi checks for authentication in the meantime? Kind regards, jonas |