Sommaire
Je continue mon exploration de ma nouvelle machine, et j'ai (dès le départ)
profité de Compiz pour agrémenter l'expérience utilisateur. Ce que j'aime dans Compiz c'est le placement des fenêtres sur la moitié droite et la moitié gauche en un raccourci clavier, le cube avec les engrenages, et les fenêtres qui se déforment. C'est gadget, sauf le placement. Mais mon précédent ordinateur avec une nvidia non supporté, il marchait sans 3D.
Je n'ai pas eu de mal avec compiz, il y a juste une commande absconse à taper pour dire à gnome de l'utiliser:
gconftool-2 --type string --set /desktop/gnome/session/required_components/windowmanager compiz
Et puis j'ai aussi découvert cairo-dock. Et là je dois avouer que j'ai été assez épaté. Je me suis donc dit: adieu gnome, au revoir xfce4, je me mets un bureau compiz et cairo-dock, le plus simple possible.
Une session compiz & cairo-dock
On pourrait se dire c'est trop facile, on installe le packet cairo-dock-compiz-session, et basta! Mais je n'ai pas trouvé un tel packet.
Ce que j'ai trouvé, c'est un tas de solutions pour faire tourner compiz et cairo-dock sous xfce4 ou sous gnome (par exemple: tuer xfwm4 et lancer compiz dans une action automatique au démarrage, lancer cairo-dock de même).
Mais non, je ne veux pas vraiment une session xfce4 ou gnome (ou kde) sans panels mais avec cairo-dock à la place. Je veux un truc simple: une session compiz avec cairo-dock. Paramétrer les gestionnaires de session de gnome ou xfce4 pour obtenir ça ne semble pas très simple.
Avec lxsession
J'ai fini par trouver une solution: lxsession. C'est un gestionnaire de session tout simple (celui de LXDE). La configuration tient en deux fichiers, à placer dans un répertoire Compiz sous /etc/xdg/lxsession:
Le premier fichier contient la liste des programmes à lancer au démarrage. on place un '@' devant s'il doit être relancé en cas de crah (si j'ai bien compris):
$ cat /etc/xdg/lxsession/Compiz/autostart
@xscreensaver -no-splash
@cairo-dock -o -e xfce
@/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1
Le fichier pour LXDE m'a servi de modèle. Je ne sais pas à quoi peut bien servir le /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 et je sens que je vais essayer sans (plus c'est simple mieux ça marche).
Le second fichier contient la configuration du WM, on peut y ajouter le thème de GTK par exemple:
$ cat /etc/xdg/lxsession/Compiz/desktop.conf
[Session]
window_manager=compiz
[GTK]
sNet/ThemeName=Clearlooks
sNet/IconThemeName=nuoveXT2
sGtk/FontName=Sans 10
iGtk/ToolbarStyle=3
iGtk/ButtonImages=1
iGtk/MenuImages=1
iGtk/CursorThemeSize=18
iXft/Antialias=1
Une fois qu'on a fait ça on peut lancer la session par
lxsession -s Compiz
Plus qu'à demander à à GDM3 de proposer ça comme choix. Deux fichiers sont nécessaires. Le premier semble devoir se placer dans /usr/share/xsessions/ (je ne suis pas arrivé à le faire marcher en le plaçant sous /usr/local/share/xsessions/, ce qui aurait été l'endroit normal pour moi)
$ cat /usr/share/xsessions/compiz.desktop
[Desktop Entry]
Version=1.0
Name=Compiz Session
Name[fr]=Session Compiz
Comment=Use this session to run Xfce as your desktop environment
Comment[fr]=Utilisez cette session pour exécuter Compiz comme environnement de bureau
Exec=startCompiz
Icon=
Type=Application
Le second est le script de lancement indiqué, lui fonctionne sous /usr/local
$ cat /usr/local/bin/startCompiz
#!/bin/bash
cd $HOME
eval `dbus-launch --sh-syntax --exit-with-session`
/usr/bin/X :0.0 -br -audit 0 -nolisten tcp vt7 &
export DISPLAY=:0.0
sleep 1
#compiz-manager decoration move resize > /tmp/compiz.log 2>&1 &
# add more apps here if necessary or start another panel, tray like pypanel, bmpanel, stalonetray
ck-launch-session lxsession -s Compiz
(J'ai piqué ça chez Arch), je ne sais pas si le dbus-launch est nécessaire.
Faire marcher cairo-dock
Il ne vous aura pas échappé que cairo-dock est lancé par lxsession avec une option de compatibilité avec XFCE:
cairo-dock -o -e xfce
En effet sans une telle option (en gros xfce/gnome/kde) l'applet qui affiche les raccourcis reste vide. J'ai choisis xfce parce que je présume que c'est la solution la moins lourde entre les trois. En attendant lxde, qui aurait l'avantage d'être léger et compatible avec lxsession.
En effet il y a un problème: il est impossible de se déloguer avec l'applet idoine: elle appelle xfce4-session-logout qui ne marche pas avec lxsession. On peut bien sûr remplir à la main la configuration de l'applet et forcer lxsession-logout, mais chaque utilisateur devra faire de même; j'ai choisi plus simplement de détourner xfce4-session-logout.
Détournement de xfce4-session-logout
Sous debian le détournement de fichier se fait ainsi:
dpkg-divert --divert /usr/bin/xfce4-session-logout.real --rename /usr/bin/xfce4-session-logout
Ça revient à un mv /usr/bin/xfce4-session-logout /usr/bin/xfce4-session-logout.real en plus costaud.
Plus qu'à installer à la place du fichier détourné un script qui appelle le bon programme de sortie:
$ cat /usr/bin/xfce4-session-logout
#!/bin/sh
if pidof lxsession 2>&1 > /dev/null ;
then
lxsession-logout ;
else
xfce4-session-logout.real $@ ;
fi
Avant les droits sous unix, c'était simple
Voilà, en théorie ça devrait marcher. Et ça marche! J'obtiens bien le menu de lxsession-logout avec ses nombreux boutons, mais suspendre et hiberner ne marchent pas. Et le problème semble connu, j'ai toutefois eu du mal à le contourner. Je vous donne le truc.
Le problème provient de UPower. Ce bidule utilise pour gérer les droits un truc parfaitement abscon: PoliciKit. lxsession-logout ne semble pas s'y identifier comme une session active, et seules les sessions actives peuvent utiliser UPower. J'ai du autoriser les sessions inactives dans /usr/share/polkit-1/actions/org.freedesktop.upower.policy (un autre fichier de configuration qui n'est pas dans /etc ?)
$ cat /usr/share/polkit-1/actions/org.freedesktop.upower.policy
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
"-freedesktopDTD PolicyKit Policy Configuration 1.0//EN"
"http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd">
<policyconfig>
<vendor>The UPower Project</vendor>
<vendor_url>http://upower.freedesktop.org/</vendor_url>
<icon_name>system-suspend</icon_name>
<action id="org.freedesktop.upower.suspend">
<description>Suspend the system</description>
<description xml:lang="fr">Mettre le système en veille</description>
<description xml:lang="it">Sospende il sistema</description>
<description xml:lang="pl">Wstrzymanie systemu</description>
<description xml:lang="sv">Försätt systemet i vänteläge</description>
<message>Authentication is required to suspend the system</message>
<message xml:lang="fr">Vous devez vous identifier pour mettre le système en veille</message>
<message xml:lang="it">È richiesto autenticarsi per sospendere il sistema</message>
<message xml:lang="pl">Wymagane jest uwierzytelnienie, aby wstrzymać system</message>
<message xml:lang="sv">Autentisering krävs för att försätta systemet i vänteläge</message>
<defaults>
<allow_inactive>yes</allow_inactive>
<allow_active>yes</allow_active>
</defaults>
</action>
<action id="org.freedesktop.upower.hibernate">
<description>Hibernate the system</description>
<description xml:lang="fr">Mettre le système en hibernation</description>
<description xml:lang="it">Iberna il sistema</description>
<description xml:lang="pl">Hibernacja systemu</description>
<description xml:lang="sv">Försätt systemet i viloläge</description>
<message>Authentication is required to hibernate the system</message>
<message xml:lang="fr">Vous devez vous identifier pour mettre le système en hibernation</message>
<message xml:lang="it">È richiesto autenticarsi per ibernare il sistema</message>
<message xml:lang="pl">Wymagane jest uwierzytelnienie, aby zahibernować system</message>
<message xml:lang="sv">Autentisering krävs för att försätta systemet i viloläge</message>
<defaults>
<allow_inactive>yes</allow_inactive>
<allow_active>yes</allow_active>
</defaults>
</action>
</policyconfig>
Avant les droits sous unix c'était simple. Il suffisait d'ajouter un utilisateur idoine dans le groupe adéquat et c'était réglé. Je sens que ce genre de machin va beaucoup m'énerver.
Voilà un bureau simple (si on peut qualifier Compiz et Cairo-dock de simples...) comme je les aime. Un seul petit inconvénient avec cairo-dock, le changement de thème semble faire sauter la configuration, les applets ajoutées, etc...
PS_qui_n_a_rien_a_voir: félicitations aux petites mains qui œuvrent quasiment en silence derrière ce site, la nouvelle version a des possibilités d'édition assez époustouflantes. Je viens de découvrir le menu automatique et la coloration syntaxique automatisée.
# Gestion des droits
Posté par erdnaxeli (site web personnel) . Évalué à 9.
J'avoue que je n'ai toujours pas compris l'intérêt de tous ces bidules en -kit.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: Gestion des droits
Posté par claudex . Évalué à 3.
L'intérêt, c'est de pouvoir réglé les permissions de manière plus fine. Ainsi au lieu de pouvoir autoriser ou non, tu peux autorisé mais demander à rentrer le mot de passe ou autoriser et demander le mot de passe root, autorisé tout cours ou refuser.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Gestion des droits
Posté par BFG . Évalué à 6.
Ce n'est pas précisément ce que fait sudo ?
[^] # Re: Gestion des droits
Posté par claudex . Évalué à 2.
Non, sudo ne permet que de demander le mot de passe de l'utilisateur. De plus, console-kit et ses cousins te permette de savoir à l'avance quelles sont tes droits et ce que tu dois faire pour éventuellement pouvoir exécuter l'action. Ce que ne permet pas sudo.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Gestion des droits
Posté par BFG . Évalué à 10.
Pour autoriser l'utilisateur à condition qu'il ait le mot de passe root, c'est la commande "su".
Vous parlez de "sudo -l" ?
[^] # Re: Gestion des droits
Posté par claudex . Évalué à 1.
Non pas du tout, je veux dire que quand je lance une applications graphique, je peux effectuer certaines actions mais pas d'autres (qui sont grisée mais débloquable avec le mot de passe root par exemple) et ça grâce à consolekit. Pour la même chose avec sudo, il faudrait relancer l'application pour obtenir ces privilèges.
Sinon, sudo ne gère pas du tout le fait que l'utilisateur soit connecté physiquement ou à travers le réseau, ce qui permet de ne pas donner les droits d'extinctions quand l'utilisateur est connecté via une session distante.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Gestion des droits
Posté par geb . Évalué à 8.
Heu ... lol ? man sudoers. C'est le rôle du deuxième champ.
[^] # Re: Gestion des droits
Posté par BFG . Évalué à 1.
Tout peut être débloqué avec le mot de passe root. Ce que "sudo -l" n'aurait pas retourné peut donc être fait avec le mot de passe root.
[^] # Re: Gestion des droits
Posté par zebra3 . Évalué à 5.
ConsoleKit est plus fin : quand sudo lance le processus en root, ConsoleKit permet de n'autoriser que quelques actions à une appli tandis qu'elle reste sous l'identifiant qui l'a lancé.
Plus sécurisé, donc.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Gestion des droits
Posté par BFG . Évalué à 3.
Encore une fois, sudo permet cela :
[^] # Re: Gestion des droits
Posté par yellowiscool . Évalué à -1.
Je pense que les actions autorisées sont au niveau des appels système. Cela permet de réduire les conséquences d'une éventuelle faille de l'application.
Imagine que l'on puisse faire un buffer overflow avec ls. On pourrait tout faire en root, comme supprimer les fichiers. Alors que si ls a seulement le droit d'obtenir des infos sur les fichiers et dossiers, une fois totalement sous contrôle du pirate, elle ne peut pas faire grand chose de plus que d'obtenir des infos.
Envoyé depuis mon lapin.
[^] # Re: Gestion des droits
Posté par BFG . Évalué à 6.
Je n'ai pas du tout l'impression que c'est ce que fait policykit. Mais si vous avez un lien, allez-y.
*Kit ne fonctionne pas en root ?
[^] # Re: Gestion des droits
Posté par zebra3 . Évalué à 0.
Pas l'appli qui demande les droits. Seul un démon minimal fonctionne en root, il n'exécute que les actions que l'appli est autorisée à faire.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Gestion des droits
Posté par barmic . Évalué à 2.
PK intercepte vraiment tout les appels système pour vérifier si c'est autorisé ou non ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestion des droits
Posté par zebra3 . Évalué à 1.
Il me semble que c'est pas une histoire d'appel système, ce sont des appels de fonctions définies dans PK.
À ce que j'ai compris, via dbus l'application demande au démon PK (dont une partie tourne en root) de lancer une action, le démon vérifie l'autorisation (en demandant un mot de passe si besoin), et le module qui tourne en root exécute la commande définie par l'action.
Tu as la liste des actions possibles sur ton système avec la commande pkaction.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Gestion des droits
Posté par barmic . Évalué à 4.
Donc il faut bien réécrire toute les appli pour qu'elles lancent toutes ces actions via PK et en fallback le fassent elle même.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestion des droits
Posté par BFG . Évalué à 3.
Personne n'a dit que vous deviez faire fonctionner tout GNOME en root pour que GNOME puisse faire "sudo shutdown -h now". sudo et shutdown sont d'ailleurs certainement plus minimaux que PolicyKit et UPower.
[^] # Re: Gestion des droits
Posté par BFG . Évalué à 5.
Trouvé dans un lien plus bas, et bien non, c'est exactement la même problématique qu'avec sudo.
[^] # Re: Gestion des droits
Posté par modr123 . Évalué à 0.
ça tombe bien j'utilises que su
[^] # Re: Gestion des droits
Posté par barmic . Évalué à 4.
Avant pour éteindre sa machine il fallait avoir les droits admins ou être dans le bon groupe. Quel est l’intérêt de demander un mot de passe supplémentaire pour le faire ? En quoi un sudo ne serait pas suffisant ?
Si c'est vraiment nécessaire un wrapper autour de halt ou shutdown ne serait pas plus simple ?
Cette configuration des *-kit est-ce qu'elle a au moins le bon goût d'être facilement centralisable ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestion des droits
Posté par BFG . Évalué à 4.
De ce que l'on peut voir, le fichier donné en exemple contient : configuration, documentation et traductions. Au moins l'un des trois n'a rien à faire là (dans le fichier, ou dans /usr).
[^] # Re: Gestion des droits
Posté par Laurent A. . Évalué à 4.
Je pense que ce lien répond à tes questions : http://hal.freedesktop.org/docs/PolicyKit/intro-define-problem.html.
PolicyKit cherche à rendre possible une configuration fine des permissions. Dans le cas que tu donnes, il n'est par exemple pas souhaitable de donner à tout un programme des droits élevés comme root juste pour pouvoir éteindre une machine. On ne va pas non plus s'amuser à créer des dizaines de groupes pour affiner les permissions.
Concrètement, un programme A demande à un programme B d'effectuer une action. B demande à PolicyKit si A en a le droit : si oui, l'action est effectuée, sinon A va devoir contacter PolicyKit pour obtenir une autorisation qui ensuite sera lue par B et l'opération pourra se faire. Cf. http://hal.freedesktop.org/docs/PolicyKit/model-theory-of-operation.html. Avec ce mécanisme, on voit que le programme A ne détient pas de droits particuliers.
[^] # Re: Gestion des droits
Posté par barmic . Évalué à 9.
Pour ne pas créer de groupes en plus, on :
C'est beau le progrès.
On aurait obtenus un résultat plus intéressant en utilisant les droits classiques (avec sudo à la rigueur) ou en passant par des capabilities. Bref en réutilisant l'existant.
Au final avec policy-kit^W^W^Wle MCP à quoi ils servent les droits unix ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestion des droits
Posté par Laurent A. . Évalué à 5.
Ouais...
Les droits ne décrivent pas la même granularité donc il n'y a pas vraiment de raison pour les mettre au même endroit. Les fichiers sont cependant regroupés s'ils utilisent PolicyKit...
??? Ça tourne sur Linux... La compatibilité, c'est a niveau des droits classique Unix (RWX) ? Ben ça s'ajoute...
On ne peut pas non plus ajouter éternellement des choses à l'existant sans efforts donc je ne suis pas choqué qu'il faille une adaptation.
Muf ?
Avec les ACL, il faut imaginer toutes les actions/opérations qu'un fichier va pouvoir subir. Avec PolicyKit, les permissions sont déplacées hors des fichiers pouvant subir l'opération.
Avec les ACL, les permissions sont permanentes, avec PolicyKit elles ne sont attribuées que dynamiquement et temporairement.
Avec les ACL, il me paraît difficile d'autoriser/refuser des opérations qui sont des appels à des méthodes distantes (penser à du RPC) à moins de faire une liste longue comme le bras d'attributs.
http://wiki.archlinux.fr/Policykit
Ouais.
[^] # Re: Gestion des droits
Posté par claudex . Évalué à 1.
Même remarque avec sudo.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Gestion des droits
Posté par B16F4RV4RD1N . Évalué à 10.
Non mais c'est génial les *KIT, d'ailleurs comme le laisse entendre le nom, ça te fait un OS en KIT, tu dois bidouiller dans des menus XML en rapport avec toutes les couches d'abstraction système, pour changer l'heure ou éteindre ton ordinateur.
Exemple simple dans un cas courant (vous vous y retrouverez sans doute tous là dedans). Tu es admin système dans une entreprise avec 30 salariés. Tu viens d'installer Ubuntu serveur dans une machine virtuelle XEN sur ton portable, cette machine virtuelle gère l'application métier de toute la boîte. Il ne s'agit pas de la faire redémarrer n'importe quand. Ainsi quand ton petit neveu (ou le fils du patron) vient te rendre visite dans l'entreprise, tu lui ouvres une seconde session (michujr), et il peut jouer à tuxkart, sans risque de modifier l'heure système ou de rebooter la machine. La secrétaire vient ensuite t'apporter un courrier, mais elle n'a pas de compilateur LaTeX sur sa machine. Tu lui ouvres une nouvelle session, et elle peut monter sa clé USB pour compiler le courrier.
Le week end, tu remportes le portable chez toi, et ta chère et tendre peut, au travers de sa session, monter le disque dur familial (par rapport au UUID unique) pour y stocker les photos de son appareil. Comme ça, tu es certain que si le disque dur de chez toi se retrouvait par hasard à ton bureau, la secrétaire ou le fils du patron depuis sa session ne pourrait pas retrouver tes photos de vacances pour les poster sur facebook à ton insu.
C'est simple (juste un fichier XML imbitable à éditer, dans /etc/TrucmuchKit/00-PrivateSeatUSB1/org.freedesktop.TrucmucheKit.service/usb-1 pour le port USB sur le côté, et /etc/TrucmuchKit/00-PrivateSeatUSB0/org.freedesktop.TrucmucheKit.service/usb-2 pour le port USB à l'arrière), fiable et convivial. Et surtout, beaucoup plus sécurisé que sudo.
Ah, par contre on me dit que dans 99% des cas les serveurs sont dans un espace protégé sans accès aux ports USB, et dans la même proportion à l'inverse les ordinateurs personnels en utilisation « desktop » sont utilisés par un seul utilisateur... bref, ces truc Kit ne servent absolument à rien, à part faire ch** le monde.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Gestion des droits
Posté par claudex . Évalué à -2.
Il y a des interfaces graphiques qui font ça très bien
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Gestion des droits
Posté par B16F4RV4RD1N . Évalué à 4.
je n'en ai pas trouvé qui permettent de faire autre chose que de lister une arborescence absconse, où il y aurait par exemple :
niveau de sécurité de l'accès des périph USB :
[ ] je suis chez moi, je veux y accéder tout le temps [ ] je travaille au FBI
etc
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Gestion des droits
Posté par imr . Évalué à 8.
J'avoue que je n'ai toujours pas compris l'intérêt de tous ces bidules en -kit.
A justifier le développement de l'usine à gaz suivante qui les remplacera, ainsi que les formations et les certifications qui les accompagnent.
[^] # Re: Gestion des droits
Posté par Antoine . Évalué à 10.
Et, accessoirement, à éviter qu'on ait le soupçon que Linux fait du sur-place.
# Great !
Posté par davandg . Évalué à 3.
Merci de nous faire partager cette petite bidouille !
Tu ne pourra pas mettre un petit screenshot de ce que ça donne ? (fait moi regretter la lourdeur de mon KDE !¹)
¹ Un troll se cache dans cette phrase, serra-tu le retrouver ?
[^] # Re: Great !
Posté par fleny68 . Évalué à 3.
compiz ne se voit pas, donc les screenshots c'est juste cairo-dock. Tu as plein de thèmes, avec des comportements très différents:
http://glx-dock.org/mc_album.php?a=3
Tu en as un qui ressemble assez fort à MacOSX, tu en as des sobres, des très amusants avec du feu sous les icones quand tu passes la souris...
Pour l'instant je tourne un peu entre tous les thèmes, je ne suis pas encore fixé sur mon préféré.
[^] # Re: Great !
Posté par Jokernathan . Évalué à 1.
Un grand merci !
Je voulais mettre ça en place depuis un bon moment, mais j'avais jamais trouvé le temps ! Voilà un journal qui va me faire gagner pas mal de temps ^^
# gdm
Posté par bubar🦥 (Mastodon) . Évalué à 3.
vire gdm, et écrit ton propre autologin, soit un hom(m)e ! blague à part sans gdm le bureau arrive encore plus vite. Et pour bloquer la session à l'allumage, xcreensaver peut s'en charger...
Sinon +1 pour cette "maxi astuce".
J'ai utilisé ça pendant "longtemps" sur mon netbook : cairo-dock + compiz (avec des icones super-zolis) en tant que session, et c'est bien agréable. Pcmanfm en renfort, et zou. La diff étant que je partait d'une session "failsafe" pour faire la session "cairo-dock", et que je modifiais lxsession-logout pour le support hibernation/suspend/éteindre. Plus qq autres trucs que j'aurais du noter, comme toi...
[^] # Re: gdm
Posté par fleny68 . Évalué à 2.
Je ne vais pas virer gdm, mon ordinateur e a plusieurs utilisateurs: moi et mes enfants.
[^] # Re: gdm
Posté par legranblon (site web personnel) . Évalué à 3.
Je te suggèrerais d'utiliser Slim ( http://slim.berlios.de/ ).
[^] # Re: gdm
Posté par zebra3 . Évalué à 8.
Slim, c'est pas un comlique décédé ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: gdm
Posté par Faya . Évalué à 1.
Slim est mon gestionnaire de session favoris mais il souffre d'un gros défaut :
Il ne permet pas d'ouvrir plusieurs sessions en même temps ! Par exemple, mettre la mienne en "pause" et en ouvrir une pour mon neveu.
Ou alors j'ai raté quelque chose ...
[^] # Re: gdm
Posté par Faya . Évalué à 1.
Bon, après très peu de recherches j'ai découvert qu'on peut en ouvrir une deuxième avec
startx -- :1
Par contre ça m'a complètement planté mon serveur moc ... Pourtant je ne vois pas trop le lien entre lui et X.
# Il fallait y penser
Posté par vladislav askiparek . Évalué à 5.
Qui a dit que Linux n'était pas prêt pour le bureau?
[^] # Re: Il fallait y penser
Posté par fleny68 . Évalué à 8.
Franchement, que Linux soit prêt ou pas pour le bureau on s'en fout.
Le jour ou quelqu'un veut proposer une session compiz/ciro-dock dans ubuntu, debian, ou fedora il peut ajouter un lxde-integration aux plugins cairo (xfce-integration semble assez simple), mettre ces quelques fichiers dans un .deb ou un .rpm, et ça roulera. Linux est utilisable sans ça, Linux est hautement hackable pour faire ce genre de truc même si personne n'a pensé à le faire avant, et c'est ça qui est important pour moi. Avec tous ces machins en PulseAudio/*Kit aux configurations imbittables, Linux devient de moins en moins hackable et ça c'est pas très cool.
[^] # Re: Il fallait y penser
Posté par Laurent A. . Évalué à 0.
Mais t'as lu au moins les liens que j'ai donné juste au-dessus ?! Comment fais-tu pour obtenir des configurations fines de permissions sans PolicyKit (ou équivalent) ?
[^] # Re: Il fallait y penser
Posté par fleny68 . Évalué à 9.
Non, mais ce n'est pas le but le problème: le but est peut-être très noble.
Prenons une question simple: je veux dire à PolicyKit que je veux que le programme lxsession-logout soit autorisé à mettre en veille et à suspendre (via UPower), je fais comment? Quel fichier de conf à écrire et à quel endroit?
Une autre: je veux que les utilisateurs du group power (ceux-là et les adm) puissent mettre en veille via upower?
J'ai cherché, mais je n'ai pas trouvé de pages claires pour m'expliquer comment écrire de telles configuration ni ou les écrire. C'est devenu tellement complexe (ah la joie des fichiers de conf en xml) que les utilisateurs mêmes avancés doivent y aller pifométriquement ou ne pas y toucher.
[^] # Re: Il fallait y penser
Posté par claudex . Évalué à 2.
ça devrait être un truc du genre
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Il fallait y penser
Posté par zebra3 . Évalué à 8.
Tu n'es même pas obligé de faire du XML.
Tu listes les actions :
Puis on crée /var/lib/polkit-1/localauthority/50-local.d/power.pkla (cf man pklocalauthority) :
Et tous les utilisateurs du groupe power ont le droit de faire un suspend, en plus tu peux le faire manuellement avec la méthode dbus qui va bien, ça se trouve avec d-feet et dbus-send. Et la conf est prise en compte automatiquement, sans relancer aucun démon.
Alors oui, c'est plus complexe, mais j'ai tout fait en partant de man polkit. Comme on dit, RTFM.
Reste que si les bureaux les plus utilisés y passent, il doit bien y avoir une raison. Je sais bien que les dév GNOME passent pour des manches (surtout ici), mais ceux de KDE sont paraît-il plus avisés (toujours d'après ce que je lis ici), donc leur choix doit avoir été réfléchi, non ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Il fallait y penser
Posté par zebra3 . Évalué à 2.
Je suis allé voir où il a besoin d'écrire du XML, c'est lorsque tu veux ajouter de nouvelles actions.
D'ailleurs, tu peux revenir à un comportement du type sudo avec pkexec (en CLI) et gksu-polkit (pour X). Tout est dans le man de pkexec :
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Il fallait y penser
Posté par barmic . Évalué à 4.
Pourquoi ces fichiers sont dans /usr et /var ?
Il y a pleins d'admin qui montent en lecture seule /usr et qui versionnent /etc.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Il fallait y penser
Posté par zebra3 . Évalué à 0.
À ce que j'ai compris, ceux dans /var c'est pour éviter que les politiques modifiées ne soient écrasées par celles par défaut lors de la mise à jour d'un paquet.
Pour ce qui est de /usr, il y a peut-être un autre endroit, je n'ai pas cherché.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Il fallait y penser
Posté par barmic . Évalué à 3.
yum/urpm n'ont pas de gestion des fichiers de configuration comme APT ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Il fallait y penser
Posté par fleny68 . Évalué à 2.
E plus maintenant les fichiers de conf sont souvent éclatés dans un dossier
comme pour apt /etc/apt/sources.d. La mise à jour d'un paquet ne risque pas de modifier des fichiers de conf ajoutés ainsi. /var et /usr ne sont vraiment pas des endroits ou mettre des fichiers de conf.
[^] # Re: Il fallait y penser
Posté par vladislav askiparek . Évalué à 2.
Humour? Second degré?
[^] # Re: Il fallait y penser
Posté par fleny68 . Évalué à 5.
Oui, je sais, mais j'en ai marre de cette rengaine qui veut que linux ne soit pas prêt pour le bureau.
[^] # Re: Il fallait y penser
Posté par Kekun (site web personnel, Mastodon) . Évalué à 2.
Comment ? Qu'ouïe-je ? Ça fait des années que je fais tourner mes machines avec des trucs pas prêts pour elles et personne me l'a encore dit ?
Remboursez mes dons !
[^] # Re: Il fallait y penser
Posté par barmic . Évalué à 2.
Non ! C'est probablement le genre de trucs qu'il vaut mieux directement proposer en amont.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Il fallait y penser
Posté par SQP . Évalué à 4.
c'est un sujet déjà ouvert chez cairo-dock, mais toutes les contributions sont bienvenues.
Compiz standalone
[^] # Re: Il fallait y penser
Posté par Étienne . Évalué à 2.
Maintenant qu'on a toutes les applications dans le cloud, il suffit d'un browser. Ce n'est pas Linux qui est prêt pour le desktop, c'est le desktop qui est prêt pour Linux.
Étienne
# DBus
Posté par YannPeniguel . Évalué à 1.
DBus est un canal de communication inter-processus. En un petit peu plus concret, c'est un démon qui permet à tes applications de communiquer ensemble. Sans DBus, certaines choses comme les notifications automatiques en barre des taches peuvent ne pas marcher, ou bien le fait d'afficher la chanson que tu écoutes dans ton logiciel de messagerie instantanée...
Bref, les fonctionnalités qui reposent sur le fonctionnement conjoint de plusieurs applications peuvent ne pas marcher si tu n'as pas DBus qui tourne.
Pour chaque personne qui me plussoie, je frappe un fan de Justin Bieber.
[^] # Re: DBus
Posté par fleny68 . Évalué à 1.
Je me demandais s'il n'était pas déjà lancé ailleurs, où s'il ne se lançait pas automatiquement à la demande.
[^] # Re: DBus
Posté par YannPeniguel . Évalué à 1.
A ma connaissance, les environnements de bureaux le lancent à l'ouverture de session, en général.
Cela dit, il ne dépend pas de X ni d'un WM... A toi de voir ce qui est en place sur ta machine. Interroge le service et voit si il a été lancé.
Pour chaque personne qui me plussoie, je frappe un fan de Justin Bieber.
# Correction importante
Posté par fleny68 . Évalué à 1.
à l'usage le fichier de lancement de lxsession ne marche pas si on demande un changement d'utilisateur. La faute à ce script de lancement de lxsession que j'ai trouvé sur le net.
Voici une version corrigé (en fait il n'y a pas besoin de lancer X):
[^] # Re: Correction importante
Posté par fleny68 . Évalué à 1.
J'ai oublié de repréciser le nom du fichier en question:
[^] # Re: Correction importante
Posté par Paul . Évalué à 1.
T'as cherché du côté de fusion-icon ? Je crois que ça suffit pour lancer un Compiz standalone. Ça donnerait :
# Une session, kézaco ?
Posté par 태 (site web personnel) . Évalué à 8.
À quoi ça sert une session ? Et qu'est-ce que c'est d'abord ?
C'est différent de ce que fait le xinitrc ?
# vi, je sais (...)
Posté par bubar🦥 (Mastodon) . Évalué à 9.
clairement, je ne suis pas le mieux placé pour faire ce type de remarque, disons que chacun a ses propres "maux aux yeux" :-)
Oui, effectivement... Ha non en fait c'était :
ha oui.
okok je ->
[^] # De la bonne utilisation des virgules
Posté par Davy Defaud . Évalué à 2.
Que voilà un bel exemple de l’utilité d’une ponctuation adaptée !
N’est‐ce pas Patrick ?! ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.