Development z Zapomnianej Strony

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

Z niewiadomych powodów Synology usunęło pakiet Mono z repozytorium ipkg. Jednak i na to znajdzie się sposób. Przecież wszystko da się skompilować ze źródeł.

Poniżej przestawię jak to zrobić. Przyznaję jednak, że jest to tylko tłumaczenie. Oryginalny post znajduje się tutaj. Wielkie dzięki dla Kennetha za jego wysiłek! Mój wkład, to przetestowanie tego na DS411 oraz użycie stabilnej wersji Mono-2.10.9 zamiast Mono-alpha-2.11.0, czyli mimo wszystko nie za dużo ;)

Ostrzeżenie: ta kompilacja można na prawdę zająć duuużo czasu, liczonego w godzinach.

 

  • Na początku instalujemy wymagane narzędzia do przeprowadzenia kompilacji:
ipkg install wget nano make automake autoconf bison \
    glib libc-dev libstdc++ m4 gcc gawk textutils gettext zlib
  • Pobieramy i wypakowujemy źródła projektu Mono:
wget "http://download.mono-project.com/sources/mono/mono-2.10.9.tar.bz2"
tar -xf mono-2.10.9.tar.bz2
  • Konfigurujemy źródła dla naszej maszyny:
cd mono-2.10.9 ./configure --prefix=/opt/mono-2.10.9

Przełącznik ‘prefix’ pozwoli nam później zainstalować skompilowaną wersję Mono w tym właśnie folderze, zamiast użycia domyślnego “/usr”. Dzięki temu w przyszłości łatwiej będzie wszystko usunąć lub aktualizować.

  • Edytujemy konfiguracje, tak aby dodać łączenie z biblioteką “rt”.
    Rozwiązuje to problem opisany tutaj, gdzie brakuje metod odwołujących się to czasu procesora.

W plikach:

mono/metadata/Makefile
mono/mini/Makefile
mono/profiler/Makefile

Edytujemy wartość zmiennej flag dla linkera (LDFLAGS):

LDFLAGS = -lrt
  • Dodatkowo, poprawiamy problem z nieistniejącymi symbolami w bibliotece pthreads, która domyślnie instaluje się z pakietów ipkg. Problem szczegółowo opisany na forum Synology.

mv /opt/arm-none-linux-gnueabi/lib/libpthread* /opt/arm-none-linux-gnueabi/lib_disabled
cp /lib/libpthread.so.0 /opt/arm-none-linux-gnueabi/lib/
cd /opt/arm-none-linux-gnueabi/lib/
ln -s libpthread.so.0 libpthread.so
ln -s libpthread.so.0 libpthread-2.5.so

  • Kompilujemy:

make

  • Instalujemy (automatycznie do /opt/mono-2.10.9):

make install

  • Dowiązujemy narzędzia, tam gdzie zainstalowałyby się domyślnie:

ln -s /opt/mono-2.10.9/bin/mono /opt/bin/mono
ln -s /opt/mono-2.10.9/bin/mcs /opt/bin/mcs
ln -s /opt/mono-2.10.9/bin/gmcs /opt/bin/gmcs

  • I finalny test:

mono --version
Mono JIT compiler version 2.10.9 (tarball Tue May 29 16:18:24 CEST 2012)
Copyright (C) 2002-2011 Novell, Inc, Xamarin, Inc and Contributors. www.mono-project.com
TLS: normal
SIGSEGV: normal
Notifications: epoll
Architecture: armel,soft-float
Disabled: none
Misc: softdebug
LLVM: supported, not enabled.
GC: Included Boehm (with typed GC and Parallel Mark)

Gotowe, brawo!



Co nim może być? Otóż – polskie znaki! Pokarało mnie potwornie, bo wszędzie próbuję stworzyć użytkownika o imieniu ‘Paweł’ (aż żal, że tak nazwałem systemowego).

Och, jak ciężko w dobie powszechnej cyfryzacji, o wsparcie chociażby dla kilku głupawych znaków tu i tam. Poległ mi na tym system online FedEx, gdzie lepiej z definicji nie używać żadnych nie ASCII-7 znaków, następnie konsola do GITa, nie umie poprawnie wyświetlić mojego imienia, ani znaleźć katalogu domowego,  a teraz rady sobie nie dają narzędzia do Android na Windows 7.

