jeudi 4 août 2016

sddm: image utilisateur

Vous en avez assez que sddm (écran de connexion graphique pour kde) ressemble à ceci:


Vous préférez plutôt y voir figurer les images (ou les avatars) des utilisateurs.
Cela nécessite une action de chaque utilisateur.
Pour kubuntu, pas de problèmes: il suffit de procéder via Configuration du système -> Détails du compte-> Gestionnaire des utilisateurs.
Pour Fedora kde (ou d'autres distributions), rien n'est prévu à ce niveau.
Mais on peut agir dans un émulateur de terminal, avec la commande kcmshell114.
Pour l’utilisateur toto:

toto@rigel:~$ kcmshell4 kcm_useraccount


mercredi 3 août 2016

Mise à niveau vers Fedora 24

J'ai hésité longtemps avant d'écrire cet article puisque tout était déjà dit dans cet article concernant le passage à Fedora 23. Je rappelle donc les commandes qu'il convient d'exécuter (en tant que root):

[root@rigel ~]# dnf update --refresh

pour mettre à jour le système existant

[root@rigel ~]# dnf install dnf-plugin-system-upgrade

pour installer le programme qui convient

 [root@rigel ~]# dnf system-upgrade download --releasever=24

pour télécharger les paquets de la nouvelle version

[root@rigel ~]# dnf system-upgrade reboot

pour procéder à la mise à niveau proprement dite.

Toutefois si l'étape 3 se termine par une erreur du genre:

Erreur : Erreur du contrôle de transaction
  le fichier /usr/bin de l'installation de google-earth-stable-7.1.4.1529-0.x86_64 entre en conflit avec le fichier du paquet filesystem-3.2-37.fc24.x86_64

cela signifie qu'un dépôt actif fournit un paquet non installable (google-earth-stable-7.1.4.1529-0.x86_64 dans notre exemple).

Il n'est pas trop tard pour supprimer ce dépôt.
Par exemple:

[root@rigel ~]# rm /etc/yum.repos.d/google-earth.repo

L'étape 3 relancée se termine alors rapidement sans aucune erreur (tous les téléchargements ont déjà été effectués).
Toutefois la dernière étape malgré un début prometteur se plante sans aucun message d'erreur.
En fait le paquet litigieux est toujours dans le cache.
il faut le supprimer avant de poursuivre:

[root@rigel ~]# rm /var/lib/dnf/system-upgrade/google-earth-stable-6.0.3.2197-0.x86_64.rpm 

En ce qui concerne la migration des données postgresql, j'ai déjà tout expliqué ici.
Toutefois j'ajouterai qu'il convient en tant que postgres de se placer là où postgres peut écrire (ou sinon le programme pg_upgrade se plante).
La séquence est donc:

[toto@rigel ~]$ su -
Mot de passe :
[root@rigel ~]# su - postgres
bash-4.3$ cd /var/lib/pgsql
bash-4.3$ mv data data_9.4

Ensuite:

[root@rigel ~]# postgresql-setup initdb

Puis:

bash-4.3$ pg_upgrade -b /usr/lib64/pgsql/postgresql-9.4/bin/ -B /usr/bin/ -d data_9.4/ -D data

(ceci suppose que la variable d'environnement PGDATA existe et contient /var/lib/pgsql/data)

Je récupère ensuite l'ancien pg_hba.conf

bash-4.3$ cp /var/lib/pgsql/data_9.4/pg_hba.conf /var/lib/pgsql/data/

En effet si je le récupère d'abord comme indiqué dans l'article précédent et qu'il contient des éléments empêchant le démarrage du nouveau serveur, pg_upgrade va se planter.

L'erreur fatale dont il est question précédemment ne se produit plus.

Ne pas oublier de récupérer pg_ident.conf et d'adapter postgresql.conf