Debian.pro/

Про Debian


Используем chroot и debootstrap для всяких светлых целей — тестирование скриптов, программ и прочего.

Вообще в этих целях неплохо использовать виртуализацию. Но тут есть некоторые проблемы, которых лишен обычный chroot. Сразу отсеиваем Xen, KVM, vbox — слишком долго развертывается, кушает слишком много ресурсов, требует поддержки hw-виртуализации. Openvz — требует специального ядра, которое может и не поддерживать вашу железку (да и вообще не хочется сидеть на 32м ядре на ноуте). LXC — то самое… ждем… но пока это из себя представляет что-то вроде «забейте гвоздик вот туда, вот тут подкрутите болтики, вот тут побейте в бубен разработ^Wи оно заработает». В общем из разумного остаётся только chroot.
Ещё раз повторюсь — наша цель — протестировать скрипт или программу прямо на нашем ноуте-десктопе-сервере, но не насорив в основной системе файликами или пакетами.
У chroot’a есть минусы. Огромные.
Запомните главное — являясь рутом в chroot’e вы остаетесь рутом в основной системе. Вы можете килять процессы, можете подмонтировать ФС хоста и попортить файлы хоста. Мы не будем монтировать ничего страшного, но тем не менее мы пробросим все устройствами и файловую систему /proc для удобства в наш chroot — поэтому в целом мы там сможем делать всё. В общем будьте осторожны.
Второй минус достаточно спорен. В нашем случае он становится плюсом. Мы используем те же сетевые устройства. И порты, которые мы займём в chroot — будут заняты и в основной системе. Короче я это к тому, что вы не сможете в chroot поднять sshd на 22м порту, если он уже поднят на 22м порту хоста.
Есть ещё куча других, но вот про эти 2 стоит помнить обязательно. Остальные нас мало касаются.
А теперь о плюсах.
У нас будет то же ядро. У меня уже есть чруты, в которых запущены Х-серверы (по ctrl-alt-f8 открываются), там вполне нормально смотрятся hd-фильмы и играются простенькие 3д-игры. Видео у меня intel hd, потому полноценные не гонял. Есть у меня и chroot-тарболл (2 дня как есть, но всё же), который после распаковки сразу становится настроенным веб-сервером. Сейчас я понимаю, что этот же механизм можно использовать для запуска двух апачей с разными php без всякого геморроя на одном физическом сервере.
У нас будет доступ ко всем ресурсам физической машины. Да, мы не можем ограничить количество памяти (кхм… на самом деле можем, но я эту статью пишу для новичков, всё же — мысли вслух). Мы можем монтировать отдельные разделы hdd, можем использовать видеокарту, процессор со всеми его фичами (да-да, KVM отлично запускается внутри chroot’a). В общем мы всё можем. Отсюда и минусы.
В общем к чему вся эта моя тирада. Повредить основной системе из чрута можно, даже если делать это не специально (kilall5, например, будучи запущенным из чрута, убивает все процессы на хосте). Применять в целях безопасности его бесполезно. Абсолютно. Применять его стоит, если вам временно понадобилось другое окружение (например, вы написали скрипт под squeeze, а вам нужно протестить его в убунте и в lenny), а возиться с полноценными системами и держать их не хочется.

Я надеюсь вы прочитали, всё что написано выше.
Приступим к созданию chroot окружения.
Мне известны 2 хороших способа создать chroot окружение. Первый — взять Openvzшный шаблон и распаковать его. Способ плох тем, что шаблоны заточены под ovz и мне неизвестно к чему это может привести. Для proof of concept я один такой распаковал, запустил и выкинул.
Второй способ является более правильным и гибким. Мы будем использовать debootstrap (для установки федоры вы можете использовать febootstrap).
Всё нижеописанное я проводил под убунтой и под дебианом. В теории, всё это должно работать в любом дистрибутиве. Но нам нужны /proc и /dev с хоста в чруте. Если есть велосипедостроители, которые что-то нашаманили в /dev — то чрутнутый дебиан может почувствовать себя не в своей тарелке.

Да, нам понадобится рут на основной машинке. Я использую машинку с названием laptop1 для подобных экспериментов. Это для тех, кто помнит про то, что хостнейм в приглашении важен для понимания где выполнять команду.
Для начала им станем:
inky@laptop1:~$ sudo su
или
inky@laptop1:~$ su
или
inky@laptop1:~$ sudo -s
Поставим пакет debootstrap:
root@laptop1:~# aptitude install debootstrap
Для аккуратности создадим каталог, в котором будем хранить все наши каталоги для чрутнутых систем:
root@laptop1:~# mkdir /chroots && cd /chroots
И поставим одну из нужных нам систем:
root@laptop1:/chroots# debootstrap lucid ./lucid-c1 http://mirror.yandex.ru/ubuntu
root@laptop1:/chroots# debootstrap maverick ./maverick-c1 http://mirror.yandex.ru/ubuntu
root@laptop1:/chroots# debootstrap natty ./natty-c1 http://mirror.yandex.ru/ubuntu
root@laptop1:/chroots# debootstrap squeeze ./squeeze-c1 http://ftp.ru.debian.org/debian
root@laptop1:/chroots# debootstrap lenny ./lenny-c1 http://ftp.ru.debian.org/debian

