Mailinglist Archive: yast-devel (246 mails)

< Previous Next >
Re: [yast-devel] Re: about the services module direction
  • From: Jiří Suchomel <jsuchome@xxxxxxx>
  • Date: Tue, 18 Aug 2009 09:10:48 +0200
  • Message-id: <200908180910.48812.jsuchome@xxxxxxx>
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 <dmacvicar@xxxxxxx> [Aug 17. 2009 11:20]:
I think the design is escaping simplicity, I would propose this

- 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

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

rest-service: basically encapsulating YaPI calls

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

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:

- 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

- 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 Suchomel

SUSE LINUX, s.r.o. e-mail: jsuchome@xxxxxxx
Lihovarská 1060/12 tel: +420 284 028 960
190 00 Praha 9, Czech Republic
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >