>>> 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 o=
r
>>>>>> 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 so=
me
>>>>> other function which just groks key/value pairs that gets fed by on=
e
>>>>> 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 wa=
y
>>>> 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 gue=
ss
>> 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 ofgit 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?
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: alien@rmail.be