como usar o perfil temporário quando o ssh para o servidor remoto

Question

Frequentemente, estou logando em servidores remotos usando o ssh, para executar tarefas administrativas padrão. Eu tenho local bashrc / vimrc e vários outros arquivos de configuração que eu gostaria de estar disponível remotamente. Muitas vezes, só faço login nesses servidores remotos uma vez, então não quero deixar uma cópia do meu perfil nessas caixas, algumas das quais estão em sites de clientes.

Eu considerei fazer alguns truques para que o servidor remoto montasse um webDAV do fusefs ou outra maneira de montar um sistema de arquivos remoto para o servidor remoto durante a sessão. No entanto, isso tem problemas se o sistema remoto não tiver os pacotes necessários ou estiver com a firewall desativada.

Existe alguma boa solução para este problema que seja compatível com distribuição cruzada, bem como o mais recente fedora / RHEL / ubuntu / debian / CentOS e não interfira ou desacelere o processo de login?

[EDITAR]

Eu acho que uma das outras considerações, é que eu poderia estar logando com a conta de usuário de alguém, então eu não quero fazer nenhuma alteração persistente no perfil. O ideal seria usar apenas um perfil temporário para a sessão e, em seguida, descartá-lo no logoff. isso pode estar entrando em território lunar ;-)

    

Answer 1

Você pode usar ssh -t para executar scripts de configuração, depois um shell e depois limpar os scripts. ssh -t permite que você execute comandos, mas ainda execute um ou mais shells no meio e aloque um terminal corretamente

Seu script de configuração pode incluir wget'ing / curl'ing / scp'ing em um diretório inicial temporário para algo como $HOME/tmphome , e então executar um script como este para iniciar um shell lá:

#!/bin/sh

HOME="$HOME/tmphome"
cd "$HOME"
bash --login

Isso deve fazer um bom trabalho de isolar seus arquivos rc para o tmphome, e ssh -t pulará o bashrc do usuário. Desde que o seu ambiente seja leve, não deve demorar muito para copiar.

Seu comando pode ser algo como ssh -t user@host 'wget http://server/tmphome.tar.gz && tar -zxvf tmphome.tar.gz && rm tmphome.tar.gz && tmphome/shell.sh'

    

Answer 2

Por que você não usa um sistema de controle de versão distribuído como o git para armazenar seus arquivos de configuração? É o que eu faço e funciona como um encanto.

    

Answer 3

Muitos administradores Unix 'old-school' armazenam suas configurações comuns em um repositório cvs . Na primeira vez que efetuarem login em um novo sistema, eles cvs checkout desse repositório e configurarão seu .bashrc para fazer um cvs update para obter as configurações atuais e, em seguida, chamarão ~/repo/bin/setup (onde repo é onde o cvs checkout segmentado e setup é um script que adiciona /repo/bin aos seus $PATH configura alias es etc).

Esse método deixa suas configurações no sistema, embora isso possa não ser um grande problema em muitos casos.

Você pode substituir naturalmente svn ou git por cvs .

    

Answer 4

Minha solução para esse problema foi aprender a me sentir confortável com os padrões comuns e programar minhas macros de dedo para ativar os (muito poucos) recursos opcionais dos quais simplesmente não posso viver.

O problema é que, para máquinas que você só consiga resolver um problema rápido, o tempo necessário para configurar seu ambiente provavelmente excederá o tempo necessário para realmente corrigir o problema. A questão é ampliada um pouco pelo seu desejo declarado de deixar o sistema sem suas configurações personalizadas quando estiver pronto - um sentimento admirável, já que fui mordido por um administrador que não podia viver sem o modo vi no (compartilhado) shell de raiz e readline. Fez muito difícil fazer qualquer coisa quando você está acostumado com os atalhos de teclado padrão.

Eu tive muita sorte em tempos mais recentes; sempre que eu tenho sido responsável por fazer as coisas com os servidores, eles têm sido "meus", no sentido de que eu tenho autoridade / autoridade administrativa permanente, e eu usei minha ferramenta de automação de sistema para pré-configurar as máquinas Eu gosto deles.

Para acesso temporário, se eu voltasse a ele e precisasse desesperadamente de meu próprio ambiente, eu estaria inclinado a desenvolver dois scripts de shell:

• Um que eu corri antes de entrar em um novo servidor, que colocou todos os meus arquivos de configuração desejados (mantendo uma cópia do que estava lá antes), e possivelmente pacotes instalados (adequados para a distribuição), ou menos relatado sobre o que estava faltando, então eu sabia o que eu estaria hanstrung em um servidor remoto quando comecei a trabalhar nele;
• O outro, que limparia tudo para o estado em que estava antes de eu executar o primeiro script - desinstalar os pacotes (você precisaria ter certeza de que sabia o que tinha instalado, em oposição ao que já estava lá antes de você chegou lá), e mover os arquivos de configuração originais de volta ao lugar.

Esses scripts seriam uma boa quantidade de trabalho para escrever e depurar, especialmente em todas as fraquezas de diferentes distribuições. É por isso que aprendi a conviver com os padrões sãos para qualquer trabalho leve - que é um bom hábito de participar caso você faça parte de uma equipe no futuro e precise compartilhar um ambiente com outras pessoas ( Mr. modo vi bash shell, estou olhando para você ).