O principal problema é: QUALQUER sessão do gnome que não esteja em cima de uma tela física / nativa real - ou sombrear essa tela (por exemplo, o modo de sombra do NXserver) - tem privilégios com falha. Mesmo quando executado como root!

Algum comentário sobre uma maneira de corrigir o comportamento problemático das sessões VNC / non-shadow NX?

Estou atualizando meu servidor sem cabeça Ubuntu inicial após um longo tempo e estou tendo muitos problemas que não me lembro de existir nas versões anteriores do Ubuntu.

Alguns detalhes:

• Comecei com o ubuntu-11.04-server-amd64.iso e instalei o ubuntu-desktop em cima dele.
• uname -a: Linux MiddleEarth 2.6.38-8-server # 42-Ubuntu SMP seg 11 de abril 03:49:04 UTC 2011 x86_64 x86_64 x86_64 GNU / Linux
  
• O hardware é Intel D920, 2GB de RAM, gfx é uma nvidia 6600, 3xGigabit, 1x100mbit, sem ventilador, sem monitor, teclado, mouse conectado.

Rodada 1

Enquanto eu estava testando / configurando com um monitor conectado , tudo ficou pêssego, tanto na frente do monitor quanto no VNC da minha máquina desktop (no vino).

Sem um monitor, embora surjam problemas:

[Não resolvido / descartado]

O primeiro problema foi o vino ser teimoso e não gostar de carregar antes / durante o GDM. Mas como esse é um sistema sem cabeça, eu realmente não preciso começar com o X por padrão (ou seja, alterar o nível de inicialização) de qualquer maneira, então isso é um pouco discutível. No entanto, lembro-me claramente que isso é muito fácil de fazer em uma versão mais antiga do ubuntu (v9.04 eu acho). E funcionou bem; mas não mais!? ... de qualquer forma, deixei a ideia de lado.

[Resolvido]

Então foi Unity / effects bagunçando VNC (resolvido por trapaça ).

[Não resolvido]

Inicialmente, mudei para o NXserver esperando que talvez os seguintes problemas sejam problemas tightvnc ou vino, mas não tenha tanta sorte. (Nota: leia round2)

Ao fazer a comunicação remota via VNC (ou NXserver), minha conta de usuário perde a capacidade de montar / desmontar HDDs.

Ao fazer a comunicação remota via VNC (ou NXserver), minha conta de usuário não pode acessar algumas opções de configuração privilegiadas,
alguns exemplos:

• não pode fazer nada (por exemplo, 'adicionar' um usuário ou 'configurações avançadas') em "Sistema -> Administração -> Usuários e Grupos".
• não pode usar 'unlock' em "Sistema -> Administração -> Tela de login".
• O gparted falha ao obter qualquer informação sobre os sistemas de arquivos.
• etc. (vários outros diálogos de administração / configuração também não funcionam corretamente)

Só posso supor que isso tenha algo a ver com os privilégios de usuário não serem atribuídos corretamente quando um dispositivo de monitor físico real não está conectado.
A razão 'POR QUE' isso acontece no ubuntu 11.04, quando está sem cabeça, me escapa; Não me lembro desse comportamento nas versões anteriores do ubuntu.

Observe que o problema de montagem do disco rígido não é um problema para os discos rígidos internos / estáticos (apenas os adiciono ao fstab, pois eles são estáticos de qualquer maneira). Mas realmente é uma grande dor para a mídia USB removível.

O resto dos problemas, eu ainda não descobri como consertar ...
Eu sei o que você está pensando ... efetue login no ssh, sudo su e execute o vncserver completamente no root?

Surpresa surpresa! O gui do root também está quebrado: o gparted falha ao obter informações, user & groups está totalmente acinzentado (esse é um comportamento diferente do meu usuário comum). Curiosamente, o proggy de administração da tela de login parece funcionar bem.

2 ª rodada

(NOTA: Não sei se isso fez ou não diferença no resultado. Em algum momento entre a primeira e a segunda rodada, apliquei as alterações mencionadas nas postagens nº 21 e nº 24 deste tópico )