I tylko jedno lekarstwo przychodzi do głowy – symlink tych wszystkich głupawych odmian, do mojego folderu. W Windows 7 junction robi się tak:

C:\Users>mklink /D "PaweĹ‚" "Paweł"

Znowu możemy poczuć się prawie jak w domu!



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!



Tyle co ukazał się upragniony przez wielu Visual Studio 2010 ServicePack 1, a już okazuję się, iż kolejność instalowania dodatków do Visual Studio ma swoje zależności.

To o czym chciałem przede wszystkim powiedzieć, to wymóg instalacji Visual Studio SDK przed zainstalowaniem SP1. Inaczej nie będzie to możliwe i instalacja się nie powiedzie z dziwnie (jak zwykle?) nic nie mówiącym komunikatem o błędzie.

Error Type: Microsoft.VisualStudio.Sdk.Setup.MissingPrerequisiteException
Error Message: You must have Microsoft Visual Studio 2010 installed on your computer before procedding.

 

Visual Studio 2010 SDK Error

Jak zatem wybrnąć z tej sytuacji (bo instalacja na maszynie wirtualnej zajęła jednak sporo czasu! i cofanie jej + ponawianie to trochę zbyt wiele)? Otóż sztuczka polega na tym, aby używając monitora rejestru zobaczyć, do czego próbuje odwołać się instalator SDK. W moim przypadku było to lokalizacja numer wersji Visual Studio Service Pack:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\VS\Servicing\10.0]
“SP” = 1

A zmieniając wartość z ‘1’ na ‘0’, oszukamy na chwilkę instalator SDK. Na koniec przywracamy ‘1’ i po sprawie.

Więcej o tym, jak znaleźć rozwiązanie samemu następnym razem - tutaj.



Jeżeli zależy nam na jakości wytwarzanego oprogramowania (co jest z góry wiadome, że tak) – to pojęcie Continous Integration nie powinno być obce. Mi osobiście do gustu przypadł projekt BuildBot. Jednym zdaniem – mały, prosty, obsługujący wiele platform, bardzo łatwo rozszerzalny i co więcej mamy pełny kod źródłowy, gdyby coś poszło nie tak…

Jak go zatem zainstalować na Windows XP (i późniejszym)? Twardzieli odsyłam do “oficjalnego” przewodnika. Ja postaram się dodać coś od siebie i zmniejszyć ilość potrzebnym kroków:

  1. Instalujemy Python 2.7.1. Inne (czyt.: wyższe) wersje Pythona mogą być nieco niewygodne, bo nie wszystkie ‘pakiety’ wymagane przez BuildBota mogą być już zaktualizowane, aby z nią działać i w chwili pisania, tak właśnie było.
  2. Do zmiennej systemowej PATH dodajemy odpowiednio katalogi (co skróci niektóre męki przy wykonywaniu poleceń z konsoli):
    • C:\Python27
    • C:\Python27\Scripts
      (najprościej chyba we Właściwościach Systemu –> Zaawansowane –> Zmienne środowiskowe i tam znajdziemy Path)
  3. Instalujemy twisted w wersji 10.2.
  4. Instalujemy SetupTools dla Pythona w wersji 2.7.1. Będą one potrzebne, aby później bez problemu pobrać z sieci wszystko to, czego jeszcze brakuje dla działającej instancji BuildBota.
  5. Teraz poleceniami instalujemy:
    • easy_install Zope.Inteface
    • easy_install jinja2
    • easy_install PyCrypto
    • easy_install PyOpenSSL
  6. Wreszcie pobieramy samego BuildBota (jako master i slave). Rozpakowujemy do katalogu C:\Temp.
  7. Instalujemy go:
    • python C:\Temp\buildbot-0.8.2\setup.py install
    • python C:\Temp\buildslave-0.8.2\setup.py install
  8. Sprawdzamy, czy wszystko działa:
    buildbot --version

    Powinno zwrócić numer wersji, a nie krzyczeć o brak zainstalowanego pakietu.
  9. Teraz pozostała już tylko własna konfiguracja maszyn budujących, dostępów do repozytoriów, nadobnych akcji, uruchamiania testów oraz przygotowywaniu release’a. O tym może opowiem coś niedługo. Dokumentacja natomiast opisuje wszystko bardzo czytelnie.

