[yast-devel] about the services module direction

Duncan Mac-Vicar Prett

17 Aug 2009 17 Aug '09

09:20

Right now in we have a web-service called services with it corresponding web- clent part. On Friday morning this was implemented using the YaPI and on Friday afternoon it was reverted to the old codebase using some lsbservice.rb code. Now there is a new custom_services plugin, AFAIK this is because the services feature has to do with a custom vendor service and not with all system services, and now nobody knows what will happen to the old services plugin. I am really confused about the requirements and the design in general (and I am worried about the direction it is taking), here are my points: - Are we going to make application vendors have to use a different APIs for services and for "custom services"? that goes against any UNIX design. - If we want to provide customization or support for non-LSB services, why do we need a separate API than lsb services instead of making the services API work with both? - Are we going to make a plugin just to provide a service API based on a vendor custom start/stop/status script? Can anyone please compare the effort of customizing that with actually either forcing the vendor to provide a LSB init script or to actually provide a lsb wrapper script that can be sourced after defining 4 variables, and for which we get the quite nice feature of managing all services through the same interface? I think the design is escaping simplicity, I would propose this approach: - Having _one_ and only one services plugin in the service side. The implementation of this REST API would access the init.d scripts, and additionally would do the following things: - also read another directory with yml files where and recognize custom services there. The vendor provides the variables in those yml, and the services plugin knows how to handle those. However the LSB services are - Having ONE, and only ONE web client module for the services The implementation of the Web client would also recognize a yml file in certain directory that would allow to hide certain services and allow branding of others. That way, the vendor can customize what to show. If the problem of which services are visible is determined on the client side (so if you access a remote host from the client you see all services) then this configuration can then be in the service side, and the API will hint the client which services need to be hidden, or whatever. This should be a hint, respected by our client, but we should allow 3rd party consumers Benefits of this approach: - we get a services API that works for all services - vendors have the choice to use LSB services or a easy way via a config file - the cient can show the data in the way the vendor wants by respecting the hints of the API, however a 3rd party API consumer can see all services as equal. Comments? -- Duncan Mac-Vicar P. - Engineering Manager, YaST SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Show replies by date

Jiří Suchomel

17 Aug 17 Aug

10:15

New subject: [yast-devel] Re: about the services module direction

On Monday 17 of August 2009 11:20:47 you wrote:

...

I think the design is escaping simplicity, I would propose this approach:

- Having _one_ and only one services plugin in the service side.

The implementation of this REST API would access the init.d scripts, and additionally would do the following things: - also read another directory with yml files where and recognize custom services there. The vendor provides the variables in those yml, and the services plugin knows how to handle those. However the LSB services are

- Having ONE, and only ONE web client module for the services

The implementation of the Web client would also recognize a yml file in certain directory that would allow to hide certain services and allow branding of others. That way, the vendor can customize what to show.

This was my original approach with the YaPI (before the revert). However, it was pointed by Klaus that current mandatory feature is to start and stop just one vendor specific service (fate 306696). That's why I commited new plugin that should do just such work: showing status of one given service, starting and stopping it. Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Duncan Mac-Vicar Prett

10:39

New subject: [yast-devel] Re: about the services module direction

On Monday 17 August 2009 12:15:34 Jiří Suchomel wrote:

...

However, it was pointed by Klaus that current mandatory feature is to start and stop just one vendor specific service (fate 306696). That's why I commited new plugin that should do just such work: showing status of one given service, starting and stopping it.

Jiri

Klaus pointed that we need to support one vendor specific service, how is this implemented is different. I don't see the need for a new API here, even less for a new package or plugin. I even described how to approach it. I fail to see how that would break the requirements. -- Duncan Mac-Vicar P. - Engineering Manager, YaST SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Jiří Suchomel

11:04

New subject: [yast-devel] Re: about the services module direction

On Monday 17 of August 2009 12:39:31 Duncan Mac-Vicar Prett wrote:

