Przejdź do głównej zawartości

Python 3.7 na Debianie 8 (Jessie) z pełnym SSL

Jakkolwiek wszyscy dobrze wiedzą, że Debian Jessie to jest staroć i w ogóle nikt go nie używa, to czasem jest potrzeba odpalić nowego Pythona (3.7 oraz nowszy) na takim archaicznym systemie. Problem jest taki, że ten stary Debian ma stare OpenSSL, z którym Python 3.7 nie gada. Nie ma rady, trzeba sobie zmielić nowe libssl i nowego Pythona.

Jak to zwykle w internecie, na ten temat można znaleźć pińcet recept, każdy z autorów zarzeka się, że tylko jego sposób działa, a wszyscy pozostali to hochsztaplerzy. Tymczasem na świeżo mogę napisać, co działa na Armbianie Jessie z jądrem 3.4. Obie zabawki budowane były na miejscu, czyli na komputerku klasy SBC z procesorem Allwinner H3 i 512MB RAM. Decyzja o budowaniu na miejscu zapadła jak zobaczyłem jakiej gimnastyki wymaga budowanie krzyżowe Pythona, np. na x86_64 dla ARMv7. Tak że jakoś przeżyjemy. Jak również spróbowałem zbudować sobie zarówno OpenSSL 1.1.1, jak i LibreSSL 2.9.0 - ostatecznie wybrałem to drugie. Proces budowania jest jakiś taki normalniejszy. LibreSSL trzeba sobie pobrać z release tag na GitHubie z repo portable.

No to jedziemy - trzeba sobie ściągnąć i rozpakować źródła w bezpiecznym miejscu, oraz zadbać o podstawowe zależności, czyli build-essential. Dodatkowo LibreSSL będzie potrzebowało libtool. Do Pythona to już co kto będzie potrzebował, rozsądne minimum to libsqlite3-dev. Zaczynamy jednakowoż od LibreSSL:

./autogen.sh

Po chwili autotools przygotuje wszystko co trzeba do konfiguracji i budowania, a teraz przychodzi moment bardzo ważnej decyzji - trzeba wybrać prefix instalacji. Może jestem zboczony, ale takie rzeczy u mnie lądują w /opt, przede wszystkim po to, żeby łatwo było się ich pozbyć. Czyli:

./configure --prefix=/opt/libressl-2.9.0

Po paru minutach już można sobie zacząć budować to libssl, a że maszyneria to słabizna, w dodatku z wyjątkowo podłym sterowaniem częstotliwością rdzeni, to trzeba z wolna i z ostrożna:

screen -dmS libressl-build sh -c 'make -j3 -l2; exec bash'

Tylko z pasywnym chłodzeniem (aluminiowy radiator na procesorze) więcej się nie da. Próbowałem wielu kombinacji parametrów -j i -l, i dopiero ta nie powodowała przegrzania procesora; udaje się utrzymać temperaturę do 75°C. Więcej jednego lub drugiego i w trakcie budowania będzie reboot, a chyba nie o to nam chodzi.

Jak już się LibreSSL zbuduje, to czas na Pythona. Nie pamiętam ile razy próbowałem na ARM zbudować sobie wersję z włączonym LTO, ale za każdym razem budowanie kończy się memory error, więc jedyne co pozostaje to --enable-optimizations. Ale to jest prościzna, natomiast większym problemem jest jak tego naszego Pytonga pożenić z kastomowym eseselem? Skrypt konfiguracyjny ma opcję --with-openssl gdzie można podać ścieżkę do własnego libssl, ale to jest jakby za mało. Za mało, bo jakkolwiek Python się zbuduje, to się nie wykonają testy, bo linker nie znajdzie libssl. I tu z pomocą przychodzi RPATH. W skrócie opcja ta umożliwa linkowanie bibliotek ze stałego położenia, innego niż wskazane w /etc/ld.so.conf, jak również podawanego w  LD_LIBRARY_PATH. Żeby nam to zadziałało, trzeba to przekazać w zmiennej LDFLAGS ale jako opcja dla linkera, więc w trochę pokręconej formie:

export LDFLAGS="-Wl,rpath,/opt/libressl-2.9.0/lib"
./configure --prefix=/opt/python-3.7.1 \
            --enable-optimizations \
            --with-openssl=/opt/libressl-2.9.0
