Passer au contenu principal

Procédures d'administration

Accéder à l'instance TPE avec une console

L'instance TPE peut être accédée avec une console en utilisant un accès ssh ou directement depuis Cockpit.

ssh support@${IP_OR_HOSTNAME_OF_TPE} -p 2222
AVERTISSEMENT

Seul l'utilisateur support doit être utilisé pour accéder au système.

Ne tentez pas d'accéder ou de modifier le mot de passe root. Sinon, tout accès au système sera bloqué.

Changer le mappage clé par défaut

Le réglage par défaut du clavier du terminal TPE est l'anglais.

Le réglage peut également être modifié avec la commande suivante :

Pour définir le français, par exemple :

localectl set-keymap fr

La liste des paramètres disponibles peut être affichée comme suit :

localectl list-keymaps

Accès à Cockpit

Le Cockpit est accessible sur l'instance TPE avec les identifiants du compte de support.

Vous devez cocher la case "Réutiliser mon mot de passe pour les tâches privilégiées" pour pouvoir effectuer des tâches d'administration sur le Cockpit.

Mise à jour des paramètres sur Cockpit

Certains paramètres de configuration peuvent être mis à jour dans Cockpit après l'installation.

Cependant, cela n'inclut pas le certificat PKI et la clé.

D'autres paramètres de configuration peuvent être mis à jour en appliquant la procédure suivante :

  1. Modifier les paramètres dans Cockpit.
  2. Lorsque vous cliquez sur Enregistrer & Appliquer, une fenêtre de confirmation s'affiche et tous les changements sont directement enregistrés et appliqués. Le redémarrage des services TPE nécessaires est effectué automatiquement.

Pour plus de détails sur les paramètres de configuration, voir Configuration TPE.

TPE apply conf

Liste des conteneurs/services et vérification de l'état

Liste des conteneurs