Разберем одну из вышеуказанных команд (debootstrap lenny ./lenny-c1 http://ftp.ru.debian.org/debian).
debootstrap — собственно, команда
lenny — мы указываем релиз дебиана (дада, убунтовцы, покайтесь, вы — всего лишь релизы дебиана по мнению debootstrap). Шутка. Здесь мы указываем название релиза дебиана или укороченное название релиза убунты (lucid, natty, maverick и так далее).
./lenny-c1 — указываем в какой каталог ставить — то есть в каталог lenny-c1 в текущем каталоге (можно было написать просто /chroots/lenny-c1)
http://ftp.ru.debian.org/debian — указываем зеркало

Начнут качаться пакетики, вы можете пока что покурить. Можно ставить и с локального зеркала, если что.
В конце мы увидим такое:
I: Base system installed successfully.
Перевод не требуется.
На этом можно закончить и переходить к концу статьи (где описано, как войти в такую систему). Но мы сделаем такую систему более или менее удобной и управляемой.
Примонтируем proc и sysfs «в туда»:
root@laptop1:/chroots# mount proc /chroots/squeeze-c1/proc -t proc
root@laptop1:/chroots# mount sysfs /chroots/squeeze-c1/sys -t sysfs

Если вы собираетесь использовать эту систему регулярно, до добавьте монтирование в /etc/fstab:
root@laptop1:/chroots# echo "proc /chroots/squeeze-c1/proc proc defaults 0 0" >> /etc/fstab
root@laptop1:/chroots# echo "sysfs /chroots/squeeze-c1/sys sysfs defaults 0 0" >> /etc/fstab

Ну и зайдем в нашу систему:
root@laptop1:~# chroot /chroots/squeeze-c1

Радуемся. У нас есть отдельная система.

Теперь примонтируем /dev к нам в чрут. Делать это необязательно. И иногда даже вредно.
root@laptop1:~# mount --bind /dev /chroots/squeeze-c1/dev
Иногда и монтировать не обязательно, девайсы сами появятся нужные. Так обстоит дело с сетевыми картами, например.
Пофиксим проблему с локалями (будет сыпаться куча сообщений вида «locale: Cannot set блаблабла» — очень мешает и бесит):
root@squeeze-chroot1:~# aptitude install locales
root@squeeze-chroot1:~# echo "en_US.UTF-8 UTF-8" >> /etc/locale.gen
root@squeeze-chroot1:~# locale-gen

После этого нужно снова перезайти в chroot.
Ещё я могу порекомендовать заменить приглашение в .bashrc, чтобы не путать консоли.
Можно сделать:
root@squeeze-chroot1:~# export PS1="CHROOT:\w# "
чтобы заменить приглашение до ребута.

Можно теперь шаманить, запускать скрипты, ставить софт. Главное не запутайтесь.

К сожалению, мне пока не удалось найти годного способа пристрелить всё, что мы поназапускали в chroot. Если вы использовали только одну консоль и не запускали демонов — то можно в ps aux | grep «bash -i» найти процесс, который породил chroot и убить его вместе с потомками. Но это не остановит демонов, которые вы там запустили. Остаётся только следить за тем, что мы запускаем и убивать ручками.

Ещё возникла проблема с запуском screen внутри чрута, но там понятно как её фиксить.


Комментарии (5):

  1. Ad1ce :

    Можно поподробней, к примеру, про два apache с двумя разными версиями php. Каким образом, будет отправляться запрос на нужный из них? Можно ли проксировать с хостового nginx на одну из chroot машин?
    И глобальный вопрос — будут ли сервисы поднятые из chroot debootstrap доступны из вне?

  2. > про два apache с двумя разными версиями php
    Ставим два дебиана, 2 апача в разные чруты на разные порты…. вуаля =)

    > Можно ли проксировать с хостового nginx на одну из chroot машин?
    На самом деле, нужно. Либо на 80й порт вешать апач с одной версией PHP, а для виртуалхостов, которым нужна другая версия — делать ProxyPass в chroot.

    > будут ли сервисы поднятые из chroot debootstrap доступны из вне?
    да, будут, в этом вся затея)

  3. Paul :

    Для сборки пакетов использую cowbuilder, он, по видимому, большинство описаного здесь делает автоматом.

  4. Гм. Вот это вот — http://wiki.debian.org/cowbuilder — автоматом) ?

  5. Toxa :

    Действительно…. как закрыть все процессы…. в голову пришло только в chroot-е делать
    kill `cat var/run/*.pid`
    а при закрытии самого терминала должно закрыться всё что запущено не деманом….

Написать комментарий