Trabalhar em um projeto remoto com o Eclipse via SSH


192

Eu tenho as seguintes caixas:

  1. Uma caixa do Windows com Eclipse CDT,
  2. Uma caixa Linux, acessível apenas para mim via SSH.

Tanto o compilador quanto o hardware necessário para criar e executar meu projeto estão apenas na máquina B.

Eu gostaria de trabalhar "de forma transparente" a partir de uma caixa do Windows nesse projeto usando o Eclipse CDT e poder criar, executar e depurar o projeto remotamente no IDE.

Como faço para configurar isso:

  • O prédio vai funcionar? Alguma solução mais simples do que escrever um makefile local que seria rsynco projeto e depois chamar um makefile remoto para iniciar a compilação real? A construção gerenciada do Eclipse tem um recurso para isso?
  • A depuração funcionará?
  • De preferência - a indexação de código do Eclipse CDT funcionará? Preciso copiar todos os arquivos de cabeçalho necessários da máquina B para a máquina A e adicioná-los para incluir o caminho manualmente?

4
Kos, você acabou usando o RSE? Como foi sua experiência?
Aleksandr Levchuk

2
Eu consegui fazê-lo, mas: a) A CDT teve alguns problemas em conhecer o sistema de arquivos virtual (AFAIK, esse é um problema temporário e desaparecerá quando eles reescreverem algumas coisas em uma API mais recente; talvez já tenham? IDK) e b) tive que enrolar minha própria cadeia de compilação (por meio de um arquivo personalizado) ec) um salvamento desagradável de arquivo de incômodo levou de 2 a 3 segundos e isso foi perturbador.
Kos

1
Se eu precisar trabalhar remotamente novamente hoje, provavelmente daria outra volta com o RSE, mas acho mais viável mantê-lo como um projeto local e implementar um sistema de compilação personalizado, com base, por exemplo, rsyncno mencionado.
Kos

2
E, infelizmente, não consegui configurar a depuração remota ou a indexação de cabeçalhos de bibliotecas remotas. Duvido que o último possa ser feito. O primeiro - eu tenho certeza que sim, mas eu realmente não precisava cavar.
Kos

Para acessar minha máquina remota, primeiro conecte-me a um servidor de logon e, a partir daí, a minha máquina remota. Ambos têm senhas diferentes. Existe alguma maneira de trabalhar em uma máquina tão remota no Eclipse?
Arjun J Rao

Respostas:


218

Experimente o Remote System Explorer (RSE). É um conjunto de plug-ins para fazer exatamente o que você deseja.

O RSE já pode estar incluído na sua instalação atual do Eclipse. Para fazer check-in no Eclipse Indigo, vá em Janela > Abrir Perspectiva > Outro ... e escolha Remote System Explorer no Open Perspective diálogo para abrir a perspectiva RSE.

Para criar um projeto remoto SSH a partir da perspectiva RSE no Eclipse:

  1. Defina uma nova conexão e escolha SSH Only na tela Select Remote System Type na caixa de diálogo New Connection.
  2. Digite as informações de conexão e escolha Concluir.
  3. Conecte-se ao novo host. (Supõe que as chaves SSH já estão configuradas.)
  4. Uma vez conectado, faça uma busca detalhada nos Arquivos Sftp do host , escolha uma pasta e selecione Criar Projeto Remoto no menu de contexto do item. (Aguarde enquanto o projeto remoto é criado.)

Se feito corretamente, agora deve haver um novo projeto remoto acessível a partir do Project Explorer e outras perspectivas no eclipse. Com a configuração da conexão SSH, as senhas corretamente podem se tornar uma parte opcional do processo normal de autenticação SSH. Um projeto remoto com o Eclipse via SSH agora é criado.


2
O RSE ainda é complicado. A melhor idéia do RSE é que o Eclipse faça tudo em uma conexão SSH, mas esse recurso ainda não está funcionando. O recurso de trabalho envolve algum servidor que você precisa configurar na caixa Linux.
Ioan

2
Os caras do RSE também gostam de receber relatórios de bugs / aprimoramentos.
Aaron Digulla

