Fedora-Fr

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Problème avec la désinstallation de FreeIPA (Gestion des identités centralisé)

VINDICATORs

Hello tlm,

Bon on est pas nombreux sur le sujet, mais je vais quand même en parler ici.

J’ai eu un souci avec la monté de version de Fedora 41 à Fedora 42 sur mon serveur physique. Il semble que ce soit un format de certificat qui ai cassé le service IPA (Identity manager/Gestionnaire d’identités). Ma dernière sauvegarde n’ayant pas marché, je vais devoir reconfigurer le tout de zéro (rien de grave, cela vas être vite remonté n’ayant pas trop de choses à refaire). Je n’ai pas non plus l’autre serveur replica de coté vu que je devais le refaire…

Sauf que d’avoir supprimer le service à cassé mes accès à distance (le serveur n’a pas d’interface graphique).

Cassé? pas vraiment, juste que l’accès aux utilisateurs ne fonctionne plus, la faute à SELINUX dont il faut relancer la labellisation.

Heureusement que j’ai le serveur physiquement à coté, j’ai juste eu à remettre une carte graphique et m’y connecter directement en mode sans échec comme suit, car le mode “rescue” ne fonctionne pas :

Au boot lorsque l’on arrive au menu GRUB touche [E] pour éditer
Taper sur la touche [&] (clavier en [QWERTY], du coup cela vas marquer “1”) A la fin de la ligne : linux ….
taper simultanément sur [CTRL]+[X] pour booter
Rentrer le mdp du compte root (normalement en [AZERTY], mais c’est possible que ce soit en [QWERTY])
taper : touch /.autorelabel && reboot

Voilà cela vas résoudre le problème d’accès à la machine 🙂.

Pour ma part je vais réactiver la sauvegarde automatique avec une tache CRON de FreeIPA histoire de ne pas avoir à remonter le service en urgence.

A voir si la réinstallation de zéro résout le problème ou si c’est des bogues qu’il faut résoudre.

Si vous voulez plus d’info sur FreeIPA, voici la page wikipedia : https://fr.wikipedia.org/wiki/FreeIPA

PS : bon je sais que Fedora est une distribution à support court, mais j’ai déjà retrouvé un bogue bloquant vieux de plus de 10 ans sur RHEL et CentOS 😉, donc cela ne veut pas dire que l’on est à l’abri de problèmes sur les distrib à support long…

Édit : bon il semble que le problème initial soit à cause de l’IPV6 :

Invalid IP address fe80::c644:d7bd:xxx:xxx for xxx.xxx.local.: cannot use link-local IP address fe80::c644:d7bd:xxx:xxx
Invalid IP address fe80::42b0:76ff:xxx:xxx for xxx.xxx.local.: cannot use link-local IP address fe80::42b0:76ff:xxx:xxx
Invalid IP address fe80::c644:d7bd:xxx:xxx for xxx.xxx.local.: cannot use link-local IP address fe80::c644:d7bd:xxx:xxx
Invalid IP address fe80::42b0:76ff:xxx:xxx for xxx.xxx.local.: cannot use link-local IP address fe80::42b0:76ff:xxx:xxx

A suivre…

VINDICATORs

J’ai aussi résolu le bogue sur FreeIPA lors de la migration… Cela fut rapidement visible à la réinstallation du service, car le problème fut le même malgré que ce soit reussi.

Il y avait un périphérique réseau fantôme dans /etc/NetworkManager/system-connections/
Ce qui fait qu’il y avait des IP IPV6 en trop.
J’avais un “enp27s0” au lieu de “enp5s0”, cela a provoqué des soucis coté DNS avec des IP qui pointé sur rien et sans doute du conflit derrière…

Du coup j’ai refais une installation du service de zéro pour rien 😛 \o/ !!!

Je n’ai plus qu’à rattacher les clients, ainsi que les services qui en dépendent (heureusement que je n’en avais plus qu’un) et ce sera bon \o/.

Nicosss

VINDICATORs Merci pour ton retour.

C’est un effet de bord qui pourrait toucher d’autres services donc c’est toujours bien d’avoir cette information.

