Обслуживание на основе компонентов

Метки:  , , , , , , , , , , , , , ,

Наверняка уже ни для кого не секрет, что как и в любом (без исключения) программном обеспечении, в коде операционных систем присутствуют ошибки. Периодически тем или иным образом их удается обнаружить, о чем рано или поздно узнает разработчик, в чьих интересах производить оперативное устранение найденных проблем. Но мало выпустить исправление (заплатку/патч), изменения эти требуется еще как-то доставить до пользовательских операционных систем, функционирующих по всему земному шару. Помимо ошибок, на всем протяжении цикла поддержки операционной системы, в неё добавляются и новые функциональные возможности. Все перечисленные виды вносимых в систему изменений (исправления, обновления, дополнения) на данный момент принято обобщать в огромный комплекс задач под названием обслуживание операционной системы.
С появлением и развитием сети Интернет, методы доставки контента обслуживания до географически-удаленных операционных систем претерпели существенные изменения: сперва в виде доступных на сайте Microsoft для скачивания файлов, затем, по мере развития архитектуры операционных систем и, в частности, алгоритмов обновления, трансформировались в сложные многоуровневые сервисы, производящие автоматическую загрузку и обновление. В последнее время Microsoft запустила уже непрерывный цикл обновлений настольных операционных систем, который подразумевает под собой не только (отдельные) текущие обновления, но так же и глобальные доработки, приводящие к (прозрачному) переходу к следующим редакциям ОС.

Тем не менее вопрос механизмов обновления является темой несколько иной статьи, а в этом материале мы, пожалуй, начнем с краткого экскурса в историю обслуживания операционных систем корпорации Microsoft. Сразу хочу оговориться, что никаких глубоких специфических данных тут пока что не будет, просто необходимые вводные сведения по достаточно значимой технологии под названием Обслуживание на основе компонентов, в которой многое до сих пор для меня не ясно. Итак, на протяжении развития операционных систем Windows существовало несколько основных видов обслуживания:

Обслуживание на основе файлов

В операционных системах, предшествующих Windows Vista (Windows XP и ранее), применялся метод обслуживания, носящий название обслуживание на основе файлов (File-Based Servicing, FBS). Процесс обслуживания был организован достаточно незатейливо: на основе .inf-файла описания изменений, обновляемые системные файлы перезаписывались новыми версиями непосредственно по пути основного размещения (в основном это: WinDir%\System32), при этом копия свежей версии помещалась еще и в кеш защищенных системных файлов (%WinDir\System32\DLLcache). Если в момент обновления задействованные системные файлы кем-то использовались (были заняты/заблокированы), то замена их производилась позже, на этапе очередной загрузки операционной системы простым копированием уже новой версии из директории кеша в директорию основного размещения. А как же старые версии, спросите вы? А старые версии обновляемых библиотек удалялись безвозвратно, но в некоторых случаях (с включенной опцией rollback) их все же можно было сохранять в системе (в каталогах вида %WinDir%\$NTUninstallKB???????$). Эта особенность создавала проблему совместимости и позже, для её решения был добавлен каталог WinSxS, в который сохранялись старые (предыдущие) версии некоторых библиотек для совместимости с Windows95-приложениями. Как вы видите, механизм обслуживания на основе файлов был довольно прост, поэтому с него и начали, тем не менее он имел существенные недостатки:

  • Основная проблема: обновление единственных экземпляров системных файлов (библиотек), что неизменно вело к сбоям в работе приложений, оптимизированных (их авторами) на использование определенной версии общих DLL. Данная категория проблем получила название проблем совместимости библиотек и исполняемых модулей.
  • Обновления (update) или исправления (hotfix) содержали полноценный инсталлятор (исполняемые модули с именами update.exe/hotfix.exe), который непосредственно производил обновление файлов (библиотек) в системе. Сами понимаете, что эта избыточность делала каждое обновление фактически автономным пакетом, что вело к отсутствию унификации/контроля установки.
  • Все файлы были как бы "свалены в кучу", то есть размещались в общей для всех директории.
  • В системе отсутствовал менеджер пакетов, что делало контроль за процессом обновления менее гибким, не было единой базы установленных компонентов, невозможно было контролировать и производить откаты и прочие виды обслуживания.

Очевидно, что назревало решение по интеграции в линейку операционных систем Windows собственной подсистемы управления пакетами.

Обслуживание на основе компонентов

