Mailinglist Archive: yast-devel (246 mails)

< Previous Next >
Re: [yast-devel] Re: about the services module direction
  • From: Jiri Srain <jsrain@xxxxxxx>
  • Date: Tue, 18 Aug 2009 17:42:54 +0200
  • Message-id: <200908181742.54807.jsrain@xxxxxxx>
Dne úterý 18 Srpen 2009 10:32:01 Klaus Kaempf napsal(a):
* 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

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.

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


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

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


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

< Previous Next >