Il problema principale è: QUALSIASI sessione di gnome che non si trova sopra un display fisico / nativo reale - o l'ombreggiatura di quel display (cioè la modalità ombra di NXserver) - ha privilegi errati. Anche quando eseguito come root!

Qualche commento su un modo per risolvere il problema per le sessioni VNC / non-shadow NX?

Sto aggiornando il mio server senza testa Ubuntu a casa dopo molto tempo e sto avendo molti problemi che non ricordo di esistere nelle precedenti versioni di Ubuntu.

Alcuni dettagli:

• Ho iniziato con Ubuntu-11.04-Server-amd64.iso e poi ho installato Ubuntu-Desktop su di esso.
• uname -a: Linux MiddleEarth 2.6.38-8-server # 42-Ubuntu SMP lun 11 aprile 03:49:04 UTC 2011 x86_64 x86_64 x86_64 GNU / Linux
  
• L'hardware è Intel D920, 2 GB di RAM, gfx è un nvidia 6600 senza ventole, 3xGigabit, 1x100mbit, nessun monitor, tastiera, mouse collegati.

Turno 1

Mentre stavo facendo il test / installazione con un monitor collegato , tutto era perfetto, sia quando ero seduto di fronte a quel monitor sia durante il VNC dal mio computer desktop (in vino).

Senza un monitor sebbene sorgano problemi:

[Unsolved / Dropped]

Il primo problema era che vino era testardo e non amava caricare prima / durante GDM. Ma dal momento che questo è un sistema senza testa, non ne ho davvero bisogno per iniziare con X di default (cioè cambiare il livello di init) comunque, quindi è un po 'controverso. Tuttavia, ricordo distintamente che questo è molto facile da fare in una versione precedente di Ubuntu (v9.04 credo). E ha funzionato bene; ma non più!? ... comunque ho lasciato cadere quell'idea del tutto.

[Risolto]

