- Generated by
1.8.5
|
libzypp
13.10.6
|
Services provide a list of repositories. So when the service is refreshed, the repositories specified by the service service is synced with the local repository list.
There are two classes of services:
Remote services are a subscription to a remote server, that provide a list of repositories that will be synced with the previous list of repositories for the same service.
By default, the remote services list is stored in the /etc/zypp/services.d directory in standard INI files. Each file can contain more than one service.
The format is the following:
[servicealias] name=My Service url=http://customers.maintenance.company.com/service enabled=true autorefresh=true type=nu
The type "nu" stands for Novell Update, which gives a customer the repositories it is entitled to access. The type "ris" is an extended version of the "nu" type. Additionally, the file could contain "repostoenable" and "repostodisable" entries, which contain a list of repository aliases to enable or disable on the next refresh. This line is modified by other programs to force enabling or disabling a certain repository.
From the remote side, the service url needs to provide a repoindex.xml file with the repository list:
<repoindex> <repo url="http://foo.com/repo1" alias="a repository 1"/> <repo url="http://foo.com/repo2" alias="a repository 2"/> ... </repoindex>
Plugin services are simple scripts that return a list of repositories. They are installed locally in the system using packages. For each script installed ZYpp will “see” a service of type “plugin”. When you refresh the service, the repositories this script returns as output will be added (or removed and kept in sync if they change afterwards).
A plugin service is a program installed in /usr/lib/zypp/plugins/services.
Once a program called "foobar" is installed, listing services will show it:
> zypper ls # | Alias | Name | Enabled | Refresh | Type ---+------------------+--------------+---------+---------+------- 1 | foobar | foobar | Yes | Yes | plugin ... ...
When this service is refreshed, the program will be executed and it will return the list of repositories in the same .repo files format that can be found in /etc/zypp/repos.d:
# output returned by the plugin [repo-oss] name=oss enabled=1 autorefresh=0 baseurl=http://download.opensuse.org//distribution/11.4/repo/oss type=yast2 keeppackages=0 ...
As you can see, the main advantage of plugin services is that they can read information from the client and calculate the repository list from there. Nothing prevents a plugin service to still interact with a server to get the repository list.
The main disadvantage is that you have logic in the client side that in case of bugs or changes, needs to be updated.
Spacewalk integration is implemented using plugin services. The plugin talks XML-RPC to the server and asks for the list of channels the system is subscribed to. The plugin needs to read the server address and perform the login.
However, the spacewalk plugin service does have an extra indirection, as the repository list returned are not plain urls, but urls of the type plugin:$name?params, which use the urlresolver plugin to get the real url. This is not necessary, and here it is done because it allows to add custom headers to the HTTP requests. You can read more about urlresolver plugins Url Resolver plugins here.
Using zypper, you can refresh services by executing
zypper refs
The repositories that are listed in the service will be added, using the reposotiy alias specified in the service index prefixed by the service alias: e.g. "myservice:myrepository". Repositories that vanished from the service will be automatically removed.
Imagine the following usecase (with this one I am using some real request from our KDE guys)
The build service provides a KDE4 repository. Which in turn requires the Qt4 repository, because is built on openSUSE 11.0 + the new Qt4 repo.
When looking at this problem, repository dependencies is what comes to head in the first place. But forget about them. If package dependencies are complicated right now, imagine adding a secondary (and duplicated) layer of information. Packages already know their dependencies.
Now imagine our KDE guys can provide an URL, which you add to zypper. And this url returns a dynamic list of repositories. And zypper adds and remove repositories based on the information returned by this url on every refresh.
This is actually where services where originated. Services were present in Novell ZenWorks. How it works?
The service url nu.novell.com is added to the system. But in this url also a customer id is present as a http username. When you registered, Novell knows the subscription and products this system is linked to and what entitlements the customer has. The service can then return a dynamic list of repositories based on the customer preferences, products and entitlements. The customer does not need to keep them manually in sync.
Now that we don’t have Zenworks in the base system, we still want this cool functionality for our customers, therefore ZYpp now implements services natively.
Technically, this even allows us to offer hotfixes to L3 supported customers on the fly: the system is marked on the server side as being hotfixed, and an extra temporary repository with the PTF (Problem Temporary Fix) packages is added to this system list of repositories.
You are a build service user, and you have an account, and of course you have a list of watched projects you are interested to. What if you could keep your system repositores in sync with your watched project list.
Or what if the build service could offer a service based on keywords or other data: like http://build.opensuse.org/services/mostpopular/repo/repoindex.xml would contain dynamically the 15 most popular repositories. You add that service, and then ZYpp does the work for you of adding new popular repositories, and remove the old ones.
Services are implemented in the following classes:
1.8.5