On 02.02.2013 15:12, Eric Stanley wrote:
> The host key should be allowed to specify one or more IP addresses, IP=20
> subnets, contiguous IP address ranges, host names and host name=20
> patterns/wildcards (i.e. *.example.com). If multiple workers register=20
> for the same host, some sort of distribution mechanism should be used t=
o=20
> load balance the workers.
First off, I'm even more firmly opposed to the assumption that
$HOSTADDRESS$ =3D=3D IP address than Andreas. I've set up Nagios instance=
s
for customers where $HOSTADDRESS$ actually happened to be
-- router management address plus SNMP index of customer-facing
interface (for a carrier who considered it verboten to snoop *into*
the network of CPE-less business customers to determine whether the
links are "up" in an SLA-relevant way)
-- IP address enriched with VLAN tags (which code for the path through
the WDM multiplexers to the CPE's management interface)
-- IP plus SSH port, plus optionally ssh options (server admin insists
on login banner, Nagios admin throws a "-q" into the gearbox ...)
-- *CHAINS* of IP / SSH port pairs (software supplier also supplies the
monitoring, but some of his customers insist on burying the server
*several* SSH hops deep within his own network)
and I suppose I've been lucky not to have had to deal with a mixed
IPv4/IPv6 shop yet.
Having that said: From your description, I'm under the impression that
you're picturing a scenario of a complex network where the central
Nagios actually cannot reach the "leaf" hosts itself, whereas the worker
concept seems to be oriented towards load distribution IIUC.
These two scenarios aren't 100% compatible in their technical needs. For
example, when the central Nagios winds up with no suitable worker for
certain target hosts, the disjoint-nets scenario likely would leave it
no choice but to mark the upcoming checks UNREACHABLE/UNKNOWN, while the
load-distrib scenario would call for it to run the checks itself (and
try harder to push *other* checks to workers to rid itself of the
increased load). Also, responsibility and, thus, configuration tends to
follow the segregation of the networks.
To sum it up, what I would imagine as Nagios' long-term development for
*your* scenario wouldn't be a Nagios/worker "tasks go downstream"
interface but one that allows a local Nagios to push "local" status data
(from config to current check results) to an upstream "integration and
oversight" Nagios.
(And yes, pinpointing how exactly you can and want to do access control,
formation of host/service *groups*, notifications for local/global
users, yadda yadda, with such a configuration brain split *will* be a bea=
r.)
On 03.02.2013 00:57, Andreas Ericsson wrote:
> libssh2, most likely, with preshared keys the same way you use keys
> to do password-less logins via ssh
Dear ***God*** don't call it that! That's *not* a PSK (symmetric crypto,
no auth, as *all* participants know the secret) but a pubkey
(asymmetric, only holder of matching *private* key can answer the
challenge, hence proper auth).
> (although using password protected
> keys will probably be quite a large pain)
(FWIW, a look at the libssh2 API suggests that it also supports the
communication with an ssh-agent. IOW, it should be possible to run
Nagios as a child of ssh-agent, load the privkey into the agent at
startup, with someone manually entering the passphrase, if need be, and
Nagios and its subprocesses can delegate the SSH auth to the agent.)
(There doesn't seem to be support for the newfangled (Open)SSH
mechanisms, though. I guess that the Nagios---worker communication
doesn't need ControlMaster, but the (non-X.509) certificates for auth
might have been of interest.)
Regards,
J. Bern
--=20
*NEU* - NEC IT-Infrastruktur-Produkte im :
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP =3D D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FA
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: Jochen.Bern@LINworks.de