Ce n’est pas la première fois que l’on retrouve ce besoin d’effectuer un ré-étiquetage SELinux pour régler des problèmes, mais c’est toujours plus simple d’avoir accès à la machine.

VINDICATORs

Nicosss

Ce qui m’étonne c’est ce changement de nom du périphérique réseau sans qu’il ait de fichier le concernant disponible, voir que ce soit modifié si il y a eu des changements automatique…

fgland

on a parlé il n’y a pas longtemps des différentes dont le système gère le nom du périphérique réseau, serait-ce le cas ?

VINDICATORs

fgland

Sans doute, bon c’est surtout qu’il n’y a rien pour faire les modifs à la volée automatiquement dans les fichiers de conf qui doivent encore servir à quelque chose. Du coup on ce retrouve avec des conflits ou des doublons et autres qui sont quand même lue.

J’ai le cas avec fancontrol et les hwmon qui changent par moment (surtout lors des mises en veille). Du moins j’avais ce comportement jusqu’à il y a peu (je n’ai pas vraiment re-constaté le problème depuis).

Enfin c’est dommage que je n’ai pas vu cette modif avant, cela m’aurais évité de faire sauter ma configuration FreeIPA… Comme je l’ai dit, rien de grave, je m’en sert juste pour faire des tests et gérer 3 comptes utilisateurs, voir quelques configuration pour mes VM de laboratoire. C’est surtout la gestion DNS qui est casse bonbon, car il faut repasser sur toutes les machines, mais bon cela me donne l’occasion d’automatiser le processus.

VINDICATORs

Pour info ~~certaines~~ mes VM ont eu du mal à se rattacher au serveur FreeIPA (Champs A non renseigné automatiquement), alors qu’elles l’étaient avant.

Du coup soit vous rajouter à la main le champ “A”, soit il faut forcer avec la commande suivante pour que ce soit automatiquement renseigné :

# ipa-client-install --mkhomedir --enable-dns-updates --force-join

Cela force le DNS de la machine/VM à se mettre à jour et au client de rejoindre le serveur avec mise à jour des infos diverses si besoin. Par contre il faut être patient, car cela peut être un peu long (d’habitude c’est rattaché assez rapidement quand il n’y a pas de problèmes…).

Du coup mes noeuds Kubernetes répondent de nouveau avec leurs noms d’hôte 🙂 :

kubemaster01:~# kubectl get nodes
NAME                         STATUS   ROLES           AGE    VERSION
kubemaster01.ipazeus.local   Ready    control-plane   167d   v1.32.3
kubemaster02.ipazeus.local   Ready    worker          167d   v1.32.4
kubemaster03.ipazeus.local   Ready    worker          167d   v1.32.4
kubeworker02.ipazeus.local   Ready    worker          167d   v1.32.3
kubeworker03.ipazeus.local   Ready    worker          167d   v1.32.3
kubeworker04.ipazeus.local   Ready    worker          167d   v1.32.3

Plus qu’à remettre les groupes et utilisateurs qui vont bien, ainsi que les règles SELINUX pour ceux-ci et les hôtes au besoin…

VINDICATORs

Bon mise à jour, reboot et hop le périphérique enp27s0 à disparut et vu que le enp5s0 fut supprimé…

Du coup il faut juste recréer enp5s0 après avoir vérifié que c’est le bon avec ifconfig ou ip a .

Puis mettre à jour le dns records pour remplacer l’ip du serveur freeipa :

# kinit admin

mdp de “admin”

et lancer la commande suivante :

# ipa dns-update-system-records

Par contre je vais voir pour fixer l’ip de l’IPV6 en dur, car elle c’est encore modifié, ce qui pose souci avec la conf du serveur DNS…
J’ai comme d’habitude fixé l’IPV4, mais j’ai encore, comme d’habitude, oublié de le faire aussi pour l’IPV6…

D’ailleurs je pense que la commande dns-update-system-records été peut être la solution au problème initial…

Donc du coup je met cette dernière réponse comme la solution.
À voir le jour où cela ce reproduit (encore une fois cela ne doit pas concerner grand monde 🙁).