Начиная с Windows Vista была разработана и внедрена принципиально новая модель обслуживания, которая получила название обслуживание на основе компонентов (Component-Based Servicing, CBS). В противоположность обслуживанию на основе файлов, в котором файлы обновлялись прямо в системных директориях, в CBS появилась аж целая иерархия директорий и целое семейство (стек) модулей/библиотек обслуживания. Был введено понятие компонента, представляющего собой (небольшой) набор файлов, сгруппированных по назначению, функциональности и возможности многократного использования (активации/деактивации). В компонент входили: библиотеки/исполняемые, манифесты, каталог безопасности и некоторые другие. Появились статусы компонентов/обновлений, в связи с чем появилась возможность активировать или отключить различные возможности (features) в операционной системе по мере необходимости. Статус означает, что сам по себе компонент может быть установлен в ОС, но не активирован. Это вводит понятие состояния, которое помимо компонентов так же затрагивает обновления и исправления. Характерный пример - средство удаленного администрирования сервера (RSAT) в Windows 7, при инсталляции которого устанавливаются все компоненты средства администрирования, но ни один из установленных элементов не активен после инсталляции. Все что делает установщик в данном случае, это просто добавляет компоненты в систему, позже необходимо самостоятельно идти в оснастку Программы и компоненты (или действовать через dism) для включения требуемых возможностей.
Как вы уже поняли, обслуживание на основе компонентов (компонентная модель) в очередной раз перевернуло все с ног на голову и принесло множество "счастливых" моментов в жизнь простого технического специалиста, существенно изменив сложившийся годами привычный подход к принципам обслуживания операционной системы.

Фактически обслуживание на основе компонентов представляет собой первый полноценный пакетный менеджер для Windows (УРА!). Он обладает внушительным функционалом: ведет историю перезаписанных файлов, может удалить один пакет, если некоторые его файлы перезаписаны другим пакетом, хранит все версии файлов в хранилище компонентов, интегрирован со службой обновления Windows (Windows Update), что обеспечивает обновление всех установленных пакетов.

Причины внедрения, отличительные черты и преимущества компонентной модели:

  1. обеспечивает полный цикл сопровождения (установка/удаление/предоставление/восстановление) всех версий общих модулей/библиотек.
  2. является более надежным (стабильным) и безопасным механизмом, в отличии от автономных инсталляторов (update.exe/hotfix.exe), хорошо знакомых по предшествующим версиям операционной системы Windows.
  3. обеспечивает более управляемый (контролируемый) процесс установки, позволяющий добавлять обновления, драйверы и дополнительные компоненты, решая проблемы нестабильности, вызванные неправильной/частичной установкой.
  4. позволяет упаковывать любые компоненты и возможности в виде небольших модулей, которые обеспечивают весь функционал компонента.
  5. обеспечивает хранение всех версий всех файлов при помощи механизма WinSxS (Side-by-side assemblies);
  6. извечная проблема Windows – отсутствие на протяжении очень продолжительного времени собственной системы управления пакетами (менеджера пакетов), наконец-то решена, встречайте CBS! :)

По информации разработчиков, компонентная модель состоит из следующих условных слоев (упрощенно - уровней):

Уровень Предназначение
CBS (Component Based Servicing) Обслуживание на основе компонентов. Так же широко известен в узких кругах под разными именами: доверенный установщик, установщик модулей Windows или попросту Trusted Installer (TrustedInstaller.exe), который функционирует на уровне пакета/обновления.
CSI (Component Servicing Infrastructure) Инфраструктура обслуживания компонентов. Функционирует на уровне компонента/развертывания. Выполняет действия с файлами и реестром.
DMI (Driver Management and Install) Управление и установка драйверов. Процессы обеспечения расширенной (продвинутой) установки драйверов.
CMI (Component Management Infrastructure) Инфраструктура управления компонентами. Обеспечивает расширенный функционал установщиков.
SMI (Systems Management Infrastructure) Инфраструктура управления подсистемами. Используется для управления различными параметрами реестра.
KTM (Kernel Transaction Manager) Менеджер транзакций в ядре. Позволяет клиентам использовать транзакции операций с реестром и файловой системой.

