Fichiers et services

/usr/local/bin/pss

Fichier exécutable.

/opt/pss/config/pss.properties

Paramètres globaux, journaux, chemins des dossiers, etc. Après toute modification, redémarrer le service.

/opt/pss/config/pss.json

Fichier de configuration principal. Créé et mis à jour automatiquement. Au démarrage, le service tente de charger précisément ce fichier. Structure du fichier — voir Le fichier de configuration pss.json.

/opt/pss/config/pss_last.json

Une copie du dernier pss.json qui s’est chargé proprement. Elle est réécrite à chaque démarrage où c’est bien pss.json qui s’est chargé ; un démarrage sur un fichier de repli ne la met pas à jour — sans quoi elle cesserait d’être la dernière valide. Elle sert de premier recours si le fichier principal n’a pas pu être analysé. Sur un nœud jamais redémarré depuis l’installation, et là où le répertoire des paramètres est en lecture seule, ce fichier n’existe pas.

/opt/pss/config/pss_back.json

Copie de sauvegarde de la configuration précédente en service. Elle n’est créée que lors de la restauration des paramètres depuis une copie enregistrée auparavant dans l’interface web (Maintenance) et sert de recours après pss_last.json. Le service ne tient pas de sauvegarde régulière : sur un nœud où les paramètres n’ont jamais été restaurés, ce fichier n’existe pas.

/opt/pss/config/pss_default.json

Fichier de configuration par défaut. Livré avec le paquet et appliqué comme dernier recours si ni pss.json, ni pss_last.json, ni pss_back.json ne peuvent être chargés. C’est également à partir de lui qu’est créé le pss.json de travail lors du tout premier démarrage : le fichier définit le port de l’interface web 8808 et le compte admin / admin.

/opt/pss/config/bad/

Archive des fichiers pss.json endommagés. Si le fichier de configuration principal ne peut pas être analysé au démarrage, il est déplacé ici sous un nom de la forme pss_YYYYMMDD_HHMMSS.json. Le répertoire est créé automatiquement et ne croît pas sans limite : les vingt fichiers aux noms les plus élevés y sont conservés. Pour plus de détails, voir la section Comportement au démarrage et en cas d’erreurs de configuration.

/opt/pss/data

Dossier de stockage des données. Créé et mis à jour automatiquement. Peut être modifié dans le fichier de configuration globale.

/usr/lib/systemd/system/pss.service

Fichier d’unité systemd du service.

/var/log/pss

Dossier d’écriture des journaux. Peut être modifié dans le fichier de configuration globale.

Nom du service : pss. S’exécute sous l’utilisateur pss.

Le travail avec la clé est assuré par le paquet du système de protection aksusbd — il comprend les services hasplmd et aksusbd. Le paquet pstreamer déclare une dépendance envers lui, en version 10.33 ou plus récente : il ne contient pas lui-même le service de protection, mais se trouve dans le même dépôt, si bien que le gestionnaire de paquets l’installe avec lui. Un service de protection plus ancien ne peut pas charger les bibliothèques du fournisseur que pstreamer dépose dans /var/hasplm.

Comportement au démarrage et en cas d’erreurs de configuration

Au démarrage, le service tente de charger successivement les fichiers de configuration du dossier /opt/pss/config :

  1. pss.json — fichier de configuration principal.

  2. pss_last.json — une copie de la dernière configuration qui s’est chargée proprement.

  3. pss_back.json — copie de sauvegarde de la configuration de travail précédente.

  4. pss_default.json — paramètres par défaut livrés avec le paquet.

Le premier fichier chargé avec succès est utilisé. Si les quatre fichiers sont absents ou endommagés, le service démarre avec des paramètres vides — ils ne contiennent aucun compte. L’administrateur est alors créé à la main : arrêter le service, ajouter dans pss.json une entrée à web-server.login avec les clés id, login et password, puis redémarrer le service — une modification apportée à un service en fonctionnement est écrasée depuis la mémoire (API ou fichier de configuration).

Deux choses découlent de l’existence de pss_last.json. Premièrement : supprimer pss.json ne repart plus d’une page blanche — le service démarrera sur pss_last.json et le réécrira dans pss.json. Il n’y aura pas d’alerte, mais cela ne passera pas inaperçu non plus : une entrée subsiste dans le journal, et un message de démarrage apparaît dans l’interface web. Pour réinitialiser réellement le nœud, on supprime pss.json en même temps que pss_last.json et pss_back.json — le service démarre alors sur pss_default.json. Rien d’autre dans le répertoire des paramètres ne doit être touché : sans pss.properties, le service ne démarre pas du tout. Deuxièmement : pss_last.json ne vaut que ce que vaut la fraîcheur du dernier démarrage propre. Les paramètres modifiés depuis l’interface web et qui n’ont jamais survécu à un redémarrage n’existent que dans pss.json, et un repli sur la dernière configuration fonctionnelle ne les conservera pas.

