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:

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

Zaszufladkowano do kategorii Git | Jeden komentarz

Jak zaimportować repozytorium CVS do Gita

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/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

Zaszufladkowano do kategorii CVS, Git | Dodaj komentarz

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.

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

Zaszufladkowano do kategorii Raspbian | Dodaj komentarz

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

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

Zaszufladkowano do kategorii Raspberry Pi, Raspbian | 2 komentarze

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:

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.

Zaszufladkowano do kategorii Git, Linux | Dodaj komentarz

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:

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

Zaszufladkowano do kategorii Linux, Oprogramowanie | Dodaj komentarz

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.

  • 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.

Zaszufladkowano do kategorii Arduino, C++, Projekty | Dodaj komentarz

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

server {
  client_max_body_size 32M;
}

 

Zaszufladkowano do kategorii nginx | Dodaj komentarz

Android NDK – std::string generuje SIGSEGV

Jest to spowodowane sposobem linkowania STL.

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

APP_STL := gnustl_shared

 

Zaszufladkowano do kategorii Android, C++ | Dodaj komentarz

Boost dla Androida pod Windowsem

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

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

Zaszufladkowano do kategorii Android | Dodaj komentarz