COMMAND param1:val1 param2:val2 ... Thus a COMMAND hollowed by key:value header lines and a multiline body separated from header by an empty line and terminated by NUL. ^@
zypp-plugin-python
.
zypper in -C zypp-plugin-python
The plugin must define a method for each message it may receive from libzypp. Message header list and body are passed to the method as arguments.
#!/usr/bin/env python # # zypp plugin # import os import sys from zypp_plugin import Plugin class MyPlugin(Plugin): def SAMPLE( self, headers, body ): # called upon revieving a SAMPLE message ... if ( ok ): self.ack() else: self.error( { "aheader":"header value" }, "body\n(multiline text ok)" ) plugin = MyPlugin() plugin.main()
Two methods ack
and error
are available to send back a standard ACK
or ERROR
message. You may optionally pass header entries and a multiline body. For sending custom messages use answer
, which takes the command name as 1st argument, followed by optional header entries and a multiline body.
Plugin closes stdin
and exits when receiving a _DISCONNECT
message. Upon an ACK
response to _DISCONNECT
libzypp will not attempt to kill the script. An exit value different than 0
may be set via an 'exit'
header in ACK
.
def _DISCONNECT( self, headers, body ): sys.stding.close() self.ack( {'exit':'99'}, 'Famous last words.' )
Service plugins are used to provide a client a list of repositories from a central location where more complex logic is needed than a simple remote xml index accessible via http (in that case you can use Remote Services).
Service plugins are Stateless. When services are refreshed, ZYpp will call each plugin and the repository list will be taken from the output of the script in INI format (same as how they are stored in /etc/zypp/repos.d).
For our example:
# example plugin output # comments are ignored [repo1] name=Base repository summary=Standard repository baseurl=http://server.com/repo1 type=rpm-md # multiple repositories can be present in the output [repo2] ...
The repositories will be added on service refresh with the alias present in the output, prefixed by the service alias (in this case, the executable name).
ZYpp sees a repository whose url has the format:
plugin:foo?param1=val1¶m2=val2
ZYpp tries to executa a plugin named foo (in /usr/lib/zypp/plugins/urlresolver) and calla it with the following protocol:
RESOLVEURL param1:val1 param2:val2 ... ^@
The plugin answers:
RESOLVEDURL: header1:val1 header2:val2 ... http://realurl.com?opts=vals ^@
And this url is used instead.
plugin:lan
The script looks which distribution you have installed, and via SLP finds the right repositories in the lan and selects the update one and returns it url. But in addition, it adds a header with the update status that can be collected on the server side.
This type of plugin can be combined with service plugins, because a local service could return a list of repos like this:
[distro] name=Distribution repository baseurl=plugin:lan?repo=distro [update] name=Update repository baseurl=plugin:lan?repo=update
The plugins default location is obtained from zypp::ZConfig::pluginsPath()