====== Renommer une utilisatrice sous Debian ======
Changer le nom système((À la différence du nom complet.)) d'une utilisatrice est une opération relativement simple, en première instance. Mais plus on aura installé, adapté, configuré d'éléments de son environnement de travail, plus on risque d'avoir créé des adhérences au nom du répertoire de l'utilisatrice, voire à son nom littéral((Ce sera notamment le cas lorsqu'on aura, par flemme ou par méconnaissance, utilisé "/home/monnom" au lieu de "~", "monnom" au lieu de "$USER" ou "id -u -n", etc…)).
Avant de procéder au changement de nom, on prendra soin de désactiver les actions planifiées((cron, utilitaires, applications.)) susceptibles d'agir sur tout ou partie du répertoire de base (home directory) de l'utilisatrice.
===== Traitement préalable de liens symboliques =====
La procédure suivie dans cette fiche s'accompagne du renommage du répertoire de base de l'utilisatrice((Bien que ça n'ait rien d'obligatoire, ce répertoire porte habituellement le nom système de utilisatrice (user name). Cette pratique est à ce point ancrée dans les habitudes qu'y déroger peut devenir source de confusion, notamment lors d'opérations de diagnostic.)). En conséquence, tous les liens __absolus__ internes au répertoire base, se trouveront cassés à l'issue de la procédure de renommage.
===== Renommer au niveau système =====
Source : [[https://www.cyberciti.biz/faq/howto-change-rename-user-name-id/|Linux Change or Rename User Name and UID (user-id)]].
La première et plus importante chose à faire est de renommer l'utilisatrice au niveau du système d'exploitation. Je suppose qu'on utilise une station de travail((La procédure s'adapte intuitivement si l'on opère sur un système sans interface graphique tel qu'un serveur.)).
- Quitter la session graphique en se déconnectant
- Basculer l'affichage vers une console (Ctrl + Alt + F2)
- Se connecter en root, puis exécuter la liste des commandes suivantes (remplacer "ancien" par l'ancien //username// d'utilisatrice et "nouveau" par le username que vous souhaitez donner à cette utilisatrice) :
killall -u ancien
id ancien
usermod -l nouveau ancien
groupmod -n nouveau ancien
usermod -d /home/nouveau -m nouveau
usermod -c “New Real Name” nouveau
id nouveau
Ceci mettra en place la configuration de base qui permettra à l'utilisatrice de se connecter avec son nouveau //username// tout en conservant : son mot de passe, ses droits (y compris //su//), son répertoire (home directory), sa boîte mail system (/var/mail:…).
===== Ajustements complémentaires =====
Les indications qui suivent ne prétendent à aucune exhaustivité ! Tout dépendra du niveau de personnalisation de votre système.
==== Alias mail de root ====
Si vous renommez votre utilisatrice principale((La première utilisatrice non-root créée lors de l'installation du système.)), vous avez très probablement aliassé l'adresse mail de //root// avec celle de cette utilisatrice. La modification du //username// n'est pas répercutée sur cet alias. Il faut aller modifier le fichier des alias.
=== Dans un terminal ===
# nano /etc/aliases ⇒ puis effectuer le la modification d'alias de root
# newaliases ⇒ indispensable pour les modification faites dans le fichier soit prises en compte
=== Via Webmin ===
Servers > Postfix > Mail Aliases
==== KDE ====
=== Dolphin ===
Le répertoire par défaut de //Dolphin// étant enregistré en dur, vous pouvez avoir l'impression que vos fichiers ont disparu… Il n'en est rien. Reconfigurez //Dolphin// pour définir l'emplacement de votre "Dossier personnel".
=== Raccourcis ===
Les raccourcis personnalisés placé sur le bureau ou dans le tableau de bord conservent l'ancien chemin du répertoire et deviennent inutilisables. En attendant de trouver mieux((Par exemple le nom du (des) fichier(s) où il suffirait de remplacer "ancien" par "nouveau"…)) : créer de nouveaux raccourcis puis supprimer les anciens.
===== Application installée en mode local =====
Les applications que vous aurez installées en mode local ont toutes les chances d'avoir enregistré les noms de leurs répertoires de travail et fichiers de configuration sous la forme de chemins absolus :-( Il faudra donc les reprendre une à une.
===== Liens symboliques =====
Cette section traie du cas où le changement de nom d'utilisatrice s'accompagne d'un changement de nom du répertoire de base.
Sources :
* [[https://www.baeldung.com/linux/find-broken-symlinks|Linux Commands – Find Broken Symlinks]]
* [[https://linux.die.net/man/8/symlinks|symlinks(8) - Linux man page]] ne serait-ce que pour la description des différentes manières qu'a un lien d'être "cassé"
Certains liens symboliques pointant sur ou à l'intérieur du répertoire de base((Home directory.)) à l'ancien nom risquent d'être cassés. Les lien internes au répertoire de base((Un lien à l'intérieur du répertoire de base pointant sur un objet qui se retrouve également à l'intérieur de ce répertoire.)) pourraient ne pas l'être à condition qu'il aient été créés sous la forme de chemins relatifs.
==== État des lieux ====
$ find /path/to/search -xtype l
==== Réparer ====
=== Nettoyer ===
Sur un poste de travail, on risque fort de découvrir l'existence de liens cassés((Sur un serveur, ce type de contrôle est censé être fait au fil de l'eau.)) sans rapport avec le changement que l'on vient d'opérer.
Ce peut être l'occasion de faire du ménage. Par la suite, cela permettra de se focaliser sur les seuls liens cassés du fait du changement de nom du répertoire de base.
=== Actions préventive rapide ===
Si les conditions d'application sont remplies, cette action doit être effectuée dès que l'état des lieux à été dressé.
Si l'ancien nom est définitivement abandonné((Il ne sera attribué à aucune autre utilisatrice.)) un lien symbolique /home/ -> /home/ rétablira la continuité des liens. Il s'agit d'une solution d'urgence car on introduit une double liaison et une adhérence permanente. Cette technique permet de se donner le temps de traiter proprement la question.
# ln -s /home/ /home/
# apt install symlinks
===== Scripts =====
Les scripts où il est fait référence à l'ancien répertoire de base seront défaillants.
Ils sont potentiellement dangereux((Par exemple, un script mal écrit faisant un changement de répertoire (cd) avant d'effectuer une série d'actions réalisera ces actions dans le répertoire courant.)). De plus, des scripts agissant sur le répertoire utilisatrice peuvent être lancés automatiquement((Sauvegardes, nettoyage, etc.)).