Средства восстановления системы в ROSA Linux (Денис Силаков, OSSDEVCONF-2014)
Материал из 0x1.tv
Содержание
Аннотация
- Докладчик
- Денис Силаков
Дистрибутив Linux является динамично развивающейся средой, постоянно получающей большие пласты обновлений. Обновления призваны привнести в систему улучшения и новый функционал, однако иногда они имеют обратный эффект, ломая что-то работающее и вызывая недовольство пользователей. Кроме того, многие члены сообщества – это энтузиасты, которых постоянно тянет попробовать что-то новое.
Например, всевозможные программы из различных источников, которые не имеют прямого отношения к дистрибутиву. Рано или поздно программы могут вступить в конфликт с приложениями и политиками ОС и привести систему (по крайней мере частично) в нерабочее состояние.
Как результат, для многих пользователей актуальным вопросом является автоматический возврат поломанной системы в рабочее состояние.
Видео
Посмотрели доклад? Понравился? Напишите комментарий! Не согласны? Тем более напишите.
Слайды
Расширенные тезисы
Инструменты уровня пакетов
Поскольку в Росе, как и в большинстве дистрибутивов Linux, установка, удаление и обновление программ сводится к манипуляции с пакетами, то и откат действий по управлению ПО логично осуществлять на уровне пакетов — то есть если с обновленным пакетом что-то не так, то надо откатиться на предыдущую версию. На практике такой подход сталкивается с двумя проблемами — во-первых, пользователь не всегда может однозначно идентифицировать пакет, который привел к сбою, а во-вторых — надо где-то взять старую версию пакета, ведь в официальных источниках (если они использовались для обновления) она уже заменена новой. Если проблемы вызваны пакетами из сторонних репозиториев, то на помощь может прийти инструмент urpm-reposync (аналог reposync из Fedora), способный привести состояние пакетной базы системы в соответствие с подключенными репозиториями — в частности, удалить пакеты, в этих репозиториях отсутствующие, а для имеющихся пакетов обновить или откатить их до официальных версий.
Urpm-reposync обладает некоторой гибкостью (в частности, позволяет не удалять «лишние» пакеты, если их зависимости по-прежнему будут присутствовать в системе после синхронизации с репозиториями), однако в целом является достаточно тяжеловесным инструментом. С его помощью можно провести синхронизацию всех пакетов, установленных в системе, но нельзя откатить конкретные обновления.
Более избирательным является urpmi.recover, работающий на уровне транзакций rpm. Этот инструмент позволяет производить откат пакетной базы по датам или транзакциям — можно откатить заданное число транзакций либо все транзакции до определенной даты.
Алгоритм работы инструмента прост — при удалении или обновлении пакетов делается резервная копия удаляемой/обновляемой версии пакета, которая и устанавливается в систему при откате. Отметим, что откатывать транзакции выборочно инструмент не позволяет, однако при сильном желании можно попробовать сделать такой откат вручную с помощью rpm — ведь старые версии пакетов доступны в кэше urpmi.recover.
Полной гарантии успешности отката urpmi.recover дать не может — ведь мэйнтейнеры далеко не всегда задумываются о том, что их пакеты могут не только обновляться, но и откатываться к предыдущим версиям.
Соответственно после отката можно ожидать «сюрпризов» в виде неожиданной отработки post-скриптов или некорректного изменения конфигурационных файлов, входящих в пакет. Тем не менее, urpmi.recover снискал популярность у тестировщиков РОСЫ, поскольку позволяет откатывать тестовые версии пакетов проще и быстрее, чем urpm-reposync.
Инструменты уровня файловой системы
Как бы ни привлекательно выглядел откат изменений на уровне пакетов, полностью гарантировать возврат системы в работоспособное состояние он не может. Во-первых, этому может воспрепятствовать специфика пакетов (например, мэйнтейнеры не проработали удаление или откат пакета до предыдущей версии), а во-вторых — ошибки в системе могли появиться и не из-за пакетов, а просто из-за некорректных действий пользователя. Традиционным способом возврата системы в рабочее состояние в таких ситуациях является использование резервных копий.
Сценарии использования систем резервного копирования подразумевают, что «плохие» ситуации в ОС происходят относительно редко, и откат ОС к предыдущему состоянию осуществляется только при выявлении подобных ситуаций. Однако в жизни бывают и другие сценарии, когда с большой вероятностью все действия пользователя в рамках текущей сессии необходимо будет откатить. Такие ситуации нередко встречаются на предприятиях, когда сотрудникам при загрузке машины предоставляется некоторая фиксированная система, которая при выключении машины или перезагрузке возвращается в исходное состояние (возможно, за исключением домашних папок сотрудников и других мест, где они могут сохранять результаты своей работы).
Нередко подобные схемы работы реализуются с помощью виртуальных машин — например, после выключения виртуальной машины можно откатывать ее к заранее сделанному снимку, а домашние директории пользователей монтировать с удаленных ресурсов. Однако Linux предоставляет средства для реализации более легковесных решений, не требующих больших накладных расходов (как в случае виртуализации) и вполне подходящих для домашнего использования.
Подобное решение — ROSA Freeze — мы реализовали в Росе. При использовании ROSA Freeze, ОС может работать в двух режимах — обычном и режиме «заморозки». При использовании последнего поверх всех системных директорий верхнего уровня (/bin, /etc, /usr и так далее; список может быть скорректирован администратором) с помощью aufs монтируются директории-«перехватчики», находящиеся в tmpfs либо на отдельном разделе жесткого диска.
Любые изменения, вносимые в «замороженные» директории, реально попадают в директории-«перехватчики», а содержимое оригинальных директорий остается неизменным. При перезагрузке машины все содержимое этих перехватчиков удаляется и системные ди- ректории возвращаются в первоначальное состояние. При этом после перезагрузки система продолжает оставаться в замороженном состоянии — выход из этого режима надо производить явно. Предусмотрена возможность переноса всех изменений из aufs, сделанных в рамках текущей сессии, в оригинальные директории. Инструмент ROSA Freeze очень молодой, однако уже готов к использованию. В настоящее время инструмент рассчитан на работу в схеме, когда все замораживаемые директории находятся на одном и том же разделе жесткого диска. В будущем мы планируем добавить поддержку заморозки директорий на разных разделах, а также реализовать в рамках ROSA Freeze механизма точек восстановления — ведь используемые подход с aufs позволяет нам автоматически получать инкрементальные различия между состояниями системы, остается только реализовать средства сохранения таких различий на диск и отката к ним.
Примечания и отзывы
Plays:1528
Comments:4