Come portre .vimrc quando ho SSH?

Il mio lavoro tende a coinvolgere l'utilizzo di SSH per connettersi a varie macchine e quindi utilizzare vim per modificare i file su tali macchine. Il problema è che devo copiare costantemente il file .vimrc in giro. È molto fastidioso aprire vim e non avere impostazioni. È ansible trasportre le mie impostazioni vim con me da macchina a macchina senza copiarla manualmente ovunque?

  • cambiare i colors dei file / dir in linux ls
  • Dov'è il completamento della mia scheda e il comportmento delle frecce in su? (Ubuntu 10.04)
  • Ho creato un tasto RSA ma SSH continua a chiedere la password
  • Ripristina session SSH
  • Configurazione per più porte SSH
  • Come posso specificare il numero di port per PuTTY da utilizzare con cmd di Windows?
  • Come utilizzare un file .bashrc personalizzato nel login SSH
  • Limitare gli utenti LDAP all'authentication senza una shell valida
  • Limitare ssh alla networking locale, ad exception dell'utilizzatore git
  • DH GEX gruppo fuori gamma
  • Fibre multipath non riesce: Risultato: hostbyte = DID_ERROR driverbyte = DRIVER_OK
  • tar e ssh grande file
  • 12 Solutions collect form web for “Come portre .vimrc quando ho SSH?”

    Condivido il tuo dolore. Ho tutti i miei file ~ /.* rc sotto controllo di versione (Subversion), ha lavorato bene fin da quando ho iniziato nel 1998, utilizzando CVS. Un modo per farlo è guardare tutti i tuoi file rc come questo quando si sta nella tua home directory:

     svn co svn+ssh://user@host/path/to/repo/trunk/home/user . A .signature A .vimrc A .bashrc A .screenrc A .psqlrc [...] Checked out revision 7645. 

    In questo modo i file di configuration verranno sincronizzati e aggiornati nei diversi computer quando si esegue svn update.

    Invece di portre .vimrc a ciascun server su cui lavorare, perché non modificare i file remoti dal tuo vim locale:

    In vim / gvim, eseguire:

     :e scp://remoteuser@server.tld//path/to/document 

    o iniziare vim come questo:

     vim scp://remoteuser@server.tld//path/to/document 

    Questo apre il file in seamingly (effettivamente copia il file localmente) e quando si salva, invia il file modificato al server per te.

    Richiede una password ssh, ma questo può essere semplificato tramite i tasti ssh.

    Come altri hanno citato l'unico inconveniente di questo metodo è che non si ottiene la competizione di path / file come si farebbe quando si lavora direttamente sulla macchina.

    Per ulteriori informazioni, consultare il seguente tutorial .

    È ansible eseguire uno script bash per copiarlo automaticamente each volta che si accede, come questo:

     #!/usr/bin/env bash scp ~/.vimrc $1: ssh $1 

    Potresti chiamarlo ssh_vim, per esempio. Non è una soluzione ideale ma risolverà il tuo problema.

    Puoi migliorarla per controllare innanzitutto se c'è già. Se non si esegue sempre ssh dalla stessa macchina, è ansible modificare lo script per get il file da scp da un'altra macchina.

    EDIT1

    Su una nota correlata, è anche ansible montare il filesystem della macchina remota con sshfs. In questo modo potrai beneficiare dell'ambiente e degli strumenti (non solo .vimrc) e hai completamento delle coperture (che non utilizzi scp: //).

    EDIT2

    Ho appena scoperto che puoi generare il file .vimrc utilizzando scp: //, come questo:

     :source scp://you@your_computer//yourpath/.vimrc 

    Questo funziona dalla linea di command vim ma al momento non so come automatizzare. Non sembra funzionare né con l'opzione '-u', né con il command .vimrc né con $ VIMINIT.

    Edit3

    L'ho trovato! È ansible farlo per avviare vim con un .vimrc prelevato dal tuo host di riferimento:

     vim -c ':source scp://you@your_computer//yourpath/.vimrc' 

    L'opzione '-c' esegue il command subito dopo il lancio di vim.

    È ansible creare un alias nel tuo shell di scelta per evitare di digitare. In bash sarebbe così:

     alias vim="vim -c ':source scp://you@your_computer//yourpath/.vimrc'" 

    Un paio di soluzioni:

    1) Creare una condivisione NFS per la cartella principale e mapparla in più posizioni.

    2) Creare un piccolo script per spingere il tuo .vimrc al server a cui si connette con un file di identity framework; / chiave. Potrebbe sembrare qualcosa di simile (pseudocode):

     connectString = arg0 #username@ipaddress scp -i ~/.ssh/indentity connectString:~/ ~/.vimrc ssh -i ~/.ssh/indentity connectString 

    La stessa risposta esatta come sunny256, ma usa git invece di SubVersion.

    Mantenere una filiale principale con i file comuni a tutti i computer e avere un branch per each nuovo computer.

    In questo modo è ansible avere quasi gli stessi file sulla maggior parte dei computer e ancora non diventare confusi.

    Sto utilizzando https://github.com/andsens/homeshick per gestire i miei dotfiles e memorizzarli su github.

    Homeshick è scritto in 100% bash, e ti aiuta a gestire "castelli" che sono solo repos di git che contengono una directory / home /. Ha comandi per spostare i file dot esistenti nel repo e sostituirli con i simboli. E a symlink tutti i file nel repo nella tua home directory su una nuova macchina.

    Quindi l'idea generale è mantenere i file dotfiles in un sistema di controllo di versioni e simmettere loro dal path reale. In questo modo il tuo repo non deve iniziare dal tuo home dir e contenere una quantità di file che non si desidera aggiungere.

    Se sei come me e disponi di molte macchine di sviluppo (anche macchine virtuali) per vari motivi puoi combinare chiavi ssh, un bash_profile intelligente e un RCS di tua scelta.

    Vorrei usare secondo nfs / samaba / sshfs. Una traccia è se non si dispone di accesso di networking tutto il tempo, allora non è ansible accedere a ciò che è necessario (volare, senza wifi, firewall, problemi di instradamento, ecc.). Le macchine che tengo in sincronia non sono tutte raggiungibili allo stesso tempo, ma voglio condividere informazioni tra di loro.

    Di seguito è come ho preso in considerazione l'assunzione di molte idee da Internet.

    .bash_profile potrebbe avere qualcosa di simile

     $HOME/bin/shell_ssh_agent 

    Ho ottenuto questo da un paio di posti ma non riesco a trovare un collegamento ad esso adesso. Il file shell_ssh_agent:

     #!/bin/bash SSH_ENV=$HOME/.ssh/environment #echo "starting" function start_agent { #echo "reaping agents" killall ssh-agent #echo "Initialising new SSH agent..." /usr/bin/ssh-agent | sed 's/^echo/#echo/' > ${SSH_ENV} #echo succeeded chmod 600 ${SSH_ENV} . ${SSH_ENV} /usr/bin/ssh-add; } # Source SSH settings, if applicable if [ -f "${SSH_ENV}" ]; then . ${SSH_ENV} #echo "sourced ssh env" ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent > /dev/null || { start_agent; } else start_agent; fi 

    Ora al primo login si impostano le chiavi. Uscire e dentro e solo ha reso la vita più facile.

    Metti tutti i tuoi script in un RCS, rendendo più semplice la sincronizzazione delle macchine di sviluppo. Uso git. L'authentication con git è tramite ssh così i tasti ssh aiutano anche qui. Nota a questo punto si potrebbe avere usato qualcosa come nfs. Sarei ancora un fan di un RCS per una ragione che menziono qui di seguito.

    Il caso d'uso è

    1. login la prima volta, le chiavi vengono impostate
    2. se RCS non è impostato controllare i tuoi script personali (e aggiornare / unire se necessario, questo potrebbe anche essere parte del tuo .bash_profile se lo volevi)
    3. modificare vimrc, script speciali, ecc e impegnarli
    4. quando si registrano in altre macchine fare un aggiornamento / fusione / checkout. Questo mantiene tutto in sincronia; cioè non copiare più file che a volte ti stomp over e non volevi.
    5. come vantaggio secondario si ottiene la potenza di un RCS. A volte faccio modifiche sfavorevoli agli script o ai config e devo rimettere indietro e simili.

    Qualcosa che voglio provare dopo è avvolgere il login / setup iniziale in un makefile che copiamo sulla nuova macchina. Il makefile può quindi fare il lavoro di impostare le chiavi, RCS, ecc Ovviamente c'è qualche overhead qui, ma se si finisce per impostare un sacco di macchine questo è:

    1. un risparmiatore di tempo
    2. è più facile mantenere in sincronia le configurazioni e gli script personali delle macchine di sviluppo
    3. gestione delle modifiche agli script e ai config.

    Uso un makefile che dispone di un elenco di tutti i server a cui accedo e quando faccio una modifica sulla mia macchina locale, 'make' viene eseguito utilizzando automaticamente il makefile che aggiorna tutti i server con qualsiasi modifica o plugin

    So che questo è un thread vecchio, ma un modo lo faccio è usare sshfs che monta il file system su fusibile. Il vim locale fa tutto il assembly, quindi non c'è alcun motivo per copiare .vimrc in giro.

    Questi hanno il lato negativo che un altro terminal dovrà essere aperto per tutti i comandi che devono eseguire sul server remoto, ma per la modifica ho trovato in questo modo il meglio.

    Ha anche il vantaggio aggiunto di essere in grado di utilizzare gli appunti di sistema.

    Se stai utilizzando l'authentication con chiave pubblica, puoi utilizzare questo nel tuo ~/.ssh/config :

     Host * PermitLocalCommand yes LocalCommand bash -c 'scp -P %p %d/.vimrc %u@%n: &>/dev/null &' 

    Mi piace più che il trucco di script suggerito in precedenza poiché non distrugge l'invocazione del command ssh (quando si specifica parametri aggiuntivi ecc.)

    Si potrebbe considerare uno script EXPECT che consente di impostare il path e l'ambiente (come le variables EXRC) quando si preme un determinato tasto. Non dovrebbe essere troppo a lungo prima che qualcuno postino uno script simile.

    Quando le tue server farm sono più di una decina di dozzine (pensare a migliaia), avendo qualcosa di facile impostazione dell'ambiente su una casella "vergine" è un vero e proprio salvatore

    Spesso quando accedo a una casella, crea il mio homedir per la prima volta!

    sshrc risolve questo problema. Inserisci il tuo .vimrc in ~ / .sshrc.d / e poi aggiunge l' export VIMINIT="let \$MYVIMRC='$SSHHOME/.sshrc.d/.vimrc' | source \$MYVIMRC" a `/.sshrc.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.