Dne úterý 18 Srpen 2009 10:32:01 Klaus Kaempf napsal(a): > * 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.
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 :-) Jiri > > - 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) -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: [email protected] Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