Oczywiście nie byłbym sobą, gdybym w tym momencie nie napotkał na problem oraz nie próbował ostrzec, że bardzo łatwo zmarnować wieczór i stracić dobry humor. Powód dość prozaiczny. Nie działa logowanie oraz podgląd wykonywanych poleceń, historia itp. Generalnie dużo rzeczy wygląda jak nieudane posuniecie i brak wsparcia dla Windowsa. Nic bardziej mylnego.  Winą obarczmy brak zgrania BuildBota z najnowszą wersją twisted. Bardzo ładnie opisano to w tickecie #1697. Z pomocą przychodzi nam tutaj oczywiście otwartość kodu tego projektu. W opisie problemu znajduje się odnośnik do poprawki. Aplikujemy ją bardzo prosto, nadpisując plik builder.py, tym, który ściągamy z repozytorium.

Uruchamiamy ponownie BuildBot mastera i gotowe!



Kolejny dzień, kolejny problem z serii, “bo coś jest zepsute u podstaw” konfiguracji systemu… Zawczasu ostrzegam, że wpis ten jest wybitnie rozwlekły i nie jest przeznaczony dla osób niecierpliwych.

Zatem po kolei. Będąc zafascynowany “nowymi” rozwiązaniami, postanowiłem w ramach testów uruchomić przykłady z pakietu CometD i zapoznać się nieco z protokołem Bayeux (zainteresowanych tematem odsyłam do dokumentacji projektu). Oczywiście nic prostszego - wchodzimy na stronę projektu, pobieramy odpowiednie źródła, wypakowujemy CometD i uruchamiamy Jetty, które instaluje w sobie odpowiednie rozszerzenie. Wszystko bardzo ładnie w kilku zdaniach opisane jest tutaj.

Jakież wyrazy cisną nam się na usta, gdy ściągane są kolejne pakiety idące już prawie w gigabajty (do Javy, Apache, Maven2, itp…). Mija w końcu to niesłychanie długie 20 minut i oczom naszym ukazuje się Jetty w pełnej krasie. Ostrzegam, że jeszcze nawet nie zaczęliśmy grzebać w naszym testowym Debianie, a przecież chwilkę temu pobraliśmy najnowsze wersje całego oprogramowania na świecie.

~/cometd-2.0.0/cometd-demo$ mvn jetty:deploy-war
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'jetty'.
[INFO] ------------------------------------------------------------------------
[INFO] Building CometD :: Demo
[INFO] task-segment: [jetty:deploy-war]
[INFO] ------------------------------------------------------------------------
[INFO] Preparing jetty:deploy-war
[INFO] [enforcer:enforce {execution: enforce-plugin-versions}]
[INFO] [jetty:deploy-war]
[INFO] Configuring Jetty for project: CometD :: Demo
[INFO] Context path = /
[INFO] Tmp directory = /home/pawel/cometd-2.0.0/cometd-demo/target/tmp
[INFO] Web defaults = org/eclipse/jetty/webapp/webdefault.xml
[INFO] Web overrides = none
[INFO] Starting jetty 7.1.5.v20100705 ...
2010-09-05 01:29:34.971:INFO::jetty-7.1.5.v20100705
2010-09-05 01:29:37.803:WARN::EXCEPTION
java.lang.NullPointerException
    at javax.naming.spi.NamingManager.getPlusPath(libgcj.so.90)
    at javax.naming.spi.NamingManager.getStateToBind(libgcj.so.90)
    at org.eclipse.jetty.jndi.NamingContext.bind(NamingContext.java:337)
    at org.eclipse.jetty.jndi.NamingContext.bind(NamingContext.java:415)
    at org.eclipse.jetty.jndi.java.javaRootURLContext.(javaRootURLContext.java:78)
    at java.lang.Class.initializeClass(libgcj.so.90)
    at org.eclipse.jetty.jndi.java.javaURLContextFactory.getObjectInstance(javaURLContextFactory.java:63)
    at javax.naming.spi.NamingManager.getURLContext(libgcj.so.90)
    at javax.naming.spi.NamingManager.getURLContext(libgcj.so.90)
    at javax.naming.InitialContext.getURLOrDefaultInitCtx(libgcj.so.90)
    at javax.naming.InitialContext.lookup(libgcj.so.90)
    at org.eclipse.jetty.plus.webapp.EnvConfiguration.createEnvContext(EnvConfiguration.java:202)
    at org.eclipse.jetty.plus.webapp.EnvConfiguration.preConfigure(EnvConfiguration.java:62)
    at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:378)
    at org.mortbay.jetty.plugin.JettyWebAppContext.doStart(JettyWebAppContext.java:114)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55)
    at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:165)
    at org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:162)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55)
    at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:165)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55)
    at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:92)
    at org.eclipse.jetty.server.Server.doStart(Server.java:242)
    at org.mortbay.jetty.plugin.JettyServer.doStart(JettyServer.java:67)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55)
    at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:437)
    at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:377)
    at org.mortbay.jetty.plugin.JettyRunWarMojo.execute(JettyRunWarMojo.java:68)
    at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
    at java.lang.reflect.Method.invoke(libgcj.so.90)
    at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
    at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
    at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
    at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

