* Jiří Suchomel <[email protected]> [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: [email protected] For additional commands, e-mail: [email protected]
