Le problème principal est le suivant: TOUTE SESSION DE GNOME ne se trouvant pas au sommet d'un affichage physique/natif réel --ou l'observation de cet affichage (c'est-à-dire le mode d'ombre de NXserver) - a des privilèges erronés. Même en tant que root!
Des commentaires sur un moyen de résoudre le problème de comportement pour les sessions VNC/non-shadow NX?
Quelques détails:
Pendant que je faisais les tests/la configuration avec un moniteur connecté , tout était parfait, à la fois assis devant ce moniteur et lorsque VNC est connecté à partir de mon ordinateur de bureau (dans vino).
Sans moniteur, bien que des problèmes surviennent:
Le premier premier problème était que vino était têtu et n’aimait pas charger avant/pendant GDM. Mais comme il s’agit d’un système sans tête, je n’en ai pas vraiment besoin pour commencer par X par défaut (c’est-à-dire changer le niveau d’initialisation) de toute façon, c’est donc un peu discutable. Cependant, je me rappelle distinctement que c'est très facile à faire dans une version plus ancienne d'ubuntu (v9.04 je pense). Et cela a bien fonctionné. mais plus maintenant!? ... de toute façon, j'ai complètement abandonné cette idée.
Ensuite c'était Unité/effets dérangeant VNC (résolu en trichant ).
Au départ, je suis passé sur NXserver en espérant que les problèmes suivants sont peut-être des problèmes tightvnc ou vino, mais pas de chance. (Note: lire round2)
Lors de l'accès à distance via VNC (ou NXserver), mon compte d'utilisateur perd la possibilité de monter/démonter des disques durs.
Lors de la communication à distance via VNC (ou NXserver), mon compte utilisateur ne peut accéder à certaines options de configuration privilégiées.
quelques exemples:
Je ne peux que supposer que cela a quelque chose à voir avec les privilèges de l'utilisateur qui ne sont pas attribués correctement lorsqu'un périphérique de moniteur physique réel n'est pas connecté.
La raison "POURQUOI" se produit dans Ubuntu 11.04, quand il est sans tête, m’échappe; Je ne me souviens pas de ce comportement dans les versions précédentes d'ubuntu.
Notez que le problème de montage du disque dur n’est pas un problème pour les disques internes/statiques (je les ajoute à fstab car ils sont statiques de toute façon). Mais vraiment une grande douleur pour les supports USB amovibles.
Le reste des problèmes, je n'ai pas trouvé comment résoudre ce problème ...
Je sais ce que vous pensez ... Connectez-vous à ssh, Sudo su, et exécutez vncserver entièrement sous root?
Surprise Surprise! L’interface graphique de root est également défectueuse: gparted n’obtient pas d’informations, les utilisateurs et les groupes sont entièrement estompés (il s’agit d’un comportement différent de celui de mon utilisateur habituel). Bizarrement, l'administration de l'écran de connexion semble bien fonctionner.
(REMARQUE: je ne sais pas si cela a eu ou non une incidence sur le résultat. À un moment donné, entre le tour 1 et le tour 2, j'ai appliqué les modifications mentionnées dans les posts # 21 et # 24 dans ce fil )
Les sessions régulières tightvnc/NXServer ont le même comportement, MAIS ...
Dans les paramètres de connexion NXClient, lorsque je choisis le mode "shadow" (shadow vous attache à l'affichage natif, c'est-à-dire que l'ombre sur le bureau) ...
Tout fonctionne parfaitement dans cette session!
Une chose que j’ai remarquée, c’est qu’il me demande immédiatement un mot de passe pour le trousseau de clés.
Mais, si je me connecte avec une connexion NX régulière (pas d’ombre), ou un vnc normal, cela revient à avoir les mêmes problèmes.
P.S. Il y a eu quelques jours où j'ai écrit round1 et round2 (je le conservais dans un fichier txt localement). Je testais diverses suggestions pour voir ce qui fonctionnerait. C'est pourquoi je ne sais pas vraiment si cette modification de périphérique VNC xorg.conf ou ce paramètre de nomodeset a eu un impact positif.
[EDIT 2011-06-10]
Au moment de la rédaction, j'avais configuré le système pour la connexion automatique, raison pour laquelle la connexion fantôme fonctionnait tout simplement. Plus tard, lorsque j'ai désactivé cela et redémarré le système, NX a donné une erreur, mais avec un peu de recherche sur Google, j'ai trouvé ce fil
Voici les modifications et commentaires que j'ai apportés à mon /usr/NX/etc/server.cfg:
EnableAdministratorLogin = "1"
EnableSessionShadowing = "1"
EnableInteractiveSessionShadowing = "1"
EnableSessionShadowingAuthorization = "0"
EnableDesktopSharing = "1"
EnableInteractiveDesktopSharing = "1"
EnableFullDesktopSharing = "1"
EnableAdministratorDesktopSharing = "1"
EnableDesktopSharingAuthorization = "0"
EnableSystemDesktopSharingAuthorization = "0"
(S'il s'agissait d'un réseau plus public, par exemple une université/un grand bureau, j'utiliserais probablement des paramètres un peu plus stricts, mais ceux-ci me conviennent parfaitement.)
Après un redémarrage, je me suis connecté avec nxclient au paramètre "shadow" (affichage natif) du bureau et j'ai obtenu GDM! :RÉ
Malheureusement, le presse-papier ne fonctionne pas dans la session "shadow" (cela fonctionne très bien pour les autres/les plus classiques)
[EDIT 2011-06-11]
Vous avez trébuché sur Xvfb mais les mêmes problèmes s’ils sont utilisés comme ceci:
Xvfb :2 -ac -screen 0 1280x1024x32 -pixdepths 8 24 2>&1 >/dev/null &
export DISPLAY=:2
gnome-session --session=2d-gnome 2>&1 >/dev/null &
x11vnc --display :2 --passwd blahblah
J'ai localisé le coupable.
Testé sur une nouvelle installation, confirmé que c'est un bogue.
J'ai soumis un rapport de bug
En résumé, le problème est le suivant: le dialogue d’authentification de polkit apparaît sur DISPLAY: 0 au lieu de DISPLAY: 1 où se trouve la session VNC/NX.
Une solution de contournement peut consister à utiliser libpam-keyring pour s’authentifier automatiquement lors de la connexion.
ou ... ne croyez pas que cela ne le ferait probablement pas, une modification de tous les paramètres du kit de stratégie de "auth_admin" à "oui" résoudrait probablement le problème et que, bien entendu, le policyKit deviendrait totalement inutile. ... soupire
Je pense que c'est le comportement correct de PolicyKit.
La stratégie pour Actif, Inactif et N'importe quel autre utilisateur est différente. Ainsi, lorsque vous êtes connecté via NX, vous n'êtes pas Actif (clients en sessions actives sur des consoles locales), ni inactif (clients en sessions inactives sur des consoles locales), mais vous obtenez le résultat en tant que Tout utilisateur.
Vous pouvez voir la stratégie par défaut pour l'action sous contrôle de stratégie pour les différents types d'utilisateurs à l'aide de la commande
pkaction --verbose
Comme vous pouvez le constater, l'utilisateur de type Any est limité par rapport aux utilisateurs actifs.
Pour remédier à cela, vous pouvez modifier la stratégie par défaut. Dans ce qui suit, suggérez un script awk pour créer un fichier de kit de règles à placer au bon endroit. Voici le script:
#!/usr/bin/awk -f
/^[^ ]/ {
action = substr($0, 1, length($0) - 1)
}
/^ / {
if ($1 == "description:") {
$1 = ""
description = substr($0, 2)
if (description == "")
description = action
} else if ($1 == "implicit") {
if ($2 == "any:")
any = $3
else if ($2 == "inactive:")
inactive = $3
else if ($2 == "active:") {
active = $3
print ""
print "[" description "]"
print "Identity=unix-group:admin"
print "Action=" action
print "ResultActive=" active
print "ResultInactive=" active
print "ResultAny=" active
}
}
}
Supposons que vous l'appeliez create-policy
. Faites-le exécutable, exécutez le script avec
pkaction --verbose | ./create-policy > local.pkla
puis déplacez le fichier résultant:
Sudo mv local.pkla /var/lib/polkit-1/localauthority/50-local.d/
Vous devriez maintenant avoir les mêmes droits que vous étiez un utilisateur de session locale.
Je rencontrais un problème similaire avec NX et j'ai trouvé le fil suivant:
Pourquoi est-ce que j'utilise Unity au lieu de Classic avec NX?
J'ai modifié mon client Windows NX pour que le poste de travail soit défini sur Unix et personnalisé, puis je l'ai configuré pour exécuter la commande suivante:
gnome-session --session=classic-gnome
Et sélectionné Nouveau bureau virtuel .
Après ça, j'étais prêt à partir.