3 \page zypp-services Services
5 \author Duncan Mac-Vicar P. <dmacvicar@suse.de>
7 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.
9 \section service-types Classes of services
11 There are two classes of services:
13 \subsection services-remote Remote Services
15 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.
17 By default, the remote services list is stored in the \ref /etc/zypp/services.d directory in standard INI files. Each file can contain more than one service.
19 The format is the following:
24 url=http://customers.maintenance.company.com/service
30 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.
31 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.
33 From the remote side, the service url needs to provide a repoindex.xml file with the repository list:
37 <repo url="http://foo.com/repo1" alias="a repository 1"/>
38 <repo url="http://foo.com/repo2" alias="a repository 2"/>
43 \subsection services-plugin Plugin Services
45 \ref plugin-services "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).
47 A plugin service is a program installed in /usr/lib/zypp/plugins/services.
49 Once a program called "foobar" is installed, listing services will show it:
53 # | Alias | Name | Enabled | Refresh | Type
54 ---+------------------+--------------+---------+---------+-------
55 1 | foobar | foobar | Yes | Yes | plugin
60 When this service is refreshed, the program will be executed and it will return
61 the list of repositories in the same .repo files format that can be found in
65 # output returned by the plugin
71 baseurl=http://download.opensuse.org//distribution/11.4/repo/oss
78 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.
80 The main disadvantage is that you have logic in the client side that in case of bugs or changes, needs to be updated.
82 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.
84 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 \ref plugin-url-resolver here.
86 \section service-refresh Refreshing services
88 Using zypper, you can refresh services by executing
94 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.
96 \section service-examples Example usecases
98 \subsection services-usecase-1 Usecase #1: The project with multiple repositories and layers
100 Imagine the following usecase (with this one I am using some real request from our KDE guys)
102 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.
104 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.
106 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.
108 \subsection services-usecase-2 Usecase #2: Update repositories based on the customer
110 This is actually where services where originated. Services were present in Novell ZenWorks. How it works?
112 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.
114 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.
116 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.
118 \subsection services-usecase-3 Usecase #3: Dynamic repository collections
120 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.
122 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.
124 \subsection services-usecase-4 Usecase #4: Collect openSUSE core repos in one service
126 Some people prefer to keep and maintain the distros core repos within one local service rather than managing the repos individually. Since version 14.21.0 libzypp supports a simple form of variable replacement within a repoindex.xml file, which makes this even easier.
128 To use a local RIS service create a directory /somewhere on your disk (or accessible via http, nfs, etc.) and create the file
129 ./repo/repoindex.xml inside. A repoindex.xml for openSUSE Leap 15.1 might look like this:
133 disturl="https://download.opensuse.org"
137 sourceenable="false">
139 <repo url="%{disturl}/distribution/%{distsub}%{distver}/repo/oss"
141 name="%{alias} (%{distver})"
145 <repo url="%{disturl}/distribution/%{distsub}%{distver}/repo/non-oss"
147 name="%{alias} (%{distver})"
152 <repo url="%{disturl}/update/%{distsub}%{distver}/oss"
154 name="%{alias} (%{distver})"
158 <repo url="%{disturl}/update/%{distsub}%{distver}/non-oss"
159 alias="upadte-non-oss"
160 name="%{alias} (%{distver})"
165 <repo url="%{disturl}/debug/distribution/%{distsub}%{distver}/repo/oss"
167 name="%{alias} (%{distver})"
168 enabled="%{debugenable}"
171 <repo url="%{disturl}/debug/distribution/%{distsub}%{distver}/repo/oss"
172 alias="debug-non-oss"
173 name="%{alias} (%{distver})"
174 enabled="%{debugenable}"
178 <repo url="%{disturl}/source/distribution/%{distsub}%{distver}/repo/oss"
180 name="%{alias} (%{distver})"
181 enabled="%{sourceenable}"
184 <repo url="%{disturl}/source/distribution/%{distsub}%{distver}/repo/non-oss"
185 alias="source-non-oss"
186 name="%{alias} (%{distver})"
187 enabled="%{sourceenable}"
192 %{VAR} always refers to the value defined in the <tt>repoindex</tt> tag (reserved names are 'ttl' and 'alias'). %{alias} is available within a <tt>repo</tt> tag after the alias was defined there.
194 Given the file is located at /somewhere/repo/repoindex.xml, add the service by:
196 zypper sa /somewhere openSUSE
199 Manually refresh the service (incl. its repos) with:
204 Refreshing the service will evaluate the repoindex.xml and adjust the Services repos accordingly. The repos alias will be prefixed by the service name:
207 > # | Alias | Name | Enabled | ... | Refresh
208 > ---+-------------------------+-----------------------+---------+-...-+--------
209 > 9 | openSUSE:debug-non-oss | debug-non-oss (15.1) | No | ... | ----
210 > 10 | openSUSE:debug-oss | debug-oss (15.1) | No | ... | ----
211 > 11 | openSUSE:repo-non-oss | repo-non-oss (15.1) | Yes | ... | Yes
212 > 12 | openSUSE:repo-oss | repo-oss (15.1) | Yes | ... | Yes
213 > 13 | openSUSE:source-non-oss | source-non-oss (15.1) | No | ... | ----
214 > 14 | openSUSE:source-oss | source-oss (15.1) | No | ... | ----
215 > 15 | openSUSE:upadte-non-oss | upadte-non-oss (15.1) | Yes | ... | Yes
216 > 16 | openSUSE:update-oss | update-oss (15.1) | Yes | ... | Yes
219 After editing the repoindex.xml you must manually refresh the service to takeover the changes, or you turn on autorefresh for the service (depends on how often you change the content):
221 zypper ms -r openSUSE
224 Rather than hardcoding the <tt>distver="15.1"</tt>, you can also use a repo variable like <tt>distver="${releasever}"</tt>.
226 \section service-impl Developers: Implementation
228 Services are implemented in the following classes:
230 - \ref zypp::repo::ServiceType (Service types enumeration)
231 - \ref zypp::parser::ServiceFileReader (.service file parser)
232 - \ref zypp::ServiceInfo Information about a service (.service file data)
233 - \ref zypp::repo::PluginServices (Services as plugins)
234 - \ref zypp::parser::RepoindexFileReader (NU and RIS remote service index XML parser)
235 - \ref zypp::repo::ServiceRepos (Repositories in a service)