Development z Zapomnianej Strony

..:: Paweł Hofman .NET Portal ::..

Dla niektórych może jest to i zbytnia perwersja, ale lubię, gdy używając jakiegoś narzędzia, stosuję się do sugerowanych przez nie konwencji. Dzięki temu wszystko to, co robię nie odstaje od siebie. I tak patrząc na repozytorium w SVN, każdy commit przypisany był do użytkownika systemowego i oznaczany po prostu jego loginem (a często i jakimiś magicznymi przy- i przedrostkami – wystarczy spojrzeć na przykład z codeplex.com: “SND\FeydRauth_cp”). GiT z kolei próbuje opatrzeć wszystko właścicielem w formacie “<login> <email>”.

Jak zatem przenosząc repozytorium utrzymać jednolite nazwy autorów tak, aby nie dało się odróżnić, która część pochodzi z czasów, gdy używany był jeden system kontroli wersji, a które już po przeprowadzce?

Odpowiedź jest bardzo prosta – użyć opcji “-A <nazwa_pliku_txt>” podczas klonowania repozytorium SVN, która zapewni translację autorów. W pliku tym zapisujemy reguły, każda w osobnej linii, w postaci:

<nazwa_autora_svn> = <nazwa_autora_git>Czyli np.:

pawel = pawel <pawel@email.com>
pawelh = pawel <pawel@email.com>

Dodatkowo, jeśli nie zależy nam na jakiejkolwiek późniejszej synchronizacji możemy dodać również opcję “--no-metadata”, która zapobiegnie doklejaniu dodatkowych danych w komentarzach, które opisywałyby źródłowe commity SVN, już docelowo w GiT-ie.

Całe polecenie wygląda wtedy tak:

git svn clone svn+ssh://<svn_url> <local_name> -A authors.txt --no-metadata

Oczywiście zakładamy tutaj, że:

- svn+ssh:// – to wykorzystywany schemat do repozytorium SVN (równie dobrze może to być samo svn:// lub http://)

- svn_url – to pełny adres gałęzi, którą będziemy klonować

- local_name – to nazwa lokalnego folderu, w którym zostanie utworzone repozytorium GiT

- authors.txt – to nazwa pliku z regułami translacji autorów opisanymi powyżej.

 

Teraz pozostaje tylko upewnić się, że ustawiliśmy w konfiguracji GiTa ten sam login i email dla nowego autora i ładnie wypchnąć nowe repozytorium.



Kolejną ciekawostką, którą chciałbym omówić są zdalne repozytoria i dostęp do nich. O ile są to repozytoria tego samego typu (czyli np. Subversion połączone z Subversion – jako externals, czy Git pracujący z Gitem – jako submodules), to nie ma to większego znaczenia i obsługa jest bezproblemowa.

Ciekawsze są oczywiście krzyżówki. Jeśli przyjrzymy się bliżej pracy w Git, który musi korzystać z zewnętrznego repozytorium Subversion, to już wcale nie musi wyglądać prosto. Weźmy choćby mój projekt CodeTitans Libraries (wspomagający użycie protokołu Bayeux, standardu wymiany danych tekstowych JSON, InversionOfControl oraz udostępniający niektórych funkcjonalności znanych programistom iOS SDK w .NET-cie). Codeplex.com udostępnia go jako Subversion.

Przyjmijmy, że repozytorium Git, ma bardzo prostą strukturę złożoną z branchy master oraz develop. Pierwszy służy to przechowywania referencji stabilnych wersji kodu oraz ich etykietowania. Drugiego używamy do rozwijania i pracy nad aktualnym kodem.

Cel: gdzieś w katalogu Externals/CodeTitans chcielibyśmy mieć kod z też projektu.

W tym celu przede wszystkich będziemy potrzebowali dodatkowego brancha. Nazwijmy go codetitans_develop. Wybiegając do przodu - Git tak naprawdę skopiuje pełny kod źródłowy zewnętrznego projektu i sam będzie go wersjonował. Niestety minus jest taki, iż będzie on ten kod próbował umieścić w głównym folderze swojego własnego repozytorium, generując niezły chaos, przy złączeniu obu projektów (tego pierwotnie trzymanego w Gicie oraz nowego). Praca na dodatkowym branchu pozwoli nam zatem na wprowadzanie lokalnych zmian, np.:

  • przeniesienia plików do wspomnianego folderu Externals/CodeTitans
  • dokonywania innych drobnych modyfikacji (np. gdy chcemy bezpośrednio dodać pliki do solution, bez referencjonowania projektów biblioteki CodeTitans Libraries, to może widoczność zmienić z ‘public’ na ‘internal’)