2
@ Aaron - Eu tentei essa solução rsync antes, a partir de um Makefile - que basicamente substituiria sua sequência de teclas por uma Ctrl + B. O problema é que, com essa abordagem, não posso executar nem depurar no Eclipse. O RSE realmente soa como uma boa ferramenta do trabalho; @Ioan, você pode elaborar o que não está funcionando? O wiki do RSE parece listar os sistemas de arquivos SSH e a depuração remota como um recurso atual ... Ou vou testá-lo nesta segunda-feira.
Kos

3
@AaronDigulla Oi, a solução é legal, mas descobri que, quando estou criando o projeto remoto, o Eclipse está tentando compilá-lo localmente. Existe alguma maneira de deixá-lo compilar e executar na máquina remota?
precisa saber é o seguinte

1
A indexação C / C ++ não está funcionando corretamente com o RSE. O indexador reclama de falta de símbolos. Funciona bem quando os arquivos de projeto e de origem são armazenados localmente, mas com o RSE isso não acontece. alguma ideia?
9136 Black_Zero #

12

A maneira mais simples seria executar o Eclipse CDT no Linux Box e usar o X11-Forwarding ou software de desktop remoto como o VNC.

Obviamente, isso só é possível quando o Eclipse está presente na caixa Linux e sua conexão de rede à caixa é suficientemente rápida.

A vantagem é que, como tudo é local, você não terá problemas de sincronização e não terá problemas estranhos entre plataformas.

Se você não tem um eclipse na caixa, pode pensar em compartilhar seu diretório de trabalho Linux via SMB (ou SSHFS) e acessá-lo na sua máquina Windows, mas isso exigiria alguma configuração.

Ambos seriam melhores do que ter duas cópias, especialmente quando é multiplataforma.


1
Receio que a caixa linux nem tenha X11. :)
Kos

2
@Kos, você precisa do servidor X11 para rodar onde está fisicamente - com um Linux em uma máquina virtual ou um servidor X11 para Windows - e o Eclipse para rodar no servidor Linux. O ssh apenas permite o tunelamento dos dados da rede - você encontrará a compressão + "-c blowfish" para ajudar a experiência.
Thorbjørn Ravn Andersen

Só para esclarecer - você está se referindo ao que é chamado de "Eclipse sem cabeça" na máquina remota? (Bem, desde que ele tenha Java :)). Eu estava procurando uma solução leve do lado do cliente, mas ter alguma configuração na máquina remota também poderia ser uma opção.
Kos

7
@ Kos: Não. O X11 funciona assim: você tem um cliente e um servidor. O servidor é onde o monitor está conectado. Faz toda a renderização e exibição. O cliente (neste caso, o Eclipse) apenas envia comandos de renderização para o servidor. Portanto, você deve instalar o X11 no Windows e executar o Eclipse na sua caixa Linux. Tudo o que você precisa fazer no Linux é definir a DISPLAYvariável para que o Eclipse saiba onde está o servidor.
Aaron Digulla

5
Porém, a rede precisa ser rápida, e o servidor também, e o Eclipse funcionará muito devagar.
mattalxndr

6

Estou no mesmo local (ou estava), FWIW acabei conferindo um compartilhamento de samba no host Linux e editando-o localmente na máquina Windows com o bloco de notas ++, depois compilei na caixa Linux via PuTTY. (Não tínhamos permissão para atualizar as versões de dez anos dos editores no host Linux e ele não tinha Java, por isso desisti do encaminhamento do X11)

Agora ... Eu executo o Linux moderno em uma VM no meu host do Windows, adiciono todas as ferramentas que eu quero (por exemplo, CDT) à VM e depois faço o checkout e construo uma prisão chroot que se assemelha ao RTE.

É uma solução desajeitada, mas pensei em incluí-la na mistura.


3

Minha solução é semelhante à SAMBA, exceto usando sshfs. Monte meu servidor remoto com sshfs, abra meu projeto makefile na máquina remota. Vá de lá.

Parece que também posso executar um front-end da GUI para mercurial.

Construir meu código remoto é tão simples quanto: ssh address remote_make_command

Estou procurando uma maneira decente de depurar embora. Possivelmente via gdbserver?


2

Eu tive o mesmo problema há 2 anos e resolvi-o da seguinte maneira:

