- Vue d'ensemble (Overview)
- Prérequis
- Installation
- Questions et réponses : modèles de déploiement
- Configuration des machines
- Configurer l'équilibreur de charge
- Configuration du DNS
- Configuration de Microsoft SQL Server
- Configuration des certificats
- Installation de production en ligne multi-nœuds compatible haute disponibilité
- Installation de production hors ligne multi-nœuds compatible haute disponibilité
- Téléchargement des packages d'installation
- install-uipath.sh parameters
- Activation du module complémentaire Redis High Availability Add-on pour le cluster
- Fichier de configuration de Document Understanding
- Ajout d'un nœud d'agent dédié avec prise en charge GPU
- Connexion de l'application Task Mining
- Ajout d'un nœud d'agent dédié pour Task Mining
- Post-installation
- Accéder à Automation Suite
- Gestion des certificats
- Redimensionner le PVC
- Mise à jour des chaînes de connexion SQL
- Administration du cluster
- Gestion des produits
- Gérer le cluster dans ArgoCD
- Configuration du serveur NFS externe
- Automatisé : activation de la sauvegarde sur le cluster
- Automatisé : Désactivation de la sauvegarde sur le cluster
- Automatisé, en ligne : restauration du cluster
- Manuel, hors ligne : Restauration du cluster
- Manuel : Activation de la sauvegarde sur le cluster
- Manuel : Activation de la sauvegarde sur le cluster
- Manuel en ligne : Restauration du cluster
- Manuel, hors ligne : Restauration du cluster
- Configuration supplémentaire
- Migration d'un magasin d'objets d'un volume persistant vers des disques bruts
- Surveillance et alerte
- Migration et mise à niveau
- Automatisée : mise à niveau en ligne
- Automatisée : mise à niveau hors ligne
- Manuel : mise à niveau en ligne
- Manuel : mise à niveau hors ligne
- Annulation en cas d'erreur
- Migration d'un disque physique Longhorn vers LVM
- Migration de Canal vers Cilium CNI
- Rétrogradation de Ceph de la version 16.2.6 à la version 15.2.9
- Options de migration :
- Étape 1 : Déplacement des données d'organisation Identity d'installation autonome vers Automation Suite
- Étape 2 : Restauration de la base de données du produit autonome
- Étape 3 : Sauvegarder la base de données de la plate-forme dans Automation Suite
- Étape 4 : Fusion des organisations dans Automation Suite
- Étape 5 : Mise à jour des chaînes de connexion du produit migré
- Étape 6 : migration de la version autonome d’Insights
- Étape 7 : suppression du locataire par défaut
- B) Migration à locataire unique
- Configuration spécifique au produit
- Bonnes pratiques et maintenance
- Résolution des problèmes
- Comment résoudre les problèmes des services lors de l'installation
- Comment désinstaller le cluster
- Comment nettoyer les artefacts hors ligne pour améliorer l'espace disque
- Comment effacer les données Redis
- Comment activer la journalisation Istio
- Comment nettoyer manuellement les journaux
- Comment nettoyer les anciens journaux stockés dans le compartiment sf-logs
- Comment désactiver les journaux de diffusion pour AI Center
- Comment déboguer les installations d'Automation Suite ayant échoué
- Comment supprimer des images de l’ancien programme d’installation après la mise à niveau
- Comment nettoyer automatiquement les instantanés Longhorn
- Comment désactiver le déchargement de la somme de contrôle txt
- Comment résoudre les chiffrements faibles dans TLS 1.2
- Impossible d'exécuter une installation hors ligne sur le système d'exploitation RHEL 8.4
- Erreur lors du téléchargement du bundle
- L'installation hors ligne échoue en raison d'un fichier binaire manquant
- Problème de certificat dans l'installation hors ligne
- La première installation échoue lors de la configuration de Longhorn
- Erreur de validation de la chaîne de connexion SQL
- Échec de la vérification des prérequis pour le module selinux iscsid
- Disque Azure non marqué comme SSD
- Échec après la mise à jour du certificat
- Automation Suite ne fonctionne pas après la mise à niveau du système d'exploitation
- Automation Suite requiert que Backlog_wait_time soit défini sur 1
- Volume impossible à monter car il n'est pas prêt pour les charges de travail
- RKE2 échoue lors de l'installation et de la mise à niveau
- Échec du chargement ou du téléchargement des données dans l'objectstore
- Le redimensionnement de la PVC ne répare pas Ceph
- Échec du redimensionnement du PVC objectstore
- Rook Ceph ou pod Looker bloqué dans l'état Init
- Erreur de pièce jointe du volume Ensembles d'états.
- Échec de la création de volumes persistants
- Correctif de récupération du stockage
- La sauvegarde a échoué en raison de l’erreur TropInstantanés (TooManySnapshots)
- Toutes les répliques Longhorn sont défaillantes
- Définition d'un délai d'expiration pour les portails de gestion
- Mettre à jour les connexions du répertoire sous-jacent
- Impossible de se connecter après la migration
- kinit : Impossible de trouver le KDC pour le domaine <AD Domain> lors de l'obtention des informations d'identification initiales
- Kinit : Keytab ne contient aucune clé appropriée pour *** lors de l'obtention des informations d'identification initiales
- L'opération GSSAPI a échoué en raison de l'erreur suivante : un code d'état non valide a été fourni (les informations d'identification du client ont été révoquées).
- Alarme reçue pour l'échec de la tâche Kerberos-tgt-update
- Fournisseur SSPI : serveur introuvable dans la base de données Kerberos
- La connexion a échoué pour l'utilisateur <ADDOMAIN><aduser>.Raison : Le compte est désactivé.
- Échec de connexion à ArgoCD
- Impossible d'obtenir l'image du bac à sable
- Les pods ne s'affichent pas dans l'interface utilisateur ArgoCD
- Échec de la sonde Redis
- Le serveur RKE2 ne démarre pas
- Secret introuvable dans l'espace de noms UiPath
- Après l'installation initiale, l'application ArgoCD est passée à l'état Progression (Progressing)
- Pods MongoDB en mode CrashLoopBackOff ou enregistrement PVC en attente après suppression
- INCOHÉRENCE INATTENDUE ; EXÉCUTER fsck MANUELLEMENT
- MongoDB ou applications métier dégradées après la restauration du cluster
- L’opérateur d’auto-guérison et le référentiel Sf-k8-utils manquants
- Services défectueux après la restauration ou la restauration du cluster
- Le pod RabbitMQ est bloqué dans CrashLoopBackOff
- Prometheus en état CrashloopBackoff avec erreur de mémoire insuffisante (OOM)
- Métriques Ceph-rook manquantes dans les tableaux de bord de surveillance
- Les pods ne peuvent pas communiquer avec le nom de domaine complet dans un environnement proxy
- Document Understanding n'est pas affiché sur la barre de gauche d'Automation Suite
- État Échec (Failed) lors de la création d'une session de labellisation des données
- État Échec (Failed) lors de la tentative de déploiement d'une compétence ML
- La tâche de migration échoue dans ArgoCD
- La reconnaissance de l'écriture manuscrite avec l'Extracteur de formulaires intelligents (Intelligent Form Extractor) ne fonctionne pas
- Utilisation de l'outil de diagnostic d'Automation Suite
- Utilisation du pack d'assistance Automation Suite
- Explorer les journaux

