2009-09-11 17 views
35

Zwykle pracuję na wielu komputerach. Mam różne pliki konfiguracyjne, np. .bashrc, .gitconfig, .irbrc, .vimrc i foldery konfiguracyjne, np. .vim/, które zawierają cenne dostosowania. Czasami chcę mieć niewielkie różnice w konfiguracji między różnymi komputerami.Zarządzanie plikami konfiguracji użytkownika na wielu komputerach

Chcę użyć kontroli wersji do zarządzania tymi różnymi plikami.

  • czy inni używają kontroli wersji do zarządzania swoimi plikami konfiguracyjnymi?
  • Jakie są wskazówki, które mogą ułatwić to zadanie?
  • jaki jest najbardziej elegancki sposób radzenia sobie z odmianami między komputerami?
  • Jestem wygodny z git; jakieś inne sugestie?
+6

Przez golly , tak, ludzie z całą pewnością używają kontroli wersji dla plików konfiguracyjnych. Widzę to szczególnie dla plików konfiguracyjnych menedżera okien, ale po prostu wyszukuj w GitHub dla "config" i zobacz, co otrzymasz. –

Odpowiedz

14

W tej chwili używam sklonowanego repo GIT. Aby wszystko było proste, jedynym plikiem, który musi się różnić między różnymi komputerami, jest .bashrc. To miłe, jeśli może istnieć tylko jedna wersja tego pliku, która reaguje inaczej na różne komputery. Tak więc, w moim .bashrc:

if [ $(hostname) == 'host1' ]; then 
    # things to do differently on host1. 
elif [ $(hostname) == 'host2' ]; then 
    # things to do differently on host2. 
fi 

To oczywiście ma pewne ograniczenia (takie jak inna technika byłaby wymagana dla .vimrc lub innych plików konfiguracyjnych wymagających dostosowania), ale działa dość dobrze.

+3

Możesz mieć plik .bashrc.local na każdym komputerze i możesz go pobrać .bashrc.local przez wspólny plik .bashrc. .bashrc.local będzie dostosowywać się do tego komputera (np. kolor). – vaichidrewar

1

git z gałęziami dla niestandardowych komputerów, z automatyczną synchronizacją przy logowaniu wydaje się dobrym rozwiązaniem dla mnie.

Użyłem etckeeper do konfiguracji wersji, ale nigdy nie rozszerzyłem konfiguracji użytkownika.

2

Jeśli używasz git, możesz zdefiniować repozytorium "origin" jako master; a następnie wykonaj klon na każdym komputerze, na którym pracujesz. możesz użyć gałęzi dla każdego komputera, aby mieć zestaw plików konfiguracyjnych.

3

Dzięki CfEngine możesz zarządzać plikami konfiguracyjnymi na różnych komputerach i robić jeszcze więcej rzeczy! Krzywa uczenia się może być nieco wysoka, ale warto, jeśli trzeba regularnie zarządzać/aktualizować/utrzymywać pulę komputerów z systemem Linux.

+0

+1 za to również http://pl.wikipedia.org/wiki/Cfengine –

+0

