@@ -52,28 +52,44 @@ Some of the daemons require certificates and CAs to work. They expect specific s
### Conveyor
The conveyor needs a delegated X509 user proxy and the necessary CA so that it can submit jobs to FTS. For the CA you have to add a `<releasename>-rucio-ca-bundle` secret. For the user proxy a cronjob can be setup to either generate it from a long proxy or directly delegate the user proxy to FTS. The cronjob uses the [fts-cron](https://github.com/rucio/containers/tree/master/fts-cron) container which expects different input secrets and has a different behaviour depending on the selected VO. The cronjob run every 6 hours. An example configuration looks like this:
The conveyor needs a delegated X509 user proxy and the necessary CA so that it can submit jobs to FTS. For the CA you have to add a `<releasename>-rucio-ca-bundle` secret. For the user proxy a cronjob can be setup to either generate it from a long proxy or directly delegate the user proxy to FTS. The cronjob uses the [fts-cron](https://github.com/rucio/containers/tree/master/fts-cron) container which expects different input secrets and has a different behaviour depending on the selected VO. When enabled, the cronjob runs once upon installation and then every 6 hours. An example configuration looks like this:
-`atlas` expects a long proxy as input secret (`<releasename>-longproxy`). It then creates a user proxy with the given VOMS extensions and with 96h lifetime and saves it as a cluster secret (`<releasename>-rucio-x509up`).
-`cms` expects a separate key and cert as input secrets (`<releasename>-fts-key` and `<releasename>-fts-cert`). It then creates a user proxy with the given VOMS extensions and with 96h lifetime and delegates it to the given FTS servers. Then saves it as a cluster secret (`<releasename>-rucio-x509up`).
-`atlas` expects a long proxy as input secret. It then creates a user proxy with the given VOMS extensions and with 96h lifetime and saves it as a cluster secret (`<releasename>-rucio-x509up`).
-`cms` expects a separate key and cert as input secrets. It then creates a user proxy with the given VOMS extensions and with 96h lifetime and delegates it to the given FTS servers. Then saves it as a cluster secret (`<releasename>-rucio-x509up`).
-`escape` expects a separate key and cert as input secrets, as well as a grid passphrase called. It then creates a user proxy with the given VOMS extensions and with 96h lifetime and delegates it to the given FTS servers. Then saves it as a cluster secret (`<releasename>-rucio-x509up`).
-`dteam` expects a long proxy like `atlas` and then creates, delegates and saves the user proxy like `cms`.
-`tutorial` expects a separate key and cert as input secrets like `cms` and then directly delegates to FTS. No proxy generation and `<releasename>-rucio-x509up` has to be manually created.
When the release is first installed the pods won't start since the necessary `<releasename>-rucio-x509up` secret hasn't been created by the cronjob, yet. In that case you can run the job once manually:
- Any other VO value will lead to the execution of the default script and expects a separate key and cert as input secrets. It then creates a user proxy with the given VOMS extensions and with 96h lifetime and delegates it to the given FTS servers. Then saves it as a cluster secret (`<releasename>-rucio-x509up`). Additionally a grid passphrase can be specified and saved in a dedicated secret.