Guide d'installation d'Automation Suite
Gestion des certificats
Le bundle d'installation fournit un outil de gestion de cluster qui vous permet de mettre à jour les certificats après l'installation. Pour accéder à l'outil, accédez à l'emplacement du bundle d'installation :
cd /opt/UiPathAutomationSuite/
cd /opt/UiPathAutomationSuite/
Pour générer la CSR et la clé privée, exécutez la commande suivante :
# copy the machine openssl configuration locally
cp /etc/pki/tls/openssl.cnf ./openssl.tmp.cnf
# Replace the [AUTOMATION_SUITE_FQDN] value. For example, "automationsuite.corp.com"
AS_FQDN=[AUTOMATION_SUITE_FQDN]
cat >> ./openssl.tmp.cnf <<EOF
[SAN]
subjectAltName=DNS:$AS_FQDN,DNS:alm.$AS_FQDN,DNS:monitoring.$AS_FQDN,DNS:registry.$AS_FQDN,DNS:objectstore.$AS_FQDN,DNS:insights.$AS_FQDN
EOF
# create the certificate request
openssl req -new -sha256 -newkey rsa:2048 -nodes -keyout server.key -subj "/C=xx/ST=xx/O=xx/OU=xx/CN=$AS_FQDN" -reqexts SAN -config openssl.tmp.cnf -out ${AS_FQDN}.csr
# copy the machine openssl configuration locally
cp /etc/pki/tls/openssl.cnf ./openssl.tmp.cnf
# Replace the [AUTOMATION_SUITE_FQDN] value. For example, "automationsuite.corp.com"
AS_FQDN=[AUTOMATION_SUITE_FQDN]
cat >> ./openssl.tmp.cnf <<EOF
[SAN]
subjectAltName=DNS:$AS_FQDN,DNS:alm.$AS_FQDN,DNS:monitoring.$AS_FQDN,DNS:registry.$AS_FQDN,DNS:objectstore.$AS_FQDN,DNS:insights.$AS_FQDN
EOF
# create the certificate request
openssl req -new -sha256 -newkey rsa:2048 -nodes -keyout server.key -subj "/C=xx/ST=xx/O=xx/OU=xx/CN=$AS_FQDN" -reqexts SAN -config openssl.tmp.cnf -out ${AS_FQDN}.csr
Votre équipe informatique utilise les valeurs obtenues pour générer un certificat signé. La clé privée générée reste locale.
Pour afficher plus d'informations sur les certificats de serveur, exécutez la commande suivante :
sudo ./configureUiPathAS.sh tls-cert --help
sudo ./configureUiPathAS.sh tls-cert --help
Sortie :
************************************************************************************
Manage cluster tls and server certificate
Usage:
configureUiPathAS.sh tls-cert [command]
configureUiPathAS.sh tls-cert [flags]
Available Commands:
update Update the tls / server certificate
get Get the tls / server certificate
Flags:
-h|--help Display help
************************************************************************************
************************************************************************************
Manage cluster tls and server certificate
Usage:
configureUiPathAS.sh tls-cert [command]
configureUiPathAS.sh tls-cert [flags]
Available Commands:
update Update the tls / server certificate
get Get the tls / server certificate
Flags:
-h|--help Display help
************************************************************************************
./configureUiPathAS.sh tls-cert
.
Installation en ligne : Comment trouver le certificat du serveur
istio-ingressgateway-certs
dans l'espace de noms istio-system
.
Consultez les fichiers de certificat dans la liste suivante :
- Le certificat TLS du serveur est stocké en tant que
tls.crt
- Clé privée TLS du serveur en tant que
tls.key
- Le bundle CA est stocké en tant que
ca.crt
Vous pouvez vérifier les secrets à l'aide de la commande suivante :
kubectl -n istio-system get secrets istio-ingressgateway-certs -o yaml
kubectl -n istio-system get secrets istio-ingressgateway-certs -o yaml
Les certificats sont également stockés dans l’espace de noms UiPath. Cela s’applique à tous les produits UiPath® qui ont besoin d’informations de certificat afin d’approuver les appels entrants. Pour plus de détails, consultez la section Comprendre l’architecture de conteneur liée aux certificats.
Installation hors ligne : comment trouver le certificat du serveur
rootCA.crt
et tls.crt
: ArgoCD et le registre Docker. Les certificats sont ensuite stockés dans les espaces de noms Docker et ArgoCD.
Vous pouvez vérifier les secrets à l'aide de la commande suivante :
# For docker registry
kubectl -n docker-registry get secrets docker-registry-tls -o yaml
# For Argocd
argocd login alm.cluster_fqnd --username argocd_username --password argocd_password
argocd cert list --cert-type https
# For docker registry
kubectl -n docker-registry get secrets docker-registry-tls -o yaml
# For Argocd
argocd login alm.cluster_fqnd --username argocd_username --password argocd_password
argocd cert list --cert-type https
Comment mettre à jour les certificats de serveur
Pour déchiffrer la clé de certificat, exécutez la commande suivante :
# replace /path/to/encrypted/cert/key to absolute file path of key
# replace /path/to/decrypt/cert/key to store decrypt key
# Once prompted, please entry the passphrase or password to decrypt the key
openssl rsa -in /path/to/encrypted/cert/key -out /path/to/decrypt/cert/key
# replace /path/to/encrypted/cert/key to absolute file path of key
# replace /path/to/decrypt/cert/key to store decrypt key
# Once prompted, please entry the passphrase or password to decrypt the key
openssl rsa -in /path/to/encrypted/cert/key -out /path/to/decrypt/cert/key
configureUiPathAS.sh
pour mettre à jour le certificat comme indiqué ci-dessous. Vous avez besoin du chemin d'accès à chacun des trois fichiers de certificat. Tout le fichier de certificat doit être au format PEM
.
- Ensemble de l'autorité de certification (Certificate Authority Bundle) : ce bundle ne doit contenir que les certificats de chaîne utilisés pour signer le certificat du serveur TLS. La limite de la chaîne est de neuf certificats.
- Certificat de serveur - Certificat de serveur public
-
Clé privée - Clé privée pour le certificat du serveur
sudo ./configureUiPathAS.sh tls-cert update --ca-cert-file /path/to/cacert --tls-cert-file /path/to/tlscert --tls-key-file /path/to/tlskey
sudo ./configureUiPathAS.sh tls-cert update --ca-cert-file /path/to/cacert --tls-cert-file /path/to/tlscert --tls-key-file /path/to/tlskey
/directory/path/to/store/certificate
.
Pour imprimer les fichiers de certificat, exécutez la commande suivante en spécifiant le répertoire dans lequel les certificats sont stockés.
sudo ./configureUiPathAS.sh tls-cert get --outpath /directory/path/to/store/certificate
sudo ./configureUiPathAS.sh tls-cert get --outpath /directory/path/to/store/certificate
Vous êtes responsable de vous assurer que les certificats générés sont approuvés.
Pour ajouter le certificat au magasin approuvé de la machine virtuelle hôte, exécutez les commandes suivantes sur tous les nœuds du cluster :
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust
Pour afficher plus d'informations sur les certificats CA supplémentaires, exécutez la commande suivante :
./configureUiPathAS.sh additional-ca-certs --help
./configureUiPathAS.sh additional-ca-certs --help
Sortie :
***************************************************************************************
Manage additional CA certificates, this can be used to add sql server CA
Usage:
configureUiPathAS.sh additional-ca-certs [command]
configureUiPathAS.sh additional-ca-certs [flags]
Available Commands:
update Update the additional trusted CA certificates.
get Get the additional trusted CA certificates
Flags:
-h|--help Display help
***************************************************************************************
***************************************************************************************
Manage additional CA certificates, this can be used to add sql server CA
Usage:
configureUiPathAS.sh additional-ca-certs [command]
configureUiPathAS.sh additional-ca-certs [flags]
Available Commands:
update Update the additional trusted CA certificates.
get Get the additional trusted CA certificates
Flags:
-h|--help Display help
***************************************************************************************
./configureUiPathAS.sh additional-ca-certs
.
Cette commande vous aide à mettre à jour ou à remplacer les certificats CA configurés existants.
./configureUiPathAS.sh additional-ca-certs update --ca-cert-file /path/to/ca/certs
./configureUiPathAS.sh additional-ca-certs update --ca-cert-file /path/to/ca/certs
--replace
à la fin.
.pem
valide et peut contenir plusieurs certificats.
Pour télécharger les certificats CA déjà configurés, exécutez la commande suivante :
./configureUiPathAS.sh additional-ca-certs get --outpath /path/to/download/certs
./configureUiPathAS.sh additional-ca-certs get --outpath /path/to/download/certs
Vous êtes responsable de vous assurer que les certificats générés sont approuvés.
Pour ajouter le certificat au magasin approuvé de la machine virtuelle hôte, exécutez les commandes suivantes sur tous les nœuds du cluster :
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust
Pour afficher plus d'informations sur les certificats de signature de jeton d'identité, exécutez la commande suivante :
sudo ./configureUiPathAS.sh identity token-cert --help
sudo ./configureUiPathAS.sh identity token-cert --help
Sortie :
************************************************************************************
Manage Identity token signing certificate
Usage:
configureUiPathAS.sh identity token-cert [command]
configureUiPathAS.sh identity token-cert [flags]
Available Commands:
update Update secondary certificate to signing
the authentication token
rotate Switch secondary certificate as a primary
token signing certificate
get Get token signing certificate
Flags:
-h|--help Display help
************************************************************************************
************************************************************************************
Manage Identity token signing certificate
Usage:
configureUiPathAS.sh identity token-cert [command]
configureUiPathAS.sh identity token-cert [flags]
Available Commands:
update Update secondary certificate to signing
the authentication token
rotate Switch secondary certificate as a primary
token signing certificate
get Get token signing certificate
Flags:
-h|--help Display help
************************************************************************************
./configureUiPathAS.sh identity token-cert
.
.pfx
.
--password
se trouve entre guillemets simples. Par exemple : --password 'CertificatePassword!@#'
.
sudo ./configureUiPathAS.sh identity token-cert update --cert-file-path /path/to/cert --password '<cert_pass>'
sudo ./configureUiPathAS.sh identity token-cert update --cert-file-path /path/to/cert --password '<cert_pass>'
Cela entraînera la rotation ou la substitution de l’ancien certificat par le nouveau téléchargé à l’aide de la mise à jour du certificat.
sudo ./configureUiPathAS.sh identity token-cert rotate
sudo ./configureUiPathAS.sh identity token-cert rotate
Il devrait y avoir un délai d'environ 24 à 48 heures entre la mise à jour du certificat et sa rotation.
Nous avons besoin de ce délai pour continuer à prendre en charge l'authentification pour le jeton mis en cache signé par l'ancien certificat.
Si vous effectuez la rotation du certificat trop tôt avant l'expiration du jeton de cache, cela peut entraîner des temps d'arrêt. Et vous devrez peut-être redémarrer tous vos robots.
Pour effectuer une mise à jour d'urgence du certificat, procédez comme suit :
Exécutez la commande suivante pour télécharger le certificat de signature de jeton actuel :
sudo ./configureUiPathAS.sh identity token-cert get --outpath /directory/path/to/store/certificate
sudo ./configureUiPathAS.sh identity token-cert get --outpath /directory/path/to/store/certificate
Par défaut, les certificats RKE2 expirent sous 12 mois. Au cours des 90 jours précédant leur date d’expiration, les certificats font l’objet d’une rotation lorsque vous redémarrez RKE2.
Pour plus de détails, consultez la section RKE2 - Options avancées - Rotation du certificat.
if [[ -d "/var/lib/rancher/rke2/server/tls" ]]; then
dir="/var/lib/rancher/rke2/server/tls"
elif [[ -d "/var/lib/rancher/rke2/agent/tls" ]]; then
dir="/var/lib/rancher/rke2/agent/tls"
else
dir="/var/lib/rancher/rke2/agent/"
fi
# Loop through each .crt file in the directory
for file in "$dir"/*.crt; do
# Extract the expiry date from the certificate
expiry=$(openssl x509 -enddate -noout -in "$file" | cut -d= -f 2-)
# Get the file name without the path
filename=$(basename "$file")
# Print the filename and expiry date in a pretty format
printf "%-30s %s\n" "$filename:" "$expiry"
done
if [[ -d "/var/lib/rancher/rke2/server/tls" ]]; then
dir="/var/lib/rancher/rke2/server/tls"
elif [[ -d "/var/lib/rancher/rke2/agent/tls" ]]; then
dir="/var/lib/rancher/rke2/agent/tls"
else
dir="/var/lib/rancher/rke2/agent/"
fi
# Loop through each .crt file in the directory
for file in "$dir"/*.crt; do
# Extract the expiry date from the certificate
expiry=$(openssl x509 -enddate -noout -in "$file" | cut -d= -f 2-)
# Get the file name without the path
filename=$(basename "$file")
# Print the filename and expiry date in a pretty format
printf "%-30s %s\n" "$filename:" "$expiry"
done
La sortie que vous obtenez doit être similaire à celle illustrée dans l’image suivante :
Par défaut, les certificats RKE2 expirent sous 12 mois. Au cours des 90 jours précédant leur date d’expiration, les certificats font l’objet d’une rotation lorsque vous redémarrez RKE2. Cependant, si la validité des certificats dépasse la période de 90 jours, vous devez effectuer une rotation manuelle des certificats en suivant les étapes mentionnées dans RKE2 - Options avancées - Rotation du certificat.
Si vous souhaitez personnaliser la période d'expiration des certificats RKE2 pour répondre à des exigences particulières, vous pouvez le faire avant de redémarrer les services RKE2 pour les nœuds de serveur et d'agent.
Pour effectuer une rotation des certificats RKE2, vous devez d’abord exécuter une série d’actions sur les nœuds de serveur, puis poursuivre certaines étapes sur les nœuds d’agent.
- Arrêtez le serveur RKE2 :
systemctl stop rke2-server.service
systemctl stop rke2-server.service - Effacez tous les processus RKE2 restants :
rke2-killall.sh
rke2-killall.sh - Supprimez le fichier
dynamic-cert.json
situé dans/var/lib/rancher/rke2/server/tls/
. -
Pour personnaliser la période d'expiration des certificats RKE2, utilisez la commande suivante. Sachez que cet exemple définit la période de validité sur 1 000 jours, mais vous pouvez modifier cette valeur en fonction de vos besoins.
SERVICE_NAME="rke2-server.service" conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf" mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/ cat > "$conf_file_path" <<EOF [Service] Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000" EOF systemctl daemon-reload
SERVICE_NAME="rke2-server.service" conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf" mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/ cat > "$conf_file_path" <<EOF [Service] Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000" EOF systemctl daemon-reload - Redémarrez le serveur RKE2 :
systemctl start rke2-server.service
systemctl start rke2-server.serviceRemarque : si le cluster comporte plusieurs nœuds de serveur, les étapes 1 à 4 peuvent ne pas s’exécuter entièrement car etcd peut ne pas permettre de finaliser l’élection du responsable. Si cela se produit, répétez les étapes 1 à 4 sur d’autres nœuds de serveur. - Supprimez la clé secrète
rke2-serving
de l’espace de nomskube-system
:kubectl delete secret -n kube-system rke2-serving
kubectl delete secret -n kube-system rke2-servingRemarque :Dans un déploiement multi-nœuds, vous ne pourrez peut-être pas exécuter les commandeskubectl
tant que vous n’aurez pas effectué les quatre premières opérations sur le nombre nécessaire de nœuds de serveur. Cela permet de répondre à l’exigence de quorum etcd. Vous pouvez supprimer la clé secrèterke2-serving
immédiatement après le démarrage du serveur RKE2.
kubectl get nodes
. Lorsque vos nœuds de serveur sont prêts, vous pouvez passer aux nœuds d’agent pour régénérer les certificats.
Effectuez les étapes suivantes sur les nœuds d’agent :
- Arrêtez le serveur RKE2 :
systemctl stop rke2-agent.service
systemctl stop rke2-agent.service - Effacez tous les processus RKE2 restants :
rke2-killall.sh
rke2-killall.sh -
Pour personnaliser la période d'expiration des certificats RKE2, utilisez la commande suivante. Sachez que cet exemple définit la période de validité sur 1 000 jours, mais vous pouvez modifier cette valeur en fonction de vos besoins.
SERVICE_NAME="rke2-agent.service" conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf" mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/ cat > "$conf_file_path" <<EOF [Service] Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000" EOF systemctl daemon-reload
SERVICE_NAME="rke2-agent.service" conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf" mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/ cat > "$conf_file_path" <<EOF [Service] Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000" EOF systemctl daemon-reload - Redémarrez le serveur RKE2 :
systemctl start rke2-agent.service
systemctl start rke2-agent.service
- Génération d'une demande de signature de certificat (CSR) et d'une clé privée
- Gestion des certificats de serveur
- Mise à jour du certificat du serveur
- Accéder au certificat TLS
- Ajout du certificat CA au magasin d'approbations hôte
- Gestion des certificats CA supplémentaires
- Mise à jour des certificats CA
- Accéder aux certificats CA
- Ajout du certificat CA au magasin d'approbations hôte
- Gestion des certificats de signature de jeton d'identité
- Mise à jour du certificat
- Rotation du certificat
- Rotation des certificats d'urgence
- Accéder au certificat
- Gestion des certificats RKE2
- Vérification de la date d’expiration du certificat RKE2
- Rotation du certificat RKE2