* Jiří Suchomel <jsuchome@suse.cz> [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