Closed leonardofl closed 7 years ago
Falta concordância.
O xauth irá "quebrar" o container se você reiniciar ou desligar o sistema, ~senão~ na mesma sessão rodará ok se não apagá-lo.
@leonardofl Fiz um referencia de um issue porque deste aviso. Alguma dúvida a mais sobre o entendimento?
O xauth irá "quebrar" o container se você reiniciar ou desligar o sistema, senão na mesma sessão rodará ok se não apagá-lo.
Se não apagá-lo quem? O container? O XAuth? O que seria "apagar o xauth"?
O container.
Enquanto o xauth pertence ao sistema e que permite trazer a GUI ao hospedeiro, parte integrante do XOrg. Em outro issue, que referenciei aqui explicava o motivo deste PS. Mas em termos gerais, o xauth é um pedido do @lbssousa que dá camada de segurança extra ao servidor gráfico, mas não consegui reaproveitar o container em outras ocasiões.
Somente coloquei em português a frase, por gentileza, sugira melhoria na documentação. Com PR. Preferencia use inglês, pois seu objetivo neste projeto é para praticá-lo, para ter habilidade em projetos opensource afora que são comunicação oficial.
Grato
A respeito do xauth, você podes podem encontrar mais informações aqui: https://www.x.org/archive/X11R6.8.0/doc/xauth.1.html
O que acontece aqui é o seguinte: quando você faz login em uma sessão desktop comum no Linux, o gerenciador de login executa o Xorg em uma espécie de "modo autenticado" (vocês podem notar isso verificando a linha de comando do Xorg em um visualizador de processos: provavelmente vai ter algo como -auth /caminho/para/o/arquivo/de/autorização
, onde este arquivo contém um token necessário para autorizar um aplicativo gráfico a rodar sobre aquela instância do Xorg). Dentro da sessão do usuário, este arquivo normalmente é referenciado pela variável de ambiente XAUTHORITY
.
Para um programa gráfico qualquer rodar sobre um servidor Xorg específico, ambas as variáveis de ambiente DISPLAY
e XAUTHORITY
(se houver) precisam estar setadas com os valores correspondentes àquele servidor. Por outro lado, para liberar o acesso de qualquer aplicativo gráfico (mesmo sem XAUTHORITY
definido) em um servidor Xorg autenticado, normalmente se executa o comando xhost +
dentro da sessão do usuário (é o que se costuma fazer para executar um aplicativo gráfico como root dentro de uma sessão do usuário, por exemplo).
O que acontece no caso do Docker é que não dá pra aproveitar diretamente o arquivo XAUTHORITY
da sessão do usuário no sistema hospedeiro, porque a estrutura de rede do container é separada do sistema hospedeiro (exceto se o container for invocado com a opção --net=host
). O que se faz aqui, no caso, é pegar o token de autorização do Xorg do sistema hospedeiro e injetá-lo em um arquivo dentro do container (mesclando o token do sistema hospedeiro com as informações da rede interna do container) e passar este arquivo para o Firefox definindo a variável XAUTHORITY
dentro do container.
O script que dispara o Firefox contido neste repositório contempla os dois casos, ou seja, funciona corretamente caso o container seja executado, ou não, com a opção --net=host
.
@lbssousa A opção --net=host
não é para interface de rede? Enquanto o volume é uma acesso a um determinado recuso/diretório dentro da maquina hospedeira, ou existe um FS de rede para o volumes, para o caso da XAUTHORITY
?
Acredito eu que o docker não utiliza a interface docker0
ou semelhante, que estejam listado no docker network ls
, para os volumes, salvo usando HA/SWARM. Enquanto sobre o "NAT" que o docker faz para acesso ao banco, o warsaw não reclama e nem bloqueia a conta na instituição, como muitos relatam quando acessa por VMs tradicionais em modo não-bridge.
Se necessário acredito podemos customizar uma rede a parte, e mandar pacotes XDMCP por ela, se for o caso, para o hospedeiro.
Pelo que eu entendi daqui, a opção --net=host
coloca o seu container na mesma rede do sistema hospedeiro, compartilhando o hostname, as inferfaces de rede, os sockets UNIX, etc. Neste modo, não é necessário, por exemplo, passar a opção -v /tmp/.X11-unix:/tmp/.X11-unix
ao docker, pois o socket já é compartilhado. Neste modo, também é possível usar integralmente o arquivo XAUTHORITY
do sistema hospedeiro, pois o hostname é compartilhado (bastaria um -v ${XAUTHORITY}:~/.Xauthority
, por exemplo).
Tem o modo privileged
que atribui o /dev
e demais privilégios para o container, porém acho ruim em questão de isolamento. Não seria o mais correto?
Fechado pois o Issue desvirtuou ao seu assunto original. Debate continua em Issue #18
Eu realmente não entendi o "else in the same session will run ok".
Você poderia, por favor, escrever aqui em português a frase toda, por favor? Daí eu mando um pull request melhorando o inglês.
Tks.