Hello, 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.
There are several ways how to do that and it seems like SLP is being used in combination with WBEM quite often. Maybe it is the right thing for us to use for the OpenLMI discovery as well. The Pegasus CIMOM can register itself in the local SLP server and then even advertises the registered profiles as the service attributes. Here's the sample output from my testing machine for the illustration:
[tsmetana@zaphod ~]$ slptool -u f-19-local findsrvs service:wbem service:wbem:https://%5Bfe80::5054:ff:feb6:b32%5D:5989,65025 service:wbem:https://192.168.122.12:5989,65025 [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... 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,Association Traversal,Query Execution,Qualifier Declaration,Indications),(MultipleOperationsSupported=FALSE),(AuthenticationMechanismsSupported=Basic),(AuthenticationMechanismDescriptions=Basic),(CommunicationMechanism=CIM-XML),(ProtocolVersion=1.0),(Namespace=root/PG_InterOp,root/PG_Internal,root/cimv2,root),(RegisteredProfilesSupported=SNIA:Server,DMTF:Profile Registration,SNIA:Server:Indication,SNIA:Profile Registration,SNIA:Server:Software,SNIA:SMI-S)
SLP would bring another dependency (the slpd daemon) but has some advantages: the discovery queries are multicasted, Pegasus already supports this out-of-the-box (we only need to start registering profiles properly) and it looks to be quite simple.
While playing with the SLP tools in Fedora I have written Python bindings for OpenSLP, so we should be able to integrate SLP support in the LMI shell: https://github.com/tsmetana/pyslp (We can "openlmify" the sources and integrate in our code eventually.)
Opinions?
Thanks and regards,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/21/2013 11:00 AM, Tomáš Smetana wrote:
Hello, 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.
There are several ways how to do that and it seems like SLP is being used in combination with WBEM quite often. Maybe it is the right thing for us to use for the OpenLMI discovery as well. The Pegasus CIMOM can register itself in the local SLP server and then even advertises the registered profiles as the service attributes. Here's the sample output from my testing machine for the illustration:
[tsmetana@zaphod ~]$ slptool -u f-19-local findsrvs service:wbem service:wbem:https://%5Bfe80::5054:ff:feb6:b32%5D:5989,65025 service:wbem:https://192.168.122.12:5989,65025 [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...
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,Association Traversal,Query Execution,Qualifier Declaration,Indications),(MultipleOperationsSupported=FALSE),(AuthenticationMechanismsSupported=Basic),(AuthenticationMechanismDescriptions=Basic),(CommunicationMechanism=CIM-XML),(ProtocolVersion=1.0),(Namespace=root/PG_InterOp,root/PG_Internal,root/cimv2,root),(RegisteredProfilesSupported=SNIA:Server,DMTF:Profile
Registration,SNIA:Server:Indication,SNIA:Profile
Registration,SNIA:Server:Software,SNIA:SMI-S)
SLP would bring another dependency (the slpd daemon) but has some advantages: the discovery queries are multicasted, Pegasus already supports this out-of-the-box (we only need to start registering profiles properly) and it looks to be quite simple.
While playing with the SLP tools in Fedora I have written Python bindings for OpenSLP, so we should be able to integrate SLP support in the LMI shell: https://github.com/tsmetana/pyslp (We can "openlmify" the sources and integrate in our code eventually.)
Opinions?
What downsides do you see with SLP other than the added dependency? It sounds to me to be almost to good to be true (already supported by Pegasus, etc.) so I would like to know what the counter-arguments might be.
=?UTF-8?B?VG9tw6HFoQ==?= Smetana tsmetana@redhat.com writes:
[...] There are several ways how to do that and it seems like SLP is being used in combination with WBEM quite often. [...]
Also, have you considered Avahi / zeroconf?
- FChE
On Fri, 2013-06-21 at 12:00 -0400, Frank Ch. Eigler wrote:
=?UTF-8?B?VG9tw6HFoQ==?= Smetana tsmetana@redhat.com writes:
[...] There are several ways how to do that and it seems like SLP is being used in combination with WBEM quite often. [...]
Also, have you considered Avahi / zeroconf?
What are the advantages of using Avahi or zeroconf over SLP, which is already implemented in Pegasus and just needs to be turned on?
- FChE
openlmi-devel mailing list openlmi-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
Russell Doty rdoty@redhat.com writes:
Also, have you considered Avahi / zeroconf?
What are the advantages of using Avahi or zeroconf over SLP
More widespread adoption, inclusion in base RHEL, multicast-based design?
which is already implemented in Pegasus and just needs to be turned on?
(Sure, that consideration could govern, assuming its SLP support is good enough.)
- FChE
On Fri, 2013-06-21 at 18:26 -0400, Frank Ch. Eigler wrote:
Russell Doty rdoty@redhat.com writes:
Also, have you considered Avahi / zeroconf?
What are the advantages of using Avahi or zeroconf over SLP
More widespread adoption, inclusion in base RHEL, multicast-based design?
My understanding is that SLP is included in base RHEL and is multicast-based. I don't have any insight into relative adoption (which is part of why I'm asking).
which is already implemented in Pegasus and just needs to be turned on?
(Sure, that consideration could govern, assuming its SLP support is good enough.)
Well, it's a significant data point... Would like to understand the tradeoffs between SLP, Avahi and zeroconf before making a final decision.
- FChE
openlmi-devel mailing list openlmi-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
Hello.
On Fri, 21 Jun 2013 18:26:59 -0400 fche@redhat.com (Frank Ch. Eigler) wrote:
Russell Doty rdoty@redhat.com writes:
Also, have you considered Avahi / zeroconf?
What are the advantages of using Avahi or zeroconf over SLP
More widespread adoption, inclusion in base RHEL, multicast-based design?
As Russ mentioned: Apart from the widespread adoption argument (which I consider somewhat moot: I don't think zeroconf is that prevalent in the server world and on desktop UPnP is probably better known as well), same holds true for SLP.
It's true that SLP is not as feature-rich as the others. On the other hand we look for the service discovery only and SLP is exactly that. Simple and (so far it looks like) working. It's also an older technology than the others however OpenSLP is still being maintained and developed (new release only a few days ago).
which is already implemented in Pegasus and just needs to be turned on?
(Sure, that consideration could govern, assuming its SLP support is good enough.)
This is a killer feature for me.
The openslp pacakge in Fedora is not in a best shape (no systemd unit, broken runtime dependencies...). This shouldn't be a big problem though -- I'll try to do something about it.
I'll keep tinkering with OpenSLP in LMI Shell and report the results eventually.
Regards,
Hi,
On Mon, 2013-06-24 at 11:10 +0200, Tomáš Smetana wrote:
On Fri, 21 Jun 2013 18:26:59 -0400 fche@redhat.com (Frank Ch. Eigler) wrote:
The openslp pacakge in Fedora is not in a best shape (no systemd unit, broken runtime dependencies...). This shouldn't be a big problem though -- I'll try to do something about it.
Who owns it? It would be good to have confidence we can keep it maintained if we'll be depending on it.
Thanks, Stephen
On Mon, 24 Jun 2013 13:20:24 +0100 "Stephen C. Tweedie" sct@redhat.com wrote:
Hi,
On Mon, 2013-06-24 at 11:10 +0200, Tomáš Smetana wrote:
On Fri, 21 Jun 2013 18:26:59 -0400 fche@redhat.com (Frank Ch. Eigler) wrote:
The openslp pacakge in Fedora is not in a best shape (no systemd unit, broken runtime dependencies...). This shouldn't be a big problem though -- I'll try to do something about it.
Who owns it? It would be good to have confidence we can keep it maintained if we'll be depending on it.
The Fedora owner is Rex Dieter, but the RHEL maintainer is Víťa Crhonek. We'll try to fix the package, send the patches to the Fedora owner and apply for co-maintainership eventually.
Regards,
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.
(For small numbers you can probably just run the test on each one and avoid the complexity, of course.)
Certainly tools like puppet/facter or mcollective support flexible ways to select managed systems based on various info known about them.
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? 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... 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?
--Stephen
On Mon, 24 Jun 2013 13:36:59 +0100 "Stephen C. Tweedie" sct@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... 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,
openlmi-devel@lists.stg.fedorahosted.org
-
Frank Ch. Eigler -
Russell Doty -
Stephen C. Tweedie -
Stephen Gallagher -
Tomáš Smetana