A zatem, po kolei:

  1. Dodanie nowego brancha:

    git checkout –b codetitans_develop
  2. Dodanie referencji do zewnętrznego repozytorium SVN:

    git svn init https://codetitans.svn.codeplex.com/svn -R codetitans --prefix Externals/CodeTitans/ --ignore-paths="^[^/]+/(?:branches|tags|bin)"

    - lokalizacja – codeplex.com
    - nazwa lokalna – codetitans
    - ponieważ repozytorium to ma standardową strukturę, a nas interesuje jedynie ‘trunk’ – ignorujemy pozostałe foldery
  3. Pobieramy historię zmian z repozytorium SVN:

    git svn fetch codetitans

    (za pierwszym razem pobrane zostanie pełna historia, co może trochę trwać; dla oszczędzenia czasu plecam dodanie opcji “-r <rev>” z numerem ostatniej rewizji, która jest dla nas istotna; później już oczywiście tylko ostatnie zmiany będą synchronizowane)
  4. Poprzednie polecenie, de facto, pobiera pliki, ale nie są one jeszcze nigdzie widoczne. Aby stały się widoczne, musimy połączyć je (operacją merge) z aktualnym branchem (tym utworzonym i ustawionym jako aktualny w kroku 1.).
    Pytanie pozostaje, co mamy teraz łączyć.

    Lista wszystkich branchy (git branch –a) ujawnia, że zostało dodane wskazanie zewnętrzne na kod SVN. Wygląda ono mniej więcej tak:

    remotes/Externals/CodeTitans/git-svn

    I łączymy kod:

    git merge –squash remotes/Externals/CodeTitans/git-svn

    Uwaga! W przyszłości to właśnie tutaj, podczas operacji merge będzie występowało najwięcej konfliktów. Tutaj też ładnie je rozwiążemy, a osobny branch gwarantuje nam, że nie mieszamy kodu (i zmian w nim) projektu zewnętrznego z naszym produkcyjnym.
  5. Wprowadzamy wszystkie niezbędne poprawki (przenosimy, zmieniamy treść plików…). Oczywiście operacje te kończymy pojedynczym:

    git commit –a –m “<komunikat>
  6. Wracamy z powrotem na nasz główny branch:

    git checkout develop
  7. I dodajemy do niego wypielęgnowany kod zewnętrznego projektu, który idealnie pasuje do naszej struktury:

    git merge --no-ff codetitans_develop

    - --no-ff – bardzo ważna opcja dla późniejszej graficznej wizualizacji repozytorium i zmian na nim; otóż wszystkie zmiany z brancha codetitans_develop nie zostaną wessane do brancha aktywnego w tym momencie brancha develop

    Tutaj już nie powinny wystąpić żadne konflikty, bo kod jest jednak rozdzielny, a wszystkie zmiany odnośnie zewnętrznej biblioteki prowadzone były na branchu “codetitans_develop”.
  8. Aktualizacja:

    Kiedy nasz projekt Subversion ulegnie zmianie, musimy je mozolnie dodać na repozytorium Git. Niestety, aby wszystko pięknie działało, należy wykonać wszystkie kroki od 3-ego włącznie.

Salute!



Czasem zdarza się sytuacja, w której ktoś, kto ma dostęp tylko do odczytu do naszego repozytorium SVN, chciałby w nim coś jednak zapisać. Udało mu się (lub jej) rozwiązać jakąś usterkę czy problem, albo usprawnić działanie. Moglibyśmy w tym miejscu dodać uprawnienia do zapisu i byłoby po sprawie.