Lub marionetka, szef kuchni, bcfg2 i [inne] (http://en.wikipedia.org/wiki/Comparison_of_open_source_configuration_management_software). – Bash

1

Tego rodzaju pytanie pojawia się sporadycznie i nigdy nie widziałem narzędzia, które poradziłoby sobie z tym powszechnym przypadkiem użycia, więc napisałem skrypt, który używa plików git i dowiązań symbolicznych do zarządzania tymi plikami.

Zobacz http://github.com/bstpierre/dotfiles

To nie jest doskonały. Obecnie istnieje błąd związany z obsługą katalogów i nie ma jeszcze wsparcia dla odmian na komputerach.

Przed użyciem jakiegokolwiek narzędzia tego rodzaju upewnij się, że masz dobre kopie zapasowe!

+1

proszę wyjaśnić w komentarzach, kiedy przydaje się – user89021

17

Przechowuję folder pod adresem ~/config/, który jest repozytorium bzr. Przesyłam/przeciągam repozytorium pomiędzy różnymi komputerami, aby zsynchronizować to.Mam zainstalować skrypt, który używam do dowiązania do mojego katalogu domowego:

#! /bin/sh 
# link all files to the home directory, asking about overwrites 
cd `dirname $0` 
SCRIPT_DIR=`pwd` 
SCRIPT_NAME=`basename $0` 
FILES=`bzr ls --versioned --non-recursive` 

cd $HOME 
for FILE in $FILES; do 
    ln --symbolic --interactive $SCRIPT_DIR/$FILE 
done 
rm $TARGET_DIR/$SCRIPT_NAME 

Jeśli chcesz użyć git zamiast BZR, można zamiast tego użyć:

FILES=`git ls-tree --name-only HEAD` 

(musiałem ask SO dowiedzieć, że obecnie)

EDIT: ja nie faktycznie to zrobić już teraz mam dotfiles repo na github, z ładnym prowizji zainstalować skrypt, który ktoś inny napisał.

+0

+1 prawie to samo, co robię –

+0

Dziękuję. repozytorium dotfiles jest bardzo pomocne! – Shuo

+0

Jakie są zalety skryptu instalacyjnego rake w porównaniu ze starym skryptem Bash? Czy istnieje różnica między posiadaniem repozytorium bzr a repozytorium dotfiles na github? To brzmi jak to samo rozwiązanie, z wyjątkiem tego, że używasz tylko git vs bzr i innego skryptu instalacyjnego teraz? –

2
+1

+1. Używam również Dropbox. Przechodzę także przez wiele systemów operacyjnych, więc większość plików konfiguracyjnych w Dropbox ma rozszerzenie oznaczające system operacyjny, w którym zostały utworzone. Jeśli oba środowiska są takie same, mogę utworzyć łącze do tego samego pliku niezależnie od rozszerzenia. Na przykład mam dowiązanie symboliczne .profile wskazujące na ~/Dropbox/config/bash/profile.osx. W moim linuxie wskazuje on na ~/Dropbox/config/bash/profile.lin. –

2

Używam dla podobnej sytuacji. luzy pozwalają na definiowanie ról/subrolek, dzięki czemu możesz zarządzać plikami o niewielkiej zmienności poprzez sklonowany plik lub łatę. Katalog luzu jest następnie zarządzany przez git w moim wdrożeniu.

+0

Używam dużo luzu. Jest lekki i szybki i nie przeszkadza. Działa bardzo solidnie tutaj. – user89021

1

myślę, co chcesz może być podobny do tego, co robiłem ...

Zrób katalog w domu nazywany .host_configs/. To jest kontrolowana wersja. Lub w moim przypadku mieszka w specjalnym folderze na centralnym komputerze, a ja go wyrzucam na dowolnej nowej maszynie. Wewnątrz niego tworzysz folder dla każdego hosta, dla którego chcesz mieć różne konfiguracje. Folder dla każdego hosta powinien mieć nazwę po krótkiej nazwie hosta dla tego komputera. Więc w git repo masz:

.host_configs/ 
      homecomp1/ 
      girlfriendcomp1/ 
      workcomp1/ 
      workcomp2/ 

W każdym folderze konkretnego gospodarza, umieścić .vimrc, .irbrc, etc., pliki konfiguracyjne dla tego konkretnego pudełka. A także, w każdym folderze hosta utworzyć plik o nazwie .[SHORT_HOST]_rc. Na przykład, jeśli twój komputer nazywa się "zdrowy", to plik o nazwie .sane_rc ... Ten plik będzie zawierał linie, które normalnie będą w .bashrc, które są unikalne dla tego hosta. Na przykład, jeśli jest to mac i potrzebuje alias ls='ls -GF' zamiast alias ls='ls --color=auto', który działa dla większości maszyn nix dla ls z kolorami, umieść tę linię w .[SHORT_HOST]_rc dla tego komputera, wraz z wszelkimi specjalnymi funkcjami, deklaracjami itp., Które normalnie .bashrc lub .profile itd. (lub .zshrc, .tschrc, w zależności od przypadku). Zatem wersja kontrolowane ~/.host_configs/ folderu wygląda następująco:

.host_configs/ 
      homecomp1/ 
        .homecomp1_rc  #special shell configs for this hostname 
        .vimrc    #you know the rest 
        .irbrc 
        .Xresources 
      girlfriendcomp1/ 
        .girlfriendcomp1_rc 
        .vimrc 
        .bubblebathrc 
      workcomp1/ 
        .workcomp1_rc 
        .bashrc 
        .vimrc 
      workcomp2/ 
        .workcomp2_rc 
        .bashrc 
        .vimrc 

używam wszystko jedno Barebone $ HOME/.bashrc (lub ~/.tshrc etc) na wszystkich moich komputerach. Biorę tylko podstawowy, który pochodzi z danej dystrybucji i przenosimy całą konfigurację specyficzną dla hosta do pliku .host-configs/[SHORT_HOST]/.[SHORT_HOST]_rc.

umieścić to na dole (z $HOME/.bashrc):

export SHORT_HOST="sane" 
for file in `find ~/.host_configs/$SHORT_HOST -name ".*"` 
do 
ln -s $file `basename $file` 
done 
source ~/`.$SHORT_HOST`_rc 

(wyszukuje wszystkie z DOT-plików dla hosta i robi dowiązania w domu do folderu ~/.host_configs/foo_host). Twoje pliki dot są w normalnym położeniu, ale są dowiązane symbolicznie do kontroli wersji. Powyższe źródła są również źródłem wszystkich linii w pliku [$SHORT_HOST]_rc do .bashrc

Możesz cofnąć do git z folderu ~/.host_configs/ po każdej zmianie.

Tak właśnie wygląda w powłoce, co jest prawdopodobnie wszystkim, czego potrzebujesz, ale jeśli potrzebujesz innych funkcji, napiszę coś, co będzie korzystało z tych samych zasad (pozyskiwanie zewnętrznego pliku .rc do .bashrc i dowiązanie wszystkich konfiguracji pliki do folderu kontroli wersji strukturalnej) w coś bardziej uniwersalnego/mniej brzydkiego niż shell. Więc zamiast powyższego w .bashrc, nie może być:

export SHORT_HOST="sane" 
ruby ~/import_conf.rb $SHORT_HOST 

... i napisać import_conf.rb zrobić bardziej kompleksowe zarządzanie conf, jak umieszczenie konkretny plik konfiguracyjny w katalogu oprócz jakiegoś domu, lub obsługa folderu konfiguracyjnego, takiego jak .ssh /, .subversion/itd. To, co robię, jest dla mnie całkiem elegancka, ale mogą istnieć lepsze rozwiązania. Dropbox z kilkoma kreatywnymi dowiązaniami symbolicznymi to także doskonały pomysł, choć polegasz na stronie trzeciej i musisz być w środowisku graficznym. Zwróć też uwagę na niespójności między tym, co możesz zrobić za pomocą dowiązań symbolicznych + Dropbox w Linuksie i skrótów + Dropbox w Windows, jeśli zaimplementujesz coś, co chce grać w systemie Windows.

0

Teraz istnieje również vcsh

Od README:

vcsh - zarządzać config pliki w $ HOME poprzez fałszywe gołymi repozytoriów git

[...]

vcsh umożliwia posiadanie kilku repozytoriów git, wszystkie zachowują swoje drzewa robocze w $ HOME bez kłócą się nawzajem. To z kolei oznacza, że ​​możesz mieć jedno repozytorium na zbiór konfiguracyjny (zsh, vim, ssh, itd.), Wybierając i wybierając konfiguracje, których chcesz użyć na którym komputerze.

Działa doskonale, ale może być nieco zniechęcająca, jeśli nie jesteś doświadczonym użytkownikiem git.

2

Oto niektórzy kierownicy dotfile:

  • homesick: W oparciu o Ruby
  • homeshick: Tak samo jak pierwszy, ale bez uzależnienia rubinowym
  • dfm: Napisany w Perlu
Powiązane problemy