Дельта синхронизация без облака

Ранее мы показывали разные способы синхронизации криптодиска между ПК и Android-устройством.

Смотрим плавность хода с помощью BMW Rheingold

Всем знакома ситуация, когда двигатель немного "троит", но пропусков зажигания нет...

Дельта-синхронизация крипто-дисков

Существуют разные способы зашифровать "облако". Один из них - поместить в облако крипто-диск. В предыдущей статье мы писали, почему это не всегда удобно.

Облачный хостинг VDS за 2 минуты

Настоящий облачный VDS-хостинг от UltraVDS: тестируем производительность

В память об Initng


Денис Колисниченко

Сегодня мы поговорим о initng - новой системе инициализации твоего Linux'а. Initng является следующим поколением init, о чем красноречиво говорят символы ng (next generation) в названии этой системы. Основное призвание initng - стать достойной заменой старому доброму init. В этой статье мы убедимся, так ли это. Ведь на момент написания этих строк еще даже не вышла первая версия initng (текущая - 0.5.3), а сама initng включена лишь в Gentoo - дистрибутив для неисправимых экспериментаторов. Так что давай на некоторое время побудем впереди планеты всей ;-).

init vs initng

Что же такого хорошего в initng, что о ней заговорили? Чтобы понять суть отличия от init, вспомним, как работает классическая версия init. Первым делом запускается ядро, которое монтирует корневую файловую систему и запускает программу инициализации системы. По умолчанию используется программа /sbin/init. Изменить программу инициализации можно с помощью параметра ядра init:

init=/путь/к/программе/инициализации

После запуска этой программы ядро успокаивается - всю дальнейшую работу выполнит именно init. Если init запустить нельзя, ядро паникует, и дальнейшее продолжение работы невозможно. Сначала init "вычисляет" уровень запуска, прописанный в файле /etc/inittab:

id:5:initdefault:

Затем, в зависимости от уровня, init запускает сценарии из каталога /etc/rc.d и его подкаталогов. Здесь ключевая фраза - "запускает сценарии", выполнением которых занимается командный интерпретатор (обычно /bin/bash), то есть "посторонняя" программа. Initng самостоятельно выполняет свои файлы конфигурации, в которых ты прописываешь действия по инициализации системы, в результате чего время загрузки системы резко сокращается. Действительно, с использованием initng мой FC3 загружается практически мгновенно. После того, как я все правильно настроил и перезапустил систему, я даже сначала не понял, что загрузка системы уже завершена.

Подготовка к установке initng

Скачать initng можно по адресу https://initng.thinktux.net/download/v0.5/ (либо взять с нашего CD/DVD). Там будут как файлы, содержащие исходный код, так и уже откомпилированные RPM-пакеты. Я советую скачать именно исходный код, причем самую последнюю версию. На момент написания этих строк последней была версия 0.5.3, поэтому я скачал файл initng-0.5.3.tar.gz.

Лично я использую Linux не только для экспериментов, но и для повседневной работы, поэтому дистрибутивы я часто не переустанавливаю. Сейчас у меня установлены два дистрибутива: Linux Mandrake 10 и Fedora Core 3. Да, дистры не первой свежести, но меня они вполне устраивают.

Сначала я попытался установить initng в моем любимом Linux Mandrake. Установить-то я ее установил, то работать "система инициализации следующего поколения" отказалась. Почему? Потому что она рассчитана под... более новые дистрибутивы. Если ты попытаешься установить RPM-пакет с initng на Linux Mandrake 10 или на той же Fedora Core 3, ты увидишь, что нужно для установки этой версии. Версия 0.5.3 требует пакет filesystem версии 2.2.4 или выше, библиотеку glibc версии 2.3.4 или выше, а также наличие SELinux.

