YaST/Research/YaaS

From openSUSE

YaST as a Service

Description

Define a service-oriented architecture for YaST and refactor modules toward this architecture. This affects a couple of other research areas, namely:

• Make YaST Independent of YCP
• Using CIM from YaST modules
• YaST DBus Service
• YaST PackageKit Service
• YaST Web User Interface

The basic elements of such an architecture are

• separation of front-end (UI) from back-end (execution engine)
  • language-agnostic protocol to enforce the separation
    • ideally a network protocol to facilitate remote execution
  • ability to run front-end as user
  • shields back-end implementation
    • allows to selectively refactor elements of backend
• Policy layer to control execution of backend
  • allows to grant users root-rights without revealing the root password
  • allows to log requests (for auditing/compliance)

Picture of the architecture

Concrete implementation proposal

• Use a REST-style protocol.
• Have the API service running with minimal rights (aka 'nobody').
• Use PolicyKit as the policy engine, runs as 'root'.
• The execution engine is called through PolicyKit, runs as 'user' or 'root' depending on the task.

Picture of the implementation proposal

Relevance to YaST/openSUSE

This will define the next-gen architecture for YaST.
It enforces a strict and language-agnostic frontend/backend separation using standardized protocols.

The policy layer allows 'role based' access to YaST functionality.

Goal

Implement an end-to-end solution with the new architecture.

Select one (a few) specific YaST module(s) to be converted to this architecture. Learn conversion rules and obstacles on the way.

Expected result is a report showing the feasibility of the architecture and giving guidelines how to refactor more of YaST towards it.

Scope

Key are the architectural elements described on top of this page.

The proposed implementation picks up already existing pieces and knowledge. It does not dictate the final architecture. Most important is to 'learn along the ways' and to find and document 'best practices'.

The result is to be applied to ongoing development and refactoring efforts in YaST. This does *not* imply to rewrite YaST modules to a service-oriented architecture for Code11 but to prepare the code for this.

Related technologies

• REST architecture style
  • A brief introduction to REST
  • Building web services the REST way
  • Common REST design patterns
  • How to create a REST protocol
  • How to create a REST-style protocol
  • Addressing doubts about REST
  • Common REST mistakes
  • collection of links
• HTTP protocol
  • HTTP - Hypertext Transfer Protocol Overview
• D-Bus
  • dbus.freedesktop.org
  • D-Bus tutorial
• PolicyKit
  • Wikipedia entry
  • PolicyKit ref manual
  • Theory of operation

Typical use case

Developer Max is a Perl-bigot, he thinks, breathes, dreams and lives in Perl. He has written a nice Perl library to control virtual machines.
His colleague Moritz is repelled by Perls 'code junk' as he calls it. Moritz uses Ruby because its object-oriented from the ground up and he just loves the clean syntax. Moritz task is to implement the command line client to Max library.

Mr. Busch, their boss, wants this to be implemented in the YaST framework. Following the ITIL practice of separation of duties this needs to be controlled by a Policy engine.

The YaST architecture makes Max and Moritz work very easy. They agree on the REST-style API and both happily work within their preferred language and work environment. Dr Lämpel, the policy expert of the team, meanwhile designs and implements PolicyKit rules. Mrs Bolte, everyone calls here 'Miss QA', has an extensive Erlang test harness to be run against the new implementation.

The architectural concept also eases the work of the documenter Mr Böck. He not only documents how to use the command line client but also writes example code in Python using the REST API, enabling ISVs in using the new functionality.

Required knowledge and skill level

Complexity: mid to high Required skills

• designing a REST-like API
• accessing D-Bus
• writing PolicyKit rules
• implementing a D-Bus service

Dev. environment/equipment

None.

Participants

If you wish to participate, add yourself here (your user page link, hompe, or e-mail or similar).

• kkaempf at suse.de
• cschum at suse.de
• garrett at suse.de
• shaas at suse.de
• schubi at suse.de
• ma at suse.de

Current Status

The current status of the project.

• how far the project is
• list of open issues
• link to the implementation description
• link to code repository

Division of work and schedule

Use cases

• configure root password
• user management
• network management
• apply updates
• set time, timezone, ntp
• viewing log files

Architecture

• pluggable
• introspection

We are trying to solve "set time,timezone"

Team 1

• split YaST-timezone, YaST-ntp-client into frontend/backend
• research required API
• research current API

Team 2 leader cschum

REST API

• client
• server/listener

Team 3 leader jsrain

server/listener interface to DBUS

Team 4 leader mvidner

YaST interface to DBUS

PolicyKit team merged with Team 4

References

• Building Web Services the REST Way (What is REST actually)
• How to create a REST protocol (Tips 'n Tricks)
• REST bookmarks (collection of references)