...

On Monday 17 August 2009 12:15:34 Jiří Suchomel wrote:

...
However, it was pointed by Klaus that current mandatory feature is to start and stop just one vendor specific service (fate 306696). That's why I commited new plugin that should do just such work: showing status of one given service, starting and stopping it.

Jiri

Klaus pointed that we need to support one vendor specific service, how is this implemented is different.

My original version was able to support any number of vendor specific services, together with a vendor specific list of /etc/init.d scripts. Klaus, could you clear it, so it we know what is really required? My understanding from your last (+fate) comments is that you actually do not want to mix standard LSB-complaint services with that given customer one and only thing needed is the way to start and stop one custom service (or, maybe better, application). Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Duncan Mac-Vicar Prett

11:10

New subject: [yast-devel] Re: about the services module direction

On Monday 17 August 2009 13:04:25 Jiří Suchomel wrote:

...

My understanding from your last (+fate) comments is that you actually do not want to mix standard LSB-complaint services with that given customer one and only thing needed is the way to start and stop one custom service (or, maybe better, application).

If you allow the original module to hide what is not in the configuration file, you got everything or I am missing something? -- Duncan Mac-Vicar P. - Engineering Manager, YaST SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Klaus Kaempf

14:09

New subject: [yast-devel] Re: about the services module direction

* Jiří Suchomel [Aug 17. 2009 13:04]:

...

On Monday 17 of August 2009 12:39:31 Duncan Mac-Vicar Prett wrote:

...
On Monday 17 August 2009 12:15:34 Jiří Suchomel wrote:

...
However, it was pointed by Klaus that current mandatory feature is to start and stop just one vendor specific service (fate 306696). That's why I commited new plugin that should do just such work: showing status of one given service, starting and stopping it.

Jiri

Klaus pointed that we need to support one vendor specific service, how is this implemented is different.

My original version was able to support any number of vendor specific services, together with a vendor specific list of /etc/init.d scripts.

Klaus, could you clear it, so it we know what is really required?

Required is - from a user pov: A simple UI to start/stop the vendor application - from a vendor pov: A simple way to set this up, without having to provide an lsb-compliant init script. (Vendors are lazy ;-) as they don't want to make building an appliance a huge investment. And we want to put the bar as low as possible. Thats why Studio offers to include files or tarballs into an appliance instead of requesting everything to be packaged as an RPM).

...

My understanding from your last (+fate) comments is that you actually do not want to mix standard LSB-complaint services with that given customer one and only thing needed is the way to start and stop one custom service (or, maybe better, application).

The request is to have a separate, dedicated, dead-easy UI to start/stop the vendor application. It should _not_ be mixed with a 'services' module with a huge list of Linux-internal services (e.g. /etc/init.d, resp. /etc/xinet.d). The request is also not to require lsb-compliant scripts but allow vendors to supply any kind of command line call for starting and stopping the application. I think the current confusion comes from the fact that these requirements were understood as "completely different front- and backend", which is not the case. The backend api should be generic to allow for managing /etc/init.d services as well as vendor-supplied services (eventually outside of /etc/init.d). Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Klaus Kaempf

14:20

New subject: [yast-devel] Re: about the services module direction

* Duncan Mac-Vicar Prett [Aug 17. 2009 11:20]:

...

Right now in we have a web-service called services with it corresponding web- clent part.

On Friday morning this was implemented using the YaPI and on Friday afternoon it was reverted to the old codebase using some lsbservice.rb code.

Now there is a new custom_services plugin, AFAIK this is because the services feature has to do with a custom vendor service and not with all system services, and now nobody knows what will happen to the old services plugin.

I am really confused about the requirements and the design in general (and I am worried about the direction it is taking), here are my points:

- Are we going to make application vendors have to use a different APIs for services and for "custom services"? that goes against any UNIX design.

I agree. The services backend (rest service) should allow for both (init.d and vendor supplied).

