Як я можу встановити пакети, не запускаючи пов'язані з ними послуги?


13

Як ви, напевно, знаєте, за умовчанням під час встановлення пакета в системі на базі Debian або Ubuntu, якщо пакет містить послугу, ця служба, як правило, буде включена і запуститься автоматично при встановленні пакета.

Це для мене проблема.

Мені здалося, що мені потрібно керувати шаблонами для створення контейнерів LXC. Є кілька контейнерів, кожен з яких відповідає випуску Debian або Ubuntu. (Є також контейнери на основі Red Hat, але вони тут не актуальні.)

/var/lib/libvirt/filesystems/debian6_template
/var/lib/libvirt/filesystems/debian7_template
/var/lib/libvirt/filesystems/ubuntu1004_template
/var/lib/libvirt/filesystems/ubuntu1204_template

Інколи я виявляю, що в шаблонах відсутній пакет або потрібна інша зміна, тому я вступлю в них, щоб встановити пакет. На жаль, коли я це роблю, я завершу кілька запущених копій послуги пакету!

В якості прикладу я виявив, що в шаблонах не було демона syslog, тому я встановив один:

for template in /var/lib/libvirt/filesystems/{debian,ubuntu}*_template; do
    chroot $template apt-get install rsyslog
done

І негайно завершили чотири копії rsyslog, що працює. Не кажучи вже про дві копії exim4. На жаль!


Я десь прочитав (хоча я не можу його знову знайти), що це не повинно запускати сервіси під час роботи в chroot, але тут явно цього не відбувається.

Один потенційно життєздатний неприємний злом вимагає тимчасової заміни різних команд, які фактично запускають сервіси, такі як, start-stop-daemonі initctlхоча це набагато більше роботи, ніж я дійсно хотів зробити. Якщо у мене немає іншого вибору, хоча ...

Ідеальним рішенням тут було б, щоб системи на базі Debian перестали робити це лайно, але якщо цього не зробити, можливо, незрозумілий або недокументований варіант командного рядка apt-get?

У випадку, якщо це було не зрозуміло, я дуже хочу , якщо це можливо, тримати щось, що стосується керування шаблонами поза шаблонами.

Відповіді:


23

Для debian ви можете це зробити за допомогою policy-rc.d . Ось одне пояснення :

Сценарії технічного обслуговування пакета повинні взаємодіяти лише з системою init за допомогою заголовків скрипта-invoc.d, update-rc.d та заголовків сценаріїв LSB ... invoke-rc.d, перш ніж вжити заходів, перевірять, /usr/sbin/policy-rc.d виконується, викликає його відповідною назвою служби та поточним номером запуску в командному рядку та діятиме відповідно до коду виходу. Наприклад, повернене значення 101 не дозволить вжити запланованих дій. Сюди входить автоматизований запуск послуги після встановлення пакета, а також зупинка служби при видаленні пакета та зводиться ритуал зупинки-оновлення-перезавантаження під час оновлення пакета до простого оновлення, яке може залишити стару версію служби

Оскільки ви не хочете, щоб будь-які служби коли-небудь запускалися, ваш сценарій policy-rc.d може бути простим

#!/bin/sh
exit 101

Це техніка, яка використовується такими інструментами, як pbuilder і mkimage-debootstrap Docker .

На жаль, ця техніка не працює з хробутами Ubuntu . Пакети, які інтегруються з початковою системою init call / usr / sbin / initctl замість виклику-rc.d під час встановлення, а initctl не консультується з політикою-rc.d. За словами автора upstart, вирішенням цього питання є заміна / sbin / initctl символьним посиланням на / bin / true у chroot. Це можна побачити і в mkimage-debootstrap

dpkg-divert --local --rename --add /sbin/initctl
ln -sf /bin/true sbin/initctl

Це здається досить чистим, хоча його також доведеться видалити перед створенням контейнера з шаблону.
Майкл Хемптон

1
Дякую за це Можливо, мені доведеться зірвати сценарій mkimage-debootstrap з Docker, оскільки, здається, вони в основному вирішили цю проблему.
Майкл Хемптон

4

Ви можете зробити:

export RUNLEVEL=1
for template in /var/lib/libvirt/filesystems/{debian,ubuntu}*_template; do
    chroot $template apt-get install rsyslog
done
exit

Я не перевіряв це chroot, але це має працювати. Спочатку він встановлює змінну середовища RUNLEVEL, тому процеси, ініційовані apt-get , не запускатимуть жодних служб, оскільки вони будуть "думати", що система працює в єдиному режимі. Оскільки середовище модифікується так, як це може вплинути на майбутні команди, потрібно вийти з оболонки, коли змінене середовище більше не потрібно, це виконується командою exit в кінці. Там можуть бути деякі (рідкісні?) Пакети , які не будуть встановлені належним чином в одному режимі (але AFAIK це не повинно бути проблемою в більшості випадків).


Тут export RUNLEVEL=1важлива частина? Що саме це спричиняє?
Майкл Хемптон

@MichaelHampton Я вважаю, що змінна середовища RUNLEVEL забезпечить поточний рівень запуску. У цьому випадку він просто перезаписує його, тому будь-яка програма вважатиме, що вона працює на 1. Це щось на кшталт "хитрування", але його повинно вистачити.
WinkyWolly

До оригінальної відповіді додано пояснення. В основному це те, що сказав @WinkyWolly.
DavisNT

На жаль, rsyslogтрапився один з "рідкісних" пакетів, який повністю підірвався при спробі встановити цей спосіб. Це все ще може бути корисним, тому ви можете продовжувати працювати :)
Майкл Хемптон
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.