Jednak czy na pewno? Zawsze jakieś “ale”! Z czegoś wynikał przecież fakt, że ów użytkownik nie posiadał pełni praw.

  • Czy wspomniana zmiana ma w ogóle sens i czy w ogóle istnieje? (może ktoś tylko chce wyłudzić dostęp)
  • Czy zmiany są w pełni przetestowane?
  • Czy nie wprowadzają luk w zabezpieczeniach i innych ukrytych furtek?
  • Czy zgadzają się one z konwencją nazewniczą i stosują projektowe formatowanie kodu?
  • Czy będziemy pamiętać, o cofnięciu uprawnień, gdy zmiany zostaną już wysłane do repozytorium?

Wyjściem z tej sytuacji może okazać się utworzenie "łatki" (patcha), która zawierała będzie tylko proponowane zmiany w konkretnych plikach i lokalizacjach. Później przekazanie jej zaufanej osobie w projekcie, która zmiany te może przejrzeć, ocenić i ma prawa do zapisu na serwerze. Oto jak się za to zabrać:

  1. Zapamiętanie zmian:

    svn diff > fix.diff

    (Rozszerzenie diff jest rozpoznawane przez wiele edytorów, podświetlając składnię podczas przeglądania, niemniej jednak każde inne byłoby równie dobre)

  2. Aplikacja zmian:

    patch -p0 -i fix.diff

    Teraz można sprawdzić, co i gdzie się zmieniło i po przeglądzie (oraz koniecznie testach) wysłać do repozytorium na serwerze.
  3. Wysłanie na serwer:

    svn commit –m “<message> 


Kontynuując post o samym tworzeniu repozytorium i dostępie do niego z poziomu terminala Linuxa, warto też wspomnieć, że tak samo łatwo skonfigurować go można na Windowsie.

Otóż tunel ssh definiujemy w sekcji [tunnels] pliku (ścieżka dla Windows 7):

C:\Users\<użytkownik>\AppData\Roaming\Subversion\config

 

Wygląda on mniej więcej tak:

ssh = “C:/Programy/Putty/plink.exe” –P <port SVN> –l <użytkownik>
                                  –i “C:/Users/<użytkownik>/.ssh/id_rsa”

Wyjaśniając:

  1. Przy użyciu programu plink (wchodzącego w skład ‘paczki’ putty, którą trzeba pobrać i zainstalować wcześniej), utrzymywane będzie połączenie ssh do serwera.
  2. Plik klucza prywatnego id_rsa, nie jest wymagany, a jedynie stanowi ułatwienie, aby nie wprowadzać hasła przy każdorazowym dostępie do serwera (a ich żądań może być wiele nawet przy jednorazowej aktualizacji plików, czy pobieraniu/przeglądaniu repozytorium).

 

 

Jest jeszcze druga wersja tego tunelu, która pozwala na jednoczesne korzystanie z TortoiseSVN. Wygląda ona tylko nieznacznie inaczej:

ssh = “C:/Program Files/TortoiseSVN/bin/TortoisePlink.exe” –P <port SVN> –l <użytkownik>
                                 –i “C:/Users/<użytkownik>/.ssh/id_rsa”

 

 

Do repozytorium dostajemy się później standardowo poleceniem:

svn co svn+ssh://<ścieżka>

oraz aktualizujemy:

svn up .

Gotowe!



Na szczęście autorzy Subversion przewidzieli, że potrzeba czasem przenieść repozytorium z jednej lokalizacji do drugiej z zachowaniem pełnej historii.

Pobieramy i zapisyjemy w pliku 'repo.dump' istniejące rewizje poleceniem:

svnadmin dump <ścieżka_do_źródłowego_repozytorium> > repo.dump

Na ekranie zobaczymy postęp w formie:

* Dumped revision 0.
* Dumped revision 1.
* Dumped revision 2.
* Dumped revision 3.
* Dumped revision 4.
* Dumped revision 5.
* Dumped revision 6.
* Dumped revision 7.
......

 

Odtwarzamy dane w nowym repozytorium poleceniem:

svnadmin load <ścieżka_do_nowego_repozytorium> < repo.dump

Co się objawi poprzez serie komunikatów o zaaplikowanych zmianach dla konkretnej wersji i może trwać dość długo (jeśli weźmiemy pod uwagę fakt, że robimy to na dość wolnym urządzeniu, które skonfigurowaliśmy uprzednio tutaj).

     * adding path :  ... done.
     * adding path :  ... done. 
     * adding path :  ... done                                                             .

------- Committed revision 18 >>>



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!