...

- If we want to provide customization or support for non-LSB services, why do we need a separate API than lsb services instead of making the services API work with both?

We dont need separate APIs but separate frontend dialogs.

...

- Are we going to make a plugin just to provide a service API based on a vendor custom start/stop/status script? Can anyone please compare the effort of customizing that with actually either forcing the vendor to provide a LSB init script or to actually provide a lsb wrapper script that can be sourced after defining 4 variables, and for which we get the quite nice feature of managing all services through the same interface?

I think the design is escaping simplicity, I would propose this approach:

- Having _one_ and only one services plugin in the service side.

The implementation of this REST API would access the init.d scripts, and additionally would do the following things: - also read another directory with yml files where and recognize custom services there. The vendor provides the variables in those yml, and the services plugin knows how to handle those.

Yes, thats the most desirable approach.

...

However the LSB services are

- Having ONE, and only ONE web client module for the services

Displaying just one application to start/stop is different from displaying a list of services. Something for our web designers. ;-) But I agree, having this handled by a single modules is the cleanest approach.

...

The implementation of the Web client would also recognize a yml file in certain directory that would allow to hide certain services and allow branding of others. That way, the vendor can customize what to show.

If the problem of which services are visible is determined on the client side (so if you access a remote host from the client you see all services) then this configuration can then be in the service side, and the API will hint the client which services need to be hidden, or whatever. This should be a hint, respected by our client, but we should allow 3rd party consumers

For the initial version, lets focus on a single application. What you're describing is the future vision the frontend and backend should allow for.

...

Benefits of this approach:

- we get a services API that works for all services - vendors have the choice to use LSB services or a easy way via a config file - the cient can show the data in the way the vendor wants by respecting the hints of the API, however a 3rd party API consumer can see all services as equal.

Comments?

The current restriction to one application was done to simplify the module design as well as the end user UI. Time runs out quickly to go any further than this. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Jiří Suchomel

14:58

New subject: [yast-devel] Re: about the services module direction

On Monday 17 of August 2009 16:20:22 Klaus Kaempf wrote:

...

* Duncan Mac-Vicar Prett [Aug 17. 2009 11:20]:

...
I think the design is escaping simplicity, I would propose this approach:

- Having _one_ and only one services plugin in the service side.

The implementation of this REST API would access the init.d scripts, and additionally would do the following things: - also read another directory with yml files where and recognize custom services there. The vendor provides the variables in those yml, and the services plugin knows how to handle those.

Yes, thats the most desirable approach.

Well, so could I return to the rest-API service plugin that was using YaPI, and was able to call /etc/init.d scripts as well as user customized ones? That means, the original approach of services, written by schubi and mvidner would be lost with some of its features that my simpler approach did not have. I summarize again my original approach: YaPI layer: provides call to show and manipulate given services, be it from /etc/init.d or custom service defined in /etc/YaST2/webyast_services.yml rest-service: basically encapsulating YaPI calls web-client: showing the services provided by rest API (= those found in webyast_services.yml) Now there could be 2 different UI parts, using the same rest service, one for /etc/init.d/ services (substituting current 'services' plugin), and the other for one (or any number) user defined service. Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Jiri Srain

18 Aug 18 Aug

06:01

New subject: [yast-devel] Re: about the services module direction

Dne pondělí 17 Srpen 2009 16:58:36 Jiří Suchomel napsal(a):

...

On Monday 17 of August 2009 16:20:22 Klaus Kaempf wrote:

...
* Duncan Mac-Vicar Prett [Aug 17. 2009 11:20]:

...
I think the design is escaping simplicity, I would propose this approach:

- Having _one_ and only one services plugin in the service side.

The implementation of this REST API would access the init.d scripts, and additionally would do the following things: - also read another directory with yml files where and recognize custom services there. The vendor provides the variables in those yml, and the services plugin knows how to handle those.

Yes, thats the most desirable approach.

