2011/1/17 Grégory Starck <g.sta...@gmail.com>
> I was asking myself the same question than Hartmut about the necessity of
> both display_name *and* alias attributes/fields of an host
> object/declaration.. one of them seems really too much (well they seems
> really redundant I mean) ; but I don't think it's a problem because both are
> already handled (differently but anyway) : if not provided in host
> declaration : display_name is by default set to 'none' by StringProp as I
> see and alias is copy of host_name in fill_predictive_missing_parameters().
>
> (but why not also set display_name to host_name instead than hardcoded
> 'none' value ??)
>
> if theses 2 properties of an host object must be kept for back
> compatibility then no problem : let's keep both but why not have
> display_name (when not provided) be also copy of host_name ??
>
Yes, it should be the same way as alias. I'm creating a ticket for it.
>
>
> Jean : no prob I won't commit anything for this (resolv host_name to
> address) as it'd be quite a big change (to create a module that does this
> work (at least for me ; because I've not yet a clear view on how this would
> be done exactly with a module).
>
In fact it not possible with the current arbiter modules : they can
"overrite" an object, not just update it.
>
> Although there was the quite "easy" possibility of doing like my proposed
> patch in my first mail of this thread :
> if address is unprovided in a host declaration then we could easily, and
> also by option (in shinken-specific.cfg), do the resolving like I proposed
> in fill_predictive_missing_parameters() when the hosts are loaded by
> arbiter at its startup. if you still see so.
>
> so something like this now :
>
> shinken-specific.cfg
>
> + #### new cfg value ; true or false. by default (unprovided) it is false.
> + # try_resolv_host_name_or_address_on_startup true|false
> + #### if set to yes :
> + ## if there are hosts defined without an address field or with an address
> field which is not a real address then the arbiter, on its startup, will try
> to resolv the host_name (or address if provided) field to compute the
> address attribute of the host.
> + ## if false : keep current behavior : if not given in host declaration
> then address field is straight copy of host_name.
>
> and in fill_predictive_missing_parameters() just act correspondingly on
> this config variable value.
>
> see ?? (but it'd not be totally "perfect" as we see there is a very very
> special case (hopefully very very unusual) with pollers (when resolving of a
> host_name would give different results depending if it's done on arbiter(s)
> side or on pollers side)
>
It's possible, but when we will have this module, this option will be
useless, so let avoid it for just 1/2 months.
>
> anyway it's only a mere proposition still.
> basically to permit simplification of host declaration (and have a better
> "view" with UI as they get the IP and not a "name" in the address attribute)
> ; even if I know that certainly most nagios configs currently used
> are explicitly declaring/setting the address field (with an IP) in their
> host declarations but this would so simplify the work/config (I find that
> less "hardcoded" values in configs is better, especially in this case).
> and also because I don't like to have the IP of some host_name be hardcoded
> in some config files (in my experience it's simply basically "bad") others
> than the config of a dns server obviously :p (when possible and here I
> think it's the case ).
>
The main thing is the UI view by IP range. It do not change really the
monitoring thing, most users put host_names in it after all.
Jean
>
> I hope I'm clear in my explanation ;)
>
> regards,
>
> greg.
>
>
>
> 2011/1/17 nap <napar...@gmail.com>
>
>
>>
>> On Mon, Jan 17, 2011 at 10:42 AM, Hartmut Goebel <
>> h.goe...@goebel-consult.de> wrote:
>>
>>> Am 17.01.2011 10:28, schrieb nap:
>>> > We cannot remove them, for backward compatibility with Nagios
>>> > configurations and UIs.
>>> Depends :-)
>>>
>>> IMHO we should cut of some old plaits. Isn't "shinken" a sharp knife" ;-)
>>>
>> Yes, for the architecture, but in the project vision it was clear that
>> compatibility is not an option, but a core feature ;)
>> But we can remove such parameters from the doc, and show only what is
>> useful for users. So new comers will have a clean doc, and current nagios
>> admins will still have their configuration that just works, every one is
>> happy (and not lost) :)
>>
>>
>>> > BTW: Resolving the hostname on the arbiter may lead to double when
>>> > using
>>> > realms and/or split-DNS.
>>> >
>>> > Double? I don't understand it.
>>> If hostnames resolve differently on arbiter and worker, the worker may
>>> access the wrong machine.
>>>
>> Yes, that why it's optional, and to be used only if the admin known what
>> he is doing :)
>>
>>
>> Jean
>>
>>
>>>
>>> --
>>> Schönen Gruß - Regards
>>> Hartmut Goebel
>>> Dipl.-Informatiker (univ.), CISSP, CSSLP
>>>
>>> Goebel Consult
>>> Spezialist für IT-Sicherheit in komplexen Umgebungen
>>> http://www.goebel-consult.de
>>>
>>> Monatliche Kolumne: http://www.cissp-gefluester.de/
>>> Goebel Consult mit Mitglied bei http://www.7-it.de
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Protect Your Site and Customers from Malware Attacks
>>> Learn about various malware tactics and how to avoid them. Understand
>>> malware threats, the impact they can have on your business, and how you
>>> can protect your company and customers by using code signing.
>>> http://p.sf.net/sfu/oracle-sfdevnl
>>> _______________________________________________
>>> Shinken-devel mailing list
>>> Shinken-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Protect Your Site and Customers from Malware Attacks
>> Learn about various malware tactics and how to avoid them. Understand
>> malware threats, the impact they can have on your business, and how you
>> can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Shinken-devel mailing list
>> Shinken-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Shinken-devel mailing list
> Shinken-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>
>
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