Depuis la console ssh (cela peut également être fait dans Cockpit à l'aide du module Conteneurs) :

$ docker ps
CONTAINER ID ... STATUS ... NAMES
50766bc8d549 ... Up 12 minutes (healthy) ... actility_twa.2.cx2h3fwn691det6krz96bw9sl
ed7cba4db759 ... Up 13 minutes (healthy) ... actility_tpdx-hub.1.wjooh9esmob1deiiqi4ua1sbt
f82e7d1cf3ab ... Up 13 minutes ... actility_snmp-system.uyq6qer1zxysyc6vx7yyz0c8g.wo6kb5wss6pz9ta80ypcus2x3
96e437b0ffac ... Up 13 minutes ... actility_proxy-http.uyq6qer1zxysyc6vx7yyz0c8g.hqkii6oehxqxyl22asq3ayez4
83a8fe10dd46 ... Up 13 minutes ... actility_tpdx-core.1.df06pb4qdbo668q5tw47ukhug
f86423c344b1 ... Up 13 minutes ... actility_snmp-tpe.1.iu001lydddgsimvoll9n6ncd8
86a34b471c72 ... Up 13 minutes ... actility_tpdx-bridge-5.1.babnostzak359n8qkz86nwqua
d6fd3f293254 ... Up 14 minutes ... actility_support1.1.v3bhstynvn59xf21jgsvr63kw
dbc677ccd94b ... Up 14 minutes ... actility_tpdx-admin.1.hjwm479w69cwskc97gel0jdvz
8a829c777729 ... Up 14 minutes ... actility_cron-rfscan1.1.tey8jcyevjxeq3iop0opvbjbw
484654265a24 ... Up 14 minutes ... actility_spectrum-analysis.1.8kf92gmy98jvvsr6jjdudr8h7
d6e38230b2a4 ... Up 13 minutes ... actility_ftp1.1.jxkvqw5wxnc8m9h8d4pw91x92
269a2b86f53b ... Up 14 minutes ... actility_shellinabox.1.fa9dof9lp72ms5wn0x0chvnjb
1bd65a105006 ... Up 14 minutes ... actility_tpdx-bridge-3.1.ucaaw48ez2xpqfyh1srkerxrd
ab9de08629d8 ... Up 14 minutes ... actility_twa-ran.1.aaa50x1aejmvc134bgqxmo5qj
2ba07eb120bb ... Up 14 minutes (healthy) ... actility_lrc1.1.0p1g86tauueqlw7ykppko3efs
3547b62359d0 ... Up 16 minutes (healthy) ... actility_sql_node1.1.dojmnthklk0bsh97ff4cvahup
95b6705e880e ... Up 18 hours ... actility_twa-dev-task-fc.2.z69fzjzgjmku8lyfnr1rszum9
5f1abd35c852 ... Up 18 hours ... actility_twa-task-res.2.vn0jgqfoxqpsvw655ehdhk5yp
03b2f7d2b151 ... Up 18 hours ... actility_traefik.uyq6qer1zxysyc6vx7yyz0c8g.rstf37e3o9d3j15ba72bbifdx
b903d9e05532 ... Up 18 hours ... actility_lrc-sync1.1.mieza6zj58p48ar2v7e3y0es1
d8b8310ce8bd ... Up 18 hours (healthy) ... actility_kafka_node1.1.5a43py1nog5iybwkxrg6smlps
750111459bcb ... Up 18 hours (healthy) ... actility_mongo_node1.1.bfcp3rsbjwp60u3w2yn7fn790
3eb528ef56ca ... Up 18 hours (healthy) ... actility_zk_node1.1.m5lhg865lw2rrn5p6c0tq8n7d
ca052a596c9e ... Up 3 days ... tpe-slrc
acbc762e0019 ... Up 3 days ... registry.uyq6qer1zxysyc6vx7yyz0c8g.bmapltso3s1c2nmqj1kxiljk7

Tous les conteneurs devraient être actifs et fonctionnels. Si ce n'est pas le cas, essayez de redéployer les services TPE. Pour cela, allez dans le module Cockpit Configuration TPE et cliquez sur "Enregistrer & Appliquer".

Liste des services

Depuis la console ssh :

$ docker service ls
ID NAME MODE REPLICAS ... PORTS
6gi8prljcgpo actility_backup-sidecar1 replicated 0/0 ...
g7wj0fx3sdny actility_backup-sidecar2 replicated 0/0 ...
iiksfmskilxw actility_cron replicated 1/1 ...
nxax6ftb2hj9 actility_cron-rfscan1 replicated 1/1 ...
23ohk1hb8j7o actility_cron-rfscan2 replicated 1/1 ...
27d6rs8pjagt actility_ftp1 replicated 1/1 ... *:21->21/tcp, *:10000-10100->10000-10100/tcp
ih1jl6g3olb4 actility_ftp2 replicated 1/1 ... *:2121->21/tcp, *:10200-10300->10200-10300/tcp
as68wgltea1f actility_kafka_node1 replicated 1/1 ...
ovoou845wtfr actility_kafka_node2 replicated 1/1 ...
fogofojolga0 actility_kafka_node3 replicated 1/1 ...
qdlirro0w7n6 actility_lrc1 replicated 1/1 ... *:2404->2404/tcp
6ci72ai6obh9 actility_lrc2 replicated 1/1 ... *:2405->2404/tcp
ik2584fgqh7g actility_lrc-sync1 replicated 1/1 ...
meauxs6l4y1e actility_lrc-sync2 replicated 1/1 ...
rlzkm4y31t02 actility_mongo_node1 replicated 1/1 ...
tk48bmuxrozb actility_mongo_node2 replicated 1/1 ...
lj2u8q9uhpcb actility_mongo_node3 replicated 1/1 ...
bqo0gwc7rlb3 actility_mongo_operator replicated 0/0 ...
y0i1lwbpxuu0 actility_monitor replicated 1/1 ...
xbe4usb0e4e2 actility_network-survey replicated 1/1 ...
84gru0eis5i1 actility_proxy-http global 3/3 ...
h1v0a8vb54ng actility_rca replicated 2/2 ... *:8080->8080/tcp
zh5flfofa3i7 actility_rca_operator replicated 0/0 ...
3vh10a2rtqf3 actility_shellinabox replicated 1/1 ...
4femixwmfa6z actility_slrc-companion1 replicated 0/1 ...
r7dshu8djt0p actility_slrc-companion2 replicated 0/1 ...
s6kc89w2y7as actility_smp-tpe replicated 2/2 ...
z7c17vqmeq0j actility_snmp-system global 3/3 ...
ahtf7wft7xsx actility_snmp-tpe replicated 1/1 ... *:13161->13161/udp
qb4vs7g5zc4u actility_spectrum-analysis replicated 1/1 ...
hydkoxv4nova actility_sql-proxy replicated 2/2 ...
hx57ne4jrknb actility_sql_node1 replicated 1/1 ...
8h97hgf9hann actility_sql_node2 replicated 1/1 ...
f9ky48qt4dl8 actility_sql_node3 replicated 1/1 ...
6dekyiwnied8 actility_support1 replicated 1/1 ... *:22->22/tcp
xurltz5swl67 actility_support2 replicated 1/1 ... *:2224->22/tcp
rafny2ryoqrf actility_task-notif-ws replicated 2/2 ...
jxl7n3gilrd3 actility_tpdx-admin replicated 2/2 ...
lb9wblk8ijrt actility_tpdx-bridge-1 replicated 1/1 ...
ufvx5frwm1b0 actility_tpdx-bridge-2 replicated 1/1 ...
bd1egc3qe703 actility_tpdx-bridge-3 replicated 1/1 ...
crsbqli1fbiq actility_tpdx-bridge-4 replicated 1/1 ...
4gxqqiw6xot5 actility_tpdx-bridge-5 replicated 1/1 ...
umee9ly3zgkl actility_tpdx-core replicated 2/2 ...
xyxik7s49ypp actility_tpdx-hub replicated 2/2 ...
y08xjumt41i8 actility_traefik global 3/3 ...
5hy114uccxl7 actility_twa replicated 2/2 ...
ubr76pzbrcge actility_twa-admin replicated 2/2 ...
skf6rv1277ew actility_twa-dev replicated 2/2 ...
whxsehi9exvg actility_twa-dev-task-fc replicated 2/2 ...
iacjnhzlp1di actility_twa-ran replicated 2/2 ...
ink5trvdtdkp actility_twa-task-res replicated 2/2 ...
onhsqc2dheci actility_wlogger replicated 2/2 ...
x4nq8hq5kyhd actility_zk_node1 replicated 1/1 ...
mbmvglq0gie5 actility_zk_node2 replicated 1/1 ...
2zupgn97atzf actility_zk_node3 replicated 1/1 ...
k592ro2ml7xg registry global 3/3 ...

Du Cockpit :

Lister les services

La plupart des services devraient être actifs et opérationnels. Si ce n'est pas le cas, essayez de redéployer les services TPE. Pour cela, allez dans le module Cockpit Configuration TPE et cliquez sur "Enregistrer & Appliquer".

Certains services ne sont démarrés que pour effectuer une action spécifique (comme une sauvegarde) et sont arrêtés lorsque l'action est terminée. Ci-dessous la liste des services qui pourraient être arrêtés sans impact fonctionnel :

  • backup-sidecar
  • mongo_operator
  • rca_operator
  • slrc_companion

D'autres services ne sont démarrés qu'en fonction des fonctionnalités activées sur le module Cockpit Configuration TPE :

  • Si la fonctionnalité "API DX" est désactivée, le service suivant est arrêté : tpdx-core.
  • Si la fonctionnalité "IoT Flow" est désactivée, les services suivants sont arrêtés : tpx-flow-hub, tpx-flow-bridge, tpx-flow-api et tpx-flow-supervisor.
  • Si les fonctionnalités "API DX" et "IoT Flow" sont désactivées, les services suivants sont arrêtés : tpdx-core, tpdx-admin, tpx-flow-hub, tpx-flow-bridge, tpx-flow-api et tpx-flow-supervisor.
  • Si la fonctionnalité "Node-RED" est désactivée, le service suivant est arrêté : node-red.
  • Si "IPsec (X.509) pour la connexion de la passerelle à TPE" est désactivée, les services suivants sont arrêtés : rca et slrc.

Connexion à un conteneur

La plupart des conteneurs sont distroless, il n'est pas possible de se connecter aux conteneurs.

Affichage des journaux de conteneur

Pour afficher les journaux d'un conteneur à l'aide du nom du conteneur, pour lrc :

docker logs $(docker ps -q -f "name=actility_lrc1")

En utilisant l'ID du conteneur :

docker logs qdlirro0w7n6

Affichage des journaux de service

Pour afficher les journaux d'un service, pour lrc :

  • Depuis la console ssh :
docker service logs actility_lrc1
  • Depuis le Cockpit, cliquez sur "Voir les journaux" :

Voir les journaux

Arrêt et démarrage des conteneurs d'infrastructure

Pour arrêter et démarrer un conteneur d'infrastructure, pour slrc :

  • Depuis la console ssh :
docker restart tpe-slrc
  • Depuis le Cockpit, cliquez sur "Redémarrer" :

Redémarrer le conteneur

Arrêt et démarrage d'un service répliqué

Pour arrêter un service répliqué, pour lrc :

docker service scale actility_lrc1=0

Pour démarrer un service répliqué avec une réplique, pour lrc :

docker service scale actility_lrc1=1

Pour démarrer un service répliqué avec 2 répliques, pour rca :

docker service scale actility_rca=2

Lorsque vous démarrez le service, prenez soin de définir le bon nombre de répliques.

Arrêt et démarrage d'un service global

Pour arrêter un service global, pour proxy-http :

docker service rm actility_proxy-http

Pour démarrer un service global :

source /etc/thingpark/tpe/installer-release ; docker run -it --rm -v /home/tpepilot/:/home/tpepilot/ -v /var/run/docker.sock:/var/run/docker.sock --entrypoint="" tpe:${tpeInstallerRelease} docker stack deploy -c /home/tpepilot/workdir/docker-compose-services.yml actility

Arrêt et démarrage de chronyd

Pour arrêter le service chronyd (synchronisation de l'heure) :

systemctl stop chronyd

Pour démarrer le service chronyd :

systemctl start chronyd

Redéploiement d'un service depuis Cockpit

Pour redéployer un service global ou répliqué depuis Cockpit, cliquez sur Redéployer. Pour le service kafka sur node1 :

Redeploy service

Redéploiement du cluster TPE depuis Cockpit

Pour redéployer l'ensemble du cluster TPE, généralement après une récupération de nœud en mode Haute Disponibilité (HA) ou lorsque la Mise à jour vers HA a échoué, depuis Cockpit, effectuez un Redéploiement du cluster :

Redeploy cluster

Ensuite, allez dans "Configuration TPE" et cliquez sur Enregistrer & Appliquer.

Vérification de l'accès au Dépôt

Pour vérifier l'accès du serveur TPE au dépôt TPE, exécutez la commande suivante dans le terminal :

wget https://InstallationID:InstallationID@repository.thingpark.com/tpe-rpm/repodata/repomd.xml

Si une erreur est levée, vérifiez la configuration du proxy.

Si le problème persiste, contactez votre support.

Surveillance des services sur Cockpit

L'utilisation du CPU, la consommation de mémoire et l'état peuvent être vérifiés pour tous les conteneurs/services sur le module TPE Services Cockpit.

Si une activité anormale est détectée (100% CPU sur un conteneur, redémarrage en boucle, etc...) faites ce qui suit :

  1. Redémarrez le service.
  2. Si la situation ne revient pas à la normale, contactez votre support.
note

Le code couleur du menu des nœuds (capture d'écran ci-dessous) n'est pas associé à l'état de l'hôte, mais fournit uniquement des informations sur l'emplacement de connexion de la session.
Cockpit nodes list

Surveillance SNMP

ThingPark Enterprise propose deux niveaux de surveillance :

  • Surveillance du système,
  • Surveillance des services.

Les deux sont accessibles via SNMP v2 dans la communauté support ou SNMP v3.

Seules les adresses IP explicitement configurées peuvent récupérer les informations.

Si le SNMP V3 est sélectionné, jusqu'à trois utilisateurs peuvent être configurés. Pour chaque utilisateur, le niveau de sécurité est configurable :

  • noauth : Un nom d'utilisateur doit être configuré

  • auth : Un nom d'utilisateur et une passe-authentification (min 8 caractères) doivent être configurés

  • priv : Un nom d'utilisateur, une passe-authentification (min 8 caractères) et une passe-privacy (min 8 caractères) doivent être configurés

prudence

Les adresses IP autorisées à accéder à SNMP sont configurées séparément pour la surveillance du système et des services :

Un client SNMP avec le MIB approprié est nécessaire pour récupérer les informations de surveillance. La récupération du MIB est détaillée dans les sections suivantes.

Surveillance du système

La surveillance du système expose les métriques des nœuds ThingPark Enterprise supportées par l'agent Net-SNMP 5.7. Voir README.agent-mibs pour la liste des tables et objets exposés.

L'agent SNMP écoute sur le port 161 de chaque nœud ThingPark Enterprise.

note

En cas de déploiement Haute Disponibilité (HA), chaque nœud ThingPark Enterprise doit être supervisé indépendamment.

Exemple

Installation du client NET-SNMP et des MIBs (sur Ubuntu/Debian)

sudo apt install snmp snmp-mibs-downloader
sudo sed -i 's/mibs :/# mibs :/g' /etc/snmp/snmp.conf

Exécutez l'une des commandes suivantes pour récupérer :

  • Charge CPU

Cas SNMPv2 :

snmptable -v 2c -c support <node-ip-address> UCD-SNMP-MIB::laTable

Cas SNMPv3, niveau de sécurité noauth et utilisateur "user1" :

snmptable -v3  -l noauth -u user1 <node-ip-address> UCD-SNMP-MIB::laTable

Cas SNMPv3, niveau de sécurité auth, utilisateur "user2" et authepassphrase "myauthpass" :

snmptable -v3  -l auth -u user2  -A myauthpass -a SHA <node-ip-address> UCD-SNMP-MIB::laTable

Cas SNMPv3, niveau de sécurité priv, utilisateur "user3" et passe-authentification "myauthpass" :

ssnmptable -v3  -l priv -u user3  -A myauthpass  -X myprivacypass -a SHA  -x AES  <node-ip-address> UCD-SNMP-MIB::laTable
  • Statistiques CPU (cas SNMPv2)
snmpwalk -v 2c -c support <node-ip-address> UCD-SNMP-MIB::systemStats
  • Utilisation de la mémoire (cas SNMPv2)
snmpwalk -v 2c -c support <node-ip-address> Memory
  • Utilisation du disque (cas SNMPv2)
snmptable -v 2c -c support <node-ip-address> UCD-SNMP-MIB:dskTable
  • Entrée/sortie disque (cas SNMPv2)
snmptable -v 2c -c support <node-ip-address> UCD-DISKIO-MIB::diskIOTable
  • Trafic réseau (cas SNMPv2)
snmptable -v 2c -c support <node-ip-address> IF-MIB::ifTable

Surveillance des services

La surveillance des services expose l'état (actif ou inactif) du Network server. Un MIB personnalisé est utilisé : iso.org.dod.internet.private.enterprise.actility.thingpark.thingparkEnterpriseMIB.thingparkEnterpriseServices.

Les deux fichiers ACTILITY-MIB.my et THINGPARK-ENTERPRISE-MIB.my doivent être fournis à votre client SNMP. Par exemple, si vous utilisez NET-SNMP, placez ces fichiers dans le répertoire .snmp/mibs de votre domicile et demandez à NET-SNMP de les charger en ajoutant la ligne suivante dans le fichier .snmp/snmp.conf :

mibs +ACTILITY-MIB:THINGPARK-ENTERPRISE-MIB

L'agent SNMP écoute sur le port 13161 de chaque nœud ThingPark Enterprise.

Exemple

Cas SNMPv2 :

$ snmptable -v 2c -c support <tpe-address>:13161 THINGPARK-ENTERPRISE-MIB::thingparkEnterpriseServiceTable

SNMP table: THINGPARK-ENTERPRISE-MIB::thingparkEnterpriseServiceTable

thingparkEnterpriseServiceName thingparkEnterpriseServiceStatus
OSS Service up
Network Service up

Cas SNMPv3, niveau de sécurité noauth et utilisateur "user1" :

snmptable -v3  -l noauth -u user1 <node-ip-address>:13161 THINGPARK-ENTERPRISE-MIB::thingparkEnterpriseServiceTable

Cas SNMPv3, niveau de sécurité auth, utilisateur "user2" et authepassphrase "myauthpass" :

snmptable -v3  -l auth -u user2  -A myauthpass -a SHA <node-ip-address>:13161 THINGPARK-ENTERPRISE-MIB::thingparkEnterpriseServiceTable

Cas SNMPv3, niveau de sécurité priv, utilisateur "user3" et passe-authentification "myauthpass" :

ssnmptable -v3  -l priv -u user3  -A myauthpass  -X myprivacypass -a SHA  -x AES  <node-ip-address>:13161 THINGPARK-ENTERPRISE-MIB::thingparkEnterpriseServiceTable

Connexion à distance

L'administrateur système du TPE peut activer l'accès à distance au serveur TPE pour le support de niveau 3 d'Actility en suivant les étapes ci-dessous :

  1. Assurez-vous que le serveur d'accès distant de niveau 3 est défini sur tpe-ocp@tpe-remote-support.actility.com:443/home/tpe-ocp/remote-sockets dans la configuration de l'infrastructure.

  2. Dans le module TPE Support Cockpit, cliquez sur le bouton "Activer l'accès à distance".

    Ouvrir le tunnel

  3. Dès que les tunnels sont ouverts, l'administrateur système du TPE doit communiquer les trois paramètres affichés à l'équipe de support :

    • ID de session
    • Mot de passe
    • Nom d'hôte TPE

Une fois l'accès à distance activé, la connexion entre le TPE et le service de support Actility est établie comme suit :

Remote access flow

Utilisateur de secours

Si vous avez perdu vos identifiants pour vous connecter à l'interface GUI de ThingPark Enterprise, dans le module TPE Support Cockpit, cliquez sur "Activer l'utilisateur de secours".

Enable rescue user

Une fois activé, un identifiant pour se connecter à l'interface GUI de ThingPark Enterprise est affiché :

Identifiant utilisateur de secours

Utilisez cet identifiant pour vous connecter à l'interface GUI, vous pourrez ensuite accéder à la page Comptes d'Utilisateur pour modifier votre propre mot de passe. Une fois terminé, désactivez l'utilisateur de secours dans le module de support du TPE Cockpit.

Synchronisation de ThingPark Exchange (TEX)

ThingPark Exchange (TEX) est le hub d'Itinérance/peering hébergé par Actility. Il est utilisé pour interconnecter votre plateforme ThingPark avec vos partenaires d'Itinérance, ainsi qu'avec des join servers externes utilisés pour activer les capteurs LoRaWAN OTAA.
L'Itinérance doit être activée si votre instance ThingPark Enterprise va connecter des capteurs provisionnés sur des réseaux tiers ("roam-in"), ou si certains de vos capteurs provisionnés localement peuvent se connecter via des réseaux tiers ("roam-out").

Pour offrir une intégration transparente entre ThingPark Enterprise et ThingPark Exchange, une interface de plan de contrôle est prise en charge entre les deux extrémités pour mettre à jour dynamiquement la configuration TPE de son réseau peer et des join servers.
De plus, cette interface de plan de contrôle entre TPE et TEX permet la synchronisation en bande des plans de canaux RF (aussi appelés RF Regions) entre les différentes plateformes de peering disposant d'un accord d'itinérance commun.

Le statut de synchronisation TEX avec le LRC peut être surveillé dans "TPE Services" sous le menu "TEX operations -> TEX synchronization".

TEX operations

En cliquant sur Synchronisation TEX, la fenêtre suivante est affichée montrant l'état actuel de la synchronisation TEX :

TEX synchronization

La synchronisation TEX est effectuée automatiquement chaque jour, mais elle peut être forcée en cliquant sur Forcer la resynchronisation. Vous pouvez aussi forcer un rafraîchissement de l'état de la synchronisation TEX en cliquant sur Rafraîchir l'état.

Si la synchronisation TEX ne fonctionne pas, le statut suivant est affiché :

Erreur de synchronisation TEX

Vous pouvez également exporter les RF Regions depuis le menu "TEX operations -> Export RF Regions". Cela permet de télécharger un fichier tgz contenant toutes les RF Regions correspondant aux bandes ISM configurées.

Procédure post-mise à niveau

La procédure post-mise à niveau consiste en un ensemble de requêtes post-mise à niveau qui migre automatiquement les données SQL et MongoDB après une mise à niveau de l'instance TPE. Le statut de la procédure post-mise à niveau peut être vérifié dans le module TPE Services Cockpit sous le service "autres". Le statut du service post-mise à niveau peut être :

  • en cours : la procédure post-mise à niveau est en cours et pas encore terminée.
  • terminée : la procédure post-mise à niveau est terminée avec succès.
  • échouée : la procédure post-mise à niveau est terminée avec des erreurs.

Vous pouvez accéder aux journaux du service de procédure post-mise à niveau à travers le menu kebab du service en cliquant sur "Voir les journaux".

Vous pouvez également vérifier l'état des requêtes post-mise à niveau en exécutant le script tpe-post-upgrade-status sur l'hôte TPE :

$ tpe-post-upgrade-status
2022/07/18 16:31:51: INFO: Start tpe-post-upgrade-status script
2 entrie(s)
uid: 2
creationTimestamp: '2022-06-23T13:50:33.000Z'
scope: 'ALL'
serviceID: 'TWA'
requestID: 'RDTP-7689-bs-certificate-migration'
requestPath: '/thingpark/wireless/rest/systems/demons/migrateBsSecurity'
requestBody: '{ "max" : 10 }'
state: 'PROCESSED'
stateTimestamp: '2022-06-27T14:05:11.000Z'
lastResponse: '{"status":200,"message":"OK","data":{"countOnly":false,"max":10,"result":{"done":6,"remaining":0}}}'
errorCounter: 0
iterationCounter: 5
uid: 4
creationTimestamp: '2022-06-23T13:50:33.000Z'
scope: 'TPE-OCP'
serviceID: 'TWA'
requestID: 'RDTP-18480-alarm-email-notification-migration-for-tpe-ocp'
requestPath: '/thingpark/wireless/rest/systems/demons/migrateUserAlarmNotifications'
requestBody: '{ "max" : 100 }'
state: 'PARTIALLY_PROCESSED'
stateTimestamp: '2022-06-27T14:14:11.000Z'
lastResponse: '{"status":250,"message":"Unknown","data":{"operatorID":null,"max":100,"countOnly":false,"result":{"done":0,"remaining":2}}}'
errorCounter: 0
iterationCounter: 2

Le script affiche la liste des requêtes post-mise à niveau et pour chaque requête, les détails de la requête, y compris l'état du traitement. L'état de traitement d'une requête post-mise à niveau peut être :

  • INIT: la demande post-mise à jour a été ajoutée et doit être traitée.
  • IN_PROGRESS: un HTTP POST est en cours pour cette demande.
  • PARTIALLY_PROCESSED: d'autres itérations sont nécessaires pour compléter la demande post-mise à jour.
  • TRANSIENT_ERROR: le dernier HTTP POST a échoué et doit être réessayé.
  • ABORTED: le gestionnaire post-mise à jour n'a pas pu compléter la demande post-mise à jour.
  • PROCESSED: la demande post-mise à jour est entièrement terminée.
  • SKIPPED: la demande post-mise à jour n'a jamais été appliquée sur ce système (car la procédure a été marquée comme DÉPRÉCIÉE ou parce que le champ d'application ne s'applique pas à ce PF).

Si pour une raison quelconque vous souhaitez exécuter à nouveau la procédure post-mise à niveau, par exemple lorsqu'elle a échoué, vous pouvez le faire via le module TPE Services Cockpit en cliquant sur "Redéployer" dans le menu kebab.

Modifier la configuration matérielle

Si vous mettez à jour la configuration matérielle de votre instance TPE (par exemple si vous changez votre profil matériel TPE), vous devez explicitement mettre à jour la configuration TPE :

  • Connectez-vous à Cockpit
  • Allez dans le module de Configuration TPE
  • Cliquez sur "Appliquer & Enregistrer" pour appliquer la nouvelle configuration.

Régénérer les certificats IPsec pour le trafic de passerelle

Pour régénérer les certificats IPSec de toutes les passerelles, suivez la procédure suivante :

  1. Exécutez une commande ssh pour se connecter au nœud TPE :

    ssh support@${IP_OR_HOSTNAME_OF_TPE} -p 2222
  2. Ensuite, exécutez le script suivant pour régénérer les certificats :

    /usr/bin/tpe-regenerate-bs-certificates