Well, so could I return to the rest-API service plugin that was using YaPI, and was able to call /etc/init.d scripts as well as user customized ones?

That means, the original approach of services, written by schubi and mvidner would be lost with some of its features that my simpler approach did not have.

I summarize again my original approach:

YaPI layer: provides call to show and manipulate given services, be it from /etc/init.d or custom service defined in /etc/YaST2/webyast_services.yml

rest-service: basically encapsulating YaPI calls

web-client: showing the services provided by rest API (= those found in webyast_services.yml)

Now there could be 2 different UI parts, using the same rest service, one for /etc/init.d/ services (substituting current 'services' plugin), and the other for one (or any number) user defined service.

Just remember that at current stage, we only concentrate on the 'single service' web-client plug-in. Jiri -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Jiří Suchomel

07:10

New subject: [yast-devel] Re: about the services module direction

On Tuesday 18 of August 2009 08:01:58 Jiri Srain wrote:

...

Dne pondělí 17 Srpen 2009 16:58:36 Jiří Suchomel napsal(a):

...
On Monday 17 of August 2009 16:20:22 Klaus Kaempf wrote:

...
* Duncan Mac-Vicar Prett [Aug 17. 2009 11:20]:

...
I think the design is escaping simplicity, I would propose this approach:

- Having _one_ and only one services plugin in the service side.

The implementation of this REST API would access the init.d scripts, and additionally would do the following things: - also read another directory with yml files where and recognize custom services there. The vendor provides the variables in those yml, and the services plugin knows how to handle those.

Yes, thats the most desirable approach.

Well, so could I return to the rest-API service plugin that was using YaPI, and was able to call /etc/init.d scripts as well as user customized ones?

That means, the original approach of services, written by schubi and mvidner would be lost with some of its features that my simpler approach did not have.

I summarize again my original approach:

YaPI layer: provides call to show and manipulate given services, be it from /etc/init.d or custom service defined in /etc/YaST2/webyast_services.yml

rest-service: basically encapsulating YaPI calls

web-client: showing the services provided by rest API (= those found in webyast_services.yml)

Now there could be 2 different UI parts, using the same rest service, one for /etc/init.d/ services (substituting current 'services' plugin), and the other for one (or any number) user defined service.

Just remember that at current stage, we only concentrate on the 'single service' web-client plug-in.

Sure, that's what I mean by that second UI. We should probably have 2 web clients, one "services" for /etc/init.d services and one ("custom_services"?) for vendor specific service. Both would use the same "services" REST API, with "index", "show" and "update" paths. There were discussions about YaPI usage and configuration file parsing: - if REST API should access all services, not only custom one, but also /etc/init.d, this is one more reason for YaPI as we can reuse existing Service.ycp module - proposed functions in YaPI are: SERVICES::Read (boolean custom) - to get either list of all /etc/init.d services OR vendor service(s) described in the file /etc/YaST2/custom_services.yml SERVICES::Get (string name) - get the status of given service (if name does not exist under /etc/init.d/, it is searched in custom_services.yml) SERVICES::Execute (string name, string action) - call the given command (start/stop/restart/...) on given service - each YaPI function has its own policy: org.opensuse.yast.modules.yapi.services.read org.opensuse.yast.modules.yapi.services.get org.opensuse.yast.modules.yapi.services.execute - this proposal includes parsing config file from YaPI, there were also ideas about parsing it from rest service. The pro for parser in YaPI is security, as already discussed: see that API have just service names as arguments. When the config file would be parsed by ruby, it would probably need to call YaPI with path to script that needs to be executed. Yes, maybe the security question is not that important and we could say that admin who has rights to execute service is equivalent to root. But the security provided here is basically for free, with this proposal, the granularity of rights is easily implementable. - well, it almost free. On the minus side, the YaPI part needs perl-YAML package as requirement. - which brings the question where the YaPI part should be packaged. My temporary implementation has it in yast2 package (which contains Services.ycp), but it basically could be anywhere. Maybe even in yast2-webservice-services package... Are there any objections against this proposal? Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Duncan Mac-Vicar Prett