Устанавливать Mandriv'у из-за initng я посчитал излишним, поэтому "под нож" пустил третью версию Fedora Core. В данной версии присутствует пакет filesystem версии 2.3, есть SELinux, а то, что нет glibc версии 2.3.4 - не беда. Я предпочитаю компилировать initng из исходных кодов, поэтому при сборке будет использоваться та версия glibc, которая есть в наличии (2.3.3). Если ты попытаешься установить RPM-пакет на FC3 без удовлетворения зависимостей (а иначе - никак), то обнаружишь, что initng работать не будет. Причем об этом красноречиво сообщит само ядро, когда при перезагрузке ты увидишь сообщение о невозможности запуска initng (поскольку тот RPM собран на glibc версии 2.3.4).

Если же ты сторонник прекомпилированных пакетов, и у тебя самый новый дистрибутив, тогда качай свежий RPM и устанавливай его с помощью такой команды:

# rpm -ihv initng-0.5.3-1.i386.rpm

Установка initng

Сначала я установил initng на реальную (физическую) систему - свой домашний компьютер. После этого, когда initng прекрасно на нем заработал, я все повторил в виртуальной машине VMWare. Этим я сразу убил двух зайцев: ответил на твой вопрос относительно использования initng в VMWare и сделал скриншоты начальной загрузки системы с использованием initng.

Перед установкой initng убедись, что у тебя установлен компилятор gcc, программы automake, autoconf, а также заголовочные файлы - все это нужно для сборки initng. Чтобы не было недоразумений, все последующие действия выполняй от имени root. Распакуй initng-0.5.3.tar.gz в каталог /usr/src. В результате будет создан каталог /usr/src/initng-0.5.3. Перейди в этот каталог и выполни команду:

# ./autogen.sh

Это вместо ./configure (новый сценарий более информативен, к тому же он запускает ./configure для создания Makefile). Далее введи команды:

# make

# make install

Скорее всего у тебя не возникнет проблем со сборкой initng. Если таковые есть, значит, ты что-то не установил. Запусти еще раз autogen.sh и внимательно посмотри, что он тебе "пишет". Можно даже перенаправить вывод в файл, чтобы затем не спеша просмотреть его.

Кроме цели install доступны еще две:

  • clean - удаляет откомпилированные файлы из каталога, содержащего исходный код
  • uninstall - удаляет initng

Нельзя забывать и о соответствующей настройке загрузчика. Ведь нам нужно добавить параметр ядра init, чтобы каждый раз не указывать его при загрузке. Если у тебя LILO, то открой в любом редакторе файл /etc/lilo.conf, скопируй секцию image, описывающую твое основное ядро и отредактируй ее, добавив в директиву append параметр "init=/sbin/initng".

Редактирование файла конфигурации загрузчика

После редактирования файла нужно, чтобы загрузчик перечитал свой конфиг. Для этого введи команду:

# lilo

Если у тебя grub (скорее всего, так оно и есть), то добавь в файл /boot/grub/grub.conf следующие строки:

title linux-initng
	kernel (hd0,1)/vmlinuz-2.6.9-1.667
	root=/dev/hda2
	init=/sbin/initng

Обрати внимание на раздел с установленным Linux, а также на название файла ядра. В этом случае я предполагаю, что ты установил Linux в раздел /dev/hda2 (параметр root, задающий корневую файловую систему). Файл ядра называется vmlinuz-2.6.9-1.667, он физически находится тоже на разделе /dev/hda2: (hd0,1) соответствует /dev/hda2. В случае с grub перезаписывать загрузчик не нужно.

Запуск initng

Для запуска Linux с initng в меню загрузчика нужно выбрать запись, обеспечивающую старт твоей системы с initng. Какую именно? Ту, которую ты только что добавил при редактировании конфигурации твоего загрузчика. Итак, Линукс запускается. Сначала как обычно - ядро. Потом ядро запускает initng, а тут смотри внимательнее - привыкай, ведь скоро так будут загружатся многие Линуксы. Отмечу, что initng запускает agetty для всех терминалов, кроме первого (tty1). На первом будут постоянно отображаться "остатки" загрузки системы, которые можно пролистать с помощью Shift+PgUp/PgDn.

