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 15:05:26 +0200
  • Message-id: <200908181505.26727.jsuchome@xxxxxxx>
On Tuesday 18 of August 2009 10:32:01 you wrote:
* 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

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.


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:

- 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


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 >