08:06

New subject: [yast-devel] Re: about the services module direction

On Tuesday 18 August 2009 09:10:48 Jiří Suchomel wrote:

...

Sure, that's what I mean by that second UI. We should probably have 2 web clients, one "services" for /etc/init.d services and one ("custom_services"?) for vendor specific service. Both would use the same "services" REST API, with "index", "show" and "update" paths.

I can't say if it will be more usable having two modules, and why two are needed, because I don't understand what reason creates the need for two. We could have only one, and support showing the custom services only because it is the only priority. But what one implements at the beginning is tied to the priorities, but the design is more looking the forest than choping trees. A typical design pattern here is to use URL parameters, so the API could return all services when GET. But if ?filter=custom is passed, then the custom_services.yml is read and only those are returned. I was discussing the same design pattern with Björn for the service to return a ISV defined list of software versions. In this case one can make a installed packages resource that returns all packages, and add a ?filter=favorites that would read the config file with the appliance important packages list. Then adding other filters is piececake, to satisfy different requirements. The weird solution would have been creating a resource /custom_packages. -- Duncan Mac-Vicar P. - Engineering Manager, YaST SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Klaus Kaempf

08:32

New subject: [yast-devel] Re: about the services module direction

* Jiří Suchomel [Aug 18. 2009 09:10]:

...

Sure, that's what I mean by that second UI. We should probably have 2 web clients, one "services" for /etc/init.d services and one ("custom_services"?)

I believe a separate 'view' in the current services module is all you need.

...

There were discussions about YaPI usage and configuration file parsing:

- if REST API should access all services, not only custom one, but also /etc/init.d, this is one more reason for YaPI as we can reuse existing Service.ycp module

Agreed. Use the YaPI to reuse init.d parser from Service.ycp. However, reading the 'vendor service' configuration can be done non-privileged.

...

- proposed functions in YaPI are:

SERVICES::Read (boolean custom) - to get either list of all /etc/init.d services OR vendor service(s) described in the file /etc/YaST2/custom_services.yml

Reading custom_services.yml does not need privileges. The 'boolean custom' parameter is needed for the REST service but not at the YaPI level.

...

SERVICES::Get (string name) - get the status of given service (if name does not exist under /etc/init.d/, it is searched in custom_services.yml)

I'd propose to merge 'Read' and 'Get'. The service resource (at the REST layer) should decribe the service and its state.

...

SERVICES::Execute (string name, string action) - call the given command (start/stop/restart/...) on given service

The 'vendor service' command should be executed via the 'bash' SCR api.

...

- each YaPI function has its own policy:

org.opensuse.yast.modules.yapi.services.read org.opensuse.yast.modules.yapi.services.get org.opensuse.yast.modules.yapi.services.execute

- this proposal includes parsing config file from YaPI, there were also ideas about parsing it from rest service. The pro for parser in YaPI is security, as already discussed: see that API have just service names as arguments. When the config file would be parsed by ruby, it would probably need to call YaPI with path to script that needs to be executed. Yes, maybe the security question is not that important and we could say that admin who has rights to execute service is equivalent to root. But the security provided here is basically for free, with this proposal, the granularity of rights is easily implementable.

I strongly believe leaving the YaPI layer untouched and doing a simle 'YAML.load(...)' in the webservice controller has far lower effort.

...

- well, it almost free. On the minus side, the YaPI part needs perl-YAML package as requirement.

- which brings the question where the YaPI part should be packaged. My temporary implementation has it in yast2 package (which contains Services.ycp), but it basically could be anywhere. Maybe even in yast2-webservice-services package...

Are there any objections against this proposal?

See above ;-) Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Jiří Suchomel

13:05

New subject: [yast-devel] Re: about the services module direction

