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.)
but why like you to have the address be a duplicate/copy of the host_name ?
well I mean :
the host 'address' attribute should only contain *address* (and I think
IP (4 or 6) only basically) like things.
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).
> 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))
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))
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)...)
> 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) :/
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 ?
if agree then I can begin to write the arbiter module for this..
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