Компонентная модель призвана обеспечить поддержку следующих системных задач:

  • Включение/отключение компонентов Windows (оснастка Программы и компоненты - Включение и отключение компонентов Windows);
  • Управление ролями посредством оснастки Server Manager в серверных версиях ОС;
  • Восстановление работоспособности системы после сбоев и разнообразных проблем загрузки;
  • Удаление/установка (проблемных) обновлений;
  • Поддержка функционирования приложений, использующих технологию Бок-о-бок (Side-by-Side);
  • Использование Центром обновления Windows при установке новых компонентов;
  • Перенос системы между различными редакциями Windows;

Хранилище компонентов (и пакетов)

Очевидно что информация о компонентах должна где-то физически размещаться. А то при выключении питания вся наша хваленая конструкция улетит в цифровой рай :) Во многих источниках фигурирует информация, что имеются два основных хранилища, относящихся к компонентной модели:

  1. Хранилище компонентов;
  2. Хранилище пакетов;

Файловая система

А поскольку единственный механизм для постоянного хранения данных - это (любой) носитель информации и размещаемая на нем файловая система, то в контексте компонентной модели была создана иерархия каталогов под названием хранилище компонентов (каталог компонентов), располагающееся в дереве директорий с корнем в %WinDir%\WinSxS (традиционно: C:\Windows\WinSxS). Разработчики уверяют что папка WinSxS является хранилищем разных версий общих библиотек и представляет собой "установочное и обслуживаемое состояние" всех системных компонентов.

Хранилище компонентов - иерархия директорий, в которой размещаются все версии всех установленных в системе компонентов.

Именование каталога WinSxS выбрано не случайно, оно является акронимом названия Side-by-Side (Бок о бок), которое подразумевает одновременное существование в системе всех выпущенных на данный момент версий той или иной библиотеки.

Устранение конфликтов между разными версиями глобальных библиотек DLL, установленных в операционной системе является одновременно и главным преимуществом компонентной модели, но так же и её большим недостатком, поскольку размер папки WinSxS в рабочих системах вырастает до неприлично больших значений. Происходит это потому, что папка может хранить содержимое, которое в действительности не используется (имеет промежуточный статус, не связано жесткими ссылками с другими расположениями в файловой системе).

В хранилище компонентов WinSxS каждый компонент помещается в собственном подкаталоге, определяемом уникальным именем, которое включает в себя архитектуру процессора, имя компонента, уникальный идентификатор, версию компонента, язык локализации, для которых он был собран. Вот типичный пример:

amd64_microsoft.windows.c..-controls.resources_6595b64144ccf1df_6.0.7600.16385_tr-tr_9e98e8587a93bcd6

Ничего необычного не видите? А что это за многоточие прямо по центру имени? А вот это вот такое своеобразное соглашение об именовании в хранилище компонентов, по которому некоторые, особенно размашистые имена, усекаются. Но стоит отметить, что у большинства компонентов имена все же полные.
Теперь обратим внимание на часть структуры компонентной модели, размещенной в файловой системе:

Путь Назначение
%WinDir%\WinSxS\ Основной (корневой) каталог компонентной модели. Каталог полезной нагрузки, в котором (в поддиректориях), размещаются бинарные файлы компонентов.
%WinDir%\WinSxS\Backup содержит защищаемые файлы: всех необходимые разнообразным приложениям версии системных библиотек и компонентов. В некотором смысле эта папка, где все библиотеки DLL системы на самом деле присутствуют. Библиотеки DLL, которые вы видите в других местах, на самом деле являются жесткими ссылками NTFS на те, что находятся в этом месте.
%WinDir%\WinSxS\Manifests Каталог для хранения манифестов.
%WinDir%\WinSxS\Catalogs .cat-файлы компонентов. Данные файлы содержат цифровые подписи каталогов и играют роль сигнатуры для файлов пакета, с помощью которой пользователь может определить происхождение пакета и проверить целостность файлов пакета драйвера.
%WinDir%\WinSxS\FileMaps .cdf-ms-файлы. Это скомпилированные версии манифестов, позволяющие быстрее обрабатывать конфигурационные параметры, содержащиеся в манифестах. Содержат такие параметры как: имя компонента, версия, описание, опции развертывания, зависимости.
%WinDir%\WinSXS\Pending.xml Файл формата XML, содержащий список действий (команд), исполняемых на этапе перезагрузки системы с целью выполнения тех задач (обновлений), которые не могут быть выполнены в момент работы ОС (поскольку во время штатной работы операционной системы могут присутствовать файлы, заблокированные другими процессами).
%WinDir%\Servicing\Packages Хранилище пакетов. Директория, находящаяся вне иерархии хранилища компонентов, но логически к ней относящаяся. Содержит файлы каталогов безопасности (.cat) и манифестов (.mum) установленных пакетов.