On Tuesday 18 of August 2009 10:32:01 you wrote:

...

* Jiří Suchomel [Aug 18. 2009 09:10]:

...
Sure, that's what I mean by that second UI. We should probably have 2 web clients, one "services" for /etc/init.d services and one ("custom_services"?)

I believe a separate 'view' in the current services module is all you need.

Yes, that might be better.

...

...
- proposed functions in YaPI are:

SERVICES::Read (boolean custom) - to get either list of all /etc/init.d services OR vendor service(s) described in the file /etc/YaST2/custom_services.yml

Reading custom_services.yml does not need privileges.

No, at least not for Read. But if I'd need it for Execute, there's no point in reading it at two places.

...

The 'boolean custom' parameter is needed for the REST service but not at the YaPI level.

This depends on who reads the file :-)

...

...
SERVICES::Get (string name) - get the status of given service (if name does not exist under /etc/init.d/, it is searched in custom_services.yml)

I'd propose to merge 'Read' and 'Get'. The service resource (at the REST layer) should decribe the service and its state.

Agreed.

...

...
SERVICES::Execute (string name, string action) - call the given command (start/stop/restart/...) on given service

The 'vendor service' command should be executed via the 'bash' SCR api.

We were discussing it already, right? YaPI is a way to call 'bash' SCR api, or do you mean using SCR service via dbus directly? That's basically the same, or where's the big difference? Or writing new dbus service? Why, when we do have YaPI, which would be used anyway for /etc/init.d services?

...

...
- each YaPI function has its own policy:

org.opensuse.yast.modules.yapi.services.read org.opensuse.yast.modules.yapi.services.get org.opensuse.yast.modules.yapi.services.execute

- this proposal includes parsing config file from YaPI, there were also ideas about parsing it from rest service. The pro for parser in YaPI is security, as already discussed: see that API have just service names as arguments. When the config file would be parsed by ruby, it would probably need to call YaPI with path to script that needs to be executed. Yes, maybe the security question is not that important and we could say that admin who has rights to execute service is equivalent to root. But the security provided here is basically for free, with this proposal, the granularity of rights is easily implementable.

I strongly believe leaving the YaPI layer untouched and doing a simle 'YAML.load(...)' in the webservice controller has far lower effort.

+ for YaPI is security for free and using existing DBUS service Calling YAML::LoadFile from Perl is equally simple as YAML.load in ruby, isn't it (http://svn.opensuse.org/svn/yast/trunk/yast2/library/runlevel/src/YaPI/SERVI... Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Klaus Kaempf

13:12

New subject: [yast-devel] Re: about the services module direction

* Jiří Suchomel [Aug 18. 2009 15:06]:

...

...
Reading custom_services.yml does not need privileges.

No, at least not for Read. But if I'd need it for Execute, there's no point in reading it at two places.

You read it (unprivileged) in the service controller an pass that value (the command to execute) down to the scr bash agent. No need to make any changes an the YaPI layer.

...

...
I strongly believe leaving the YaPI layer untouched and doing a simle 'YAML.load(...)' in the webservice controller has far lower effort.

+ for YaPI is security for free and using existing DBUS service

Calling YAML::LoadFile from Perl is equally simple as YAML.load in ruby, isn't it

Not quite. By depending on perl:YaML you're adding a new package dependency. We have to be extra careful with WebYaST external dependencies and check for maintenance coverage. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Jiří Suchomel

13:57

New subject: [yast-devel] Re: about the services module direction

On Tuesday 18 of August 2009 15:12:50 Klaus Kaempf wrote:

...

...
...
I strongly believe leaving the YaPI layer untouched and doing a simle 'YAML.load(...)' in the webservice controller has far lower effort.

+ for YaPI is security for free and using existing DBUS service

Calling YAML::LoadFile from Perl is equally simple as YAML.load in ruby, isn't it

