RFC for enablement of slpd on openbmc
Hi All,
*Enabling SLP Server on openBMC*
What is SLP
=======
Service Location Protocol (SLP) is a protocol that provides a framework to allow networking applications to discover the existence, location, and configuration of networked services in enterprise networks.
openSLP is widely accepted in the industry
What do we need to do?
==============
1) Bring SLP(OpenSLP) in image:- Write the bitbake recipe(didn't find the readily available bitbake recipe)
2) Configure the services through Settings daemon.
3) Write the .service file as it needs to start after network is up(after networkd-online.target)
How to configure the services which needs to be registered with slpd
============================================
Option 1:- settingsd
Note: Gives the flexibility to change the configured services @ runtime. Do we require this functionality?
Option 2:conf file for discovery services
Note: During build time we can get the service info(service-name,port) from the existing infra(discoveryservice.bbclass)
How to register the services
==================
1) Static Registration:- will not work as we need ip/host-name details which we don't have @build time.
2) Application(new DBUS app) will register the configured services to the slpd on startup.
We need to provide the dynamic registration support on BMC as IP of BMC can change any time. Registration of services with slpd takes the URL of the service which includes ip and port of the service which needs to be registered.
Create a DBUS service application
=====================
1) Once the service starts it registers the configured services with slpd.
2) listening on RTNETLINK event for ip change: raise a dbus signal(for the IP change)
if there is IP change then dereg the old service followed by reg
service as the ip has changed.
Regards
Ratan Gupta
Please make sure there is a distro feature for this that can be turned off to remove SLP entirely from the image.
Quoted 76 lines · Ratan Gupta
Hi All,
*Enabling SLP Server on openBMC*
What is SLP
=======
Service Location Protocol (SLP) is a protocol that provides a framework to allow networking applications to discover the existence, location, and configuration of networked services in enterprise networks.
openSLP is widely accepted in the industry
What do we need to do?
==============
1) Bring SLP(OpenSLP) in image:- Write the bitbake recipe(didn't find the readily available bitbake recipe)
2) Configure the services through Settings daemon.
3) Write the .service file as it needs to start after network is up(after networkd-online.target)
How to configure the services which needs to be registered with slpd
============================================
Option 1:- settingsd
Note: Gives the flexibility to change the configured services @ runtime. Do we require this functionality?
Option 2:conf file for discovery services
Note: During build time we can get the service
info(service-name,port)from the existing infra(discoveryservice.bbclass)How to register the services
==================1) Static Registration:- will not work as we need ip/host-name details which we don't have @build time.
2) Application(new DBUS app) will register the configured services to the slpd on startup.
We need to provide the dynamic registration support on BMC as IP of BMC can change any time. Registration of services with slpd takes the URL of the service which includes ip and port of the service which needs to be registered.
Create a DBUS service application
=====================
1) Once the service starts it registers the configured services with slpd.
2) listening on RTNETLINK event for ip change: raise a dbus signal(for the IP change)
if there is IP change then dereg the old service followed by reg
service as the ip has changed.Regards
Ratan Gupta_______________________________________________
openbmc mailing list
[email protected]
https://lists.ozlabs.org/listinfo/openbmc
Quoted 3 lines · Rick Altherr
Please make sure there is a distro feature for this that can be turned off to remove SLP entirely from the image.
Agreed. We did structure the Avahi support that way and this should be done the same.
Signature · 1 line
Patrick Williams
Quoted 11 lines · Ratan Gupta
*Enabling SLP Server on openBMC*
What is SLP
=======
Service Location Protocol (SLP) is a protocol that provides a framework to allow networking applications to discover the existence, location, and configuration of networked services in enterprise networks.
openSLP is widely accepted in the industry
What are the aspects of SLP that are requirements for the intended use-case? SLP as a protocol has both direct query and an optional "directory" implementation that aggregates SLP results. In your experience is that necessary or used?
What is the anticipated size footprint of using openSLP? The RFC doesn't seem that significant, so if we do not need the directory aspect might it be more beneficial to write a small daemon ourself to give SLP responses rather than trying to mold openSLP to fit our needs?
I'm certainly not advocating avoiding using existing open source. But, with there not being an update to openSLP since 2013 and all the aspects we are going to have to work around below, I'm wondering on the benefit.
Quoted 8 lines
What do we need to do?
==============
1) Bring SLP(OpenSLP) in image:- Write the bitbake recipe(didn't find the readily available bitbake recipe)
2) Configure the services through Settings daemon.
We do have a .bbclass for "registration" we need to ensure that this is utilized for SLP as much as possible.
Quoted 3 lines
3) Write the .service file as it needs to start after network is up(after networkd-online.target)
This service file is for the openslp daemon, correct?
Quoted 6 lines
How to configure the services which needs to be registered with slpd
============================================
Option 1:- settingsd
Quoted 7 lines
Note: Gives the flexibility to change the configured services @ runtime. Do we require this functionality?
Option 2:conf file for discovery services
Note: During build time we can get the service
info(service-name,port)from the existing infra(discoveryservice.bbclass)
I don't entirely understand how these aren't phases of the same solution.
The problem space as I see it:
1. An application provides a service to be advertised by SLP.
2. The application is currently started via a .service or a .socket file.
a. Some services are always running.
b. Some services use socket-activation.
3. We need to register this service with the SLP daemon, somehow.
Do we need to ensure the application is running (or available to run via socket activation) before we do the registration? If the application is being restarted should we remove the registration and add it back after it comes back?
You mentioned dealing with IP address changes. It is pretty annoying that openSLP doesn't do this for you (a custom daemon could). How are you handling multiple network interfaces? How to we flag internal vs external interfaces? Isn't there a mechanism via systemd (or networkd) to identify when the ip address changes? Ideally, this would be a restart of a .service.
I could see us building a very small application that performs three functions:
1. slp-register register <service>
2. slp-register deregister <service>
3. slp-register ip-change
For each registered service "foo.service", we can generate foo-slp-register.service. The foo-slp-register.service will depend on foo.service, so it is started immediately after and stopped when the foo.service is stopped. The 'start' will be to call 'slp-register register' and the 'stop' will be to call 'slp-register deregister'.
We also can then keep off of something in systemd / networkd to run 'slp-register ip-change' whenever the IP changes. This could either restart *-slp-register.service or it could extract all of the SLP registrations and update them with new IP addresses. Putting all of the *-slp-register.service into a 'target' might make restarting them very simple.
With this approach we do not need a long running application.
Quoted 5 lines
How to register the services
==================1) Static Registration:- will not work as we need ip/host-name details which we don't have @build time.
It is unfortunate about this. We can solve this with a custom slp-daemon.
Quoted 3 lines
2) Application(new DBUS app) will register the configured services to the slpd on startup.
I am not understanding what the 'dbus app' aspect of this would be. What would be the dbus interfaces?
Quoted 5 lines
We need to provide the dynamic registration support on BMC as IP of BMC can change any time. Registration of services with slpd takes the URL of the service which includes ip and port of the service which needs to be registered.
Quoted 8 lines
Create a DBUS service application
=====================
1) Once the service starts it registers the configured services with slpd.
2) listening on RTNETLINK event for ip change: raise a dbus signal(for the IP change)
Who is getting this signal?
Quoted 6 lines
if there is IP change then dereg the old service followed by reg
service as the ip has changed.Regards
Ratan Gupta
Signature · 1 line
Patrick Williams
Hi Patrick,
Thanks for giving the feedback,please find my comments inline.
Regards
Ratan Gupta
Quoted 11 lines · Patrick Williams
Quoted 10 lines · Ratan Gupta
*Enabling SLP Server on openBMC*
What is SLP
=======
Service Location Protocol (SLP) is a protocol that provides a framework to allow networking applications to discover the existence, location, and configuration of networked services in enterprise networks.
Quoted 5 lines
Quoted 1 line
openSLP is widely accepted in the industry
What are the aspects of SLP that are requirements for the intended use-case? SLP as a protocol has both direct query and an optional "directory" implementation that aggregates SLP results. In your experience is that necessary or used?
Slp supports three agents
1) UA(slptool)
2) SA(in our case it would be new app which we have to write for
reg of services)
3) DA(where the reg info stores) it could be on network or on the
same machine..but it is required to support the RFC.
Quoted 5 lines
What is the anticipated size footprint of using openSLP? The RFC doesn't seem that significant, so if we do not need the directory aspect might it be more beneficial to write a small daemon ourself to give SLP responses rather than trying to mold openSLP to fit our needs?
runtime foot print TOP Command shows
214 1 daemon S *3620* 3% 0% slpd -l /tmp/slpd.log >>>3.5K
file size which will take in flash
slpd:- 100.4K
libslp:-69.7K
Quoted 4 lines
I'm certainly not advocating avoiding using existing open source. But, with there not being an update to openSLP since 2013 and all the aspects we are going to have to work around below, I'm wondering on the benefit.
I think we are not doing any workaround here,It is slp (as per the
RFC)which expects
IP in their reg url as the slp needs ip in the reg url,we are
catering that need via de
Quoted 7 lines
Quoted 7 lines
What do we need to do?
==============
1) Bring SLP(OpenSLP) in image:- Write the bitbake recipe(didn't find the readily available bitbake recipe)
Quoted 8 lines
Quoted 1 line
2) Configure the services through Settings daemon.
We do have a .bbclass for "registration" we need to ensure that this is utilized for SLP as much as possible.
Yes we would be using it3) Write the .service file as it needs to start after network is up(after networkd-online.target)
This service file is for the openslp daemon, correct?
Yes
How to configure the services which needs to be registered with slpd
============================================
Option 1:- settingsd
Note: Gives the flexibility to change the configured services @ runtime. Do we require this functionality?
Option 2:conf file for discovery services
Note: During build time we can get the service info(service-name,port) from the existing infra(discoveryservice.bbclass)
Quoted 11 lines
I don't entirely understand how these aren't phases of the same solution.
The problem space as I see it:
1. An application provides a service to be advertised by SLP.
2. The application is currently started via a .service or a .socket file.
a. Some services are always running.
b. Some services use socket-activation.
3. We need to register this service with the SLP daemon, somehow.
Quoted 4 lines
Do we need to ensure the application is running (or available to run via socket activation) before we do the registration? If the application is being restarted should we remove the registration and add it back after it comes back?
I believe that is not needed as the application(SA) would be dependent on the conf
and out policy suggest that network services should restart always
so it would be unnecessary
to do reg and unreg
Quoted 20 lines
You mentioned dealing with IP address changes. It is pretty annoying that openSLP doesn't do this for you (a custom daemon could). How are you handling multiple network interfaces? How to we flag internal vs external interfaces? Isn't there a mechanism via systemd (or networkd) to identify when the ip address changes? Ideally, this would be a restart of a .service.
I could see us building a very small application that performs three functions:
1. slp-register register <service>
2. slp-register deregister <service>
3. slp-register ip-changeFor each registered service "foo.service", we can generate foo-slp-register.service. The foo-slp-register.service will depend on foo.service, so it is started immediately after and stopped when the foo.service is stopped. The 'start' will be to call 'slp-register register' and the 'stop' will be to call 'slp-register deregister'.
Quoted 8 lines
We also can then keep off of something in systemd / networkd to run 'slp-register ip-change' whenever the IP changes. This could either restart *-slp-register.service or it could extract all of the SLP registrations and update them with new IP addresses. Putting all of the *-slp-register.service into a 'target' might make restarting them very simple.
With this approach we do not need a long running application.
I agree but do we really need to dereg and reg in the case when the service is going down as.
Our service policy is restart always whenever the network service
goes down. so service would be down for a moment
Long running application i was asking for the IP change event,I am
not aware if systemd-networkd send some event
whenever the ip change occurs.
Quoted 7 lines
Quoted 5 lines
How to register the services
==================1) Static Registration:- will not work as we need ip/host-name details which we don't have @build time.
It is unfortunate about this. We can solve this with a custom slp-daemon.
Agree but the custom one would not be implementing the full RFC.
Quoted 5 lines
Quoted 3 lines
2) Application(new DBUS app) will register the configured services to the slpd on startup.
I am not understanding what the 'dbus app' aspect of this would be. What would be the dbus interfaces?
I thought of if some other app(netman.py) wants to do the reg and
unreg. so thought of exposing the
Register Service
unregister Service
Raising the DBUS signal in case of IP change.
Quoted 7 lines
Quoted 7 lines
We need to provide the dynamic registration support on BMC as IP of BMC can change any time. Registration of services with slpd takes the URL of the service which includes ip and port of the service which needs to be registered.
Create a DBUS service application
Quoted 7 lines
Quoted 6 lines
=====================
1) Once the service starts it registers the configured services with slpd.
2) listening on RTNETLINK event for ip change: raise a dbus signal(for the IP change)
Who is getting this signal?
This one was required,if certain application is interested in IP
change event then it can use.
today no application is interested in this event.
Quoted 6 lines
Quoted 6 lines
if there is IP change then dereg the old service followed by reg
service as the ip has changed.Regards
Ratan Gupta
Quoted 9 lines · Ratan Gupta
Quoted 4 lines
What is the anticipated size footprint of using openSLP? The RFC doesn't seem that significant, so if we do not need the directory aspect might it be more beneficial to write a small daemon ourself to give SLP responses rather than trying to mold openSLP to fit our needs?
runtime foot print TOP Command shows 214 1 daemon S *3620* 3% 0% slpd -l /tmp/slpd.log >>>3.5K file size which will take in flash slpd:- 100.4K libslp:-69.7K
Not horrible then.
Quoted 7 lines
Quoted 3 lines
I'm certainly not advocating avoiding using existing open source. But, with there not being an update to openSLP since 2013 and all the aspects we are going to have to work around below, I'm wondering on the benefit.
I think we are not doing any workaround here,It is slp (as per the
RFC)which expects
IP in their reg url as the slp needs ip in the reg url,we are
catering that need via de
What I mean by a "workaround" is that for localhost reasons it would be much more convenient to have the daemon do this work of automatically updating the URL when the IP changes. The non-local IP case isn't especially interesting for the BMC.
Quoted 9 lines
Quoted 4 lines
Do we need to ensure the application is running (or available to run via socket activation) before we do the registration? If the application is being restarted should we remove the registration and add it back after it comes back?
I believe that is not needed as the application(SA) would be dependent on the conf
and out policy suggest that network services should restart always
so it would be unnecessary
to do reg and unreg
We currently do it this way for Avahi so I am fine doing the same for SLP. Someone ambitious could enhance this aspect in the future.
Quoted 7 lines
Quoted 7 lines
We also can then keep off of something in systemd / networkd to run 'slp-register ip-change' whenever the IP changes. This could either restart *-slp-register.service or it could extract all of the SLP registrations and update them with new IP addresses. Putting all of the *-slp-register.service into a 'target' might make restarting them very simple.
Quoted 8 lines
Quoted 1 line
With this approach we do not need a long running application.
I agree but do we really need to dereg and reg in the case when the service is going down as.
Our service policy is restart always whenever the network service
goes down. so service would be down for a moment
Long running application i was asking for the IP change event,I am
not aware if systemd-networkd send some event
whenever the ip change occurs.
Correct. I don't feel it is needed now.
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
2) Application(new DBUS app) will register the configured services to the slpd on startup.
I am not understanding what the 'dbus app' aspect of this would be. What would be the dbus interfaces?
I thought of if some other app(netman.py) wants to do the reg and
unreg. so thought of exposing the
Register Service
unregister Service
Raising the DBUS signal in case of IP change.
I don't think we need to dynamically do these, other than the IP change. We can handle that through a service restart rather than a long running dbus process for an infrequent operation?
Signature · 1 line
Patrick Williams