On Mon, 24 Jun 2013 13:36:59 +0100
"Stephen C. Tweedie" <sct(a)redhat.com> wrote:
Hi,
On Fri, 2013-06-21 at 17:00 +0200, Tomáš Smetana wrote:
> I have mentioned this several times before: I had been asked to provide
> some example scripts that would "for every computer on the network... do
> something". It's not quite obvious how to actually find every
> WBEM-capable device on the network.
I'm not sure we _want_ to. I expect that it's usually more a case of
"find all devices which match criteria $TEST" than "find absolutely
every device and give me the full list." On a large network,
pre-pruning the set of systems is going to be important.
That's right. I actually mentioned "every WBEM-capable device" in the above
which is a kind of the $TEST criteria. It can be narrowed down to "and having
the 'LMI Storage' profile registered" or something similar. And we'll
find
only those which want to be discovered anyway -- SLP requires a multicast
interface to be set up and the slpd daemon running.
<...>
So the next question for me would be, how would we model system info
in
an SLP environment to allow that selectivity? Require the CIM
infrastructure to interrogate system properties for all discovered
systems, or expose some basic granular per-system info over SLP itself?
Yes, I would aim for the second option. All it takes is to register the
profiles properly.
The latter would seen to allow us to minimise network traffic,
although
it would imply sending system-specific info over a channel not secured
by OpenLMI's own ssl connection, so we'd have to be careful about how we
do it.
It certainly _looks_ like we can do this via SLP ---
> [tsmetana@zaphod ~]$ slptool -u f-19-local findattrs service:wbem
>
(template-url-syntax=https://192.168.122.12:5989),(service-id=PG:192-168-122-12),(service-hi-name=Pegasus),(service-hi-description=Pegasus
> OpenPegasus Version 2.12.1
> Development),(template-type=wbem),(template-version=1.0),(template-description=This
> template describes the attributes used for advertising Pegasus CIM
>
Servers.),(InteropSchemaNamespace=root/PG_InterOp),(FunctionalProfilesSupported=Basic
> Read,Basic Write,Schema Manipulation,Instance Manipulation, ...
as there seems to be a bunch of metadata already exposed here.
Any thoughts?
You're right that this means to send the information over an unencrypted
channel. I'm not a security expert however I think this is the generic
problem for all the other service discovery protocols (zeroconf, upnp) which
simply imply we trust the network we run them in. SNMP autodiscovery may
suffer from a similar problem IIRC. This is something I really didn't
realize...
This probably means the SLP feature will have to stay off by default. Still
I think it's worth the effort to put the openslp in shape and add some
support for it in the LMI shell.
Thanks and regards,
--
Tomáš Smetana
Platform Engineering, Red Hat