Not quite. By depending on perl:YaML you're adding a new package dependency. We have to be extra careful with WebYaST external dependencies and check for maintenance coverage.

Yes, that's the point where we differ. Plus points for YaPI are - using existing dbus service - security while minus point is extra requirement of perl-YAML in some yast package. You say, the minus is more important than the plus, I'm saying the opposite. Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Ladislav Slezak

16:29

New subject: [yast-devel] Re: about the services module direction

Dne 18.8.2009 15:12, Klaus Kaempf napsal(a):

...

...
...
I strongly believe leaving the YaPI layer untouched and doing a simle 'YAML.load(...)' in the webservice controller has far lower effort.

+ for YaPI is security for free and using existing DBUS service

Calling YAML::LoadFile from Perl is equally simple as YAML.load in ruby, isn't it

Not quite. By depending on perl:YaML you're adding a new package dependency. We have to be extra careful with WebYaST external dependencies and check for maintenance coverage.

And what about using yast2-ruby-bindings? We could create a small Yast module written in Ruby which reads a Yaml file and returns a Hash or Array (which would be converted to YCPMap or YCPList by the bindings). This approach doesn't need any extra package, YAML is a part of the Ruby standard library. -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Klaus Kaempf

17:53

New subject: [yast-devel] Re: about the services module direction

* Ladislav Slezak [Aug 18. 2009 18:29]:

...

Dne 18.8.2009 15:12, Klaus Kaempf napsal(a):

...
...
...
I strongly believe leaving the YaPI layer untouched and doing a simle 'YAML.load(...)' in the webservice controller has far lower effort.

+ for YaPI is security for free and using existing DBUS service

Calling YAML::LoadFile from Perl is equally simple as YAML.load in ruby, isn't it

Not quite. By depending on perl:YaML you're adding a new package dependency. We have to be extra careful with WebYaST external dependencies and check for maintenance coverage.

And what about using yast2-ruby-bindings? We could create a small Yast module written in Ruby which reads a Yaml file and returns a Hash or Array (which would be converted to YCPMap or YCPList by the bindings).

This approach doesn't need any extra package, YAML is a part of the Ruby standard library.

I still don't get while you insist that reading a config file needs root privileges. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Ladislav Slezak

19 Aug 19 Aug

08:21

New subject: [yast-devel] Re: about the services module direction

Dne 18.8.2009 19:53, Klaus Kaempf napsal(a): [...]

...

I still don't get while you insist that reading a config file needs root privileges.

Actually reading it as root is a side effect. I'd like to keep the functionality in one module. We already have boolean Service::Restart(string service), boolean Service::Stop(string service), map Service::Info (string name), integer Service::Status (string name), ... which already work with LSB services, why this functions should not be enhanced to work also with custom services? I mean if Service::Restart() doesn't find a LSB service it could search for a custom service. This way we can simply hide the implementation details about custom services. More over the standard Yast Runlevel editor would work with custom services automatically, users could change them locally even without WebYaST... -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Jiří Suchomel

20 Aug 20 Aug

14:10

New subject: [yast-devel] Re: about the services module direction

On Tuesday 18 of August 2009 15:05:26 Jiří Suchomel wrote:

...

...
...
SERVICES::Get (string name) - get the status of given service (if name does not exist under /etc/init.d/, it is searched in custom_services.yml)

I'd propose to merge 'Read' and 'Get'. The service resource (at the REST layer) should decribe the service and its state.

Agreed.

Well, maybe not. Because it would take too much time if not only list, but also status were requested for all current /etc/init.d services. It is also seen in YaST runlevel module: first it reads (and shows) the list of services, than it queries for each service status and updates the list with each arriving result. In web UI, we could do it with AJAX calls. Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Klaus Kaempf

24 Aug 24 Aug

07:58

New subject: [yast-devel] Re: about the services module direction

* Jiří Suchomel [Aug 20. 2009 16:11]:

...

