XFCE Wheezy

Support Debian
#1

Bonsoir à tous,

La der des der pour cet upgrade qui se sera, somme toute, bien passé. En fait il y en a trois, mais qui à mon sens relèvent de la même eau.

  1. Plus de montage automatique de mes clés USB :

Échec au montage de "32 GB Filesystem". Not Authorized.
Mais je peux les monter manuellement. Je peux aussi les monter automatiquement, pourvu que je sois logué (mode graphique, donc…) en root !

  1. Panneau de déconnexion très réduit, je n’ai plus le reboot, l’arrêt, l’hibernation. Sauf bien sûr en me loguant en root etc…

  2. Et enfin devant les sites demandant un mot de passe, le sombre message m’en demandant un, lui, pour déverrouiller le trousseau de clés.

Cela inspire-t-il quelqu’un, et suis-je le seul dans ce cas ?

#2

Bonjour,
thunar-volman est-il installé ?

#3

Yes, il y est. Et maintenant me vient un doute absolument horrible, c’est que cette situation ne corresponde qu’à un vieux tour de vis, chez Wheezy, en matière de sécu. Mais alors comment arrêter les machines, utiliser nos clés USB, et puis ce trousseau à déverrouiller à tout bout de champ ?

#4

Bonjour,

Menu des applications
Disques amovibles et médias

regarde là, peut-être y a-t-il un élément salvateur

à+

#5

Bizarre, avec mon install propre « Debian-XFCE » d’avril en testing de l’époque, je n’ai aucun des soucis que tu rencontres.

Quand tu parles d’upgrade, tu « upgrades » depuis quoi ? (Squeeze/Lenny/Etch ? depuis combien de temps ?)

#6

[quote]Menu des applications
Disques amovibles et médias[/quote]
OK merci je regarde. Mais il faut d’abord que je l’exhume, je l’ai enterré (tous ces menus) soigneusement il y a deux ans ! Mais je n’avais rien détruit, seulement caché…

#7

Depuis Squeeze, le treize juillet, avec les trois temps réglementaires et rien en mode graphique :

  1. apt-get update ;
  2. apt-get upgrade ;
  3. apt-get dist-upgrade ;
    les headers derrière pour le driver Nvidia et tout était réglé, plutôt pas trop mal fors ces bavures.

On les retrouve un peu partout, mes trois trucs, les gars en font état plutôt individuellement, sous Ubuntu ou Debian, sous XFCE, en upgrade ou première installation, donc finalement ce ne serait pas lié à Wheezy. Quant aux solutions, le plus souvent il n’y en a pas, ou alors c’esr de l’Ubuntu pur…

#8

OK, il s’agit d’un dist-upgrade depuis une Squeeze…

Mon conseil :
– essaie de créer un nouvel utilisateur pour voir s’il souffre des mêmes problèmes (ça peut donner une indications)
– si tout ou partie de tes problèmes sont résolus, essaie de dégager les fichiers de config (un peu comme les ~/.gconf ~/.gconfd ~/.gnome* pour GNOME 2), puis fermeture et réouverture de session utilisateur; par exemple “mv ~/.gconf ~/.gconf_old”

Je dirais que tes problèmes 2 et 3 ont de bonnes chances d’être résolus ainsi. Ensuite pour le problème 1, je pense qu’il faut voir de ce côté :
http://www.debian-fr.org/detecter-une-cle-usb-quand-elle-est-branchee-t43953.html

Il est possible que le système de gestion des « disques amovibles » ait beaucoup changé depuis Squeeze. En recoupant avec le lien plus haut, peut être ton système utilise-t-il usbmount :
– usbmount est-il installé ?
– udev et pmount sont-ils installés ?

Je parierais sur un truc comme ça : mauvaise solution de gestion de disques amovibles ou conflits entre plusieurs solutions ou solution « partiellement installée », par sur un soucis de config utilisateur de XFCE me paraît assez improbable.

#9

Chou blanc ! Et en allant voir les configurations des supports amovibles etc., et surtout en renommant mes fichiers et répertoires de configuration, gnome2 gconf etc. Dommage, là j’y croyais…

