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

mardi 1 mars 2016

Droits

Une phrase comme celle-ci
"Les droits sur /usr/bin sont du type 0755...."
reprise de l'article précédent a pu intriguer quelques néophytes.
Aussi, bien qu’il existe des centaines d’articles traitant des droits sur les fichiers en linux, je me suis finalement décidé à y mettre mon grain de sel.

Travaillant dans un (émulateur de) terminal, je génère à l'aide de la commande cat le fichier quisuisje contenant le texte :
echo Je suis $USER
Je termine par ENTER pour envoyer la ligne et CTRL+D pour signifier la fin du processus.
J'essaie d'exécuter le fichier avec
./quisuisje
mais évidemment ça ne fonctionne pas tant que je n'ai pas donné le droit d'exécution (chmod +x) :


J'examine (commande ls) quels sont les droits sur le fichier.
Ceux-ci

r droit en lecture
w droit en écriture
x droit en exécution

sont répartis en 3 catégories

  • droits du propriétaire du fichier (c'est moi : toto)
  • droits des membres du groupe indiqué. Ici ce sont les amis du propriétaire (membres du groupe toto)
  • droits des autres utilisateurs

Je ne veux pas que mes amis puissent modifier le fichier, aussi je leur enlève le droit en écriture sur le fichier :



La commande chmod, telle qu’utilisée ici, est suivie d’une ou de plusieurs lettres qui indiquent le ou les utilisateurs concernés :

u désigne le propriétaire
g les membres du groupe
o les autres

Vient ensuite ± puis le ou les droits ajoutés ou retirés selon le cas.
(Note: si rien ne précède +/-, la commande concerne tous les utilisateurs)

L'ensemble des droits sur un fichier constitue un nombre binaire et chaque droit attribué correspond à un bit de ce nombre binaire mis sur ON.
Les droits sur quisuisje correspondent au nombre binaire
000111101101
(Les 3 premiers bits sur OFF sont associés à des droits spéciaux dont il n'a pas été question jusqu’ici).

Je voudrais calculer le nombre hexadécimal correspondant.
Pour ce faire je regroupe les bits par série de 4 et je leur attribue les valeurs 8, 4, 2, 1.
J'annule ces valeurs si le bit est sur OFF, ensuite dans chaque groupe j'additionne les valeurs survivantes pour avoir le chiffre du nombre hexadécimal :

Le nombre décimal vaut :

1x256 + 14x16 + 13 = 493

Mais quel sens faut-il donner à la transformation en hexadécimal du nombre binaire correspondant aux droits ?
Aucun : ça n'a aucun sens. Il s'agit cependant d'un excellent entraînement pour passer maintenant à l'octal.
Les bits sont cette fois regroupés par séries de 3 avec les valeurs 4, 2, 1.
Pour le reste nous procédons de la même façon :


Le nombre décimal équivalent est évidemment inchangé :

7x64 + 5x8 + 5 = 493

Cette fois, ça a du sens.
Plutôt que d'adapter les droits sur quisuisje avec
chmod (g-w) quisuisje
on aurait pu les fixer directement :
chmod 755 quisuisje

Les droits rwx pour un dossier n'ont pas la même signification que pour un fichier :
r droit de lire le répertoire
w droit d'y ajouter ou d'y supprimer des fichiers
x droit d'y aller (dans le dossier)
Je crée dossier puis j’enlève les droits r et x aux utilisateurs qui ne sont ni toto (c’est moi) ni ses amis (membres du groupe toto) :


Au fait quels sont mes amis ?


Seulement riri.
Donc titine n’a pas le droit d’aller dans dossier :


Je rétablis le droit x pour tous. Cette fois titine peut aller dans dossier mais elle ne peut y lire le répertoire (il lui manque le droit r) :


Pour finir je donne à tous les droits rwx sur dossier (chmod 777 dossier).
Mais si un utilisateur à le droit de supprimer des fichiers, il peut tous les supprimer, même ceux qui ne sont pas à lui, même ceux pour lesquels il n'a pas le droit d'écriture!
Ainsi sur la copie d'écran qui suit, riri supprime le fichier hello appartenant à titine :


C'est ici qu'intervient le sticky bit :



S'il est activé pour un dossier dans lequel tous peuvent écrire, chacun ne pourra y supprimer que ces propres fichiers.

Activation :


Vérification:


Les droits sur le dossier sont maintenant décrit par la chaîne rwxrwxrwt et hello est à l'abri de toute suppression (sauf par son propriétaire titine ou toto propriétaire du dossier).
Le nom sticky bit provient d’un usage ancien de ce bit qui n’est pas celui expliqué ici.

Je peux aussi activer pour dossier le bit setgid :



Tout fichier créé par titine (comme salut) sera dorénavant caractérisé par le groupe toto (groupe du dossier de travail):


Comme riri appartient au groupe toto, il pourra donc modifier ce fichier.

Je veux maintenant faire machine arrière : remettre sur off les 2 bits spéciaux qui ont été activés :


Ça fonctionne pour le sticky bit (rwt devient rwx) avec chmod en mode numérique.
Pour le bit setgid, il faut utiliser chmod en mode symbolique.

Un dernier droit spécial n'a pas été évoqué jusqu'à présent.

Afin de pouvoir montrer sur une exemple ce dont il s'agit, je recopie l'exécutable whoami dans mon dossier test :


Comme je suis propriétaire de cette copie de whoami, je peux lui attribuer les droits que je veux.
Aussi j'active pour cet exécutable le bit setuid :



Pour ma copie de whoami lancée par titine, tout se passe comme si c'était moi (toto) qui l'avait lancée. Le whoami d'origine n'est évidemment pas impacté.
Pourquoi ne pas avoir avoir utilisé le fichier quisuisje pour ce qui précède?
Tout simplement parce que pour des raisons de sécurité le bit setuid est désactivé pour les fichiers scripts exécutables.

samedi 9 janvier 2016

Google-earth Fedora vs openSuse

Comme je l'ai indiqué dans le billet précédent, le paquet téléchargé ici pour Fedora 64 bits (à savoir le paquet google-earth-stable_current_x86_64.rpm) n'est pas installable suite à un conflit avec le fichier /usr/bin du paquet filesystem.
J'ai expliqué comment remédier à ce problème: supprimer la ligne

%dir %attr(0755, root, root) "/usr/bin"

dans le fichier spec du paquet (voir le billet précédent).

Cependant sur la page de téléchargement on peut constater que le paquet destiné à openSuse est le même que celui pour Fedora.
Et dans openSuse, l'installation de ce même paquet ne pose aucun problème!
Quel est ce mystère?
La réponse se trouve du côté du fichier /usr/bin fourni par filesystem.
Dans openSuse:




Les droits sur /usr/bin sont du type 0755, exactement comme dans le fichier spec.

Dans Fedora (23):




Les droits ne correspondent plus: ils valent 0555 ce qui provoque le conflit.

Plutôt que de supprimer la ligne litigieuse du fichier spec, il suffit de la modifier.


Donc je lance la commande


toto@rigel:~/Téléchargements$ rpmrebuild -p -e google-earth-stable_current_x86_64.rpm 

Ensuite dans l'éditeur qui s'ouvre (normalement c'est vi), je trouve la ligne ad hoc avec

/usr\/bin

J'amène à l'aide des flèches le curseur sur le 7, puis:

r5
:wq

A la question qui vient, je réponds que je veux continuer, ce qui provoque la création d'un nouveau paquet qu'il suffit d'installer.