screen -dnS py371-build sh -c 'make -j3 -l2; exec bash'

Po jakichś 2-3 godzinach powinno być gotowe. Jeżeli jednak procesor się przegrzał i nastąpił reboot, to trzeba wyczyścić katalog z artefaktów i całe budowanie rozpocząć od nowa - taka uroda PGO.

Komentarze

Popularne posty z tego bloga

Programowanie ESP8266 w C/C++

ESP8266 powoli ustępuje miejsca swojemu następcy ESP32, ale jest to proces wyjątkowo powolny. Może to ceny tak samych chipów jak i płytek developerskich to powodują (niewiele jest gotowych modułów w cenie poniżej $10 z przesyłką), a może rozbudowany ekosystem bibliotek do ESP8266. W każdym razie ze starszym bratem ESP32 jeszcze długo będziemy mieć do czynienia, zwłaszcza że jest to wciąż jedna z najlepszych opcji jeżeli chodzi o mikrokontrolery.

ESP8266 można programować w Lua lub w Pythonie, jednak najlepszym wyjściem jest zaprogramowanie własnego firmware w C++ lub w C - daje to największą kontrolę i zapewnia najlepszą wydajność. Jakie mamy do tego możliwości? Od najłatwiejszej do najbardziej skomplikowanej.
ESP8266 core dla Arduino Link: Github

To jest najprostsze rozwiązanie, implementacja ramówki Wiring dla ESP8266. Jakkolwiek można tę obsługę zainstalować w Arduino IDE, to nie ma to większego sensu, bo nie da się tego edytora używać do niczego poważniejszego. Pisze się to w nor…

RetroPie, bo mi się dziecko alienowało

Dziecko moje najdroższe alienowało mi się siedząc przed komputerem w swoim pokoju. Nie żebym jej zabraniał, ale skoro ma grać, to niech gra przy nas, w salonie. Przynajmniej będziemy wiedzieli w co gra.

Wymagane hardware:

Raspberry Pi 2 Mod. B,karta SD min. 8GB,gamepad na USB,telewizor
Opcjonalne w zależności od konfiguracji:

karta WiFi na USBklawiatura na USBpendrive czy inny storage na USB Jak już to wszystko mamy, to możemy robić. Zajmie to parę godzin wszystkiego.
RetroPie Obraz RetroPie pobieramy ze strony projektu, to będzie ten którego nazwa kończy się na rpi2.img.gz. Następnie obraz ten trzeba rozpakować i nagrać w standardowy sposób na kartę SD. Wkładamy kartę do RPi, podłączamy pada do USB, bootujemy naszą zabawkę i zaczynamy konfigurowanko jak zwykle z RPi (z podłączonego klawikordu i na telewizorze, albo po ludzku, po zalogowaniu przez SSH), czyli najpierw używając skryptu raspi-config rozciągamy system plików na całą kartę, reboot, pełna aktualizacja systemu, być może reboo…

Hello, Mr. Developer

Po dłuższej robocie z innymi rzeczami trafił mi się jeden mały projekt, który idealnie nadał się na rozpoznanie bojem, co tam nowego panie w światku bibliotek narzędziowych/ramówek do robienia aplikacji sieciowych - proste REST API z jednym zasobem w kilku perspektywach. Pierwsza myśl była "robiłem to meeelion razy, w jeden dzień będzie z pokryciem 100%". Ale zaraz zorientowałem się, że to dobra okazja, żeby przy okazji rozejrzeć się, czy czasem coś nowego nie pojawiło się na arenie w ciągu tych 3 czy 4 lat, kiedy tłukłem w standardzie Flask + SQLAlchemy, do porzygu. Pamiętam przecież, jak ze 3 lata temu co chwilę pojawiały się jakieś zajawki, że tu jakiś framework osiągnął niesamowite wyniki w benchmarkach, a to jakiś przełomowy koncept miał na zawsze odmienić sposób w jaki robi się webaplikacje w Pythonie, a to to, a to tamto. Poprosiłem więc o chwilę ekstra na zastanowienie się i wyruszyłem wraz z Google na poszukiwanie króla dżungli.
Jest źle, a nawet bardzo źle. Asynch…