Słowem wstępu – jak to już wcześniej opisałem udało mi się reanimować router. Model całkiem niezły i radość tym większa, że teraz mając dwa, na jednym można poeksperymentować. Jak zatem da się go jakoś mądrze wykorzystać? Otóż w sieci domowej miło jest mieć jakiś serwerek, gdzie poprzez zwykłe otoczenie w Windowsie można by trzymać kopie swoich dokumentów, zdjęć, filmów i mieć do nich zawsze dostęp. Lub też utrzymywać inne repozytorium (jak SVN, git czy mercurial) albo uderzyć z zupełnie innej strony i postawić sobie stronkę WWW na własne potrzeby. Małe uwagi w tym miejscu:

  • ta dobra – opisywany model ma dwa wyjścia USB, także w teorii na brak miejsca nie musimy narzekać, bo zawsze można jakiegoś pendrive’a, czy dysk podpiąć
  • ta lepsza – w porównaniu do normalnego PC, który musiałby pełnić podobną rolę, router nie ma w ogóle wentylatorów, czyli nie hałasuje oraz nie zużywa tyle prądu!
  • i w końcu ta zła – na standardowym firmware’rze tego nie osiągniemy i trzeba się nieco nagimnastykować, aby wgrać alternatywne oprogramowanie.

Przeglądając Internet natrafimy na takie zastępcze firmware’y jak: OpenWrt, DD-Wrt, Tomato, Oleg czy dziesiątki tysięcy ich klonów, które jedyne co wniosły, to odbiły się w którymś momencie od głównej gałęzi kodu, wypuściły serię koszulek czy kubków z nazwą nowego projektu i zamarły...

Po krótkiej analizie zdecydowałem się na OpenWRT. Głównie z tej przyczyny, iż jest on ciągle rozwijany i niedawno wyszła nowa wersja (o kryptonimie BackFire 10.03). Ponadto posiada bardzo dużą ilość pakietów, które realizują w zasadzie wszystkie funkcjonalności, których wymagałem, a ilość pomocy i poradników na jego temat jest przeogromna.