A mon avis ce n’est pas technique à proprement parler, c’est une espèce d’obstruction en matière de droits qui s’est logée quelque part…

#10

M’est avis que les ~/.gnome* ne sont pas utilisés par XFCE, mais plutôt des reliquats de l’histoire, tests de GNOME ou utilisation d’applications de l’écosystème GNOME.

Crée un nouvel utilisateur, et logue toi en tant que lui. Fait tes tests : tu sauras vite si le système est pourri ou si seul ta config utilisateur est pourrie. Cerise sur le gâteau, un petit « ls -la ~ » te donnera les répertoires de fichiers de config par défaut.

#11

Je viens de faire la manip : il y a un spot de fichier de config dans ~/.config, il y a un répertoire ~/.gconf.

Pour créer l’utilisateur test, en root :

puis tu réponds aux questions, mot de passe etc… puis délog puis relog en temps qu’utilisateur « test » sous XFCE. Ensuite tu peux voir si cet utilisateur a les mêmes problèmes que ton vieux compte.

Cadeau : le contenu des répertoire ~/.config ~/.gconf par défaut pour un nouvel utilisateur…

[code]# tree -a -L 3 ~test/.config
/home/test/.config
├── autostart
│ └── xfce4-settings-helper-autostart.desktop
├── Thunar
│ └── accels.scm
├── user-dirs.dirs
├── user-dirs.locale
└── xfce4
├── desktop
│ └── icons.screen0.rc
├── panel
│ ├── launcher-10
│ ├── launcher-11
│ ├── launcher-12
│ └── launcher-9
├── xfconf
│ └── xfce-perchannel-xml
└── xfwm4

12 directories, 5 files

tree ~test/.gconf

/home/test/.gconf/
└── apps
├── %gconf.xml
└── nm-applet
└── %gconf.xml
[/code]

#12

Ave à toi, et bravo et merci pour cette balèze arborescence,

J’avais à peine reposé la plume que je repensai au .config, lequel bien sûr en est plein. Du coup je viens de le faire sauter à son tour, et malheureusement après reboot mes trois horreurs sont toujours là. Reste plus que le adduser, donc, mais même lui j’ai bien l’impression que ce sera infructueux, comme pour ceux chez qui je l’ai lu. De toutes manières le réinstall pur et dur ne me garantit nullement d’en sortir, dès lors que l’on rencontre là encore des cas, et alors il n’y a plus rien d’autre à faire que trouver ce qui se passe, et qui en l’occurrence ne semble pas annoncer quelque chose de catastrophique.

#13

Bon courage, en effet ça n’a pas l’air de venir de la config utilisateur. Le nouvel utilisateur vierge peut t’en donner la preuve finale.

Prochaine étape :
– séparer /home et système en 2 partitions (si ce n’est déjà fait)
– faire une archive de ton /home (optionnel, sait-on jamais, et ça ne fait pas de mal)
– créer une nouvelle partition pour un nouveau système (optionnel, ça te permet de garder ton système actuel, le temps de tout tester)
– faire une install propre de Wheezy XFCE en pointant sur ton /home (potentiellement, faire une listing de tous les paquets supplémentaire à installer, et des manips particulières à mettre en œuvre)
– compter les morts, conserver le bon (j’adore le concept 2 (à 3) partitions système + un /home)

Je ne vois pas pourquoi ça continuerait à chier dans la colle après une réinstallation fraîche du système…

#14

Il n’y aurait pas par hasard du sudo là-dessous ? Vieille idée qui a mis du temps à se préciser… Je n’utilise jamais sudo, toujours su. A l’upgrade j’ai dit d’écraser les fichiers de configuration, de mettre des standards, seulement comme je n’avais touché à rien je ne retrouve pas de .old. En attendant voici mon /etc/sudoers :

[code]#

This file MUST be edited with the ‘visudo’ command as root.

Please consider adding local content in /etc/sudoers.d/ instead of

directly modifying this file.

