Chroot

Chroot do 32-bit systemu ARM z poziomu 64-bit linux'owego hosta

Eksperymentując ostatnio z moją maszynką Raspberry Pi 4B, zaszła potrzeba, by zejść do systemu RasPiOS/Raspbian przy pomocy mechanizmu chroot. Problem w tym, że system wyrzuca komunikat: chroot: failed to run command ‘/bin/bash’: Exec format error . Niby wszystko jest na swoim miejscu ale ta widoczna wyżej wiadomość nie chce zniknąć uniemożliwiając tym samym dalszą zabawę z RPI. Okazało się, że winna jest tutaj architektura CPU. Mój laptop działa pod kontrolą 64-bitowego Intel'owskiego procesora (x64, x86-64, AMD64), na którym uruchomiony jest również 64-bitowy Debian linux. Z kolei Raspberry Pi ma 64-bitowy procesor ARM (ARMv8-A) działający pod kontrolą 32-bitowego systemu operacyjnego. Te dość spore rozbieżności sprawiają, że nie damy rady skorzystać z chroot, przynajmniej nie bez zaprzęgnięcia do tego celu emulatora QEMU.

Chroot Apache2 vs dyrektywa open_basedir w PHP

Kilka dni temu wpadł mi w oko artykuł na temat wykonania chroot serwera Apache2. Problem z tamtym tekstem jest taki, że nie uwzględnia on serwera bazy danych MySQL. W efekcie, taki chroot'owany Apache2 będzie miał problemy z połączeniem się do bazy, a nasz serwis bez niej raczej nie będzie działał prawidłowo. Przydałoby się zatem dopracować nieco ten artykuł i wypracować takie rozwiązanie, które nie popsuje przy okazji naszego serwisu www. Dlatego też w tym wpisie wykonamy sobie chroot zarówno serwera Apache2 z obsługą PHP i bazy danych MySQL za sprawą modułu unixd .

Poradnik maintainer'a, czyli jak zrobić pakiet deb

Debian posiada bardzo rozbudowany system robienia pakietów. Generalnie rzecz biorąc, to wszystkie z nich musiały przejść przez ten proces zanim trafiły do głównego repozytorium dystrybucji. Dzięki takiemu stanu rzeczy, nie musimy ręcznie powielać pracy szeregu innych osób i odpada nam własnoręczna kompilacja pakietów, a wszyscy wiemy, że zajmuje ona cenny czas i zasoby. Paczki .deb są tworzone ze źródeł i instalowane przy pomocy menadżera pakietów aptitude/apt/dpkg . Nic jednak nie stoi na przeszkodzie by daną aplikację skompilować sobie ręcznie i zainstalować ją przy pomocy make install . Problem w tym, że w taki sposób robi się śmietnik w naszym systemie i śledzenie wszystkich zainstalowanych w ten sposób pakietów w pewnym momencie stanie się wręcz niemożliwe. Dlatego też przydałby nam się mechanizm, który ułatwiłby nam nieco to zadanie. Debian udostępnia szereg narzędzi, które są w stanie w pełni zautomatyzować cały ten proces budowy pakietów. Ten poradnik zaś ma na celu zebranie wszystkich istotniejszych informacji związanych z obsługą narzędzi takich jak dh_make , dpkg-buildpackage , pbuilder , quilt czy lintian , tak by tworzyć pakiety w prosty sposób i przy tym równając do najwyższych standardów debiana.

Przygotowanie środowiska chroot do pracy

Linuxy mają tę właściwość, że bardzo ciężko jest stracić do któregoś z nich dostęp, nawet w przypadku kompletnego zawału systemu. Jeżeli dysponujemy jakimś alternatywnym środowiskiem w postaci płytki live cd/dvd czy pendrive albo też posiadamy gdzieś zainstalowanego innego linuxa, to istnieje spore prawdopodobieństwo, że uda się nam reanimować nasz główny system. Wszystko za sprawą narzędzia jakim jest chroot , przy którego to pomocy możemy zmienić główny katalog systemu plików ( / ) dla wykonywanych procesów bez potrzeby przechodzenia całej skomplikowanej procedury uruchamiania systemu operacyjnego. Jeśli tylko uda nam się uzyskać dostęp do shella, to nie ma takiej możliwości by system nie stanął na nogi.