<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Chroot on Morfitronik</title>
    <link>https://morfikov.github.io/tags/chroot/</link>
    <description>Recent content in Chroot on Morfitronik</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>pl-PL</language>
    <lastBuildDate>Sun, 07 Nov 2021 10:20:00 +0100</lastBuildDate><atom:link href="https://morfikov.github.io/tags/chroot/feed.xml" rel="self" type="application/rss+xml" />
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Chroot do 32-bit systemu ARM z poziomu 64-bit linux&#39;owego hosta</title>
      <link>https://morfikov.github.io/post/chroot-do-32-bit-systemu-arm-z-poziomu-64-bit-linuxowego-hosta/</link>
      <pubDate>Sun, 07 Nov 2021 10:20:00 +0100</pubDate>
      
      <guid>https://morfikov.github.io/post/chroot-do-32-bit-systemu-arm-z-poziomu-64-bit-linuxowego-hosta/</guid>
      <description>&lt;p&gt;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:
&lt;code&gt;chroot: failed to run command ‘/bin/bash’: Exec format error&lt;/code&gt; . 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&#39;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.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Chroot Apache2 vs dyrektywa open_basedir w PHP</title>
      <link>https://morfikov.github.io/post/chroot-apache2-vs-dyrektywa-open_basedir-w-php/</link>
      <pubDate>Mon, 22 Aug 2016 22:03:02 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/chroot-apache2-vs-dyrektywa-open_basedir-w-php/</guid>
      <description>&lt;p&gt;Kilka dni temu wpadł mi w oko artykuł na temat wykonania &lt;a href=&#34;https://nfsec.pl/root/5874&#34;&gt;chroot serwera
Apache2&lt;/a&gt;. Problem z tamtym tekstem jest taki, że nie uwzględnia on
serwera bazy danych MySQL. W efekcie, taki chroot&#39;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 &lt;code&gt;unixd&lt;/code&gt; .&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Poradnik maintainer&#39;a, czyli jak zrobić pakiet deb</title>
      <link>https://morfikov.github.io/post/poradnik-maintainera-czyli-jak-zrobic-pakiet-deb/</link>
      <pubDate>Mon, 07 Dec 2015 19:26:00 +0100</pubDate>
      
      <guid>https://morfikov.github.io/post/poradnik-maintainera-czyli-jak-zrobic-pakiet-deb/</guid>
      <description>&lt;p&gt;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
&lt;code&gt;.deb&lt;/code&gt; są tworzone ze źródeł i instalowane przy pomocy menadżera pakietów &lt;code&gt;aptitude&lt;/code&gt;/&lt;code&gt;apt&lt;/code&gt;/&lt;code&gt;dpkg&lt;/code&gt; .
Nic jednak nie stoi na przeszkodzie by daną aplikację skompilować sobie ręcznie i zainstalować ją
przy pomocy &lt;code&gt;make install&lt;/code&gt; . 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 &lt;code&gt;dh_make&lt;/code&gt; , &lt;code&gt;dpkg-buildpackage&lt;/code&gt; , &lt;code&gt;pbuilder&lt;/code&gt; , &lt;code&gt;quilt&lt;/code&gt; czy &lt;code&gt;lintian&lt;/code&gt; ,
tak by tworzyć pakiety w prosty sposób i przy tym równając do najwyższych standardów debiana.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Przygotowanie środowiska chroot do pracy</title>
      <link>https://morfikov.github.io/post/przygotowanie-srodowiska-chroot-do-pracy/</link>
      <pubDate>Thu, 11 Jun 2015 23:24:07 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/przygotowanie-srodowiska-chroot-do-pracy/</guid>
      <description>&lt;p&gt;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 &lt;a href=&#34;https://pl.wikipedia.org/wiki/Chroot&#34;&gt;chroot&lt;/a&gt; , przy którego to pomocy możemy zmienić
główny katalog systemu plików ( &lt;code&gt;/&lt;/code&gt; ) 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.&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>
