Mailinglist Archive: yast-devel (246 mails)

< Previous Next >
Re: [yast-devel] Re: about the services module direction
  • From: Klaus Kaempf <kkaempf@xxxxxxx>
  • Date: Tue, 18 Aug 2009 10:32:01 +0200
  • Message-id: <20090818083201.GA4949@xxxxxxxxxxxxx>
* Jiří Suchomel <jsuchome@xxxxxxx> [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

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:

- 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

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 ;-)

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

To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >