ДНК системы

Введение

Дезоксирибонуклеиновая кислота (ДНК) — один из двух типов нуклеиновых кислот, обеспечивающих хранение, передачу из поколения в поколение и реализацию генетической программы развития и функционирования живых организмов. Основная роль ДНК в клетках — долговременное хранение информации о структуре РНК и белков.

Исследование

После недавнего обновления серверов компании «Калкулэйт», стали видны очевидные минусы Calculate Directory Server:

# Устанавливаемые пакеты (программы, библиотеки, модули) работающего длительное время сервера, равно как и настройки, могут быть забыты либо утеряны, например с уходом администратора.
# Довольно сложно подобрать пример, в котором состав ПО соответствовал бы всем задачам. Как правило, либо не хватает определенных пакетов, либо их чрезмерно много.
# Скорость введения в строй нового сервера, в силу специфики сборки пакетов из исходников, невысока и при высокой загрузке, либо отсутствии свободного времени, доставляет неудобство.
# USE флаги сборки сервера часто могут не соответствовать потребностям некоторого ПО. Постоянное добавление поддержки нового функционала, путем включения USE флагов сводит на нет преимущества портежей в лучшей производительности и защищенности сервера.
# Сервер не использует возможности оптимизации пакетов при компиляции, предлагая оптимизации под два типа процессоров - Pentium Pro совметсимые и x86_64.

Постановка задачи

Выявленные недочёты можно условно свести к двум типам:

# Хранению информации об особенностях системы.
# Получению оптимальномого образа дистрибутива.

Решение

На данный момент мы уже имеем некоторые наработки, позволяющие частично выполнить поставленные задачи. Среди них интерактивная сборка системы, сборка дистрибутива на базе CLS, утилиты настройки сервера Calculate 2.

Решение этих задач будет возложено на новые утилиты Calculate 2.2 (ранее упоминаемый проект Calculate 3).

# Мы планируем создать некое подобие ДНК (DNA), в котором будет собрана вся информация о системе. DNA будет представлять из себя архив, подобный тому, который сейчас создается утилитой cl-backup. На базе DNA можно будет не только восстановить работу сервисов, но и собрать систему по образу и подобию используемой, подготовить ее к работе.
# Будет создан новый дистрибутив - Calculate Scratch Server. В сравнении с Calculate Linux Scratch в нем не будет Xorg, Firefox, библиотек, драйверов и утилит - всего того, что устанавливается дополнительно к stage3.
# Пакет calculate-server будет разбит по сервисам: calculate-dhcp, calculate-dns, calculate-ftp, calculate-jabber, calculate-ldap, calculate-mail, calculate-proxy, calculate-samba, calculate-unix и др., избавляя от лишних зависимостей.
# Установку и сборку системы планируем переписать под новой библиотекой calculate-lib 2.2, добавив улучшенную поддержку шаблонов Calculate 2 - пакеты calculate-install и calculate-builder.
# Использовать в Calculate Directory Server только те сервисы, настройка которых поддерживается утилитами Calculate 2.

Работа будущего сервера

Попробуем представить себе процесс подготовки нового сервера.

Первая установка

# Установка системы в минимальной комплектации.
# Доустановка необходимого набора программ, с модификацией профиля в /etc/make.conf, /etc/portage/.
# Выполнение настроек системы посредством утилит Calculate 2.2 с созданием шаблонов настроек.
# Получение резервной копии данных и DNA файла системы.

Обновление системы

# На любую установленную версию Calculate Linux копируем DNA файл сервера.
# Выполняем операцию восстановления системы по DNA, при этом:

## За основу будет взят также CSS либо CDS серер.

## По информации из world будут восстановлен состав пакетов на основе USE флагов DNA.

## В случае изменения переменных CFLAGS, при совместимом процессоре производится пересборка пакетов.

Установка обновления

Безусловно сервер, обладающий минимально необходимым набором ПО, будет работать достаточно долго. Причиной к переустановке сервера может послужить смена toolchain (gcc, glibc,…), требующая пересборки пакетов. В этом случае обновление должно пройти максимально быстро, без вмешательства администратора.

# На рабочий сервер копируется образ системы.
# В течение ~1 минуты происходит установка образа в резервный корневой раздел с первичной настройкой.
# Перезагрузка и восстановление настроек по DNA, резервной копии данных с перезапуском используемых сервисов.
# Создание нового DNA по мере изменения настроек, установки или удаления ПО.

Хорошая задумка, к сожалению я не админ и каких либо дельных советов дать не могу.

Это будет работать только для сервера?

Это будет работать для любого дистрибутива.

Системное администрирование станет как генная инженерия :slight_smile: - администраторы будут создавать новые гибриды, путем объединения различных участков DNA…

Вот так постепенно мы создаём машины по своему образу и подобию… Александр, а вы не чувствуете себя богом? :):):slight_smile:

я чур за коллективный разум :slight_smile:

А я, чур, за кластер!

Толковое направление полета мысли. Только несколько вопросов:
А каким макаром - если не секрет будет создаваться dna системы? Будет автоматически генериться template индивидуально под эту машину? или будет нечто вроде dispatch-conf + rcs. Или может есть какие менее извращенные варианты, но я просто их не увидел :slight_smile:
Конкретно интересно - как будут отслеживаться изменения конфигов внесенные юзером мимо шаблонов?

Ну вот скажем Samba. Конфиг формируется из конфига Samba сервера, шаблона программы и шаблона пользователя. При выполнении cl-backup, /etc/smb.conf попадает в архив. Соответственно Ваши настройки не пропадают.

По такому же принципу должен формироваться DNA для остальных сервисов. Как быть с неподдерживаемыми службами, я пока не знаю. Один из вариантов - создавать для них шаблон. До более сложных вариантов отслеживания изменений в /etc с применением GIT мы ещё морально не созрели.

Есть мысль как быть с неподдерживаемыми службами - можно воспользоваться файлом /var/db/pkg/*/*/CONTENTS и проверять целостность по принципу утилиты equery k <пакет>

Метод надежный, при некоей доработке - позволяет найти “лишние” файлы - те которые ни одной установленной апликухе не принадлежат, но имеет СУЩЕСТВЕННЫЙ недостаток - очень долго будет перечитываться ФС-ка при проверке.

Файлы, которые не пренадлежат ни одному приложению вообще должны быть проигнорированы. Задача не перенести /etc на новое место, а обработать все поддерживаемые настройки и на базе их создать новые. Остальные должны формироваться через шаблон пользователя.

пример из кальки

hostname ~ # equery b /etc/postfix/ldap-aliases.cf 
[ Searching for file(s) /etc/postfix/ldap-aliases.cf in *... ]
hostname ~ # 

я понимаю, что тут куча файла из профиля. однако, к примеру если я сделаю свой скрипт /etc/init.d/moy_script, кину в автозагрузку и забуду о нем раньше чем напишу для него шаблон или ebuild в своем оверлее - как тогда быть.

К примеру в генте - эти файлы валялись мусором на харде, особо ничему не мешая (если в дальнейшем не пересекутся с какой апликухой)

Конечно я не предлагаю поощрять “дырявые” головы, но отслеживание файлов не входящих ни в один пакет, ОТЛИЧАЮЩИХСЯ от сгенеренных шаблоном и, хотябы, ОПОВЕЩЕНИЕ юзера об этом - имхо, задача важная. Особенно если обновление - это по сути установка новой системы с переносом конфигов старой.

Согласен, возможно стоит закреплять эти настройки за пакетами. Надо будет подумать.