Git – SSL certificate problem: unable to get local issuer certificate

Ten problem pojawia się, gdy sami tworzymy certyfikaty SSL dla Gita.

Poprawna metoda rozwiązania problemu, to wskazanie Gitowi certyfikatów CA:

Problem można również pominąć wyłączyć sprawdzanie certyfikatów w Gicie:

Linki

http://www.jamescoyle.net/how-to/1891-git-ssl-certificate-problem-caused-by-self-signed-certificates

Jak zaimportować repozytorium CVS do Gita

Instalujemy konsolę Babun, uruchamiamy ją i instalujemy potrzebne narzędzia:

Logujemy się, aby uniknąć konieczności podawania za każdym razem hasła (zamień anonymous na swój login):

Importujemy repozytorium:

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:

Powinniśmy otrzymać wynik zbliżony do:

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ą:

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ę:

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):

Po pobraniu zmian, korzystamy z polecenia „rebase”, aby uaktualnić naszą wersję:

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:

W czasie gdy CVS pobiera repozytorium, wyszukujemy w logu hashe rewizji, które chcemy wysłać na serwer CVS:

Zapisujemy hash:

Eksportujemy zmiany:

W wyniku powinniśmy otrzymać:

Ostatnia linia, to polecenie które musimy wykonać, aby wysłać zmiany na serwer CVS:

Linki

https://stackoverflow.com/questions/23109027/authreply-i-hate-you-response-while-using-git-cvsimport

https://stackoverflow.com/questions/11362676/how-to-import-a-cvs-repository-in-git-and-use-it-locally

https://stackoverflow.com/questions/584522/how-to-export-revision-history-from-mercurial-or-git-to-cvs/586225#586225

https://stackoverflow.com/questions/11478353/git-cvsexportcommit-pserver-fails

https://lists.gnu.org/archive/html/info-cvs/2004-08/msg00135.html

Strumieniowanie wideo z Raspberry Pi przy pomocy MJPG-streamera

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.

Oraz tworzymy dowiązanie symboliczne. Bez niego MJPG-streamer nie skompiluje się.

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.

MJPG-streamera nie instalujemy z oficjalnego repozytorium, ponieważ ta wersja nie działa z kamerą Pi, ale korzystamy z tego.

Po kompilacji, pozostajemy w katalogu ze źródłami i wydajemy poniższe polecenie:

Uruchomi się strumień wideo o rozdzielczości 1280×720 i szybkości 30 klatek na sekundę.

Podgląd jest dostępny pod adresem:

Linki

https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=100818

Wyłączenie usypiania karty Wi-Fi w Raspberry Pi

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”:

I dodać do niego:

Po restarcie:

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

Wersjonowanie konfiguracji serwera

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:

Tworzymy puste repozytorium:

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.

Ponieważ domyślnie ignorujemy wszystko, nowe pliki musimy dodawać z opcją -f:

Następnie zachowujemy zmiany:

Jeżeli chcemy sprawdzić co zostało zmienione, to wykonujemy polecenie:

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.

Emulowanie parametrów sieci przy pomocy netem

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:

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:

Dodajemy regułę:

Ponownie pingujemy ten sam serwer:

Jak widać czas odpowiedzi wzrósł o ok. 200 ms.

Utrata pakietów

Reguła:

Oraz wyniki próbkowania:

Pozostałe reguły znajdziemy w dokumentacji.

Linki

http://www.linuxfoundation.org/collaborate/workgroups/networking/netem

Arduino – zdalnie sterowany robot

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.

Koszt części:

  • Arduino Uno Rev 3 – 94,99 PLN
  • Tamiya 70168 Double Gearbox Kit – 50,38 PLN
  • Tamiya 70100 Track and Wheel Set – 36,94 PLN
  • L293D – 3,80 PLN
  • HC-SR04 – 1,23 USD (eBay)
  • HC-06 – 4,47 USD (eBay)
  • przycisk – 0,17 PLN
  • dioda – 0,08 PLN

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.

nginx – 413 Request Entity Too Large

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”:

 

Android NDK – std::string generuje SIGSEGV

Jest to spowodowane sposobem linkowania STL.

W pliku jni/Application.mk ustawiamy zmienną APP_STL na gnustl_shared.

 

Boost dla Androida pod Windowsem

Pobieramy NDK (r10) oraz bibliotekę boost (1.55).

Zakładam, że NDK rozpakujemy do katalogu:

a boosta do katalogu:

Na końcu pliku:

dodajemy:

Otwieramy linię poleceń i przechodzimy do katalogu:

a następnie wydajemy polecenie:

W trakcie kompilacji pojawiały się błędy (cc1plus.exe has stopped working), a sama kompilacja zakończyła się wynikiem:

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

https://github.com/MysticTreeGames/Boost-for-Android