Introduction

Propagation = the distribution of changes made in the system to particular destinations

i.e.; a simple action such as adding a new Virtual Organization (VO) member by the VO manager has significant consequences for the user at all VO's resources - creating /home directories, setting access rights, adding a line in password, etc..

Propagation transports new states to destinations and runs pre-installed machine scripts to make all necessary changes (e.g., configure services, create directories, set access rights).

There are several advantages to propagating a new state. Sometimes, the destination must be reinstalled, or new hardware is added to the infrastructure. Its inner state might be lost or empty, and only one update from Perun, can provide it with a new, up-to-date state.

As a result, destinations maintain the state until Perun sends the new one. The destination can operate independently even when Perun system is down.

We provide a package of open-source ready-to-run bash scripts that run on destinations. Administrators can edit, customize and replace them with their own scripts to have full control over what Perun does in their destination.

Propagation workflow

Open

Perun propagation

1. Change detection: When a VO manager adds a new member, this change is logged in the Audit log. The Engine reads this log, detects the change, and processes it.

2. State Generation (GEN scripts): The Engine calls GEN scripts to generate a completely new state for the destination, including the current change (e.g., adding a new line in the password file).

3. State Transmission (SEND Script): The SEND script takes this new state and sends it to the destination via SSH (the most common method) or other channels (e.g., email or Jabber).

4. State Application (Slave Script): The SEND script triggers the SLAVE script stored in the destination. The SLAVE script (usually uses root access, but it is not necessary), identifies the type of service and checks the versions of the service script. If the versions match, the SLAVE script configures the particular service at the destination.

5. Customization (Pre- and Post-Scripts): To meet specific requirements (e.g., home directory settings, script paths), pre- and post-scripts can be used. These optional scripts run before and after the SLAVE script to add additional functionality.

6. Status Reporting: After completing the process, the SLAVE script returns the status to the SEND script, which reports it back to the IdM system. Return codes from the destination are checked regularly, and if an error occurs, repropagation can be triggered.