1) Eu construo meus projetos com makefiles, não gerenciados pelo eclipse 2) Eu uso uma conexão SAMBA para editar os arquivos dentro do Eclipse 3) Construindo o projeto: O Eclipse chama um make "local" com um makefile que abre uma conexão SSH para o Linux Hospedeiro. Na linha de comando SSH, você pode fornecer parâmetros que são executados no host Linux. Eu uso para esse parâmetro um shell script makeit.sh que chama o make "real" no host linux. Os diferentes alvos para a construção que você pode fornecer também pelos parâmetros do makefile local -> makeit.sh -> makefile no host linux.


Bom, mas não pode ser chamado de "transparente" - não permite depuração, no mínimo. Também poderia ser baseado no RSync, em vez do Samba (que era o que eu tinha antes de postar minha pergunta original).
Kos

2

eu tentei ssh -X mas era insuportavelmente lento.

Eu também tentei o RSE, mas ele nem mesmo apoiou a construção do projeto com um Makefile ( estou me informando que isso mudou desde que publiquei minha resposta , mas ainda não o experimentei)

Eu li que o NX é mais rápido que o encaminhamento do X11, mas não consegui fazê-lo funcionar.

Por fim, descobri que meu servidor suporta X2Go (o link tem instruções de instalação, se o seu não). Agora eu só precisava:

  • faça o download e descompacte o Eclipse no servidor,
  • instale o X2Go na minha máquina local ( sudo apt-get install x2goclientno Ubuntu),
  • configure a conexão (host, login automático com chave ssh, escolha executar o Eclipse).

Tudo é como se eu estivesse trabalhando em uma máquina local, incluindo construção, depuração e indexação de código. E não há atrasos visíveis.



0

Atualmente, esta resposta se aplica apenas ao uso de dois computadores Linux [ou talvez também funcione no Mac? - não testado no Mac] (sincronizando de um para o outro) porque escrevi esse script de sincronização no bash. No gitentanto, é simplesmente um invólucro , portanto, fique à vontade para pegá-lo e convertê-lo em uma solução Python de plataforma cruzada ou algo assim, se desejar


Isso não responde diretamente à pergunta do OP, mas é tão próximo que eu garanto que ele responderá à pergunta de muitas outras pessoas que chegam nesta página (a minha incluiu, na verdade, como eu vim aqui antes) escrever minha própria solução) estou postando aqui de qualquer maneira.

Eu quero:

  1. desenvolva código usando um IDE poderoso como o Eclipse em um computador Linux leve e, em seguida,
  2. construa esse código via ssh em um computador Linux diferente e mais poderoso (a partir da linha de comando, NÃO a partir do Eclipse)

Vamos chamar o primeiro computador em que escrevo o código "PC1" (Computador Pessoal 1) e o segundo computador em que construo o código "PC2". Eu preciso de uma ferramenta para sincronizar facilmente de PC1 para PC2. Eu tentei rsync, mas era incrivelmente lento para grandes repositórios e consumia toneladas de largura de banda e dados.

Então, como eu faço isso? Que fluxo de trabalho devo usar? Se você também tiver essa pergunta, aqui está o fluxo de trabalho que eu decidi. Eu escrevi um script bash para automatizar o processo usando gitpara enviar automaticamente as alterações de PC1 para PC2 por meio de um repositório remoto, como o github. Até agora, funciona muito bem e estou muito satisfeito com isso. É muito, muito mais rápido do que rsync, mais confiável, na minha opinião, porque cada PC mantém um repositório funcional de git e usa muito menos largura de banda para fazer toda a sincronização, por isso é facilmente viável no hot spot de um telefone celular sem usar muitos dados.