Реестр

По факту данные реестра тоже хранятся в виде файлов, тем не менее все же принято выделять его в самостоятельную сущность. Хранилище компонентов имеет часть конфигурации в реестре, в следующих ключах:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing;
  • HKEY_LOCAL_MACHINE\Schema;
  • HKEY_LOCAL_MACHINE\Components - временный, подключаемый на время обслуживания, ключ реестра. Подключается из файла C:\Windows\system32\config\COMPONENTS;

соответственно, в ключе HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages перечисляются все установленные в системе пакеты.

cbs packages

Для того, что бы была возможность работать со списком пакетов, необходимо назначить правильные права на весь раздел Component Based Services со всем вложенным содержимым (подразделами->подключами). Как можно увидеть по снимку экрана, у каждого пакета имеется параметр с именем Visibility, который ответственен за видимость пользовательскими утилитами обслуживания, и если он имеет значение 1 - пакет виден, если 2 - то это скрытый пакет. У пакета может иметься подключ Owners, в котором (в качестве параметров) перечислены родительские пакеты, в этом случае отдельно удалить сам пакет не представляется возможным. Если вы самостоятельно проинспектируете подключ Owners, то увидите, что значительная часть системных пакетов входит в состав неких родительских глобальных пакетов с именами вроде Microsoft-Windows-EnterpriseEdition~*, Microsoft-Windows-HomeBasicEdition~*, Microsoft-Windows-HomePremiumEdition~*, Microsoft-Windows-ProfessionalEdition~*, Microsoft-Windows-StarterEdition~*, Microsoft-Windows-UltimateEdition~*. Соответственно, чтобы иметь возможность удалить пакет, его нужно исключить из всех родительских пакетов (сделать автономным), попросту удалив находящиеся в подключе Owners параметры.

Компоненты (Components)

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

Компонент (Component) - группа файлов, в которую включены: один (или несколько) бинарных файлов, .cat-файл каталога безопасности и .manifest-файл (файл формата XML с описанием настроек безопасности, метода инсталляции и параметров реестра).

Упрощенно компоненты состоят из полезной нагрузки (библиотеки, исполняемые файлы, локальные файлы конфигурации и прочие файлы) и манифеста (определяет зависимости). Каждый такой набор содержит все необходимые файлы, параметры реестра, и методы, требуемые для полной установки/удаления компонента. В компонентной модели атомарной единицей при обновлении является не файл (как ранее при файловом методе обслуживания), а компонент, и при обновлении единственного файла выпускается новая версия всего компонента, в состав которого входит обновляемый (пропатчеваемый) файл. Таким образом:

Компонент это минимальная установочная неделимая единица для компонентной модели.

Это порождает довольно интересный, ранее не встречаемый, алгоритм обновления: в процессе установки библиотеки, уже имеющейся в системе, факт наличия обнаруживается, однако файл библиотеки DLL не перезаписывается, вместо этого новая версия помешается в папку WinSxS, при этом сохраняются соответствующие записи реестра, данных и прочее. Таким образом, наряду с новой версией компонента, в системе со временем накапливаются и все "старые" его версии, призванные обеспечить штатное функционирование программного обеспечения, нуждающегося в строго определенной версии компонента. Даже если исправление найденной ошибки вносится в один единственный файл, если этот файл относится к компоненту, содержащему и другие файлы, то обновление будет так же содержать все файлы этого компонента. Все эти файлы, вне зависимости от того, внесены в них изменения или нет, будут собраны (скомпилированы), номера их версий будут увеличены (изменены), далее все они будут упакованы (помещены) в пакет исправления. При этом, в системных местоположениях (например, в каталоге %WinDir%\System32) отображаются текущие версии системных библиотек, которые представляют собой жесткие ссылки, ведущие на оригиналы, размещаемые в хранилище компонентов.

Компоненты группируются по пакетам, но у большинства пакетов компонентов нет.

Все отключаемые компоненты, видимые в оснастке Удаление компонентов Windows, можно получить командой:

dism /Online /Get-Features

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

Возможность (feature)