See the man page for details on how to write a sudoers file.

Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

Host alias specification

User alias specification

Cmnd alias specification

User privilege specification

root ALL=(ALL:ALL) ALL

Allow members of group sudo to execute any command

%sudo ALL=(ALL:ALL) ALL

See sudoers(5) for more information on “#include” directives:

#includedir /etc/sudoers.d
[/code]
La tentation serait grande de …

#15

Pour info, mon /etc/sudoers a le même contenu que le tien.

Ci-après quelques infos sur les groupes de mes utilisateurs si ça peut t’aider vu que tu as l’air de creuser une piste plus permissions (mon compte = « mon_user », « test » est le nouvel utilisateur crée pour le ce fil) :

$ id mon_user uid=1000(mon_user) gid=1000(mon_user) groupes=1000(mon_user),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),103(netdev),105(scanner),110(bluetooth) $ id test uid=1001(test) gid=1001(test) groupes=1001(test)

J’ai masse de groupes pour l’utilisateur « mon_user », et rien du tout pour « test ». Du coup je me pose des questions, sur ces histoires de permissions. Tiens donc, il faudra que je fasse quelques tests. Et surtout je me demande comment tous ces groupes ont pu arrivés pour « mon_user ».

#16

user@CHE:~/Bureau$ id user uid=1000(user) gid=1000(user) groupes=1000(user),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev),115(powerdev),116(scanner)
Très comparable, donc.

Je pense en effet que cela tourne autour d’une affaire de rang de permissions, de statut, avec peut-être quelque chose de propre à XFCE. A mon avis cela doit être assez simple, mais ce que je ne comprends pas, c’est pourquoi cela arrive si peu. En revanche c’est un phénomène qui a l’air assez vieux, et lié à n’importe quelle upgrade ou installation, Debian, Ubuntu, autres, et donc non restreint à mon actuelle bascule Squeeze-Wheezy.

#17

Bonjour,

peut-être faut-il chercher du côté de policyKit?

à+

#18

Riche idée, je découvre tout un monde. Merci à toi !

Ce que je cherche maintenant, c’est un panneau d’autorisations pour XFCE. J’ai l’impression que c’est comme cela qu’il faut paramétrer PolicyKit, non dirctement. Et un tel panneau, j’en ai bien vu un en screenshot, mais pour Gnome. Damned de damned ! Même sans m’en servir, d’ailleurs, mais histoire de voir ce qui a pu se passer lors de l’upgrade en Wheezy, si un fichier de configuration a sauté, ou si au contraire j’en ai trop.

#19

Je reviens sur mon idée de déclaration des droits utilisateur directement dans XFCE : visiblement, au travers des discussions, dans Gnome il y a tout un panneau pour cela, mais dans XFCE ? Ne ferait-il pas partie d’un paquet peu courant, non installé automatiquement ?

Je me rends bien compte que sur le fond ces affaires de droits tournent autour de Sudoers et de Policykit, mais dans les deux cas il n’a guère l’air conseillé d’aller taper directement dans les fichiers (/etc/pam.d), d’abord ce n’est pas beaucoup prévu pour cela, ensuite cela ne semble pas très efficient.

De toutes manières c’est uniquement l’upgrade en Wheezy qui a causé ces désordres, donc ça doit être gros comme une maison, et voilà pourquoi je pencherais pour un bon vieux fichier de config manquant.

#20

[quote]Ce problème étant toujours d’actualité, voici une solution pour une session démarrée via startx :
installer libpam-ck-connector
éditer /etc/pam.d/common-session et ajouter session optional pam_loginuid.so
avant session optional pam_ck_connector.so nox11

N’ayant pas trouvé de solution fonctionnant avec Slim, je l’ai remplacé par LightDM.[/quote]

(D’un bien utile fil de 2011)

Bon alors et pour XDM ? Parce que, finalement, si je réinstallais une Wheezy ex nihilo au lieu d’avoir upgradé, je retomberais sur le problème tant que je reste en XDM ? Bizarre quand même, il doit y avoir un moyen…