Configuração:

  1. Instale o script no PC1 (esta solução assume que ~ / bin está no seu $ PATH):

    git clone https://github.com/ElectricRCAircraftGuy/eRCaGuy_dotfiles.git
    cd eRCaGuy_dotfiles/useful_scripts
    mkdir -p ~/bin
    ln -s "${PWD}/sync_git_repo_from_pc1_to_pc2.sh" ~/bin/sync_git_repo_from_pc1_to_pc2
    cd ..
    cp -i .sync_git_repo ~/.sync_git_repo
  2. Agora edite o arquivo "~ / .sync_git_repo" que você acabou de copiar acima e atualize seus parâmetros para se adequar ao seu caso. Aqui estão os parâmetros que ele contém:

    # The git repo root directory on PC2 where you are syncing your files TO; this dir must *already exist* 
    # and you must have *already `git clone`d* a copy of your git repo into it!
    # - Do NOT use variables such as `$HOME`. Be explicit instead. This is because the variable expansion will 
    #   happen on the local machine when what we need is the variable expansion from the remote machine. Being 
    #   explicit instead just avoids this problem.
    PC2_GIT_REPO_TARGET_DIR="/home/gabriel/dev/eRCaGuy_dotfiles" # explicitly type this out; don't use variables
    
    PC2_SSH_USERNAME="my_username" # explicitly type this out; don't use variables
    PC2_SSH_HOST="my_hostname"     # explicitly type this out; don't use variables
  3. Git clone seu repositório que você deseja sincronizar no PC1 e no PC2.

  4. Verifique se as teclas ssh estão configuradas para poder empurrar e puxar para o repositório remoto do PC1 e PC2. Aqui estão alguns links úteis:
    1. https://help.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh
    2. https://help.github.com/en/github/authenticating-to-github/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent
  5. Verifique se as teclas ssh estão configuradas para ssh de PC1 a PC2.
  6. Agora cdem qualquer diretório dentro do repositório git no PC1 e execute:

    sync_git_repo_from_pc1_to_pc2
  7. É isso aí! Cerca de 30 segundos depois, tudo será sincronizado magicamente do PC1 para o PC2, e a saída será impressa o tempo todo para informar o que está fazendo e onde está no disco e em qual computador. Também é seguro, porque não substitui nem exclui nada que não foi confirmado. Ele faz o backup primeiro! Leia mais abaixo para saber como isso funciona.

Aqui está o processo que esse script usa (ou seja: o que realmente está fazendo)

  1. Do PC1: verifica se há alterações não confirmadas no PC1. Nesse caso, ele os confirma em uma confirmação temporária na ramificação atual. Em seguida, força os empurra para uma ramificação SYNC remota. Em seguida, ele descompacta seu commit temporário que acabou de fazer na ramificação local e, em seguida, coloca o repositório git local de volta exatamente como estava, testando todos os arquivos previamente testados no momento em que você chamou o script. Em seguida, é uma rsynccópia do script para o PC2 e faz umassh chamada para informar ao PC2 para executar o script com uma opção especial para fazer apenas coisas do PC2.
  2. Aqui está o que o PC2 faz: ele cdentra no repositório e verifica se existem alterações locais não confirmadas. Nesse caso, ele cria uma nova ramificação de backup extraída da ramificação atual (nome da amostra:. Agora, ele faz check-out da ramificação SYNC, retirando-a do repositório remoto, se ainda não estiver na máquina local. as alterações mais recentes no repositório remoto e faz uma redefinição forçada para forçar o repositório SYNC local a corresponder ao repositório SYNC remoto. Você pode chamar isso de "puxão rígido". É seguro, no entanto, porque já fizemos backup de alterações não confirmadas. tinha localmente no PC2, então nada está perdido!my_branch_SYNC_BAK_20200220-0028hrs-15secNesse <- observe que AAAAMMDD-HHMMhrs - SSsec) e confirma todas as alterações não confirmadas nessa ramificação com uma mensagem de confirmação como DO BACKUP OF ALL ALTERAÇÕES NÃO COMPROMETIDAS NO PC2 (TARGET PC / BUILD MACHINE)
  3. É isso aí! Agora você produziu uma cópia perfeita do PC1 para o PC2 sem precisar garantir diretórios de trabalho limpos, pois o script tratava de todas as confirmações e itens automáticos para você! É rápido e funciona muito bem em grandes repositórios. Agora você tem um mecanismo fácil de usar qualquer IDE de sua escolha em uma máquina durante a construção ou teste em outra máquina, facilmente, através de um ponto de acesso wifi do seu telefone celular, se necessário, mesmo que o repositório tenha dezenas de gigabytes e você esteja na hora e com recursos limitados.

Recursos:

  1. Todo o projeto: https://github.com/ElectricRCAircraftGuy/eRCaGuy_dotfiles
    1. Veja muito mais links e referências no próprio código-fonte dentro deste projeto.
  2. Como fazer um "puxão", como eu o chamo: Como forçar o "git pull" a substituir arquivos locais?

Palavras-chave:

  1. sincronização do repositório git entre computadores, quando se desloca?
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.