2011/1/16 Grégory Starck <g.sta...@gmail.com>
> 2011/1/16 nap <napar...@gmail.com>
>
>> Hi,
>>
>> I never thought about this. It sounds good, but it should ba an option (I
>> like to get host_name in address,
>
>
> (already totally agree that putting this in a arbiter module could/would be
> a good way to do.)
>
Yep, it's the configuration master after all :)
>
> but why like you to have the address be a duplicate/copy of the host_name ?
>
hum... don't understand ...
> well I mean :
> the host 'address' attribute should only contain *address* (and I think
> IP (4 or 6) only basically) like things.
>
Not really. Address can be something else for "dummies hosts" that are not
just servers or routers, it's just a value with a name after all. But yes,
in 99% of the cases, it's a IP/DNS name.
> Unless explicitly configured otherwise in the host declaration ; but if
> something is explicitly set for address field of an host declaration then we
> can still do the DNS lookup on it instead of on the 'host_name'
> field/attribute (unless the address field in host declaration
> would already be a real IP (but even then the resolv of the IP should still
> give the IP itself).
>
I think it should be the reverse for backward compatibility : if you want to
resolve it, you say it. If not, you don't.
>
>
>
>> it's the DNS role to do this after all),
>
>
> yes and that's what would rightly be done : use the (local unless we would
> permit others) DNS (through socket.getaddrinfo() call) to resolv host_name
> (or explicitly provided 'address' field in host declaration) to an address
> and store/save this in/as the address attribute of an host :)
>
> (otherwise what's actually done is that it's the commands themselves that
> are doing the lookup when a command is using the $HOSTADDRESS$ macro (unless
> the address field was explicitly set to a real address in host conf))
>
Yes, so the job is done by all the workers there.
>
>
> but it can be fun as an arbiter module : it lookup all (or not) address at
>> the module starting, update the first conf pakages before being send to the
>> schedulers, then one a X minutes, it update all, and update the values in
>> the schedulers (will need an extra scheduler interface call, but should not
>> be so hard). With all in a module, admins will have all power on this, and
>> will not fear about it.
>>
>
>
> but this still leave the (quite subsidiary) question :
>
> if the resolving is only done by an arbiter module (at the arbiter level
> thus) then it could be bad in the case that some pollers/commands should do
> themselves the resolving for their good job to be accomplished.. if you see
> also what I mean (if not I can try explain more clearly) ;) (but ok 1)
> it's quite mostly unusual to have possibly different results of a dns lookup
> depending on where the lookup is done (but I've seen some cases ;) and 2) I
> guess/think most nagios/shinken configs are in the same network/dns
> conditions and so aren't concerned by this specific case))
>
hum.. it's a strange case indeed.
>
> so basically I think that this (doing resolving of host_name to address (if
> address not explicitly given in conf) should/could also be done at the
> pollers level.. (but eventually & ultimately in a configurable way : there
> could have admin who want resolving of host_name/address be done only at
> some well defined level(s)...)
>
It's not their jobs, and in the configuration pas, they are not connected
from now.
But an arbiter module can run and act when it wants, so after it can maybe
ask pollers to "do something" like this, but it's not code from now (need
poller modules for it). And the module will need to look at realm
dispatching to know which hosts go to which pollers (it's easy to know the
scheduler, but pollers need an additionnal loop).
>
>
>
>> And with it, it will improve the arbiter modules way of working (update
>> instead of full rewrite) and the scheduler interface too (incremental update
>> instead of full one), so it's ok for a module,
>
>
> I don't really see well what you mean but it's certainly have more meaning
> than what I say ;)
>
>
>
>> but not in the core I think, because it's not to the core to to dns lookup
>> one a X minutes, but it fill perfectly to a module.
>>
>
> I totally agree to this.
>
>
>
>> We can also add a "property" add feature for modules, because this one
>> will need an extra parameters for hosts. I'll look at it for the 0.6 feature
>> plan, so very very soon ;)
>>
>
> here also you go over my understanding but anyway (what extra parameters ?
> as far as i see this wouldn't add any host parameter but "only" change the
> way the 'address' one is used/computed) :/
>
Yes, never mind, it's an implementation detail, not the point in this email
:)
>
>
> So in summary : by default let say we would do the resolving only be done
> at the arbiter level (by a module) but leave a configurable way to have it
> be done also at the pollers level ?
>
So to resume :
* we need to add an arbiter module that do the resolving by itself, not
active by default, and that will do for all/some of the hosts, it's a module
parameter after, not a core one.
* the pollers ask will be more hard, because it's an architecture hack. It's
possible, but the module should manage all the hacks it will need.
I'm wondering if the pollers things is so useful. After all, for such cases,
the admins can configure by themselves the IPs of such hosts.
>
> if agree then I can begin to write the arbiter module for this..
>
Yep, but don't commit from now (or in a branch), I'm currently freezing the
master as 0.5 (just need the NSCA fix and we are ready ;) ).
Jean
>
> Greg.
>
>
>
>> Jean
>>
>>
>
>
>
>> 2011/1/15 Grégory Starck <g.sta...@gmail.com>
>>
>>> hi dev guys,
>>>
>>> what would you think of this :
>>>
>>>
>>> (tests)greg@brutus:~/Documents/Projets/shinken$ git show
>>> bc37d7ee46dc03ab244a3c4af1406ad72c4a54e6
>>> commit bc37d7ee46dc03ab244a3c4af1406ad72c4a54e6
>>> Author: Grégory Starck <g.sta...@gmail.com>
>>> Date: Sat Jan 15 14:44:45 2011 +0100
>>>
>>> * host: try to get real address for address property if unprovided.*
>>>
>>> diff --git a/shinken/host.py b/shinken/host.py
>>> index e155b05..ff649c0 100644
>>> --- a/shinken/host.py
>>> +++ b/shinken/host.py
>>> @@ -26,6 +26,7 @@ scheduling/consome check smart things :)
>>>
>>> import time
>>> import re #for keys generator
>>> +from socket import getaddrinfo
>>>
>>> from shinken.autoslots import AutoSlots
>>> from shinken.item import Items
>>> @@ -624,7 +625,11 @@ class Host(SchedulingItem):
>>> # Fill adresse with host_name if not already set
>>> def fill_predictive_missing_parameters(self):
>>> if hasattr(self, 'host_name') and not hasattr(self, 'address'):
>>> - self.address = self.host_name
>>> + try:
>>> + self.address = getaddrinfo(self.host_name, 0)[0][4][0]
>>> + except Exception as e:
>>> + logger.log("Couldn't translate %s to address ; using it
>>> as address (err=%s)" % (self.host_name, e))
>>> + self.address = self.host_name
>>> if hasattr(self, 'host_name') and not hasattr(self, 'alias'):
>>> self.alias = self.host_name
>>>
>>> (tests)greg@brutus:~/Documents/Projets/shinken$
>>>
>>>
>>>
>
> ------------------------------------------------------------------------------
> 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