As sessões regulares do tightvnc / NXServer têm o mesmo comportamento, MAS ...

[Solução Parcial / O problema real ainda está lá]

Nas configurações de conexão do NXClient, quando escolho o modo 'sombra' (a sombra o anexa à exibição nativa, ou seja, sombreamento na área de trabalho) ...

Tudo funciona perfeitamente dentro desta sessão!

Uma coisa que notei é que ela imediatamente pede uma senha do chaveiro ... talvez toda a bagunça tenha algo a ver com o sistema de chaveiros que o gnome usa?

Mas, se eu conectar-me a uma conexão NX regular (não sombreada) ou a uma VPN normal, ela voltará a ter os mesmos problemas.

PS Havia alguns dias entre os dois quando escrevi round1 e round2 (eu o mantinha em um arquivo txt localmente). Eu estava testando várias sugestões para ver o que funcionaria, e é por isso que não sei ao certo se a edição do dispositivo xorg.conf VNC ou a configuração do conjunto de nós fizeram a diferença.

[EDIT 10/06/2011]

NXServer e GDM

No momento da redação, eu havia configurado o sistema para o logon automático, e foi por isso que a conexão de sombra simplesmente funcionou. Quando desativei isso mais tarde e reiniciei o sistema, o NX deu um erro, mas com um pouco de pesquisa no Google, encontrei esse tópico

Estas são as descomentações e alterações que fiz no meu /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 uma rede mais pública, ou seja, universidade / escritório grande, provavelmente usaria configurações um pouco mais rígidas, mas elas me agradam.)

Após uma reinicialização, entrei com o nxclient na configuração 'shadow' (exibição nativa) da área de trabalho e obtive o GDM! : D

Infelizmente, a área de transferência não funciona na sessão 'sombra' (funciona nas outras / regulares)

[EDIT 2011-06-11] Tropecei
no Xvfb, mas ele tem os mesmos problemas quando usado assim:

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

Eu localizei o culpado.
Testado em uma nova instalação, confirmou que é um bug.

Enviei um relatório de bug

Em resumo, o problema é: O diálogo de autenticação do polkit será exibido em DISPLAY: 0 em vez de DISPLAY: 1 onde a sessão do VNC / NX está.

Uma solução alternativa pode ser usar o libpam-keyring para se autenticar automaticamente no login.
ou ... raspe isso, que provavelmente não faria isso, uma alteração em todas as configurações do kit de políticas de 'auth_admin' para apenas 'yes' provavelmente resolveria o problema e, é claro, faria com que o policyKit ficasse completamente ... suspiro

Eu acho que esse é o comportamento correto do PolicyKit.

A política para Usuário Ativo , Inativo e Qualquer outro usuário é diferente; portanto, quando você está conectado através do NX, não é Ativo (clientes em sessões ativas em consoles locais), nem Inativo (clientes em sessões inativas em consoles locais), mas resulta como Qualquer usuário.

Você pode ver a política padrão da Ação sob controle de política para os diferentes tipos de usuários com o comando

pkaction --verbose

Como você pode ver, o usuário do tipo Qualquer é limitado em comparação aos usuários Ativos.

Para remediar, você pode modificar a política padrão. A seguir, sugira um script awk para criar um arquivo do kit de políticas para colocar no local correto. Este é o 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
    }
  }
}

Suponha que você chame create-policy. Torne executável, execute o script com

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

mova o arquivo resultante:

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

Agora você deve ter o mesmo direito que era um usuário de sessão local.

Eu estava com um problema semelhante no NX e encontrei o seguinte segmento:

Por que obtenho o Unity em vez do Classic quando uso o NX?

Editei meu cliente Windows NX para que a área de trabalho seja definida como Unix e personalizada e, em seguida, defina-a para executar o seguinte comando:

gnome-session --session=classic-gnome

E selecionou Novo Desktop Virtual .
Depois disso, eu estava pronto para ir.