A zatem po kolei:

  1. Zaznajamiamy się z tematem. Polecam poczytanie przewodników – jak wypalić, co i gdzie zmieniać, jak zachowywać się w przypadku błędów, czy jak dogrywać pakiety. Mnogość informacji znajduje się na stronie samego OpenWRT, jego polskim portalu oraz tego oto jednego zapaleńca z eko.one.pl.
  2. Kompilujemy! Nic bardziej mylnego! To jest największy złodziej czasu oraz sprawca zepsutego humoru! Niestety po instalacji Debiana na maszynie wirtualnej, zaaplikowaniu pakietów z narzędziami dla developera oraz ściągnięciu źródeł samego OpenWRT (z ich SVNa oraz później poprzez make download) i po 3-ch zmarnowanych wieczorach poddałem się. Za każdym razem coś się nie chciało skompilować. Ponadto budowanie równoległe (make –j3) dawało jeszcze bardziej dziwaczne błędy. W dodatku cały czas istnieje obawa, że nie mamy doświadczenia i, że czegoś zapomnimy dodać, marnując jeszcze więcej czasu przy konfiguracji. Dlatego też skierowałem się w inną stronę...
  3. Instalujemy gotowy plik obrazu firmware’u *.trx, który już ktoś dla nas przygotował. Tutaj kolejna uwaga: na pewno nie ten ze strony OpenWRT :) Powód jest prozaiczny – te obrazy nie zawierają standardowo wkompilowanego w kernel wsparcia do USB. Niby nic wielkiego, bo przecież można to później dograć. Jednak nie pozwoli to na wykonanie jednej sztuczki, zwiększającej pamięć, o której mowa w następnych punktach. Tutaj znajdziemy odpowiednio skompilowane wersje.
  4. Poprzez panel sterowania Windowsa 7 dodajemy sobie nową funkcję – program tftp.
  5. Wprowadzamy router Asusa w stan gotowości do wgrania firmware’u (trzymając wciśnięty przycisk reset przez 10sek zaraz po włożeniu kabla zasilającego).
  6. Ustawiamy ręcznie adres IP swojej karty sieciowej tak, aby widziała ona router (czyli 192.168.1.20/255.255.255.0; często też jeśli wcześniej zmieniliśmy adres podsieci wymagana może być zmiana ‘1’ na inną wartość)
  7. Wykonujemy polecenie:

    tftp –i 192.168.1.1 PUT openwrt-brcm47xx-squashfs.trx

    czekamy aż wszystko się wyśle, później router się uruchomi sam ponownie i aż będziemy się mogli zalogować poprzez usługę telnet.
  8. Wymieniona wersja nie posiada oczywiście żadnego interfejsu graficznego (czy też konfiguracji poprzez www), dlatego wszystko od tej pory wykonujemy na konsoli, edytując wartości w plikach konfiguracyjnych. Dodatkowymi atutami będą: znajomość poleceń systemu Linux oraz programów telnet, Putty.
  9. Po zalogowaniu zmieniamy hasło (poleceniem passwd) po czym logujemy się ponownie używając Putty.
  10. Teraz widząc, że nasz router ma tylko 32MB pamięci RAM  – rozszerzamy ją dodając pamięć wirtualną swap. Wszystko opisane jest bardzo przystępnie tutaj. Polega to głównie na sformatowaniu pendrive’a i podzieleniu go na dwie partycje: (1) pliku wymiany swap o pojemności 256MB oraz (2) danych.
  11. Teraz widzimy, że router ma nie więcej niż 4MB przestrzeni, na którą możemy coś wgrać. Jest to stanowczo za mało nawet na nasze pakiety (tj.: obsługę polskiego kodowania, moduły do Subversion, Pythona, Mercuriala, Sambę itp). Plus jest taki, że już mamy pendrive’a podpiętego do USB (koniecznie obsługa USB musi być wkompilowana w kernel – zachęcam do poczytania o partycji ‘overlay’ oraz jak działa system plików squashfs oraz jffs). Teraz też możemy pokazać mu, że można wykorzystać drugą partycję, aby to ona stała się ‘fizyczną’ pamięcią zapisywalną routera. Robimy zatem wszystko zgodnie z tym poradnikiem. Pamiętajmy jednak, że zmiana podstawowej partycji do zapisu danych spowoduje, że wszystkie ustawienia, które do tej pory zmieniliśmy na routerze zostaną zastąpione tymi, które są zapisane na pendrive’ie i jeśli był on pusty wcześniej tzn. że zostaną użyte domyślne i całą konfigurację trzeba przeprowadzić od nowa.
  12. Dwie ostatnie rady są o tyle dobre, że nie trzeba już nic robić, aby przekierowywać instalowane pakiety, czy w ogóle martwić się o miejsce na samą konfigurację routera. Wszystkie sztuczki z modyfikowaniem ‘destination’ dla opkg, czy dodawaniem nowych folderów do zmiennej środowiskowej $PATH idą do lamusa.
  13. Dodatkowo dodajemy i tak dysk na USB albo drugi pendrive, na którym będziemy przechowywać faktycznie pliki z danymi!

O samej konfiguracji serwisów wpis niebawem. Trzymam kciuki, że ten poradnik w takiej formie ocali komuś trochę czasu!



VisualSVN oprócz wersji klienta SVN, od niedawna udostępnia również instalator, który pomaga w łatwy i przyjemny sposób udostępniać usługę SVN-serwer na własnych serwerach developerskich poprzez HTTP/HTTPS. Razem z binariami do zarządzania repozytorium, instalowany jest serwer Apache (lub to co jest z niego wymagane) oraz autorski panel administracyjny. Poprzez niego zakładane są repozytoria, przypisywane uprawnienia użytkowników oraz generowane (przypinane) certyfikaty SSL dla połączeń HTTPS.

To co ucieszyć może domorosłych programistów i administratorów to fakt, iż nawet darmowa wersja pozwala na wykorzystanie go w pracach nad komercyjnymi produktami. Dodatkowym atutem jest fakt, iż bardzo łatwo integruje się z domeną Active Diretory.



mar
08

Instalacja serwera SVN

by Paweł | Tags:

Zachęcony ostatnio rozmową z kolegą z pracy, który w ramach zarządzania swoim domowym projektem zrobił z nim wreszcie porządek na dysku i przeniósł do systemu kontroli wersji, postanowiłem uczynić to samo. Oczywiście tylko w stosunku do projektów, których na razie nie mam zamiaru publikować i które aktualnie już nie znajdują się na codeplex.com czy code.google.com.

