Introduction

Speaking about propagation, we mean the distribution of changes made in the system to particular destinations.

For example, a simple action such as adding a new VO member by the VO manager has large consequences such as creating /home directories, setting access rights, adding a line in password... etc. for the user at all VO's resources.

Propagation does not only transport completely new states to destinations but also runs pre-installed scripts on machines to make all necessary changes (configure services, create directories, set access rights...).

Propagation of a new state has several significant advantages. Sometimes there is a situation when the destination must be reinstalled or new hardware is added to the infrastructure. Its inner state is lost or empty, but only one update from Perun, gives it a new up-to-date state.

Consequently, destinations keep the state until the new one is sent by Perun. The destination can run on its own also when Perun system does not work.

A package of open-source bash scripts to run on destinations is delivered with Perun installation. They are fully functional and ready to run, but when an administrator wants, he could edit or customize them, or even more, replace them with his scripts. He has control over what Perun does in the destination fully in his hands.

Propagation workflow

Open

Perun propagation

Considering action when the VO manager has added a new member to his VO, information about this change goes to the Audit log. This log is read by the Engine, so a change influencing resources is detected and processed.

First, the engine calls GEN scripts. These GEN scripts generate a completely new state of the destination including the current change (e.g. new line in password).

As a second step, the engine calls the SEND script. This script takes a new state generated in the first step by the GEN script and sends it to a destination via SSH (most common way) or any other channel (for example email or jabber ).

As a third step, the SEND script triggers the SLAVE script "perun" stored in the destination. Perun usually uses root access to run the SLAVE script in a destination, but often Perun simply does not need it. It can run as any user, but the user has to have proper rights to run all associated SLAVE scripts.

SLAVE script identifies a type of service and checks versions of the service script. This control is important due to new versions of the SLAVE scripts. If the version of the service script matches the version of the SLAVE script, then, a predefined SLAVE script configuring a particular service in destination is run.

Sometimes destinations have specific requirements (e.g. settings of home directories, paths to scripts, etc.). To fulfill these requirements without change of slave script, pre- and post-scripts are used. They can complement the functionality of slave scripts.

When the slave script starts, it searches for pre- script in the service directory and runs it before its functionality. The same process runs after the slave script execution, the post_ scripts are launched. Usage of the script is optional, but it can be utilized by administrators, who want to add a new functionality to our Perun scripts. Pre- and post-scripts simply bring a higher level of customization.

After finishing the whole process, as a response the SLAVE script returns the status to the SEND script, which reports it back to the Perun system.

All return codes obtained from the destination are checked on a regular basis (e.g. once per hour) and if an error code occurs, repropagation can be triggered.