Na początku serii porad o zarządzaniu i operacjach z serwerem SVN pokażę najprostszą rzecz – a mianowicie utworzenie nowego repozytorium. Zakładam jednocześnie, że będzie ono hostowane na naszym lokalnym routerze z systemem OpenWRT BackFire 10.03 oraz, że w chcemy mieć do niego dostęp przy użyciu protokołów svn:// i svn+ssh://, zależnie od tego, z której strony się łączymy.

Prawdopodobnie Subversion nie jest jeszcze zainstalowany w ogóle. Dlatego, aby się upewnić sprawdzamy listę zainstalowanych dodatków:

opkg update
opkg list-installed | grep subversion

Jeśli w wyniku zobaczymy na ekranie wpisy o SVN, to znak, że wszystko jest OK. W przeciwnym wypadku najlepiej pobrać już przygotowaną oficjalną dystrybucję ze strony openwrt.org i spróbować ją zainstalować. Służy do tego polecenie:

opkg update
opkg install subversion-server subversion-client

Następnie wracamy do meritum sprawy i tworzymy repozytorium poleceniem:

svnadmin create -fs-type fsfs /sciezka_do_repozytorium

Nowe repozytorium (z rewizją 0.) momentalnie zostanie stworzone. Dalej, edytujemy pliki konfiguracyjne, aby umożliwić sobie zdalny dostęp oraz minimum bezpieczeństwa:

  • w katalogu /etc/config edytujemy plik subversion:

    config subversion
            option path     '/ścieżka_do_repozytorium'
            option port     '3690'
  • w katalogu /ścieżka_do_repozytorium/conf edytujemy plik svnserve.conf:

    ustawiając brak możliwości logowania anonimowego, dając pełnię praw do zapisu zalogowanym poprawnie użytkownikom oraz wskazujemy plik, gdzie znajduje się lista użytkowników i ich haseł

    anon-access = none
    auth-access = write
    password-db = passwd
  • w końcu definiujemy użytkowników w pliku passwd (pozostając nadal w folderze conf naszego repozytorium). Cóż, plik ten nie jest w żaden sposób zabezpieczony. Także gdy już inny zły użytkownik znajdzie ten folder lokalnie, to nie będzie miał żadnego problemu z odzyskaniem i podmianą haseł, dlatego lepiej NIE używać tutaj hasła roota i podobnych.
  • na sam koniec uruchamiamy usługę subversion odpowiednim poleceniem tak, aby włączała się ona automatycznie po restarcie systemu (i gwarantowała dostęp po niezabezpieczonym protokole svn://):

    /etc/init.d/subversion start
    /etc/init.d/subversion enable


    (podpowiedź: po prostu startuje to proces svnserve na porcie 3690 oraz tworzy odpowiednie dowiązanie symboliczne S50subversion w katalogu /etc/rc.d, co powoduje, że będzie on włączany podczas ładowania systemu)

    W ramach testu możemy w tym miejscu posłużyć się TortoiseSVN i w Przeglądarce Repozytorium wypróbować adres: svn://openwrt/ (zamiast ‘openwrt’ należy wstawić nazwę nadaną naszemu routerowi lub po prostu jego adres IP z sieci wewnętrznej). Powinniśmy momentalnie zobaczyć monit o podanie nazwy użytkownika i hasła. Jeśli trwa to dłużej, to coś jest zepsute.
  • dodatkowo, w zależności od tego, z której strony routera chcemy się dostawać do repozytorium (od środka sieci lokalnej, czy z zewnątrz od WAN) tworzymy lub nie dziurę na porcie 3690 w firewallu. Sposób jak tego dokonać opisano tutaj. Pamiętajmy jednak, że przesyłane dane NIE będą w żaden sposób zabezpieczone ani zaszyfrowane. Jeśli zależy nam na bezpieczeństwie, to zalecane jest w tym momencie nie używanie tego połączenia z zewnątrz naszej sieci i czytanie dalej.

Gwarancję bezpiecznego dostępu do danych w naszym repozytorium zapewni nam tunelowanie. Tzn. w naszym przypadku skupimy się na przesyłaniu niezaszyfrowanych danych protokołem svn:// po szyfrowanym tunelu SSH. W ten sposób już nikt nie podsłucha tak łatwo wymiany danych z serwerem. Tutaj kroki, aby zaczęło to działać są nieco bardziej skomplikowane, bo najpierw:

  • zakładamy nowego użytkownika lokalnego, który będzie używany do logowania się na router. Mocno odradzam używania root’a w tym celu. Opis jak założyć użytkownika znajduje się tutaj. Pamiętajmy, aby użytkownik ten miał zdefiniowany poprawny katalog domowy oraz hasło! Hasło można nadać wykonując polecenie:

    passwd <nazwa_użytkownika>

    (uwaga: od tej pory, logując się do SVN przez SSH, plik z hasłami definiowany w katalogu conf repozytorium będzie ignorowany i SVN będzie zakładało, że poprawna autoryzacja SSH jest wystarczająca, a wszystkie zmiany będą odbywały się w kontekście właśnie tego użytkownika!)
  • otwieramy port 22 od strony połączenia WAN, co umożliwi nam zdalne logowanie SSH (jako dodatkowe zabezpieczenie możemy otworzyć inny port, który tylko my będziemy znać i robić przekierowanie na port 22 lub zmienić port nasłuchiwania usługi SSH)
  • jako test w tym momencie możemy wykonać na dowolnym innym komputerze podłączonym do naszej sieci:

    ssh <nazwa_użytkownika>@<IP routera od strony WAN>

    lub

    ssh –p <number_portu_jeśli_inny_niż_22> <nazwa_użytkownika>@<IP routera od strony WAN>

    lub wykorzystać program Putty, gdy testujemy z Windowsa.
  • tworzymy jeszcze tylko dowiązanie symboliczne na routerze, abyśmy nie musieli pamiętać ścieżki do repozytorium i mieli je zawsze dostępne pod hasłem “repo”

    ln –s /ścieżka_do_repozytorium /repo
  • na sam koniec przechodzimy do konfigurowania klienta, gdzie musimy zdefiniować odpowiedni ‘tunel’. Na moim komputerze wygląda to tak, że w katalogu “~/.subversion” należy edytować plik config i dodać tam w sekcji “[tunnels]” następującą linijkę (wszystko w jednej linii!):

    ssh = $SVN_SSH ssh –q –p <numer_port_od_strony_WAN_dla_SSH>
                          –l <nazwa_użytkownika_do_logowania_SSH>
  • Gotowe! Od tej pory pobieramy repozytorium poprzez nieco zmodyfikowany adres:

    svn co svn+ssh://<adres_publiczny_naszego_routera>/repo <lokalny_folder_gdzie_zapisać_pliki>

    Jeśli nie utworzyliśmy dowiązania ‘repo’ to w jego miejscu musimy wpisać całą ścieżkę lokalną do repozytorium, co nie musi być zawsze oczywiste.

    Jedyny mankament to to, iż za każdym razem, gdy mamy odwiedzić repozytorium musimy wielokrotnie wpisać hasło. Mi to nie przeszkadza, ale mimo wszystko to też da się obejść. Odsyłam do popularnego tematu w google ‘automatyczne logowanie SSH’.

Od tej pory wersjonowanie plików stało się jeszcze przyjemniejsze!