A później jest już prościej, bo co sekundę wyskakuje wyjątek (co zdecydowanie lepiej rzuca się w oczy):

2010-09-05 01:38:42.200:WARN::EXCEPTION java.lang.ClassCastException: gnu.java.nio.ServerSocketChannelImpl cannot be cast to java.nio.channels.SocketChannel
    at org.eclipse.jetty.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:708)
    at org.eclipse.jetty.io.nio.SelectorManager.doSelect(SelectorManager.java:195)
    at org.eclipse.jetty.server.nio.SelectChannelConnector.accept(SelectChannelConnector.java:134)
    at org.eclipse.jetty.server.AbstractConnector$Acceptor.run(AbstractConnector.java:793)
    at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:436)
    at java.lang.Thread.run(libgcj.so.90)

   

Jednym słowem czad!

No niby prosty przykład, a ile radości. Cóż, znowu ktoś zawinił. Tym bardziej ciekawe jest kto oraz że na forum projektu milczą o tym błędzie, jakby się wszyscy pod ziemię zapadli. Podpowiem, że projekty (CometD oraz sam Jetty) dostępne sąt od kilku ładnych lat i na pewno ktoś by się z tym problemem zetknął. Chyba nie jestem aż takim szczęściarzem. A może jednak to jest jakaś niszowa przypadłość? Bynajmniej. Troszkę szperania i co się okazuje. Otóż ani PATH ani JAVA_HOME nie pokazują lokalizacji JVM (Java Virtual Machine). Dokumentacja do Jetty mówi o tym wyraźnie. Ustawiamy ścieżkę do /usr/lib/jvm/java-1.5.0-gcj-xxx i wszystko powinno ruszyć. Teoretycznie. W praktyce, dostajemy dokładnie ten sam błąd. No jakoś się całe środowisko pokumało, że tylko jedna wersja Javy była zainstalowana i nawet bez JAVA_HOME udało się ją załadować. No to może jeszcze inaczej, może gdzieś, jakiś przełącznik, jakaś aktualizacja, patch rejestru (dobra to nie Windows), symlink? wrr, cokolwiek.

Otóż nie. To, co zazwyczaj okazuje się poprawne, zazwyczaj też siedzi na samym szarym końcu rozwiązań i ostatnie wpada do głowy. Cały JVM jest do wyrzucenia :) No bo przecież GNU Java nie jest zgodna z Sun Java (tu wstaw dowolną wersję), bo i po co? Jakichże to kolorów nabiera wtedy życie…

Tak, ale instalacja oryginalnej ‘sunowskiej’ Javy też nie jest wcale taka prosta. Aby uzyskać dostęp do wersji Javy (Sun JDK 1.5 i JDK 1.6), niezbędny jest na początku dodatkowy wpis w konfiguracji apt-get. Te JDK-i oznaczone są bowiem jako “non-free” i musimy zaakceptować dodatkową licencję zanim będziemy mogli z nich skorzystać.

  • Dopisujemy więc na końcu pliku konfiguracyjnego apt-get (/etc/apt/sources.list) następującą linijkę:

deb http://ftp.debian.org/debian lenny main contrib non-free

  • Odświeżamy listę dostępnych pakietów:

apt-get update

  • Instalujemy Javę (kawę i kolejne 20 min mamy już tym razem w pogotowiu):

apt-get install sun-java6-jdk

apt-get install sun-java5-jdk

  • Na koniec, ustawiamy ją jako domyślną w systemie:

update-java-alternatives -s java-6-sun
echo 'JAVA_HOME="/usr/lib/jvm/java-6-sun"' | tee -a /etc/environment

  • Gotowe! Uruchamiamy ponownie skrypt Maven, który uruchamia Jetty i instaluje w nim CometD. Tym razem z powodzeniem pod adresem http://localhost:8080/ mamy już działające przykłady i użycie Bayeux! Nic dodać nic ująć.

Jednak wieczór można uznać za udany. Szkoda tylko, że nie to mi go skradło, na co chciałem go przeznaczyć…

Dziękuję za uwagę.



Stało się i znów jest problem. Jednego dnia zamykamy sprawny komputer, drugiego okazuje się, że zamiast włączać się jak zawsze (powiedzmy, że bez większych problemów) nasz Windows 7 ciągle się restartuje, uruchamia tryb odzyskiwania systemu lub testuje pamięć. Objawy o tyle dziwne, że wzięły się znikąd (tzw. efekt skraplania się z powietrza), a Windows wygląda, jakby chciał działać, a jednak nie mógł. Widać bowiem i animowane logo ‘okienek’ i pasek postępu, a nagle wyskakuje dialog odzyskiwania systemu i poszukiwania zaistniałego problemu.

Poczekawszy, aż proces odzyskiwania się zakończy (co u mnie niekiedy trwało i 10 minut), z logów dowiedziałem się, że wszystko jest OK, że przeprowadzono 1000 razy próbę ratunku i że mogę wysłać wieści do Redmont. Dopiero na samym końcu widniał napis w stylu:

Plik sterownika “C:\WINDOWS\system32\drivers\sptd.sys” jest uszkodzony.

Jakiekolwiek próby automatycznego odtworzenia tego pliku się nie udawały. Windows też nie próbował pominąć tego sterownika przy starcie i po prostu uruchamiać się dalej, tkwiąc w martwym punkcie po kolejnym restarcie. Wykonane testy pamięci nie zwróciły żadnego błędu. Wyjście awaryjne w postaci cofnięcia się do jednego z Punktów Odtwarzania Systemu, również się nie powiodło. Niby komunikat przed ich wykonaniem informował, że nie można przerwać tego procesu, ale gdzieś w środku wyskakiwał błąd z magiczną wartością 0x8xxx…

Na szczęście naciśnięcie F8 przy uruchamianiu komputera na płytach Asusa wyświetla menu z listą dysków twardych. Mogłem uruchomić dzięki temu inny z moich systemów operacyjnych i próbować szukać rozwiązania. W tym samym czasie skanowanie powierzchni partycji z systemem Windows 7 nie wykazało najmniejszego problemu. Sprzęt sprawny, komputer dzień wcześniej działał, to o co chodzi? Ano o to, że sterownik sptd.sys to: SCSI Pass Through Direct, czyli jeden z wielu sterowników dostępu do danych przestał działać! Jest on używany między innymi przez Daemon-Tools do świadczenia swoich usług i potwierdzania swojej ‘fizyczności’. No ale Daemony miałem zainstalowane od miesięcy i wszystko działało…ot złośliwość losu… Zmiana nazwy pliku ISO, który był włożony do wirtualnej stacji oczywiście też nie poprawiła sytuacji i system się nadal nie uruchamiał.

Rozwiązanie:

  1. Po zakończonej próbie automatycznego odzyskiwania, wybieramy ‘zaawansowane’ opcje (widoczne jako niebieski odnośnik na dole głównego okna programu).
  2. Wpisujemy login i hasło dla administratora komputera.
  3. Uruchamiamy terminal (potocznie znany tryb MS-DOS lub konsolą), w którym nawigujemy do katalogu system32/drivers i zmieniamy nazwę pliku sptd.sys, na jakąkolwiek inną (odsyłam do pomocy poleceń: cd, cp, del).
  4. Uruchamiamy komputer ponownie i tym razem uruchomi się bez najmniejszego problemu. Wszystko będzie działać prócz wirtualnej stacji DVD.
  5. Ze strony autorów sterownika SPTD (www.duplexsecure.com) pobieramy najnowszą wersję, którą dzisiaj jest v1.69 i instalujemy.
  6. Koniec. Wszystko wraca do normy.


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!