Quindi è stato Unity / effetti a disturbare VNC (risolto con l'inganno ).

[Unsolved]

Inizialmente sono passato a NXserver sperando che forse i seguenti problemi siano problemi legati al vino o al vino, ma nessuna fortuna. (Nota: leggere round2)

Quando remoto tramite VNC (o NXserver) il mio account utente perde la possibilità di montare / smontare HDD.

Quando eseguo il remoting tramite VNC (o NXserver) il mio account utente non può accedere ad alcune opzioni di configurazione privilegiate,
alcuni esempi:

• non può fare nulla (es. "aggiungere" un utente o "impostazioni avanzate") in "Sistema -> Amministrazione -> Utenti e gruppi".
• impossibile utilizzare "sblocco" in "Sistema -> Amministrazione -> Schermata di accesso".
• gparted non riesce a ottenere alcuna informazione sul filesystem.
• ecc. (vari altri dialoghi admin / config non funzionano neanche correttamente)

Posso solo immaginare che ciò abbia a che fare con i privilegi dell'utente che non sono assegnati correttamente quando un dispositivo di monitoraggio fisico reale non è collegato.
Il motivo 'PERCHÉ' questo accade in Ubuntu 11.04, quando è senza testa, mi sfugge; Non ricordo questo comportamento nelle versioni precedenti di Ubuntu.

Si noti che il problema di montaggio dell'HDD non è un problema per i hdd interni / statici (li aggiungo semplicemente a fstab poiché sono comunque statici). Ma davvero un grosso problema per i supporti USB rimovibili.

Il resto dei problemi, non ho capito come risolvere ...
So cosa stai pensando ... accedi a ssh, sudo su ed esegui vncserver interamente sotto root?

Sorpresa sorpresa! Anche la GUI di root è rotta: gparted non riesce a ottenere informazioni, l'utente e i gruppi sono completamente oscurati (questo è un comportamento diverso rispetto al mio utente normale). Stranamente il proggy di amministrazione della schermata di accesso sembra funzionare bene.

Turno 2

(NOTA: non so se questo ha fatto o non ha fatto differenza per il risultato. Ad un certo punto tra il round 1 e il round 2, ho applicato le modifiche menzionate nei post # 21 e # 24 in questa discussione )

Le normali sessioni tightvnc / NXServer hanno lo stesso comportamento, MA ...

[Soluzione parziale / Il problema reale è ancora presente]

Nelle impostazioni di connessione di NXClient, quando scelgo la modalità 'shadow' (shadow ti collega al display nativo, ad esempio desktop shadowing) ...

Tutto funziona perfettamente in questa sessione!

Una cosa che ho notato è che mi chiede immediatamente una password del portachiavi ... forse l'intero casino ha qualcosa a che fare con il sistema di portachiavi che gnome usa?

Ma, se mi connetto con una normale connessione NX (non shadow), o con un normale VNC, torna ad avere gli stessi problemi.

PS Ci sono stati un paio di giorni tra quando ho scritto round1 e round2 (lo tenevo in un file txt localmente). Stavo testando vari suggerimenti per vedere cosa avrebbe funzionato, motivo per cui non so con certezza se la modifica del dispositivo VNC xorg.conf o l'impostazione del nomodeset hanno fatto la differenza.

[MODIFICA 2011-06-10]

NXServer e GDM

Al momento della stesura del documento avevo impostato il sistema per il login automatico, motivo per cui la connessione shadow funzionava semplicemente. Quando in seguito l'ho disabilitato e riavviato il sistema, NX ha dato un errore, ma con un po 'di Google ho trovato questo thread

Questi sono i commenti e le modifiche che ho fatto sul mio /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"

(Se fosse una rete più pubblica, ad esempio università / grandi uffici, probabilmente utilizzerei impostazioni un po 'più rigide, ma queste mi vanno bene.)

Dopo un riavvio ho effettuato l'accesso con nxclient all'impostazione 'shadow' (visualizzazione nativa) del desktop e ho ottenuto GDM! : D

Sfortunatamente gli Appunti non funzionano nella sessione 'shadow' (Funziona su altri / normali bene)

[EDIT 2011-06-11]
Inciampato su Xvfb ma ha gli stessi problemi se usato in questo modo:

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

Ho individuato il colpevole.
Testato su una nuova installazione, ha confermato che è un bug.

Ho inviato una segnalazione di bug

In breve il problema è: il dialogo di autenticazione polkit apparirà su DISPLAY: 0 invece di DISPLAY: 1 dove si trova la sessione VNC / NX.

Una soluzione alternativa potrebbe essere quella di utilizzare il portachiavi libpam per autenticarsi automaticamente all'accesso.
o ... gratta che, probabilmente non lo farebbe, una modifica per tutte le impostazioni del kit di politiche da "auth_admin" a "sì" probabilmente risolverebbe il problema, e che ovviamente farebbe in modo che policyKit muti del tutto ... sospiro

Penso che questo sia il comportamento corretto di PolicyKit.

I criteri per Attivo , Inattivo e Qualsiasi altro utente sono diversi, quindi quando si è connessi tramite NX non si è attivi (client in sessioni attive su console locali), né inattivi (client in sessioni inattive su console locali), ma si ottiene come Qualsiasi utente

È possibile visualizzare la politica predefinita per l'azione sotto controllo politica per il diverso tipo di utenti con il comando

pkaction --verbose

Come puoi vedere, l'utente di tipo Any è limitato rispetto agli utenti attivi.

Per porre rimedio, è possibile modificare la politica predefinita. Di seguito viene suggerito uno script awk per creare un file di kit di criteri da inserire nella posizione corretta. Questo è lo 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
    }
  }
}

Supponi di chiamarlo create-policy. Rendilo eseguibile, esegui lo script con

pkaction --verbose | ./create-policy > local.pkla 

quindi spostare il file risultante:

sudo mv local.pkla /var/lib/polkit-1/localauthority/50-local.d/

Ora dovresti avere gli stessi diritti di un utente di sessione locale.

Stavo riscontrando un problema simile con NX e ho trovato il seguente thread:

Perché ottengo Unity anziché Classic quando utilizzo NX?

Ho modificato il mio client Windows NX in modo che il desktop sia impostato su Unix e personalizzato, quindi l'ho impostato per eseguire il comando seguente:

gnome-session --session=classic-gnome

E selezionato Nuovo desktop virtuale .
Dopo quello sono stato bravo ad andare.