В русскоязычной версии Windows слово Feature переведено почему то как Компонент. А разве дословно Feature переводится не как Возможность, а компонент как Component? Казалось бы мелочь, тем не менее эта неточность порождает неразбериху в терминологии относительно разницы компонентов и возможностей. И так ведь рядовому пользователю (да и специалисту) не понятно что в рамках операционной системе есть Возможность а что Компонент, а тут еще происходит откровенная подмена понятий. К примеру, хорошо знакомая всем оснастка Programs and Features выглядит в русской версии как Программы и компоненты. Если мы откроем её, то увидим, что с её помощью мы можем:

  • Удалять установленные в системе программы;
  • Включать/отключать компоненты операционной системы;

В свою очередь, если мы открываем оснастку Включение или отключение компонентов Windows мы видим такие вещи как "Internet Explorer 11", "Microsoft .NET Framework 3.5.1" и прочие. И что, по вашему, это компоненты, то есть атомарные неделимые установочные единицы компонентной модели? Нет, поскольку под компонентами в Windows подразумеваются значительно более маленькие сущности, например в том же Internet Explorer 11 более 20 компонентов. Так что же это тогда такое? Давайте разбираться.
Любой программный продукт состоит из компонентов (components), сгруппированных в возможности (features).

Возможность (feature) — это иерархическая группа компонент (и/или других возможностей).

То есть, когда при установке приложения появляется диалог выбора устанавливаемых частей (опций) программы или выводится оснастка "Включение или отключение компонентов Windows", пользователь имеет дело именно с возможностями. Выбор той или иной возможности для установки влечёт за собой и установку в систему всех компонентов, которые она в себя включает. То есть возможность, которая на самом деле имеется в виду в оснастке Программы и компоненты является набором компонентов, и при активации этой возможности в систему устанавливаются необходимые компоненты компонентной модели, являющиеся атомарными неделимыми установочными единицами компонентной модели.

То есть, с большой натяжкой возможности в некоторых оснастках операционной системы можно было бы назвать компонентами, но все равно это запутывает пользователя, потому как компонентами в классическом виде называются объекты компонентной модели.

Пакеты (Packages)

Помимо компонентов, в системе присутствуют так называемые пакеты, которые могут представлять собой как отдельные автономные инсталляции (например: Internet Explorer Optional Package, Remote Desktop Service WinIP и прч.), содержащие системные приложения, так и исправления операционной системы (KBnnnnnnn) и комплекты драйверов.
Пакеты, как и компоненты, имеют собственное хранилище (хранилище пакетов), которое состоит из двух основных частей:

  • одна часть пакета располагается в хранилище пакетов, то есть дереве директорий с корнем в %WinDir%\servicing\Packages. В нем содержатся конфигурационные файлы пакета, тут каждый установленный пакет/обновление представлен двумя файлами: файлом каталога безопасности (.cat) и манифеста (.mum), определяется собственным уникальным именем, которое включает в себя архитектуру процессора, имя пакета, уникальный идентификатор, версию пакета, язык локализации, для которых он был собран.
  • другая часть (основные файлы) пакета размещается в хранилище компонентов, директории %WinDir%\WinSxS.

Манифест пакета описывает полезную нагрузку и статус: установлен и задействован (активирован), установлен, не установлен. Статусы пакетов:

  • Installed (Установлен) - пакет установлен и присутствует в каталоге WinSxS. Полезная нагрузка пакета размещена в файловой системе и активна;
  • Superseded (Заменён) -- ;
  • Not Present (Отсутствует) -- ;
  • Staged (Промежуточное, подготовленное) -- пакет не установлен однако присутствует в каталоге WinSxS. В этом состоянии находятся многие роли/возможности в системе (сразу после установки). Когда какая-либо роль/возможность не активна, то данная роль находится в как раз в промежуточном состоянии. В графическом интерфейсе состояние видно в качестве флажка напротив роли, который не активен (не установлен). Активация чекбокса компонента запускает процесс перемещения его бинарных файлов из промежуточного состояния в установленное;
  • Absent (Отсутствует) -- пакет не установлен и отсутствует в каталоге WinSxS. Иногда это означает, что пакет "отключен и его полезная нагрузка удалена";

Соответственно, в процессе установки пакеты выполняют обновление (имеют своей целью) компонентов. В компонентной модели каждый пакет может содержать одну или несколько отключаемых возможностей (в виде опций). В общем случае пакеты бывают установленными и подготовленными (к установке). Все установленные и видимые в системе пакеты можно получить командой:

dism /Online /Get-Packages

Манифесты (Manifests)

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

  • Манифест компонента – описатель компонента Windows. Манифест компонента задает его зависимости от имен, версий, ресурсов и других компонентов, в нем указываются различные параметры компонента, такие как наименование, каталог установки, параметры (ключи) реестра, исполняемые файлы, наименования служб и прочие. Манифест определяет как именно файлы группируются по компонентам. Имя файла манифеста включает имя соответствующей сборки, размещаемой в каталоге %WinDir%\WinSxS. Имеет расширение .manifest. Размещается в каталоге %WinDir%\WinSxS\Manifests;
  • Манифест пакета или обновления - описатель пакета/обновления Windows. В нем указываются различные параметры пакета: наименование, идентификатор, язык установки, зависимости. Этот типа манифеста используется в качестве идентификатора (символического имени) сервиса обслуживания, для выполнения над пакетом операций включения/отключения/удаления посредством различных сервисных утилит (DISM, pkgmgr). Имя файла манифеста включает имя соответствующего пакета, размещаемого в каталоге %WinDir%\WinSxS. Имеет расширение .mum. Размещается в каталоге %WinDir%\servicing\Packages;

Применительно же к приложению, манифест определяет зависимости, которые приложение использует и связывает его со строго определенной версией компонента (сборки), библиотеки. Другими словами, приложение связывается с конкретной сборкой посредством информации, размещаемой непосредственно в ресурсной секции приложения, в ресурсе с именем Manifest. Желающие использовать строго определенные версии библиотек, должны непосредственно указывать идентификаторы сборок в собственном манифесте.

Обновление (KBnnnnnnn)

Обновления представляют собой отдельные модули. Могут быть представлены в нескольких вариантах:

  • .cab-файлы (Cabinet) - архивы. Предназначены для распространения и установки при помощи модулей Центра обновлений Windows в автоматизированном режиме;
  • .msu-файлы (Microsoft Update Standalone Package) - исполняемые файлы. Предназначены для распространения и установки самими пользователями в ручном режиме через каталог обновлений Microsoft. Фактически представляют собой упакованный набор, состоящий из .cab-, .xml, .txt-файлов;

Обновление содержит пакеты.

Обслуживание

Обслуживание - действие в операционной системе по включению/выключению ролей/возможностей, установке/удалению обновлений и сервис-паков.

Стек обслуживания в операционных системах Windows Vista и новее состоит из трех основных уровней:

  1. Верхний: работают такие клиенты как: Windows Update, Programs and Features, и MSI, которые доставляют пакеты в систему. Программные клиенты верхнего уровня в дополнение отвечают за взаимодействие с пользователем, обеспечивают сбор/хранение пользовательских настроек на всем протяжении обслуживания.
  2. Средний: На среднем уровне стека обслуживания функционирует Trusted Installer (trustedinstaller.exe), CBS. Клиенты верхнего уровня спускают скачанные пакеты к CBS, которая оценивает каждый пакет для определения, применимы ли они к данной операционной системе. Для применяемых обновлений CBS предоставляет компоненты CSI, генерирует соответствующие события установки и регистрирует пакеты в оснастке Программы и компоненты, в случае необходимости. Наконец, CBS предоставляет интерфейсы для индексации и инвентаризации обновлений.
  3. Нижний: На нижнем уровне стека обслуживания располагается CSI, которая использует Kernel Transaction Manager (KTM) для выполнения работы.

Как мы уже говорили, обслуживание системы в новых реалиях происходит уже на уровне компонентов. Файлы поддержки технологии расположены в каталоге %SystemRoot%\servicing. Например, в Windows 7 в данном каталоге размещаются:

Наименование Описание
CbsApi.dll Основная библиотека поддержки технологии CBS.
CbsMsg.dll Дополнительная библиотека поддержки CBS.
TrustedInstaller.exe интерфейс между стеком обслуживания и разнообразными пользовательскими программами по обслуживанию, такими как sfc, dism, pkgmgr, оснасткой "Программы и компоненты", инсталляторами MSI, компонентом "Обновление Windows". Фактически, теперь только модуль TrustedInstaller.exe может модифицировать критические системные файлы. Использует модули уровня CSI для выполнения всей работы.
wrpinitapi.dll Библиотека поддержки технологии Windows File Protection (WFP).
\Packages Подкаталог-хранилище пакетов. Содержит файлы каталогов безопасности (.cat) и манифестов (.mum) установленных пакетов/обновлений. Сами пакеты/обновления, скорее всего, содержатся в директории %WinDir%\WinSxS;