Nie będę w tym momencie wychwalał korzyści płynących z utrzymywania repozytorium i możliwości podglądnięcia dowolnych historycznych zmian, etykietowania, czy nawet  tworzenia wersji eksperymentalnych naszego projektu w stosunku do stosowanej obecnie (i powszechnie?) techniki pakownia całego katalogu z odpowiednią datą w tytule… Nie opowiem również, jak wzrasta samozadowolenie z własnej pracy, a tym bardziej o jej komforcie. Zachęcam natomiast do zaznajomienia się z 12-o punkowy Testem Joela opublikowanym w 2000 roku przez Joela Spolsky’ego, który poucza, na co jeszcze w swoim życiu programistycznym zwrócić uwagę.

Jednak muszę tutaj przyznać, że nie jestem i nie byłem zbytnio zafascynowany myślą instalacji IISa albo Tomcata, czy innego serwera WWW, tylko po to, aby na domowym komputerze mieć system kontroli wersji. Dlatego też opisana poniżej procedura opiera się na następujących założeniach:

  • minimalne zużycie pamięci i procesora
  • możliwość włączenia/wyłączenia tej zabawki w dowolnym momencie
  • brak dodatkowych kosztów, jeśli wymagane dodatkowe oprogramowanie (darmowe lub open-source)
  • możliwość współpracy i dostępu dla kilku osób w sieci lokalnej

 
Przed przystąpieniem do właściwego konfigurowania swojego środowiska wymagana jest instalacja dwóch programów:

  • SlikSvn – darmowa kompilacja serwera Subversion, która zawiera minimalny zbiór narzędzi i bibliotek, bez integracji z serwerem Tomcat oraz innych niepotrzebnym gadżetów; niestety jest to tylko zbiór plików i to dalsza procedura ma właśnie na celu zrobienie z nich użytku
  • TortoiseSvn – darmowy klient SVN, który umożliwi nam między innymi pobieranie i wkładanie plików do repozytorium z poziomu Explorera Windows; polski słownik i interfejs są również dostępne, co ładnie sprawdza błędy pisowni podczas dołączania komentarzy i opisów plików

 

