Journal Ma simple session avec Compiz et Cairo-dock

18
17
juil.
2011

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 (page perso) . Évalué à 9.

    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.

    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 (page perso) . É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 . Évalué à 6.

        Ce n'est pas précisément ce que fait sudo ?

        • [^] # Re: Gestion des droits

          Posté par (page perso) . É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 . Évalué à 10.

            Non, sudo ne permet que de demander le mot de passe de l'utilisateur.

            # /etc/sudoers
            
            # autoriser bob à lancer ls avec mot de passe
            bob ALL = /bin/ls
            
            # autoriser bob à utiliser ls sans mot de passe
            bob ALL = NOPASSWD: /bin/ls
            
            # autoriser tout court
            ALL ALL = NOPASSWD: /bin/ls
            
            # refuser à tout le monde
            # rien à faire
            

            Pour autoriser l'utilisateur à condition qu'il ait le mot de passe root, c'est la commande "su".

            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.

            Vous parlez de "sudo -l" ?

            • [^] # Re: Gestion des droits

              Posté par (page perso) . Évalué à 1.

              Vous parlez de "sudo -l" ?

              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 . Évalué à 8.

                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.

                Heu ... lol ? man sudoers. C'est le rôle du deuxième champ.

              • [^] # Re: Gestion des droits

                Posté par . Évalué à 1.

                qui sont grisée mais débloquable avec le mot de passe root par exemple

                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 . É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 . Évalué à 3.

            ConsoleKit permet de n'autoriser que quelques actions à une appli tandis qu'elle reste sous l'identifiant qui l'a lancé.

            Encore une fois, sudo permet cela :

            # autoriser bob à lancer ls -l /root, mais pas ls -l -a ni ls -l /root -a
            bob ALL = NOPASSWD: /bin/ls -l /* , !/bin/ls -l * *
            
            • [^] # Re: Gestion des droits

              Posté par (page perso) . É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 . Évalué à 6.

                Je pense que les actions autorisées sont au niveau des appels système.

                Je n'ai pas du tout l'impression que c'est ce que fait policykit. Mais si vous avez un lien, allez-y.

                Imagine que l'on puisse faire un buffer overflow avec ls. On pourrait tout faire en root, comme supprimer les fichiers.

                *Kit ne fonctionne pas en root ?

                • [^] # Re: Gestion des droits

                  Posté par . É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 . É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 . É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 . É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 . Évalué à 3.

                    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.

                    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 . É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 . Évalué à 0.

            ça tombe bien j'utilises que su

      • [^] # Re: Gestion des droits

        Posté par . É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 . É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 . É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 . Évalué à 9.

            On ne va pas non plus s'amuser à créer des dizaines de groupes pour affiner les permissions.

            Pour ne pas créer de groupes en plus, on :

            • créer un deamon
            • on perd la centralisation des droits (il y en a un peu dans les /etc/passwd et un peu dans policy-kit)
            • on perd la compatibilité unix
            • on doit réécrire tout un tas d'applications pour qu'elles s'interfacent à policy-kit
            • on perd la distribution des droits sur un parc de machines

            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 . Évalué à 5.

              on a créé un deamon

              Ouais...

              on perd la centralisation des droits (il y en a un peu dans les /etc/passwd et un peu dans policy-kit)

              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...

              on perd la compatibilité unix

              ??? Ça tourne sur Linux... La compatibilité, c'est a niveau des droits classique Unix (RWX) ? Ben ça s'ajoute...

              on doit réécrire tout un tas d'applications pour qu'elles s'interfacent à policy-kit

              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.

              on perd la distribution des droits sur un parc de machines

              Muf ?

              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.

              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

              C'est beau le progrès.

              Ouais.

            • [^] # Re: Gestion des droits

              Posté par (page perso) . Évalué à 1.

              on perd la centralisation des droits (il y en a un peu dans les /etc/passwd et un peu dans policy-kit)

              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 . É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 (page perso) . Évalué à -2.

            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

            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 . É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 . É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 . Évalué à 10.

        Et, accessoirement, à éviter qu'on ait le soupçon que Linux fait du sur-place.

  • # Great !

    Posté par . É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 . É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 . É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 . É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 . Évalué à 2.

      Je ne vais pas virer gdm, mon ordinateur e a plusieurs utilisateurs: moi et mes enfants.

      • [^] # Re: gdm

        Posté par (page perso) . Évalué à 3.

        Je te suggèrerais d'utiliser Slim ( http://slim.berlios.de/ ).

        • [^] # Re: gdm

          Posté par . É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 . É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 . É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 . Évalué à 5.

    Qui a dit que Linux n'était pas prêt pour le bureau?

    • [^] # Re: Il fallait y penser

      Posté par . É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 . Évalué à 0.

        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.

        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 . É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 (page perso) . Évalué à 2.

            ça devrait être un truc du genre

            <match action="org.freedesktop.upower.suspend">
              <match group="power">
                <return result="yes"/>
              </match>
              <match group="adm">
                <return result="yes"/>
              </match>
            </match>
            

            « 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 . Évalué à 8.

              Tu n'es même pas obligé de faire du XML.

              Tu listes les actions :

              $ pkaction | grep upower
              org.freedesktop.upower.hibernate
              org.freedesktop.upower.qos.cancel-request
              org.freedesktop.upower.qos.request-latency
              org.freedesktop.upower.qos.request-latency-persistent
              org.freedesktop.upower.qos.set-minimum-latency
              org.freedesktop.upower.suspend
              

              Puis on crée /var/lib/polkit-1/localauthority/50-local.d/power.pkla (cf man pklocalauthority) :

              [Normal Staff Permissions]
              Identity=unix-group:power
              Action=org.freedesktop.upower.suspend
              ResultAny=no
              ResultInactive=no
              ResultActive=yes
              

              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 . É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 :

              • tu crées l'action et les autorisations de base dans un fichier XML dans /usr/share/polkit-1/ (avec l'extension .policy) ;
              • tu crées si besoin d'autres autorisations dans /var/lib/polkit-1/50-local.d/ (comme au dessus) ;
              • tu lances la commande avec 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 . É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 . É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 . Évalué à 3.

                    À 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.

                    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 . É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 . Évalué à 2.

        Humour? Second degré?

        • [^] # Re: Il fallait y penser

          Posté par . É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 (page perso) . É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 . Évalué à 2.

        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.

        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 . É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 . Évalué à 1.

    je ne sais pas si le dbus-launch est nécessaire.

    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 . É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 . É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 . É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):

    #!/bin/bash
    
    cd $HOME
    eval `dbus-launch --sh-syntax --exit-with-session`
    ck-launch-session lxsession -s Compiz
    
    • [^] # Re: Correction importante

      Posté par . Évalué à 1.

      J'ai oublié de repréciser le nom du fichier en question:

      $ cat /usr/local/bin/startCompiz
      #!/bin/bash
      
      cd $HOME
      eval `dbus-launch --sh-syntax --exit-with-session`
      ck-launch-session lxsession -s Compiz
      
      • [^] # Re: Correction importante

        Posté par . Évalué à 1.

        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.

        T'as cherché du côté de fusion-icon ? Je crois que ça suffit pour lancer un Compiz standalone. Ça donnerait :

        $ cat /usr/local/bin/startCompiz
        #!/bin/bash
        cd $HOME
        eval `dbus-launch --sh-syntax --exit-with-session`
        ck-launch-session fusion-icon
        
  • # Une session, kézaco ?

    Posté par (page perso) . É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 . É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" :-)

    Avant les droits sous unix, c'était simple

    Oui, effectivement... Ha non en fait c'était :

    Avant, les droits sous unix c'était simple

    ha oui.
    okok je ->

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.