Регистрироваться можно на любой консоли, начиная со второй (tty2), нажав Alt+F2. Нужно отметить, что если у тебя дистрибутив соответствует требованиям initng, то ее запуск должен пройти быстро и безболезненно. У меня так оно и было.


начало запуска initng


в процессе...

Конфигурационные файлы

Все конфигурационные файлы initng делятся на две группы - файлы уровней запуска и файлы служб. Первые находятся в самом каталоге /etc/initng, имеют расширение ".runlevel" и содержат список служб, которые должны быть выполнены на соответствующем уровне. Вторые находятся в подкаталогах каталога /etc/initng и имеют расширение ".i". Имеется три основных файла уровней запуска: default.runlevel, single.runlevel и system.runlevel. Первый - это уровень запуска по умолчанию, второй - это однопользовательский режим (уровень 1), третий - системный уровень. С первым файлом все ясно - он запускает твой уровень по умолчанию. Третий файл обеспечивает загрузку первого уровня запуска, то есть single-режима - он подготавливает все необходимое для работы системы. А как же файл single.runlevel? Данный файл предназначен для "расширения" первого уровня запуска. В нем находится всего лишь одна инструкция - вызов системного уровня (system), но при необходимости ты можешь добавить сюда вызовы дополнительных программы, не редактируя файл system.runlevel.

При установке initng формируется файл default.runlevel: в него добавляются записи сервисов, которые должны запускаться на том уровне, который на момент установки initng был уровнем по умолчанию в твоей системе. Например, если у тебя система запускалась на пятом уровне, то в default.runlevel будут добавлены все необходимые записи, чтобы после перезагрузки с initng ты не почувствовал никакой разницы (кроме, разумеется, скорости загрузки). При установке initng я работал на третьем уровне, поэтому был создан следующий файл default.runlevel:

system
daemon/klogd
daemon/eth0
daemon/syslogd
daemon/sshd
daemon/gpm
daemon/xinetd
daemon/sendmail
daemon/xfs

Первая строка - это вызов системного уровня запуска, который является обязательным для всех уровней. Уровень system содержит жизненно важные инструкции для работы системы - udev, загрузку модулей, поддержку USB и сети (интерфейс lo), запуск agetty для терминала, загрузку системного шрифта, запуск iptables и многое другое. Открой файл system.runlevel, и ты сам все поймешь без моих комментариев. Однако редактировать его стоит лишь в том случае, если ты полностью уверен в своих действиях.

После этого запускается демон протоколирования ядра (klogd), далее конфигурируется интерфейс eth0, запускаются демон системного протоколирования, SSH-сервер, gpm - это сервис мыши в консоли, xinetd - так называемый супер сервер, sendmail - агент MTA, а xfs - сервер шрифтов.

Зайди в подкаталог daemons: в нем ты найдешь i-файлы для запуска большинства демонов (служб), которые только могут быть установлены в твоей системе. Например, для запуска Web-сервера используется файл httpd.i. Чтобы Web-сервер запускался автоматически при запуске системы, добавь в файл default.runlevel строку "daemon/httpd". Более корректным способом добавления служб на уровень запуска является использование программы ng-update, поскольку данная прога учитывает зависимости между службами. Что это такое? Например, у нас есть демон Б, который зависит от службы А. Если ты хочешь добавить в уровень демон Б, ты его должен добавить после А, которая должна быть уже запущенной к моменту запуска Б. То есть, редактируя файлы уровней, ты должен четко понимать, что ты делаешь. Если ты в чем-то не уверен, используй ng-update - эту программу мы рассмотрим чуть позже.

i-файлы

Перед тем, как перейти к рассмотрению формата i-файлов, нужно знать о том, какие типы служб можно описывать в этих самых i-файлах. Службы бывают трех типов: демоны (daemon), сервисы (service) и виртуальные службы (virtual). Демон - запускается и после запуска не завершат работу, а остается в памяти. После запуска демон может получить один из двух статусов - RUNNING, означающий, что демон нормально работает, или FAIL_STARTING - запуск демона завершился с ошибкой. Если при запуске демона произошел сбой, то все зависящие от него службы будут остановлены. Сервис - запускается, выполняет свою работу (например, монтирует файловые системы или загружает системный шрифт), а потом - завершается. Виртуальная служба вообще ничего не делает, она просто зависит от других. Если виртуал запущен, то ты можешь быть уверен - все службы, от которых он зависит, запущены.

