On Tuesday 18 of August 2009 08:01:58 Jiri Srain wrote:
> Dne pondělí 17 Srpen 2009 16:58:36 Jiří Suchomel napsal(a):
> > On Monday 17 of August 2009 16:20:22 Klaus Kaempf wrote:
> > > * Duncan Mac-Vicar Prett <[email protected]> [Aug 17. 2009 11:20]:
> > > > I think the design is escaping simplicity, I would propose this
> > > > approach:
> > > >
> > > > - Having _one_ and only one services plugin in the service side.
> > > >
> > > > The implementation of this REST API would access the init.d scripts,
> > > > and additionally would do the following things:
> > > > - also read another directory with yml files where and recognize
> > > > custom services there. The vendor provides the variables in those
> > > > yml, and the services plugin knows how to handle those.
> > >
> > > Yes, thats the most desirable approach.
> >
> > Well, so could I return to the rest-API service plugin that was using
> > YaPI, and was able to call /etc/init.d scripts as well as user customized
> > ones?
> >
> > That means, the original approach of services, written by schubi and
> > mvidner would be lost with some of its features that my simpler approach
> > did not have.
> >
> > I summarize again my original approach:
> >
> > YaPI layer: provides call to show and manipulate given services, be it
> > from /etc/init.d or custom service defined in
> > /etc/YaST2/webyast_services.yml
> >
> > rest-service: basically encapsulating YaPI calls
> >
> > web-client: showing the services provided by rest API (= those found in
> > webyast_services.yml)
> >
> > Now there could be 2 different UI parts, using the same rest service, one
> > for /etc/init.d/ services (substituting current 'services' plugin), and
> > the other for one (or any number) user defined service.
>
> Just remember that at current stage, we only concentrate on the 'single
> service' web-client plug-in.
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"?)
for vendor specific service. Both would use the same "services" REST API,
with "index", "show" and "update" paths.
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
- 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
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)
SERVICES::Execute (string name, string action) - call the given command
(start/stop/restart/...) on given service
- 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.
- 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?
Jiri
--
Jiri Suchomel
SUSE LINUX, s.r.o. e-mail: [email protected]
Lihovarská 1060/12 tel: +420 284 028 960
190 00 Praha 9, Czech Republic http://www.suse.cz
--
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