Un fichier de configuration inacceptable. Si pss.json n’a pas pu être lu, le service le déplace dans l’archive /opt/pss/config/bad/ sous le nom pss_YYYYMMDD_HHMMSS.json ; la date et l’heure du nom sont l’instant de l’archivage en UTC, le même repère que celui du journal par défaut. Le service poursuit ensuite le chargement dans l’ordre habituel et réenregistre la configuration en service dans pss.json à partir du fichier qui s’est effectivement chargé. Les détails (nom de la clé, description de l’erreur, nom du fichier dans l’archive) sont consignés dans le journal d’exploitation, et l’alerte sur l’échec du chargement nomme elle aussi directement le chemin de l’archive.

Le chargement est interrompu par : une erreur de syntaxe JSON, une valeur null, une forme de valeur incorrecte (un objet là où une valeur unique est attendue, et l’inverse), un nombre ou un mot étranger à la place de true et false, une chaîne trop longue, un identifiant d’entrée de tableau absent ou en double, la répétition d’une valeur déclarée unique. Une clé inconnue ne fait pas rejeter le fichier : elle est ignorée, un avertissement nommant la section et la clé est écrit dans le journal, et à l’enregistrement suivant la clé disparaît du fichier. L’analyse complète de ce que le service accepte à la lecture du fichier et de ce qu’il refuse figure dans Ce que fait le service à la lecture du fichier.

Seul le fichier principal pss.json est placé dans l’archive. Les fichiers pss_last.json, pss_back.json et pss_default.json ne sont pas archivés lorsqu’ils sont endommagés — les entrées du journal suffisent au diagnostic, et les fichiers eux-mêmes restent en place et peuvent être corrigés manuellement.

Si /opt/pss/config/bad/ contient déjà un fichier portant le même horodatage (par exemple lors de deux démarrages ratés dans la même seconde), le nouveau reçoit un suffixe numérique — pss_YYYYMMDD_HHMMSS_2.json et suivants ; la copie enregistrée auparavant n’est pas perdue pour autant. Le répertoire ne peut pas enfler : l’apparition d’une nouvelle copie y laisse les vingt fichiers aux noms les plus élevés, les autres étant supprimés. Pour les archives que le service nomme d’après l’heure, ce sont précisément les vingt plus récentes ; les fichiers étrangers laissés dans le répertoire comptent également et occupent ces places, aussi vaut-il mieux ne rien garder de superflu dans bad/. Une modification ratée — une copie ; un redémarrage à lui seul ne crée pas de nouvelles copies, car le fichier rejeté a déjà été déplacé et un fichier fonctionnel a été écrit à sa place.

Valeurs numériques en dehors de la plage autorisée. Si le fichier de configuration contient une valeur numérique inférieure au minimum autorisé ou supérieure au maximum autorisé pour ce paramètre, le service ne rejette pas le fichier dans son intégralité. À la place, un avertissement est consigné dans le journal indiquant le nom du paramètre, la valeur lue et la limite appliquée, et la valeur elle-même est ramenée à la limite de plage autorisée la plus proche (le minimum ou le maximum). Une fois le chargement terminé, le service réenregistre automatiquement pss.json avec les valeurs déjà corrigées, de sorte que ces avertissements n’apparaissent plus au démarrage suivant.

Outre le journal, la correction est signalée par la notification de démarrage du service dans l’interface web : elle indique le nombre de valeurs ramenées à une borne et renvoie au journal pour le détail. Lisez-la après une mise à jour ayant resserré une plage : la correction est silencieuse, et sur un paramètre de rétention elle signifie que les données au-delà de la nouvelle borne seront supprimées par le prochain passage de nettoyage.

Ce comportement ne s’applique qu’au chargement initial du fichier de configuration. Lors de la modification des paramètres via l’interface web ou l’API HTTP (Pilotage via l’API HTTP), les valeurs en dehors de la plage autorisée sont toujours rejetées avec une erreur — sans correction automatique.

Un refus ne ramène pas pour autant le nœud à son état antérieur : ce que le nœud a eu le temps de lire avant la valeur invalide reste appliqué, et un message signalant un enregistrement rejeté ne signifie pas que rien n’a changé (Comment arrivent les erreurs).

Modifier le fichier à la main, le valider avec le schéma et transporter les paramètres vers un autre nœud ou une autre version — Le fichier de configuration pss.json et Modifier, vérifier et transporter les paramètres.