ucf - Mettre à jour le fichier de configuration : préserver les modifications de l’utilisateur dans les fichiers de configuration
SYNTAXE
ucf [options] <Nouveau fichier> <Destination>
ucf [options] --purge <Destination>
DESCRIPTION
Cet utilitaire fournit un moyen de demander à l’utilisateur s’il souhaite ou non accepter les nouvelles versions des fichiers de configuration fournies par le responsable du paquet, avec divers heuristiques conçus pour minimiser le temps d’interaction. Il utilise debconf pour interagir avec l’utilisateur, conformément à la politique Debian. Dans la SYNTAXE ci-dessus, le Nouveau fichier est le fichier de configuration fourni par le paquet (soit inclus dans le paquet, soit généré par les scripts du responsable), et Destination est l’emplacement (généralement sous /etc) où se trouve le fichier de configuration réel, et qui a potentiellement été modifié par l’utilisateur final. Étant donné que les fichiers édités seraient des fichiers réels, et non des liens symboliques, ucf suit et résout les liens symboliques avant d’agir. Dans la mesure du possible, ucf tente de préserver la propriété et les permissions du Nouveau fichier lorsqu’il est copié vers le nouvel emplacement.
Ce script tente de fournir une gestion de type conffile pour les fichiers installés sous /etc qui ne sont pas inclus dans un paquet Debian, mais qui sont gérés par le script postinst. La politique Debian stipule que les fichiers sous /etc qui sont des fichiers de configuration doivent préserver les modifications de l’utilisateur, et cela s’applique également aux fichiers gérés par les scripts du responsable. En utilisant ucf, vous pouvez inclure un ensemble de fichiers de configuration par défaut dans /usr ( /usr/share/<pkg> est un bon emplacement) et maintenir des fichiers dans /etc, en préservant les modifications de l’utilisateur et en offrant généralement les mêmes fonctionnalités lors des mises à niveau que dpkg fournit normalement pour les « conffiles ».
De plus, ce script fournit des fonctionnalités pour faire passer un fichier qui n’avait pas de protection de type conffile à ce schéma, et tente de minimiser le nombre de questions posées lors de l’installation. En effet, la fonctionnalité de transition est meilleure que celle offerte par dpkg lors de la transition d’un fichier d’un statut non-conffile à un statut conffile. La deuxième forme de la SYNTAXE ci-dessus est utilisée pour supprimer les informations sur le fichier de configuration lorsque le paquet est supprimé ; et c’est essentiel pour permettre des réinstallations en douceur.
Au cours des opérations, lorsque le script travaille avec des fichiers de configuration, ucf crée éventuellement des copies des versions du fichier de configuration en question. Par exemple, un fichier avec le suffixe ucf-old contient l’ancienne version d’un fichier de configuration remplacé par ucf. De plus, des copies du fichier de configuration avec les suffixes ucf-new et ucf-dist peuvent être créées ; et les scripts de maintenance doivent envisager de supprimer les copies du fichier de configuration avec ces extensions lors de la suppression.
OPTIONS
-h, --help
Affiche un bref message d'utilisation.
-n, --no-action
Exécution à blanc. Affiche les actions qui seraient entreprises si le script était exécuté, mais n'effectue aucune action.
-d[n], --debug=[n]
Définit le niveau de débogage au niveau n (n est optionnel et prend par défaut la valeur 1). Veuillez noter qu'il ne doit y avoir aucun espace avant le chiffre optionnel n. Ceci active une grande quantité d'informations de débogage.
-p, --purge
Supprime toutes les traces du fichier du fichier de hachage d'état. Ceci est nécessaire pour permettre à un paquet d'être réinstallé après avoir été purgé ; car sinon, le fichier de configuration réel est supprimé, mais il reste dans le fichier de hachage ; et lors de la réinstallation, aucune action n'est effectuée, car la somme de contrôle md5 du nouveau fichier correspond à celle du fichier de hachage. En bref, n'oubliez pas d'utiliser cette option dans le script postrm pour chaque fichier de configuration géré par ucf lorsque le paquet est purgé (en supposant qu'ucf lui-même existe). Remarque : ucf ne touche pas réellement le fichier sur le disque dans cette opération, de sorte que toute suppression de fichier reste la responsabilité du paquet appelant.
-v, --verbose
Rend le script très bavard concernant la définition des variables internes.
-P foo, --package foo
Ne suit pas les redirections dpkg-divert du paquet foo lors de la mise à jour des fichiers de configuration.
-s foo, --src-dir foo
Définit le répertoire source (les sommes de contrôle md5 historiques doivent se trouver dans des fichiers et des sous-répertoires de ce répertoire) sur foo. Par défaut, on suppose que le répertoire dans lequel se trouve le nouveau fichier est le répertoire source. Définir cette option remplace les paramètres de la variable d'environnement UCF_SOURCE_DIR et de la variable de fichier de configuration conf_source_dir.
--sum-file foo
Force la lecture des sommes de contrôle md5 historiques à partir de ce fichier, au lieu de les stocker par défaut dans le répertoire source. Définir cette option remplace les paramètres de la variable d'environnement UCF_OLD_MDSUM_FILE et de la variable de fichier de configuration conf_old_mdsum_file.
--three-way
Ceci active l'option, lors de l'installation, pour que l'utilisateur puisse voir une fusion des modifications entre l'ancienne version du mainteneur et la nouvelle version du mainteneur dans la copie locale du fichier de configuration. Si l'utilisateur apprécie ce qu'il voit, il peut demander que ces modifications soient fusionnées. Cela permet de fusionner les nouvelles modifications en amont, tout en conservant les modifications locales du fichier de configuration. Ceci est réalisé en stockant le fichier de configuration dans une zone de cache pendant l'enregistrement, et en utilisant diff3 pendant l'installation (le nom du fichier stocké est une version modifiée du chemin complet du fichier de configuration afin d'éviter les conflits d'espace de noms).
--debconf-ok
Indique qu'il est acceptable pour ucf d'utiliser une instance debconf déjà en cours d'exécution pour les invites (il a toujours été acceptable d'utiliser ucf lorsque debconf n'est pas en cours d'exécution ; il invoquera debconf si nécessaire).
--debconf-template foo
Indique à ucf d’utiliser le modèle debconf multiselect nommé à la place du modèle debconf fourni par ucf. L’appelant est responsable de s’assurer que le modèle nommé existe et que sa liste de choix correspond à celle du modèle ucf par défaut, et doit définir Choix-C : ${CHOIX} afin de garantir que les valeurs renvoyées correspondent à celles du modèle par défaut. Notez que les choix doivent être différents selon que l’option --three-way est également définie.
--state-dir /chemin/vers/le/répertoire
Définit le répertoire d’état sur /chemin/vers/le/répertoire au lieu du répertoire par défaut /var/lib/ucf. Principalement utilisé pour les tests.
-Z Définit le contexte de sécurité SELinux du fichier de destination sur le type par défaut.
UTILISATION
Le cas d’utilisation le plus courant est assez simple : une seule ligne d’invocation dans le script postinst lors de la configuration, et une autre ligne dans le script postrm pour indiquer à ucf d’oublier le fichier de configuration lors de la désinstallation (en utilisant l’option --purge), c’est tout ce dont vous avez besoin (en supposant que ucf est toujours installé sur le système).
Il est recommandé d’enregistrer également tous les fichiers gérés par ucf dans le registre ucf ; cela associe le fichier de configuration au package auquel il appartient. Cela se fait en appelant simplement ucfr. Les utilisateurs peuvent ensuite interroger l’association entre un fichier de configuration et le package à l’aide de l’outil ucfq. Veuillez consulter les pages de manuel correspondantes pour plus de détails.
Les packages qui utilisent debhelper peuvent simplifier la création des fragments de script de maintenance nécessaires en utilisant l’outil dh_ucf.
Si un fichier maintenu par des scripts de maintenance passe d’un statut non protégé au statut protégé par le script, le responsable peut faciliter la transition en réduisant le nombre de questions qui peuvent être posées lors de l’installation. Plus précisément, aucune question ne doit être posée si le fichier en question est une version non modifiée qui a été incluse dans une version précédente de ce package ; et le responsable peut aider en indiquant au script les sommes de contrôle md5 historiques que contenaient les versions publiées de ce fichier.
Pour ce faire, vous pouvez soit créer un fichier appelé <Nouveau fichier>.md5sum, avec une somme de contrôle md5 par ligne (les noms de fichiers que vous utilisez sont ignorés, à l’exception de l’entrée portant le nom « default »), soit créer un répertoire appelé <Nouveau fichier>.md5sum.d, qui doit contenir n’importe quel nombre de fichiers, chacun contenant une seule ligne, à savoir la somme de contrôle md5 d’une version précédente de <Nouveau fichier>. Les noms de ces fichiers ne sont pas importants, à une exception près : le fichier appelé « default » est traité de manière spéciale. Par exemple, l’auteur utilise personnellement les numéros de version du package ou les noms de code de la distribution, comme 7.6.3 ou potato. Si aucune des sommes de contrôle md5 historiques ne correspond, nous sommes presque certains que soit l’historique des sommes de contrôle md5 n’est pas complet, soit l’utilisateur a modifié le fichier de configuration.
La somme de contrôle md5 historique par défaut
L’exception à la règle concernant les noms mentionnée précédemment est que si aucune des sommes de contrôle md5 ne correspond, et si le fichier <Nouveau fichier>.md5sum.d/default existe, ou s’il existe une ligne correspondant à un fichier par défaut dans <Nouveau fichier>.md5sum, il sera utilisé comme somme de contrôle md5 par défaut de la version précédente du package supposée avoir été installée sur cette machine. Comme vous pouvez le constater, à moins qu’il n’y ait un nombre limité de packages précédemment publiés (par exemple, un seul), le responsable fait également une supposition éclairée, mais cette option est fournie au responsable.
Si le fichier <Nouveau fichier>.md5sum, ou le répertoire <Nouveau fichier>.md5sum.d, n’existe pas, ou si aucune des sommes de contrôle MD5 ne correspond, nous testons le fichier <Destination> installé pour vérifier s’il est identique à <Nouveau fichier>. Si ce n’est pas le cas, nous demandons à l’utilisateur s’il souhaite que nous remplacions le fichier.
Une fonctionnalité supplémentaire est également proposée : ucf peut stocker une ancienne version de la copie du fichier de configuration fournie par le mainteneur et, lors d’une mise à niveau, calculer les modifications apportées à la version du fichier de configuration fournie par le mainteneur, puis appliquer ce correctif à la version locale du fichier (sur demande de l’utilisateur, bien sûr). Il existe également une fonctionnalité de prévisualisation permettant à l’utilisateur d’examiner les résultats d’une telle fusion avant de demander que l’action soit effectuée.
VARIABLES D’ENVIRONNEMENT
La variable UCF_FORCE_CONFFNEW, si elle est définie, force le nouveau fichier à toujours remplacer le fichier de destination installé, tandis que la variable UCF_FORCE_CONFFOLD, si elle est définie, conserve silencieusement le fichier installé. UCF_FORCE_CONFFMISS n’est applicable que lorsque le fichier de destination installé n’existe pas (peut-être en raison d’une suppression par l’utilisateur), et force ucf à recréer le fichier manquant (le comportement par défaut consiste à respecter les souhaits de l’utilisateur et à ne pas recréer le fichier supprimé localement). De plus, lorsque ucf crée un shell inférieur, il remplit les variables UCF_CONFFILE_NEW et UCF_CONFFILE_OLD, qui sont utiles pour examiner les modifications.
Les indicateurs confmiss, confnew, confold, confdef et confask de la variable DPKG_FORCE sont également pris en charge. Voir dpkg(1) pour plus d’informations.
FICHIERS
Ce script crée le fichier new_file.md5sum, et il peut copier le fichier (supposé être fourni avec le package) <Nouveau fichier> vers sa destination, <Destination>.
/var/lib/ucf/hashfile et /var/lib/ucf/hashfile.X, où X est un petit entier, où les versions précédentes du fichier de hachage sont stockées.
/etc/ucf.conf
EXEMPLES
Si le package foo souhaite utiliser ucf pour gérer l’interaction avec l’utilisateur pour le fichier de configuration foo.conf, dont une version est fournie dans le package sous /usr/share/foo/configuration, un simple appel à ucf dans le fichier post inst est tout ce dont vous avez besoin :
ucf /usr/share/foo/configuration /etc/foo.conf
Lors d’une désinstallation, vous devez indiquer à ucf d’oublier le fichier (voir les exemples détaillés dans /usr/share/doc/ucf/examples) :
ucf --purge /etc/foo.conf Veuillez noter que purge peut également être utilisé pour faire en sorte qu’ucf oublie l’état précédent des fichiers, et lorsque le package est ensuite installé ou mis à jour, ucf demandera à l’utilisateur de remplacer le fichier de configuration actuel. Faites-le si vous souhaitez modifier votre décision de ne pas mettre à jour la version fournie par le mainteneur du fichier de configuration.
La motivation de ce script était de fournir une gestion de type fichier de configuration pour les fichiers de démarrage des paquets Emacs Lisp (par exemple, /etc/emacs21/site-start.d/50psgml-init.el). Ces fichiers de démarrage ne sont pas fournis avec le paquet, mais sont installés pendant la phase de configuration post-installation par le script /usr/lib/emacsen-common/emacs-package-install $package_name.
Ce script est destiné à être invoqué par le script d'installation des paquets situé à /usr/lib/emacsen-common/packages/install/$package_name pour chaque variante d'Emacs installée, en l'appelant avec les valeurs appropriées pour le nouveau fichier (/usr/share/emacs/site-lisp/<pkg>/<pkg-init.el) et le fichier de destination (/etc/emacs21/site-start.d/50<pkg-init.el), et il doit faire le reste.
VOIR AUSSI
ucf.conf(5), ucfr(1), ucfq(1), dpkg(1), dh_ucf(1), diff3(1).
La politique Debian Emacs, fournie avec le paquet emacsen-common.
AUTEUR
Cette page de manuel a été écrite par Manoj Srivastava <_>, pour le système Debian GNU/Linux.