On Tuesday 18 of August 2009 15:05:26 Jiří Suchomel wrote:

...
...
...
SERVICES::Get (string name) - get the status of given service (if name does not exist under /etc/init.d/, it is searched in custom_services.yml)

I'd propose to merge 'Read' and 'Get'. The service resource (at the REST layer) should decribe the service and its state.

Agreed.

Well, maybe not.

Because it would take too much time if not only list, but also status were requested for all current /etc/init.d services. It is also seen in YaST runlevel module: first it reads (and shows) the list of services, than it queries for each service status and updates the list with each arriving result. In web UI, we could do it with AJAX calls.

CIM has similar constraints (i.e. instance attributes which are 'expensive' to calculate) and solves it which a flag. We could adopt the same concept here and simply add a "?with_state=1" to the REST uri. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Jiri Srain

18 Aug 18 Aug

15:42

New subject: [yast-devel] Re: about the services module direction

Dne úterý 18 Srpen 2009 10:32:01 Klaus Kaempf napsal(a):

...

* Jiří Suchomel [Aug 18. 2009 09:10]:

...
Sure, that's what I mean by that second UI. We should probably have 2 web clients, one "services" for /etc/init.d services and one ("custom_services"?)

I believe a separate 'view' in the current services module is all you need.

...
There were discussions about YaPI usage and configuration file parsing:

- if REST API should access all services, not only custom one, but also /etc/init.d, this is one more reason for YaPI as we can reuse existing Service.ycp module

Agreed. Use the YaPI to reuse init.d parser from Service.ycp. However, reading the 'vendor service' configuration can be done non-privileged.

Getting information about the service definitely can, but examining the status and/or starting/stopping/restarting most likely needs root privileges.

...

...
- proposed functions in YaPI are:

SERVICES::Read (boolean custom) - to get either list of all /etc/init.d services OR vendor service(s) described in the file /etc/YaST2/custom_services.yml

Reading custom_services.yml does not need privileges.

The 'boolean custom' parameter is needed for the REST service but not at the YaPI level.

...
SERVICES::Get (string name) - get the status of given service (if name does not exist under /etc/init.d/, it is searched in custom_services.yml)

I'd propose to merge 'Read' and 'Get'. The service resource (at the REST layer) should decribe the service and its state.

...
SERVICES::Execute (string name, string action) - call the given command (start/stop/restart/...) on given service

The 'vendor service' command should be executed via the 'bash' SCR api.

Ah, that matches what you wrote above regarding non-root :-) Jiri

...

...
- each YaPI function has its own policy:

org.opensuse.yast.modules.yapi.services.read org.opensuse.yast.modules.yapi.services.get org.opensuse.yast.modules.yapi.services.execute

- this proposal includes parsing config file from YaPI, there were also ideas about parsing it from rest service. The pro for parser in YaPI is security, as already discussed: see that API have just service names as arguments. When the config file would be parsed by ruby, it would probably need to call YaPI with path to script that needs to be executed. Yes, maybe the security question is not that important and we could say that admin who has rights to execute service is equivalent to root. But the security provided here is basically for free, with this proposal, the granularity of rights is easily implementable.

I strongly believe leaving the YaPI layer untouched and doing a simle 'YAML.load(...)' in the webservice controller has far lower effort.

...
- well, it almost free. On the minus side, the YaPI part needs perl-YAML package as requirement.

- which brings the question where the YaPI part should be packaged. My temporary implementation has it in yast2 package (which contains Services.ycp), but it basically could be anywhere. Maybe even in yast2-webservice-services package...

Are there any objections against this proposal?

See above ;-)

Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

-- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

5360

Age (days ago)

5367

Last active (days ago)

List overview

Download

20 comments

5 participants

participants (5)

Duncan Mac-Vicar Prett
Jiri Srain
Jiří Suchomel
Klaus Kaempf
Ladislav Slezak

[yast-devel] about the services module direction

tags

participants (5)