--- title: Fichiers et services url: https://doc2.pstreamer.tv/fr/manual/install/files.html lang: fr product: Perfect Streamer version: 2.0.2.362 --- # 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](../extras/config_file.md#extras-config-file). ****/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](../webui/administration.md#webui-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](../extras/api.md#extras-api-vs-file)). 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](../extras/config_file.md#extras-config-file-reading). 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](../extras/api.md#extras-api)), 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](../extras/api.md#extras-api-results)). 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](../extras/config_file.md#extras-config-file) et [Modifier, vérifier et transporter les paramètres](../extras/config_editing.md#extras-config-editing).