Właściwa procedura wygląda tak:

 

  1. SvnService - new userTworzymy nowego użytkownika SvnService, w kontekście którego wykonywane będą wszystkie operacje na repozytorium. Pom oże to bardzo w samym zarządzani u dostępem do katalogów oraz innymi uprawnieniami w przyszłości.
     
    (Zarządzanie komputerem / Użytkownicy i grupy lokalne)










     
  2. SvnService - not a local user Poni eważ nie chcemy, aby ktoś na naszym komputerze zalogował się jako ten użytkownik oraz aby nie był on widoczny na stronie startowej Windowsa, usuwamy go z grupy użytkowników (lokalnych).











     
  3. SvnService - logon as serviceDodajemy jednak u prawnienia do logowania w trybie usługi, gdyż SVN będzie uruchamiany właśnie przez tego użytkownika jako lokalna usługa systemowa zaraz po włączeniu komputera.

    (Zasady zabezpieczeń lokalnych / Zasady lokalne / Przypisywanie praw użytkownika / Logowanie w trybie usługi)






     
  4. SvnService - open port [Opcjonalnie] Otwieramy port TCP/IP 3690 (domyślny dla tej usługi ) w używanym firewallu w systemie, aby umożliwić dostęp innym użytkownikom z sieci lokalnej dostęp do przyszłego repozytorium.








     
  5. Dodajemy nową usługę do systemu, która będzie odpowiedzialna za zarządzanie serwerem Subversion, uruchamiana oczywiście z poświadczeniami utworzonego wcześniej użytkownika. Tworzymy równocześnie repozytorium w z góry predefiniowanym miejscu. Wszystko to załatwia prosty skrypt napisany w starym dobrym shellu Windowsa:

    @echo off

    set svnpath=C:\Program Files\SlikSvn\bin
    set svnrepository=E:\Repositories\Local Projects
    set svnaccount=machine\SvnService
    set svnpassword=P@$$w0rd

    sc create svn binpath= "\"%svnpath%\svnserve.exe\" --listen-host 0.0.0.0 --service -r \"%svnrepository%\"" displayname= "Subversion Server" depend= Tcpip start= auto obj= %svnaccount% password= %svnpassword%

    net start svn

    "%svnpath%\svnadmin.exe" create "%svnrepository%"


    [Wymagane!] Zmieniamy parametry odnośnie użytkownika, hasła oraz lokalizacji według własnych wymagań.

    Omówienie parametrów svnserve.exe:

    • --service – od pewnego czasu SVN nie potrzebuje już żadnego zewnętrznego oprogramowania i sam potrafi włączyć się w trybie usługi, nie wymagając interakcji z aktualną sesją użytkownika
    • --listen-host - wymyszenie nasłuchiwania na wszystkich interfejsach IPv4 (szczególnie ważne, gdy spotkamy problemy z połączeniem na Windows Vista)
    • -r – definicja lokalizacji repozytorium, nawet jeśli nie jest ono jeszcze stworzone
    • inne parametry – jak chociażby port, tryb pracy bazy danych z kodem można ustawić według własnych potrzeb, tu pozostawiamy ich domyślne wartości

    Omówienie parametrów sc.exe:

    • create – utworzenie usługi w systemie (delete – usunięcie, ale wymagane jest wcześniejsze jej zatrzymanie poprzez “net stop svn”)
    • svn – nazwa usługi
    • binpath – lokalizacja uruchamianego pliku wraz z listą parametrów
    • displayname – nazwa wyświetlana wewnątrz narzędzi systemowych zarządzających usługami
    • depend – lista innych usług, od których zależy nasz serwer SVN
    • start – sposób uruchamiania usługi (auto = razem ze startem systemu)
    • obj – użytkownik, który uruchamia usługę
    • password – jego hasło

      [Uwaga!] To nie jest błąd, że wszystkie te parametry mają spację pomiędzy znakiem równości a wartościami. To jest właśnie składnia wywołania i przekazywania parametrów menadżera usług.
       
  6. Należy jeszcze tylko zlokalizować katalog z repozytorium i zmienić uprawnienia użytkowników:
    • usunąć prawa dostępu dla wszystkich użytkowników
    • nadać pełnię praw dla użytkownika SvnService
    • prawa te powinny być dziedziczne dla wszystkich elementów tego katalogu i potomnych
       
  7. Edytujemy plik z katalogu repozytorium /conf/svnserve.conf, w którym definiujemy, że:
    • anonimowi użytkownicy nie mają dostępu
    • zalogowani użytkownicy mogą zmieniać wszystkie pliki
    • listę użytkowników znajdziemy w pliku passwd w tym samym katalogu

      anon-access = none
      auth-access = write
      password-db = passwd
  8. Edytujemy plik passwd z tego samego katalogu definiując użytkowników i ich hasła, np.


    [users] 
    harry = harryssecret 
    sally = sallyssecret

  9. TortoiseSVN - repository browse...Testujemy  dostęp do repozytorium, włączając przeglądanie plików w TortoiseSVN ze ścieżką:

    svn://localhost/  lub
    svn://nazwa-maszyny/

    Wpisujemy nasze poświadczenia zdefiniowane w pliku passwd i gotowe! 







      

    TortoiseSVN - open repository URL






     
  10. Od tej porTortoiseSVN - server preview y możemy już cieszyć się opcją importowania danych do repozytorium, tworzenia nowych katalogów, przeglądania wersji i wszystkimi innymi dobrodziejstwami.
     

 









Dodatkowo – jeśli ktoś dobrnął aż tutaj i chciałby dalej pogłębiać swoją wiedzę na temat systemu Subversion, zachęcam do zapoznania się z darmową wersją książki o tym systemie kontroli wersji dostępną on-line w systemie O’Reilly Media tutaj lub off-line w katalogu, do którego zainstalowany został SlikSvn.



Autor

Paweł Hofman [CodeTitans]

ASP.NET
C/C++, C#, Objective-C
SQL

License and Disclaimer

Moje Gry i Aplikacje

Zobacz mnie na GoldenLine

Zobacz mnie na LinkedIn
Supported by Polish SQL Server User Group (PLSSUG)

Supported by WrocNet.org

Zine.net.pl

Wpisy

Projekty

Moje projekty open-source:

Sign in