Рассмотрим пример файла daemon/httpd.i:

daemon daemon/httpd {
	need = system/bootmisc;
	require_network;
	use = daemon/sshd daemon/mysql daemon/postgres system/netmount;
	exec daemon = /usr/sbin/httpd;
	pid_file = /var/run/httpd.pid;
}

Ключевое слово daemon указывает на то, что httpd - демон. Нужно отметить, что initng различает службы не по имени файла, а по идентификатору, стоящему после служебного слова daemon (service/virtual), что позволяет описывать в одном файле нечто вроде:

daemon daemon/agetty/* {
      need = system/bootmisc;
      env DEV_PRE=tty;
      exec daemon = /sbin/agetty 38400 ${DEV_PRE}${NAME};
      respawn;
}

Вернемся к нашему httpd. Директивы need и use позволяют строить зависимости. Об этом мы поговорим чуть позже. Смотрим дальше: директива require-network говорит сама за себя - демону httpd нужна сеть. Директива use позволяет указать, какие службы использует наш httpd. Директива exec задает исполняемый файл службы (демона), а директива pid_file - задает имя PID-файла службы.

Я не случайно привел листинг службы-демона agetty. Обрати внимание на директивы ENV и respawn. Первая используется для установки переменных окружений, а вторая "говорит" initng, что данную службу нужно перезапустить в случае ее аварийного завершения.

Зависимости и конфликты

Директива need позволяет указать службы, от которой зависит наша. Если данные службы не были запущены, то перед запуском нашей службы initng запустит все, что ты указал с помощью need. Директива use используется иначе: она просто указывает, какие службы может использовать наша. Если данные службы не запущены, initng не будет их запускать. Директива use используется просто для того, чтобы определить порядка запуска служб. Данная информация используется, если ты используешь утилиту ng-update для добавления служб на уровень.

Директива conflict позволяет установить службу, с которой наша служба конфликтует. Например, FTP-сервер wu-ftpd может конфликтовать с FTP-сервером ProFTPD, sendmail с postfix. Думаю, принцип понятен? В системе не может быть двух служб,выполняющих одни и те же или взаимно обратные действия.

Утилиты ngc и ng-update

Первая используется для запуска/останова службы (аналог service в init), а вторая - для добавления службы на указанный тобою уровень запуска. Синтаксис следующий:

ngc <действие> <служба>

ng-update <действие> <служба> <уровень запуска>

Рассмотрим несколько примеров:

ngc -u httpd - запуск httpd

ngc -d httpd - останов httpd

ngc -h - помощь

ng-update add net/ppp0 default - добавляем запуск net/ppp0 на уровень default

ng-update del net/eth1 default - удаляем запуск net/eth1 из default

Initng и X Org

У системы initng небольшой конфликт с X Window. Это связано с тем, что после установки initng мышка будет называться не /dev/mouse, а /dev/psaux (так оно и должно быть), поэтому тебе придется немного отредактировать твой конфиг X Window. И еще: если у тебя видеокарточка от nVidia, то тебе нужно будет немного "пошаманить" над драйверами nvidia (подробности смотри в /usr/src/initng-0.5.3/doc/initng.txt). Если ты не разберешься в настройке, напиши, я тебе подскажу, что и как нужно сделать.

Диагноз

Буду краток: initng не только можно использовать, но и нужно: значительно сократилось время запуска системы, появилось больше возможностей по настройке служб, поскольку initng намного гибче своего предшественника. Initng не сложен в настройке - просто немного не привычно. К тому же скоро будут готовы GUI для initng, существенно облегчающие работу с ним. Все твои вопросы ты можешь задать на форуме на https://www.dkws.org.ua.


прототип GUI для настройки initng

Статья опубликована в мартовском номере журнала "Хакер"