В стеке обслуживания реализован давно уже знакомый специалистам системный механизм под названием Защита Ресурсов Windows (Windows Resource Protection (WRP)), в операционных системах до Windows Vista более известный под именем Защита Файлов Windows (Windows File Protection (WFP)).

WRP предназначена для защиты некоторых важных в функциональном отношении системных каталогов, файлов и ключей реестра.

Сам принцип защиты критических файлов так же поменялся со времен WFP, теперь отсутствует системный процесс, который в режиме реального времени отслеживает попытки модификации критических файлов, а система ограничивает доступ к важным системным файлам при помощи списков контроля доступа (ACL/DACL), то есть WRP контролирует только определенные местоположения в операционной системе.

Поэтому, если Вы захотите поэкспериментировать с системными файлами, например, что-то отреверсить и поменять алгоритм работы, лучше скопируйте их предварительно из системных каталогов в какую-нибудь безобидную пользовательскую папку, что бы WRP до них не добралась!

Некоторые сервисные утилиты, например sfc, в своей работе активно эксплуатирует стек обслуживания и, соответственно, функции библиотеки wrpinitapi.dll, которая предоставляет поддержку функций работы с WRP. В процессе работы утилиты sfc, WRP посредством процесса TrustedInstaller.exe производит обход всех критических системных компонентов, которые важны для поддержки функционирования операционной системы. В процессе обхода файл, размещенный в системном каталоге, сравнивается с эталонным файлом, размещенным в хранилище %WinDir%\WinSxS. Если обнаруживаются какие-либо модификации системного файла, WRP восстанавливает оригинальную копию данного файла из директории %WinDir%\WinSxS\Backup, которая содержит все защищаемые системные файлы.

CSI

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

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

Когда пакет удаляется, процесс реверсируется:

  • Инсталлятор создает список всех используемых файлов, и другие действия которые необходимы для перезагрузки ОС.
  • Удалить файлы или зависимости – файлы могут быть удалены из системы или могут остаться в хранилище компонентов для будущего использования.
  • Неиспользуемые файлы могут быть удалены из системы, затем система может быть перезагружена для выполнения освобождения места и удаления файлов, которые были заняты (использовались) на предыдущих шагах.

Когда новая версия компонента установлена в систему, слой CSI опрашивает хранилище компонентов с целью определить, какие именно компоненты обновлены. В процессе установки компонента, CSI использует модуль Очереди простых операций (Primitive Operations Queue, POQ), который считывает список всех файлов и ключей реестра, подлежащих установке/обновлению. Продвинутые установщики или универсальные команды затем запускаются для завершения установки. Расширенные установщики запускаются в контексте процессов с использованием CMI. Если в процессе инсталляции компонента имеет место какой-либо сбой, CSI откатывает всю цепочку изменений, сделанных текущей инсталляцией. Если файл или процесс во время инсталляции компонента используется каким-либо источником и не может быть заменен, действия универсальных команд и продвинутых установщиков заносятся в файл %WinDir%\WinSXS\Pending.xml, и затем эти операции над файлами выполняются уже во время последующей перезагрузки. Если несколько пакетов устанавливаются в одно и то же время, каждый последующий (кроме первого) пакет добавляется к pending.xml. Логгирование на протяжении процесса обновления производится в файл %windir%\Logs\CBS\CBS.log.

Заключение

Зачем нам нужна подобная избыточная компонентная модель, в которой хранятся все версии всех компонентов и пакетов? Действительно, вся эта структура, в которой хранится содержимое компонентов и пакетов предыдущих версий может показаться на первый взгляд абсурдной, тем не менее этот механизм может поддерживать систему в актуальном состоянии при любых обстоятельствах. При любых откатах или удалениях вам нужно всего-лишь спроектировать компоненты, которые находятся в хранилище в промежуточном статусе. Проекция производится по последнему имеющемуся в хранилище компоненту, надо всего-лишь перестроить зависимости.
В релизы Windows Vista и 7, обслуживание на основе компонентов (компонентная модели) были внедрены в недоработанном, "сыром" виде, что повлекло за собой большое количество проблем у пользователей, выражавшихся в возникновении разнородных ошибок обновлений.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Помощь сайту