Ten problem pojawia się, gdy sami tworzymy certyfikaty SSL dla Gita.
Poprawna metoda rozwiązania problemu, to wskazanie Gitowi certyfikatów CA:
git config --system http.sslCAPath /git/certificates
Problem można również pominąć wyłączyć sprawdzanie certyfikatów w Gicie:
git config --global http.sslVerify false
Linki
http://www.jamescoyle.net/how-to/1891-git-ssl-certificate-problem-caused-by-self-signed-certificates
Instalujemy konsolę Babun, uruchamiamy ją i instalujemy potrzebne narzędzia:
pact install git-cvs
Logujemy się, aby uniknąć konieczności podawania za każdym razem hasła (zamień anonymous na swój login):
cvs -d :pserver:anonymous@cvs.server.address.com:/cvs/project_name login
Importujemy repozytorium:
git cvsimport -C directory -r cvs -k -d :pserver:anonymous@cvs.server.address.com:/cvs/project_name module_name
Importowanie dużego repozytorium, może potrwać nawet kilka lub kilkanaście godzin.
Kiedy import się zakończy możemy w pełni korzystać z możliwości Gita. Na początek proponuję przejrzeć istniejące gałęzie:
git branch --all
Powinniśmy otrzymać wynik zbliżony do:
> master > remotes/cvs/critical_bug_fix > remotes/cvs/new_window_feature > remotes/cvs/HEAD -> cvs/master > remotes/cvs/master
Załóżmy, że chcemy pracować na gałęzi „new_window_feature”. Każda zmiana musi zostać zachowana w lokalnej gałęzi, zanim wyślemy ją na serwer CVS, więc tworzymy ją:
git checkout -b new_window_feature remotes/cvs/new_window_feature
Teraz możemy pracować, przeglądać historię zmian itd. Po zakończonej pracy, ale przed wysłaniem zmian na serwer, należy upewnić się, że mamy najnowszą kopię kodu, a jeżeli ktoś w między czasie wysłał swoje zmiany na serwer, pobrać je. Służy do tego polecenie „git cvsimport”. Zanim ponownie go użyjemy, zapiszemy w konfiguracji kilka parametrów, aby ułatwić sobie przyszłą pracę:
git config --local cvsimport.module module_name git config --local cvsimport.r cvs git config --local cvsimport.d :pserver:anonymous@cvs.server.address.com:/cvs/project_name
Powyższe parametry są dokładnie takie same jak te, które podawaliśmy przy imporcie repozytorium. Przed importem zmian, musimy przejść na gałąź „master” (może istnieje inny sposób, ale na chwilę obecną go nie znam):
git checkout master git cvsimport
Po pobraniu zmian, korzystamy z polecenia „rebase”, aby uaktualnić naszą wersję:
git checkout new_window_feature git rebase remotes/cvs/new_window_feature
Pobieranie repozytorium i synchronizacja zmian z serwera CVS do nas jest prosta i dość oczywista. Niestety, wysyłanie naszych zmian na serwer CVS już nie.
Aby wysłać własne zmiany na serwer CVS, musimy wcześniej pobrać kopię roboczą repozytorium przy pomocy klienta CVS, a następnie każdą rewizję przenosić do z kopii roboczej Gita do kopii roboczej CVS:
cvs -d :pserver:anonymous@dcvs.server.address.com:/cvs/project_name checkout module_name
W czasie gdy CVS pobiera repozytorium, wyszukujemy w logu hashe rewizji, które chcemy wysłać na serwer CVS:
git log
Zapisujemy hash:
> commit b3e7es855e43baba2b28521b619f7387a3ee4373 > Author: Jan Kowalski <jan@kowalski.pl> > Date: Tue Jul 7 08:47:48 2015 +0200 > Fixed code formatting.
Eksportujemy zmiany:
git cvsexportcommit -v -w /path/to/csv/working/copy b3e7es855e43baba2b28521b619f7387a3ee4373
W wyniku powinniśmy otrzymać:
> Applying to CVS commit b3e7es855e43baba2b28521b619f7387a3ee4373from parent ea7964b788e69382ec81d2e1d2d98bd3a21c203f > Checking if patch will apply > Applying > Patch applied successfully. Adding new files and directories to CVS > Commit to CVS > Patch title (first comment line): Fixed code formatting. > Ready for you to commit, just run: > cvs commit -F .msg 'path/to/changed/file.cpp'
Ostatnia linia, to polecenie które musimy wykonać, aby wysłać zmiany na serwer CVS:
cvs commit -F .msg 'path/to/changed/file.cpp'
Linki
https://stackoverflow.com/questions/23109027/authreply-i-hate-you-response-while-using-git-cvsimport
https://stackoverflow.com/questions/11478353/git-cvsexportcommit-pserver-fails
https://lists.gnu.org/archive/html/info-cvs/2004-08/msg00135.html
Najnowsza wersja MJPG-streamera najwyraźniej nie działa z najnowszą wersją Raspbiana (wersja jądra 3.18.7+).
Kompilacja przebiega poprawnie, serwer HTTP również uruchamia się poprawnie, ale żadne dane wideo nie są przesyłane. Poniżej rozwiązanie tego problemu
Najpierw instalujemy potrzebne paczki.
sudo apt-get install libjpeg8-dev imagemagick libv4l-dev
Oraz tworzymy dowiązanie symboliczne. Bez niego MJPG-streamer nie skompiluje się.
sudo ln -s /usr/include/linux/videodev2.h /usr/include/linux/videodev.h
Wcześniejsze wersje MJPG-streamera posiadały wtyczkę input_file.so, która pozwalała na monitorowanie katalogu i przesyłanie pliku graficznego, który się w nim pojawiał.
Obecna wersja posiada wtyczkę input_uvc.so, która wymaga, aby kamera była dostępna w katalogu /dev. Kamera dedykowana dla Raspberry Pi nie jest domyślnie dostępna w tym katalogu, więc musimy załadować moduł bcm2835-v4l2. Poniższe polecenie najlepiej dodać do /etc/rc.local, aby moduł ładował się przy każdym starcie Pi.
sudo modprobe bcm2835-v4l2
MJPG-streamera nie instalujemy z oficjalnego repozytorium, ponieważ ta wersja nie działa z kamerą Pi, ale korzystamy z tego.
git clone https://github.com/SaintGimp/mjpg-streamer cd mjpg-streamer/mjpg-streamer make
Po kompilacji, pozostajemy w katalogu ze źródłami i wydajemy poniższe polecenie:
./mjpg_streamer -i "input_uvc.so -f 30 -r 1280x720" -o "output_http.so -p 8080 -w www"
Uruchomi się strumień wideo o rozdzielczości 1280×720 i szybkości 30 klatek na sekundę.
Podgląd jest dostępny pod adresem:
http://127.0.0.1:8080/stream.html
Linki
https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=100818
Domyślnie karta Wi-Fi (WiFi USB N 150Mbps Edup EP-N8508GS), którą podłączyłem do Raspberry Pi usypiała się po kilkunastu sekundach. Nie jest to problem podczas korzystania z Raspberry Pi, ponieważ karta wybudza się szybko, ale powoduje, że nie można się do niej podłączyć z zewnątrz.
Aby wyłączyć usypianie karty należy utworzyć plik „8192cu.conf”:
sudo nano /etc/modprobe.d/8192cu.conf
I dodać do niego:
options 8192cu rtw_power_mgnt=0
Po restarcie:
sudo reboot
Karta Wi-Fi nie będzie usypiana. Oczywiście, wiąże się to z nieco większym poborem energii.
Linki
https://raspberrypi.stackexchange.com/questions/1384/how-do-i-disable-suspend-mode
Na swoim serwerze tworzę kopie zapasowe plików konfiguracyjnych oraz ważnych plików przy pomocy systemu kontroli wersji.
Używanie systemu kontroli wersji ma przewagę nad zwykłymi kopiami zapasowymi, ponieważ mogę z łatwością sprawdzać które linie zostały zmodyfikowane oraz przywracać poprzednie wersje przy pomocy jednego polecenia.
Aby utworzyć repozytorium, przechodzimy do głównego katalogu:
cd /
Tworzymy puste repozytorium:
git init
Następnie tworzymy plik .gitignore, w którym umieszczamy regułę ignorującą wszystkie pliki oraz katalogi. Robimy tak, ponieważ łatwiej jest dodać pliki, które chcemy wersjonować niż wyłączać wszystkie, które nie powinny się znaleźć w repozytorium.
touch /.gitignore echo "/*" > .gitignore
Ponieważ domyślnie ignorujemy wszystko, nowe pliki musimy dodawać z opcją -f:
git add -f /etc/apache2 git add -f /etc/php5
Następnie zachowujemy zmiany:
git commit -m "Added Apache and PHP configuration."
Jeżeli chcemy sprawdzić co zostało zmienione, to wykonujemy polecenie:
git status
W ten sposób możemy łatwo śledzić zmiany w konfiguracji lub sprawdzić czy instalacja dodatkowych aplikacji wpływa na konfigurację. Jeżeli serwer przestanie działać poprawnie, to można łatwo wrócić do poprzedniej.
Jest to tylko prosty przykład wykorzystania systemu kontroli wersji do tworzenia kopii zapasowej konfiguracji. Repozytorium powinno się znajdować na osobnym serwerze tak, aby w przypadku awarii możliwe było uzyskanie dostępu do kopii.
netem służy do emulowania opóźnień i utraty danych w sieciach komputerowych. Przy jego pomocy możemy sprawdzić czy nasze oprogramowanie jest odporne na działanie zakłóceń w sieci.
Do testów używam systemu Debian. Instalujemy emulator:
apt-get install netemul
Po instalacji możemy dodawać reguły zmieniające parametry sieci. Poniżej zamieszczam przykłady dwóch najbardziej przydatnych reguł, czyli opóźnienia oraz utraty pakietów. Wszystkie polecenia wykonujemy bezpośrednio w konsoli.
Opóźnienie
Pingujemy dowolny serwer:
PING google.pl (173.194.113.63) 56(84) bytes of data. 64 bytes from some.host.com (173.194.113.63): icmp_req=1 ttl=54 time=289 ms 64 bytes from some.host.com (173.194.113.63): icmp_req=2 ttl=54 time=280 ms 64 bytes from some.host.com (173.194.113.63): icmp_req=3 ttl=54 time=256 ms 64 bytes from some.host.com (173.194.113.63): icmp_req=4 ttl=54 time=256 ms
Dodajemy regułę:
tc qdisc add dev eth0 root netem delay 200ms
Ponownie pingujemy ten sam serwer:
PING google.pl (173.194.113.63) 56(84) bytes of data. 64 bytes from some.host.com (173.194.113.63): icmp_req=1 ttl=54 time=566 ms 64 bytes from some.host.com (173.194.113.63): icmp_req=2 ttl=54 time=519 ms 64 bytes from some.host.com (173.194.113.63): icmp_req=3 ttl=54 time=462 ms 64 bytes from some.host.com (173.194.113.63): icmp_req=4 ttl=54 time=457 ms
Jak widać czas odpowiedzi wzrósł o ok. 200 ms.
Utrata pakietów
Reguła:
tc qdisc change dev eth0 root netem loss 10%
Oraz wyniki próbkowania:
--- google.pl ping statistics --- 36 packets transmitted, 32 received, 11% packet loss, time 62492ms
Pozostałe reguły znajdziemy w dokumentacji.
Linki
http://www.linuxfoundation.org/collaborate/workgroups/networking/netem
Celem projektu jest zbudowanie robota, który będzie potrafił samodzielnie poruszać się w zamkniętych pomieszczeniach (w mieszkaniu). Robot powinien być świadomy swojej aktualnej pozycji oraz reagować na zmieniające się otoczenie (nowe przeszkody na trasie przejazdu).
Sercem robota jest Arduino Uno Rev3. Silnikami steruje układ L293D. Za wykrywanie przeszkód odpowiada czujnik ultradźwiękowy HC-SR04, a za komunikację radiową moduł bluetooth HC-06.
Robota porusza się dzięki gumowym gąsienicom (zestaw Tamiya), a „pod maską” pracują dwa silniki (zestaw Tamiya 70168) z przekładniami z przełożeniem 344:1.
Dodatkowo robot posiada włącznik oraz diodę sygnalizującą pracę robota.
Wygląd robota pozostawia wiele do życzenia (karton, widoczne przewody), ale jest to tylko prototyp. Kolejne wersje będą bardziej rozbudowane oraz zamknięte w obudowie ze sklejki lub plastiku.
Planuję wyposażyć robota w kompas elektroniczny (HMC5883L), akcelerometr (LIS35DE) oraz umieścić czujnik odległości na serwomechanizmie (Tower Pro Serwo SG-92R). Dzięki temu robot będzie mógł lepiej orientować się w otaczającej go przestrzeni.
Robot otrzyma również kamerę (Raspberry Pi Model A oraz moduł z kamerą HD) dzięki czemu możliwe będzie rejestrowanie trasy oraz nawigowanie z użyciem obrazu.
Robot zostanie powiększony. Gąsienice zostaną wydłużone, a podstawa poszerzona, aby zmieścić dodatkowy osprzęt oraz chwytak.
W kolejnych wpisach poświęconych Arduino opiszę budowę robota oraz jego oprogramowanie.
Błąd pojawia się, gdy próbujemy wysłać na serwer zbyt duży plik.
Rozwiązaniem jest dodanie ustawienia „client_max_body_size” do sekcji „server”:
server {
client_max_body_size 32M;
}
Jest to spowodowane sposobem linkowania STL.
W pliku jni/Application.mk ustawiamy zmienną APP_STL na gnustl_shared.
APP_STL := gnustl_shared
Pobieramy NDK (r10) oraz bibliotekę boost (1.55).
Zakładam, że NDK rozpakujemy do katalogu:
C:\android-ndk-r10
a boosta do katalogu:
C:\boost_1_55_0
Na końcu pliku:
D:\Dev\boost_1_55_0\tools\build\v2\user-config.jam
dodajemy:
using gcc : androidR8e : arm-linux-androideabi-g++ : <archiver>arm-linux-androideabi-ar <compileflags>-fpic <compileflags>-ffunction-sections <compileflags>-funwind-tables <compileflags>-fstack-protector <compileflags>-no-canonical-prefixes <compileflags>-fexceptions <compileflags>-frtti <compileflags>-D__ARM_ARCH_5__ <compileflags>-D__ARM_ARCH_5T__ <compileflags>-D__ARM_ARCH_5E__ <compileflags>-D__ARM_ARCH_5TE__ <compileflags>-Wno-psabi <compileflags>-march=armv5te <compileflags>-mtune=xscale <compileflags>-msoft-float <compileflags>-mthumb <compileflags>-fomit-frame-pointer <compileflags>-fno-strict-aliasing <compileflags>-finline-limit=64 <compileflags>-Wa,--noexecstack <compileflags>-DANDROID <compileflags>-D__ANDROID__ <compileflags>-DNDEBUG <compileflags>-g0 <compileflags>-O3 <compileflags>-std=c++11 <compileflags>-I$(AndroidNDKRoot)/platforms/android-9/arch-arm/usr/include <compileflags>-I$(AndroidNDKRoot)/sources/cxx-stl/gnu-libstdc++/4.8/include <compileflags>-I$(AndroidNDKRoot)/sources/cxx-stl/gnu-libstdc++/4.8/libs/armeabi/include # @Moss - Above are the 'oficial' android flags <architecture>arm <compileflags>-fvisibility=hidden <compileflags>-fvisibility-inlines-hidden <compileflags>-fdata-sections <cxxflags>-D__arm__ <cxxflags>-D_REENTRANT <cxxflags>-D_GLIBCXX__PTHREADS ;
Otwieramy linię poleceń i przechodzimy do katalogu:
C:\boost_1_55_0
a następnie wydajemy polecenie:
b2 --without-python --without-serialization threading=multi link=static runtime-link=static toolset=gcc-android target-os=linux threadapi=pthread --stagedir=android stage
W trakcie kompilacji pojawiały się błędy (cc1plus.exe has stopped working), a sama kompilacja zakończyła się wynikiem:
...failed updating 26 targets... ...skipped 6 targets... ...updated 237 targets...
Pomimo błędów udało się mi poprawnie utworzyć plik APK, więc prawdopodobnie błędy dotyczą modułów, które nie były używany przez naszą aplikację.
Linki
https://stackoverflow.com/questions/17667978/using-boost-in-android-ndk-with-windows