Ответы на экзамен по операционным системам
Оглавление
1. Логика развития и ключевые свойства версий ОС Windows 3x, 9x, NT, 2000, XP. . 4
Графические интерфейсы и расширения для DOS.................................................. 4
(1991г) Win 3.1 ориентирована на 32bit систему, поддерживает сегментно
страницчную вирт память - защищенный режим памяти. .................................................... 5
Семейство Windows 9x ................................................................................................... 5
Семейство Windows NT .................................................................................................. 6
2. Логика развития и ключевые свойства версий ОС Windows XP, Windows 7,
Windows 8. ........................................................................................................................................ 8
Windows 7............................................................................................................................ 10
3. Логика развития и ключевые свойства версий ОС Windows Server 2003, Server
2008, Server 2012 ............................................................................................................................ 11
Windows Server 2003 .......................................................................................................... 11
Windows Server 2008 .......................................................................................................... 12
4. Общая архитектура Windows уровня ядра, состав и функции основных
компонентов. .................................................................................................................................. 14
5.
Общая архитектура Windows прикладного уровня. Свойства API Win32. ............. 19
6. Объектный принцип в организации Windows. Свойства объектов процессов и
потоков. 22
7. Управление процессами и диспетчеризация Windows. ............................................. 24
8. Принцип установки и удаления приложений. Проблемы зависимостей
установленных приложений и системы и способы их преодоления. Инсталлятор MSI. ...... 26
9. Различия программных моделей DOS-, Win16-, Win32-приложений, особенности
их выполнения в Windows. ........................................................................................................... 27
10. Базовые свойства командного языка Windows и его расширения. Смысл и
применение переменных окружения. Программирование командных файлов. ..................... 30
11. Средства обмена данными между приложениями в Windows. Базовые понятия
OLE, особенности применения связывания и внедрения объектов. Роль технологии OLE во
внутренних механизмах Windows. .............................................................................................. 34
12. Процесс загрузки Windows, управление загрузкой. Роль реестра на этапах
загрузки. 36
13.
Технология UEFI и GPT-формат дисков, проблемы внедрения............................ 41
14. Файловые системы в современных версиях Windows. Общие свойства файловой
системы NTFS. ............................................................................................................................... 43
15. Структура системных данных на томе NTFS. Принцип адресации расположения
файлов на томе. .............................................................................................................................. 47
16. Атрибуты файлов NTFS, форматы записей MFT для файлов и каталогов.
Применение расширенных атрибутов. ........................................................................................ 51
17. Расширенные возможности NTFS: сжатие и шифрация данных, точки повторной
обработки. 54
18. Расширенные возможности NTFS: монтирование томов, жесткие и
символические связи, "консолидированная безопасность", применение VHD. ..................... 59
19.
20.
Модели драйверов в Windows. Общие свойства и функции драйверов. .............. 63
Структура подсистемы ввода-вывода и стек драйверов Windows. ....................... 66
21. Назначение, функции и общий принцип технологии Plug and Play (PnP).
Проблемы внедрения..................................................................................................................... 68
22.
Структура системы PnP, функции и взаимодействие компонентов. .................... 71
23. Установка и конфигурирование устройств в Windows, распределение
аппаратных ресурсов. Роль INI-файлов. ..................................................................................... 79
24. Свойства и применение библиотек динамической компоновки DLL. Базовые
библиотеки API Win32. Управление связыванием. ................................................................... 82
25. Назначение и общие свойства реестра Windows. Логическая структура и типы
данных. Физическое хранение данных реестра. ........................................................................ 88
26. Типовые операции с реестром. Обзор ключей реестра HK_Classes_Root и
HK_Local_Machine. ....................................................................................................................... 91
27. Понятие и свойства учетной записи пользователя Windows. Пофиль
пользователя и его представление в реестре. ............................................................................. 93
28. Характеристика ОС Linux. Состав и специфика дистрибутивов, проблемы
стандартизации и распространения. ............................................................................................ 96
29.
Структура и функции ядра Linux. Современные тенденции в развитии ядра. .. 102
Введение в ядро Linux ..................................................................................................... 102
Свойства ядра Linux ......................................................................................................... 103
Основные подсистемы ядра Linux .................................................................................. 103
Интерфейс системных вызовов ................................................................................... 104
Управление процессами ............................................................................................... 104
Управление памятью .................................................................................................... 104
Виртуальная файловая система ................................................................................... 105
Сетевой стек................................................................................................................... 106
30. Свойства и управление процессами Linux. Применение сигналов. .................... 107
31. Понятие и свойства учетных записей пользователей Linux. Управление
пользователями. ........................................................................................................................... 110
32. Командный и графический пользовательский интерфейс в Linux. Общие
свойства командной оболочки bash ........................................................................................... 114
33. Командные средства управления процессами и заданиями в Linux. Выполнение
программ в оперативном и фоновом режимах. Управление полномочиями демонов и
прикладных процессов. ............................................................................................................... 116
34. Управление устройствами в Linux. Назначение и применение специальных
файлов устройств. Система udev. .............................................................................................. 118
35. Монтирование файловой системы на томе, основные параметры монтирования.
Монтирование фаловых устройств при загрузке Linux и работа со сменными носителями.
120
36. Общие свойства файловых систем в Linux, основные типы поддерживаемых
файловых систем, именование и атрибуты файлов. ................................................................ 124
Базовая файловая система UNIX S5FS .......................................................................... 126
37. Типы файлов в Linux. Структура системных данных файловой системы:
индесные дескрипторы и каталоги. ........................................................................................... 129
Идентификация типов файлов в Linux ........................................................................... 129
2.1. Обычный файл........................................................................................................ 129
2.2. Директория ............................................................................................................. 129
2.3. Символьное устройство......................................................................................... 130
2.4. Блочное устройство ............................................................................................... 130
2.5. Сокеты локального домена ................................................................................... 130
2.6. Именованные каналы............................................................................................. 130
2.7. Символические ссылки.......................................................................................... 130
38. Управление файлами в Linux. Операции над файлами, группами файлов и
каталогами. ................................................................................................................................... 133
Команды для работы с файлами и каталогами ............................................................. 133
4.6.1. Команды chown и chgrp ...................................................................................... 133
4.6.2. Команда mkdir ..................................................................................................... 133
4.6.3. Команда cat .......................................................................................................... 133
4.6.4. Команда cp ........................................................................................................... 134
4.6.5. Команда mv .......................................................................................................... 134
4.6.6. Команды rm и rmdir ............................................................................................ 134
39. Управление доступом к файлам и каталогам в Linux. Основные режимы доступа
и дополнительные признаки SetUID, SetGID, StikyBit. Применение и механизм проверки
доступа к файловой системе. ...................................................................................................... 135
40. Общая структура тома в Linux. Адресация расположения файла на томе.
Ограничения классической файловой системы s5fs. ............................................................... 138
Структура жёсткого диска .................................................................................................. 138
Сектора .............................................................................................................................. 138
Разделы .............................................................................................................................. 138
Таблица разделов.............................................................................................................. 138
Тип раздела ....................................................................................................................... 139
Логические тома (LVM) .................................................................................................. 139
Дисковые массивы (RAID) .............................................................................................. 140
Системы файлов Linux ................................................................................................. 141
41.
Развитие структуры и свойств файловых систем в Linux. Журнализация. ........ 145
42. Установка и обновление программ, поставляемых в исходных текстах и rpmпакетах. Использование утилит для работы с репозиториями Linux. ................................... 146
В операционной системе Linux существуют три способа установки программного
обеспечения:.............................................................................................................................. 146
Традиционный. ................................................................................................................. 146
Из пакетов RPM. ............................................................................................................... 146
Из пакетов, содержащих исходный код. ........................................................................ 146
Рассмотрим по порядку все три способа. ...................................................................... 146
Программы для работы с репозиторием ....................................................................... 148
Установка ПО с использованием rpm ............................................................................ 150
43.
Обновление компонентов Linux. Сборка и обновление ядра Linux. .................. 152
Шаг 1. Получение исходного кода ядра................................................................... 156
Шаг 2. Получение необходимых для сборки пакетов........................................... 157
Шаг 3. Применение патчей.......................................................................................... 158
Шаг 4. Конфигурация будущей сборки ядра .......................................................... 159
Шаг 5. Сборка ядра ....................................................................................................... 160
Шаг 6. Установка образов и заголовков ядра ........................................................ 160
Шаг 7. Генерация начального RAM-диска ............................................................... 161
Шаг 8. Обновление конфигурации загрузчика GRUB ........................................... 161
Шаг 9. Проверка ядра ................................................................................................... 161
Логика развития и ключевые свойства версий ОС Windows 3x, 9x, NT, 2000, XP.
Графические интерфейсы и расширения для DOS
Эти версии Windows не были полноценными операционными системами, а являлись
надстройками к операционной системе MS-DOS и были по сути многофункциональным
расширением, добавляя поддержку новых режимов работы процессора, поддержку
многозадачности, обеспечивая стандартизацию интерфейсов аппаратного обеспечения и
единообразие для пользовательских интерфейсов программ. Предоставляли встроенные
средства (GDI и USER, первые версии Windows вообще состояли из трех модулей —
KERNEL, GDI и USER, первый из них предоставлял вызовы управления памятью,
запуском .EXE-файлов и загрузкой .DLL-файлов, второй — графику, третий — окна) для
создания графического интерфейса пользователя. Они работали с процессорами начиная с
Intel 8086.
1.
1.
Windows 1.0 (1985)
2.
Windows 2.0 (1987)
3.
Windows 2.1 (Windows 386, 1987) — в системе появилась возможность запуска
DOS-приложений в графических окнах, причём каждому приложению предоставлялись
полные 640 Кб памяти. Полная поддержка процессора 80286. Появилась поддержка
процессоров 80386.
4.
режима.
Windows 3.0 (1990) — улучшена поддержка процессоров 80386 и защищённого
5.
Windows 3.1 (1992) — серьёзно переработанная Windows 3.0; устранены UAE
(Unrecoverable Application Errors — фатальные ошибки прикладных программ), добавлен
механизм OLE, печать в режиме WYSIWYG («что видите, то и получите»), шрифты
TrueType, изменён Проводник (диспетчер файлов), добавлены мультимедийные функции.
6.
Windows для рабочих групп (Windows for Workgroups, WfWG) 3.1/3.11 —
первая версия ОС семейства с поддержкой локальных сетей. В WfWG 3.11 также
испытывались отдельные усовершенствования ядра, применённые позднее в Windows 95.
Windows 3.x
22 мая 1990г. Предварительная установка на компьютеры –получила мировое
распространение. Замена DOS собственным диспетчером программ и диспетчер файлов.
Была включена панель управления. Поддержка окон.
Система поддерживала несколько режимов памяти, включая 16-разрядный Real Mode
для компьютеров с более ранними процессорами, нежели Intel 80286, и 32-разрядный
Enhanced Mode для более производительных процессоров 80386.
Требования к аппаратному обеспечению у системы были следующие:
процессоры 8086/8088 или более современные
384 Кб памяти в режиме Real Mode, 1 Мб в режиме Standart Mode и 2 Мб в режиме
Enhanced Mode
6-7 Мб свободного пространства на жёстком диске
графические карты CGA/EGA/VGA/Hercules/8514/A/XGA и совместимый монитор
MS-DOS 3.1 или новее
также рекомендовалось использовать совместимую с продуктом Microsoft мышь.
(1991г) Win 3.1 ориентирована на 32bit систему, поддерживает сегментно
страницчную вирт память - защищенный режим памяти.
(1993г) Win 3.11 - эта была платформа с уклоном в корпоративную направленность она поддерживала организацию локальной сети по протоколам TCP/IP, IPX/SPX и
NetBEUI, включала программы удаленного администрирования компьютера, позволяла
использовать сетевые принтеры и накопители, программу для приема и отправки факсов и
др.
Семейство Windows 9x
Включает в себя Windows 95, Windows 98 и Windows ME.
Windows 95 была выпущена в 1995 году. Её отличительными особенностями
являются:
новый пользовательский интерфейс,
поддержка длинных имён файлов,
автоматическое определение и конфигурация периферийных устройств Plug and
Play,
способность исполнять 32-битные приложения и наличие поддержки TCP/IP прямо
в системе.
Windows 95 использует вытесняющую многозадачность и выполняет каждое 32битное приложение в своём адресном пространстве.
появление реестра
Операционные
системы
этого
семейства
не
являлись
безопасными
многопользовательскими системами как Windows NT, поскольку из соображений
совместимости вся подсистема пользовательского интерфейса и графики оставалась 16битной и мало отличалась от той, что в Windows 3.x. Так как этот код не был thread-safe,
все вызовы в подсистему оборачивались в мьютекс по имени Win16Lock, который, кроме
того, ещё и находился всегда в захваченном состоянии во время исполнения 16-битного
приложения. Таким образом, «повисание» 16-битного приложения немедленно
блокировало всю ОС.
Программный интерфейс был подмножеством Win32 API, поддерживаемым Windows
NT, но имел поддержку юникода в очень ограниченном объёме[9]. Также в нём не было
должного обеспечения безопасности (списков доступа к объектам и понятия
«администратор»).
В составе Windows 95 присутствовал MS-DOS 7.0, однако его роль сводилась к
обеспечению процесса загрузки и исполнению 16-битных DOS приложений.
Исследователи заметили, что ядро Windows 95 — VMM — обращается к DOS под собой,
но таких обращений довольно мало, главнейшая функция ядра DOS — файловая система
FAT — не использовалась. В целом же интерфейс между VMM и нижележащей DOS
никогда не публиковался, и DOS была замечена (тем же Эндрю Шульманом) в наличии
недокументированных вызовов только для поддержки VMM.
Семейство Windows NT
Основная статья: Windows NT
Операционные системы этого семейства в настоящее время работают на процессорах
с архитектурами x86, x64, и Itanium,ARM. Ранние версии (до 4.0 включительно) также
поддерживали некоторые RISC-процессоры: Alpha, MIPS, и Power PC. Все операционные
системы этого семейства являются полностью 32- или 64- битными операционными
системами, и не нуждаются в MS-DOS даже для загрузки.
Windows NT и Windows 95 различия.
Windows NT поддерживает многопроцессорные системы, а Windows 95 — нет.
Файловая система Windows NT поддерживает средства защиты, например
управление избирательным доступом (discretionary access control). В файловой
системе Windows 95 этого нет.
Windows NT — полностью 32разрядная (а теперь и 64разрядная) операционная
система, в ней нет 16разрядного кода, кроме того, который предназначен для
выполнения 16разрядных Windows приложений. Windows 95 содержит большой
объем старого 16разрядного кода из предшествующих операционных систем —
Windows 3.1 и MSDOS.
Windows NT полностью реентерабельна, а многие части Windows95
нереентерабельны (в основном это касается 16разрядного кода,взятого из Windows
3.1). Большинство функций, связанных с графикой и управлением окнами (GDI и
USER), включают именно нереентерабельный код. Система выглядит как
однопоточная изза нереентерабельности кода (Win 95)
Windows NT позволяет выполнять 16-разрядные Windows приложения в
выделенном адресном пространстве, а Windows 95 всегда выполняет такие
приложения в общем адресном пространстве, в котором они могут навредить друг
другу и привести к зависанию системы.
Разделяемая (общая) память процесса в Windows NT видна только тем процессам,
которые имеют проекцию на один и тот же блок разделяемой памяти. В Windows 95
вся общая память видна и дос тупна для записи всем процессам.
Некоторые критически важные страницы памяти, занимаемые операционной
системой Windows 95, доступны для записи из пользовательского режима,
объктный принцип внутренней организации
ориентация на глобальную сеть, поддержка многопротокольной маршрутизации,
создание доменов
NTFS, многопользовательская защита
Win 2000
Windows 2000 представляет собой 32-разрядную ОС, обеспечивающую
многозадачную и многопоточную обработку приложений (программ).
Она поддерживает удобный графический пользовательский интерфейс, возможность
работы в защищенном режиме, совместимость программ реального режима и сетевые
возможности.
В Win2k реализована технология поддержки самонастраивающейся аппаратуры Plug
and play, допускаются длинные имена файлов и обеспечиваются повышенные
характеристики устойчивости.
Отличительные свойства Win2k:
1. 32-разрядность – операции над 32-разрядными данными выполняются быстрее, чем
в 16-разрядных ОС;
2. многозадачность представляет возможность одновременной параллельной работы с
несколькими
приложениями.
Это
повышает
эффективность
использования
микропроцессора и производительность труда пользователя;
3. многопоточность – способность Win2k организовывать одновременную обработку
нескольких потоков конкурирующих за процессорное время. При этом допускается
параллельное выполнение нескольких приложений, а также нескольких фрагментов (задач)
одного или нескольких приложений. В текстовом процессоре могут одновременно
выполняется автоматическая проверка орфографии, редактирование документов;
4. пользовательский интерфейс Win2k обеспечивает удобство в запуске и
переключений приложений. Основными компонентами пользовательского интерфейса
являются: рабочий стол, панель задач (панель задач обеспечивает запуск и переключение
приложений). На рабочем столе размещены графические объекты, соответствующие
приложениям, документам, сетевым устройствам. Каждый графический объект имеет
поименованный ярлычок (иконка, пиктограмма). С помощью мыши, ярлычков, главного
меню и панели задач пользователь может легко включать и переключать приложения;
5. технология plug and play ориентирована на поддержку любого типа устройства
включая: мониторы, видеоплаты, принтеры, звуковые платы, модемы, приводы, сидиром.
При ее использовании обеспечиваются следующие вспомогательные устройства:
· распознавания устройств для установки и настройки;
· динамическое изменение состояния устройств;
· интеграция драйверов устройств, системных компонентов и пользовательского
интерфейса.
При подключении устройств Win2k самостоятельно вычисляет используемые номера
прерываний, адреса портов ввода-вывода, канала прямого доступа к памяти. При
возникновении конфликтов они возникают автоматически, избавляя пользователя от
необходимости поиска подходящих параметров для совместно подключаемых устройств;
6. работа в сети и коммуникационной службе. Включает встроенную поддержку
наиболее известных протоколов TCP/IP, IPX/SPX, обеспечивает взаимодействие с сетями
NoWell, Netware, Unix, Apple Talk. Обеспечивает удаленный доступ к сетям. Win2k
поддерживает сеанс удаленного доступа.
7. интеграция с Интернет. Пользователи могут безопасно просматривать ресурсы
рабочей или корпоративной сети и Интернет, работать с электронной почтой. Win2k
включает IIS/Internet Information Server – платформу Web сервера для размещения Webузлов в Интернет и интросетях.
встроенные средства администрирования Win2k позволяют управлять локальными и
удаленными компьютерами, имея стандартный интерфейс средств администрирования.
Логика развития и ключевые свойства версий ОС Windows XP, Windows 7,
Windows 8.
Windows XP
Операционнаясистема Microsoft Windows XP (отангл. eXPerience — опыт), известна
также под кодовым наименованием Microsoft Codename Whistler. Первоначально в планы
корпорации Microsoft входила разработка двух независимых операционных систем нового
поколения. Первый проект получил рабочее название Neptune, эта ОС должна была стать
очередным обновлением Windows Millennium Edition, новой системой линейки Windows
9X. Второй проект, называвшийся Odyssey, предполагал создание ОС на платформе
Windows NT, которая должна была придти на смену Windows 2000. Однако руководство
Microsoft посчитало нецелесообразным рассредоточивать ресурсы на продвижение двух
разных ОС, вследствие чего оба направления разработок были объединены в один проект Microsoft Whistler. Возможно, именно благодаря этому решению Windows XP объединяет в
себе достоинства уже знакомых пользователям операционных систем предыдущих
поколений: удобство, простоту в инсталляции и эксплуатации ОС семейства Windows 98 и
Windows ME, а также надежность и многофункциональность Windows 2000. В настоящее
время Windows XP для настольных ПК и рабочих станций выпускается в трех
модификациях: Home Edition для домашних персональных компьютеров, Professional
Edition — для офисных ПК и, наконец, Microsoft Windows XP 64bit Edition — это версия
Windows XP Professional для персональных компьютеров, собранных на базе 64-битного
процессора Intel Itanium с тактовой частотой более 1 ГГц.
Для запуска Microsoft Windows XP необходим персональный компьютер, отвечающий
следующим минимальным системным требованиям: процессор — Pentium-совместимый,
тактовая частота от 233 МГц и выше; объем оперативной памяти — 64 Мбайт; свободное
дисковое пространство — 1,5 Гбайт.
Если сравнить Windows XP с более ранними версиями Microsoft Windows, в новой
операционной системе легко обнаружить множество значительных отличий. Несмотря на
то, что эта ОС была разработана на основе уже хорошо знакомой российским
пользователям платформы NT и, на первый взгляд, по своим характеристикам во многом
2.
схожа с Microsoft Windows 2000, фактически Windows XP относится к принципиально
иному поколению операционных систем семейства Windows. Теперь пользователь
Windows не привязан к какому-либо стандартному интерфейсу, устанавливаемому в
системе по умолчанию. Если вам не нравится традиционный вид окон, элементов
управления и Панели задач, доставшийся новой ОС "в наследство" от Windows 2000, то вы
можете без труда изменить их, загрузив из Интернета любой из сотен специально
разработанных "Тем". Традиционное Главное меню, открывающее доступ к установленным
на компьютере программам, хранящимся на дисках документам и настройкам
операционной системы, также претерпело ряд значительных изменений. Теперь при
нажатии кнопки Пуск появляется динамическое меню, содержащее значки лишь пяти
программ, которыми пользуется наиболее часто. Благодаря этому можно начать работу с
нужными приложениями значительно быстрее. Здесь же расположены значки браузера
Microsoft Internet Explorer 6 и почтового клиента Outlook Express 6, кнопки Выход из
системы (Log Off) и Выключение компьютера (Turn Off Computer).
В среде Microsoft Windows пользователю часто приходится одновременно работать с
несколькими документами или набором различных программ. При этом неактивные
приложения сворачиваются в Панель задач, вследствие чего она рано или поздно
переполняется значками, и переключение между задачами становится затруднительным.
Для того чтобы разгрузить Панель задач и освободить больше рабочего пространства для
отображения значков запущенных приложений, в Windows XP используется так
называемый алгоритм группировки задач, согласно которому однотипные программы,
работающие на компьютере одновременно, объединяются в логическую визуальную
группу.
В состав Windows XP включен специальный механизм - быстрое переключение
сеансов (Fast User Switching), с применением которого можно быстро, без регистрации
подключать к работе с операционной системой новых пользователей и групп
пользователей. Появилась также возможность переключаться между несколькими сеансами
работы без необходимости сохранять данные или перезагружать систему. При этом каждый
из пользователей может самостоятельно изменять настройки Windows и работать с
собственными файлами и документами, создавать, изменять и сохранять какие-либо
данные независимо от других пользователей Windows XP. Для каждого нового сеанса
работы операционная система отводит специальный участок верхней памяти в размере 2
Мбайт, однако этот объем никак не ограничивает количество прикладных программ,
которые могут быть запущены пользователем. В частности, механизм Fast User Switching
дает возможность пользователю, работающему, например, с текстовым редактором,
ненадолго отлучиться от компьютера, а во время его отсутствия другой пользователь
может открыть собственный сеанс Windows и поработать в Интернете или загрузить игру.
При этом текст, редактируемый отсутствующим пользователем, по-прежнему хранится в
памяти: вернувшись к компьютеру, пользователь может продолжить работу с документом с
того места, где она была прервана, не перезагружая систему и не запуская заново
соответствующую программу. На предварительной презентации бета-версии Microsoft
Whistler, состоявшейся 13 февраля 2001 года в Сиэтле, председатель правления корпорации
Microsoft Билл Гейтс сообщил прессе, что данная версия Windows, на создание и
тестирование которой затрачено свыше 1 млрд долларов США - важнейшая разработка
Microsoft с момента выпуска на рынок Windows 95, а вице-президент корпорации Джим
Оллчин добавил: "Windows XP - это не просто апгрейд Windows, это - апгрейд стиля
жизни".
Windows 7
Windows 7 (ранее известная под кодовыми названиями Blackcomb и Vienna) — версия
компьютерной операционной системы семейства Windows NT, следующая за Windows
Vista. В линейке Windows NT система носит номер версии 6.1 (Windows 2000 — 5.0,
Windows XP — 5.1, Windows Server 2003 — 5.2, Windows Vista и Windows Server 2008 —
6.0). Серверной версией является Windows Server 2008 R2.
Microsoft сделала заявление о том, что операционная система поступит в продажу 22
октября 2009 года, меньше, чем через три года после выпуска предыдущей операционной
системы, Windows Vista. Партнерам и клиентам, обладающим лицензией Volume
Licensing, доступ к RTM был предоставлен 24 июля 2009 года.
В состав Windows 7 вошли как некоторые разработки, исключенные из Windows Vista,
так и новшества в интерфейсе и встроенных программах.В Windows 7 будет функция
отключения или включения браузера Internet Explorer. Windows 7 будет обладать
поддержкой multitouch-мониторов. Эта возможность была продемонстрированаMicrosoft
на ежегодной конференции TechEd’08 в Орландо. В ходе демонстрации использовалась
сборка 6.1.6856, а также опытная модель ноутбука с multitouch-экраном. По некоторым
данным в Windows 7 будет частично реализован функционал, запланированный в Windows
Vista (имела кодовое имя «Longhorn»).Также планируется более тесная интеграция с
программами и сервисами Windows Live. В Windows 7 реализована более гибкая настройка
User Account Control (UAC), которая в отличии от Windows Vista имеет ещё два
промежуточных состояния между режимами «Включить» и «Выключить».Внесены
изменения в технологию шифрования BitLocker, и добавлена функция шифрования
съёмных носителей BitLocker to go позволяющая шифровать съёмные носители, причём
даже при отсутствии модуля TPM.Улучшения коснулись и брандмауэра Windows —
вернулась функция уведомления пользователя о блокировке программы, пытающийся
получить доступ к сети.Windows 7 не сможет воспроизводить лицензионные Blu-Ray
диски с видео, однако сможет считывать и записывать на них информацию.С помощью
групповой политики и функции AppLocker можно будет запретить запуск определенных
приложений.Функция Branch Cache позволит снизить задержки у пользователей,
работающих с компьютером удаленно. К примеру, файл доступный по сети, кэшируется
локально, поэтому он скачивается уже не с удаленного сервера, а с
локального компьютера. Эта функция может работать в двух режимах — Hosted Cache и
Distributed Cache. В первом случае — файл хранится на выделенном локальном сервере
под управлением Windows Server 2008 R2, во втором — на компьютере у клиента.Функция
DirectAccess позволяет устанавливать безопасное соединение с сервером в фоновом
режиме, в отличие от VPN, которому требуется участие пользователя. Также DirectAccess
может применять групповые политики до входа пользователя в систему.Remote Desktop
Host позволяет пользователю подключиться к удалённому компьютеру с правами
администратора.Microsoft рассматривает также возможность выпуска Windows 7 не только
на оптических дисках, но и на флеш-носителях, что должно упростить процесс установки
платформы на нетбуки, не имеющие встроенного привода для оптических носителей
Windows 7 также будет использовать sandbox-режим, внедрение которого
обсуждалось в ходе альфа и бета тестирования (на стадии разработки Longhorn). Весь
неуправляемый код будет запускаться в среде (песочнице), в которой операционная
система будет ограничивать доступ программы к аппаратной части компьютера и сети.
Доступ к низкоуровневым сокетам, равно как и прямой доступ к файловой системе,
уровню абстракции от оборудования (Hardware abstraction layer или HAL), полному
доступу к адресу памяти, будет запрещён. Весь доступ к внешним приложениям, файлам и
протоколам будет регулироваться операционной системой и немедленно пресекаться
(теоретически). Если этот подход окажется удачным, то он сулит почти полную
безопасность, так как при таком подходе вредоносной программе теоретически
невозможно причинить какой-либо ущерб системе, если она заблокирована внутри
метафорического «стеклянного ящика». Такой подход вызывает ассоциации с Virtual PC.
Если всё правильно, эта среда будет уметь приспосабливаться к базе кода, которая была
написана на его языке. Это снимет большинство проблем, которые возникают в результате
обратной совместимости при переходе к новой операционной системе.
При использовании приложений в Beta 1 были обнаружены утечки памяти в
некоторых приложениях, которые приводили к полному зависанию, несмотря на режим
песочницы. Теоретически, если режим не станет эффективнее, это может вызвать всплеск
развития программ, намеренно использующих эти уязвимости в своих целях.
Билл Гейтс упомянул повсеместно внедряемую строку мгновенного поиска (аналог
Spotlight). Служба индексирования содержимого развивалась начиная с Windows XP, а
похожая строка поиска была включена в Windows Vista. Также в Windows 7 используется
DirectX 11.
Получит ли Windows 7 новое ядро?
Нет. Хотя надо сказать, что подобные разработки велись. По крайней мере, так
заявлял один из инженеров Microsoft еще в октябре прошлого года. По его сообщению, 200
программистов компании работали над уменьшением ядра для Windows 7. Ядро даже
получило собственное название MinWin и должно было занимать в шесть раз меньше
памяти, чем ядро Vista.
Однако,Флорес и Синофски заявили, что Windows 7 не получит нового ядра.
“Вопреки некоторым спекуляциям, Microsoft не создает нового ядра для Windows 7”,
сказал Флорес. Впрочем, Синофски сказал несколько по-другому, “…ядро в Windows
Server 2008 является эволюцией ядра Windows Vista, а ядро Windows 7 будет дальнейшей
эволюцией этого ядра”.
Windows8
Внешний вид и новый интерфейс Metro
Основные нововведения
Учетная запись Майкрософт и синхронизация параметров: Возможность войти в
Windows с помощью Live ID. Это позволит войти в профиль пользователя и загрузить
настройки через интернет, а также добавляет интеграцию со SkyDrive.
3.
Логика развития и ключевые свойства версий ОС Windows Server 2003, Server
2008, Server 2012
Windows Server 2003
Windows Server 2003 (кодовое название при разработке — Whistler Server, внутренняя
версия — Windows NT 5.2) — операционная система семейства Windows NT от компании
Microsoft, предназначенная для работы на серверах. Она была выпущена 24 апреля 2003
года. Windows Server 2003 является развитием Windows 2000 Server и серверным
вариантом операционной системы Windows XP. Изначально Microsoft планировала назвать
этот продукт «Windows .NET Server» с целью продвижения своей новой платформы
Microsoft .NET. Однако впоследствии это название было отброшено, чтобы не вызвать
неправильное представление о .NET на рынке программного обеспечения. Windows Server
2008 — следующая серверная версия Windows NT, которая должна будет заменить
Windows Server 2003.Windows Server 2003 в основном развивает функции, заложенные в
предыдущей версии системы — Windows 2000 Server. На это указывало и версия NT 5.2
ядра системы (NT 5.0 для Windows 2000). Ниже приведены некоторые из наиболее
заметных изменений по сравнению с Windows 2000 Server. Windows Server 2003 — первая
из операционных систем Microsoft, которая поставляется с предустановленной оболочкой
.NET Framework. Это позволяет данной системе выступать в роли сервера приложений для
платформы Microsoft .NET без установки какого-либо дополнительного программного
обеспечения.В составе Windows Server 2003 распространяется версия 6.0 служб Internet
Information Services, архитектура которой существенно отличается от архитектуры служб
IIS 5.0, доступных в Windows 2000. В частности, для повышения стабильности стало
возможным изолировать приложения друг от друга в отдельных процессах без снижения
производительности. Также был создан новый драйвер HTTP.sys для обработки запросов
по протоколу HTTP. Этот драйвер работает в режиме ядра, в результате чего обработка
запросов ускоряется.
По заявлениям Microsoft, в Windows Server 2003 большое внимание было уделено
безопасности системы. В частности, система теперь устанавливается в максимально
ограниченном виде, без каких-либо дополнительных служб, что уменьшает поверхность
атаки. В Windows Server 2003 также включён программный межсетевой экран Internet
Connection Firewall. Впоследствии к системе был выпущен пакет обновления, который
полностью сосредоточен на повышении безопасности системы и включает несколько
дополнительных функций для защиты от атак. Согласно американскому стандарту
безопасности Trusted Computer System Evaluation Criteria (TCSEC) система Windows Server
2003 относится к классу безопасности C2 — Controlled Access ProtectionВ Windows Server
2003 впервые появилась служба теневого копирования тома (англ. Volume Shadow Copy
Service), которая автоматически сохраняет старые версии пользовательских файлов,
позволяя при необходимости вернуться к предыдущей версии того или иного документа.
Работа с теневыми копиями возможна только при установленном «клиенте теневых
копий» на ПК пользователя, документы которого необходимо восстановить.Также в
данной версии системы был расширен набор утилит администрирования, вызываемых из
командной строки, что упрощает автоматизацию управления системой.Введено новое
понятие — «роли», на них основано управление сервером. Проще говоря, чтобы получить
файл-сервер, необходимо добавить роль — «файл-сервер».
Windows Server 2008
Microsoft Windows Server 2008 (кодовое имя «Longhorn Server») — новая версия
серверной операционной системы от Microsoft. Эта версия должна стать заменой Windows
Server 2003 как представитель операционных систем поколения Vista (NT 6.x).
Windows Server 2008 включает вариант установки называемый Server Core (русск.
Установка ядра сервера). Server Core — это существенно облегченная установка Windows
Server 2008 в которую не включена оболочка Windows Explorer. Вся настройка и
обслуживание выполняется при помощи интерфейса командной строки Windows, или
подключением к серверу удалённо посредством Консоли управления. При этом доступны
Блокнот и некоторые элементы панели управления, к примеру, Региональные Настройки.
В Windows Server 2008 произошло значительное обновление Служб Терминалов
(Terminal Services). Службы Терминалов теперь поддерживают Remote Desktop Protocol
6.0. Самое заметное усовершенствование, названное Terminal Services RemoteApp,
позволяет опубликовать одно конкретное приложение, вместо всего рабочего стола.
Другая важная особенность, добавленная в Службы Терминалов — Terminal Services
Gateway и Terminal Services Web Access (теперь полностью через web-интерфейс).
Terminal Services Gateway позволяет авторизованным компьютерам безопасно
подключаться к Службам Терминалов или Удаленному Рабочему Столу из интернета
используя RDP через HTTPS без использования VPN. Для этого не требуется открывать
дополнительный порт на межсетевом экране; трафик RDP туннелируется через HTTPS.
Terminal Services Web Access позволяет администраторам обеспечивать доступ к службам
терминалов через Web-интерфейс. При использовании TS Gateway и TS RemoteApp,
передача данных происходит через HTTP(S) и удаленные приложения выглядят для
пользователя так, как будто они запущены локально. Несколько приложений запускаются
через один сеанс чтобы гарантировать отсутствие потребности в дополнительных
лицензиях на пользователя.
Благодаря Terminal Services Easy Print администраторам больше нет необходимости
устанавливать какие-либо драйверы для принтеров на сервер. При этом Easy Print Driver
перенаправляет пользовательский интерфейс и все возможности исходного принтера.
Помимо этого, он улучшает производительность при передаче заданий на печать за счет
перевода заданий в формат XPS перед отправкой клиенту.
Windows Server 2008 первая операционная система Windows, выпущенная со
встроенным Windows PowerShell, расширяемой оболочкой с интерфейсом командной
строки и сопутствующим языком сценариев, разработанным Microsoft. Язык сценариев
PowerShell был разработан специально для выполнения административных задач, и может
заменить собой потребность в cmd.exe и Windows Script Host.
Самовосстанавливающаяся NTFS
Если в предыдущих версиях Windows операционная система обнаруживала ошибки в
файловой системе тома NTFS, она отмечала том как «грязный»; исправление ошибок на
томе не могло быть выполнено немедленно. С самовосстанавливающейся NTFS вместо
блокировки всего тома блокируются только поврежденные файлы/папки, остающиеся
недоступными на время исправления. Благодаря этому больше нет необходимости
перезагрузки сервера для исправления ошибок файловой системы.
Также операционная система теперь отображает информацию S.M.A.R.T. жестких
дисков чтобы помочь определить возможные сбои жёсткого диска. Впервые эта
возможность появилась в Windows Vista.
Server Manager это новое, основанное на ролях средство управления Windows Server
2008. Он является комбинацией Управление данным сервером и Мастер настройки
безопасности из Windows Server 2003. Server Manager является улучшенным диалогом
Мастер настройки сервера который запускался по умолчанию в Windows Server 2003 при
входе в систему. Теперь он позволяет не только добавлять новые роли, но ещё и
объединяет в себе все операции, которые пользователи могут выполнять на сервере, а
также обеспечивает консолидированное, выполненное
отображение текущего состояния каждой роли.
в
виде
единого
портала
На данный момент невозможно удаленное использование Server Manager, однако
запланированно создание клиентской версии.
4.
Общая архитектура Windows уровня ядра, состав и функции основных
компонентов.
DOS
приложения
Win16
приложения
защищенные
подситемы
среды
Win32
защищающие
интегрированные
подсистемы
(серверы)
Системные
службы
Win32
приложения
Службы
сервера
OS/2
приложения
POSIX
приложения
OS/2
POSIX
Служба
рабочей
станции
Безопасность
Active
directory
Системный интерфейс NTDLL.DLL
Кольцо 3
NT Executive
GDI
Менеджер Менеджер Менеджер Менеджер Менеджер Менеджер
Драйвер
виртуальной процессов
IPC
PnP
безопасности управления
памяти
питанием графического
устройства
Менеджер объектов
Микроядро
Подсистема
ввода-вывода
Файловые системы
HAL
Аппаратная часть
Менеджер КЭШа
Драйверы устройств
Кольцо 0
1. Режим ядра — это привилегированный режим работы, в котором код получает
прямой доступ ко всем аппаратным ресурсам и всей памяти, включая адресные
пространства всех процессов режима пользователя. Функциональные возможности
компонентов режима ядра включают:
— прямой доступ к оборудованию;
— прямой доступ ко всем видам памяти компьютера;
— возможность работы без передачи на жесткий диск в файл подкачки виртуальной
памяти;
— более высокий приоритет исполнения, чем процессы режима пользователя.
Компоненты режима ядра структурированы по функциям. Основную работу по
управлению объектами выполняет система Windows NT (Windows NT Executive).
NT Executive управляет объектами, операциями ввода – вывода. Имеются менеджеры,
каждый из которых представляет собой набор внешних подпрограмм для взаимодействия с
другими процедурами и экспортирует процедуры, поддерживающие взаимодействие с
ядром.
Менеджер объектов — управляет основными системными объектами, такими как
пространство имён, совместно используемые ресурсы, объекты пользователя, объекты,
обеспечивающие контроль доступа к ресурсу.
Менеджер IPC — менеджер межпроцессорного взаимодействия, в основе работы
которого лежит механизм передачи сообщений. Существуют два типа компонентов: LPC и
RPC – локальный и удалённый вызовы процедур соответственно. Менеджер IPC может
преобразовывать RPC в LPC, если и клиентская и серверная части находятся на одной
машине.
Менеджер виртуальной памяти (VMM) — выполняет операции с памятью, формирует
виртуальное адресное пространство процессов, реализует разделяемые области памяти,
управляет подкачкой страниц, файлами подкачки и т.п.
Менеджер процессов – создаёт и завершает процессы и потоки, приостанавливает,
возобновляет и управляет дескрипторами.
Менеджер PnP — централизованно управляет процессами Plug-and-Play, обеспечивает
распознавание устройств — для этого «заставляет» драйверы шин проводить энумерацию,
конфигурирование, запуск устройств. Служит средством связи между драйверами, HAL,
NT Executive. Взаимодействует с PnP-частью прикладного уровня.
Монитор безопасности — устанавливает правила защиты на локальном компьютере,
выполняет регистрацию и защиту исполняемых объектов, формирует маркер доступа,
который наследуется от родителя.
Менеджер управления питанием — в BIOS необходимо включить поддержку ACPI
для работы (Advanced Configuration Power Interface) — продвинутый интерфейс
конфигурирования питания. Он включает в себя четыре режима потребления энергии для
устройств и шесть режимов для системы. Переход в эти состояния возможен, если все
драйверы поддерживают эти режимы. Менеджер управляет API — интерфейсами питания,
координирует события питания, генерирует возвратный пакет питания (IRP).
Оконный менеджер и интерфейс графического устройства (GDI) — управляет
системой отображения на экране и принтере.
Подсистема ввода-вывода включает:
— Менеджер ввода-вывода — предоставляет службы ядра драйверам устройств,
преобразует команды чтения/записи в возвратные пакеты запросов ввода-вывода IRP
(Input/Output Request Pockets). Возможность асинхронного ввода-вывода позволяет
приложению продолжать выполняться, не дожидаясь ответа на запрос.
— Менеджер файловой системы — работает с драйвером файловой системы FSD (File
System Driver), который поддерживает различные типы файловых систем (FAT12, FAT16,
FAT32, NTFS, HPFS, CDFS…) Драйверы принимают файл-ориентированные запросы и
транслируют их в аппаратно-зависимые вызовы.
— Сетевой редиректор и сетевой сервер.
— Менеджер КЭШа — производит кэширование дисковых операций. Кэширование
выполняется для всех файловых систем однотипно.
Драйверы устройств — драйверы низкого уровня, обращаются к оборудованию на
физическом уровне.
Исполнительная система основывается на системах микроядра. Микроядро выполняет
планирование процессов и потоков, обработку прерываний и исключительных ситуаций,
синхронизацию процессоров, восстановление системы после сбоев, отложенный вызов
процедур. В отличие от остальной исполняемой части операционной системы, ядро
никогда не выгружается из оперативной памяти, его выполнение никогда не прерывается
другими потоками. Код ядра написан в основном на Си, а части, дающие наибольшую
нагрузку на процессор, на языке Ассемблера. Микроядро реализует полный механизм
переключения контекста, сохраняет КЭШ, настраивает карту памяти нового потока и
загружает его регистры.
Ядро предоставляет поддержку двух специальных классов объектов: управляющие
объекты и объекты диспетчеризации. Система строит объекты пользователя на основе этих
объектов. Назначение ядра – сделать основную часть ОС независимой от оборудования.
Микроядро вместе с HAL обеспечивают переносимость системы, независимость от
оборудования. HAL (Hardware Abstraction Layer) — слой абстракции от оборудования
изолирует ядро, драйверы устройств и исполняемую часть NT от аппаратных платформ, на
которых должна работать операционная система. Этот программный слой позволяет
скрыть особенности аппаратных платформ, предоставив ОС стандартные точки входа в
процедуры, благодаря чему для нее исчезают различия между платформами и
архитектурами. Поэтому ОС может функционировать на разных платформах с разными
процессорами. HAL имеет вызовы для связывания процедур обработки прерываний с
вектором прерывания.
5.
Общая архитектура Windows прикладного уровня. Свойства API Win32.
Самая важная подсистема среды в Windows NT - это подсистема среды Win32
(рассматриваемая ниже), которая предоставляет прикладным программам интерфейс API
32-разрядной Windows. В Windows NT также имеются подсистемы среды: POSIX, OS/2 и
виртуальная DOS машина (virtual DOS machine, VDM), эмулирующая 16-разрядную
Windows и MS-DOS.
Данные подсистемы предоставляют свои API, но используют для получения
пользовательского ввода и отображения результатов подсистему Win32, то есть
перенаправляют видеовывод своих приложений подсистеме Win32 для отображения.
Подсистема среды Win32
Подсистема среды Win32 делится на серверный процесс (csrss.exe - Client/Server
Runtime Subsystem) и клиентские DLLs (user32.dll, gdi32.dll, kerneI32.dll), которые связаны
с программой, использующей Win32 API.
Win32 API разделен на три категории:
Управление
окнами (windowing) и передача сообщений (messaging). Эти интерфейсы
оконных процедур и процедур сообщений включают, например, такие функции, как
CreateWindow(), SendMessage(), и предоставляются прикладной программе через
библиотеку user32.dll.
Рисование
(drawing). Например, функции BitBitQ и LineTo() являются Win32функциями рисования и предоставляются библиотекой gdi32.dll.
Базовые
сервисы. Базовые сервисы включают весь ввод/вывод %т32, управление
процессами и потоками, управление памятью, синхронизацию и предоставляются
библиотекой kernel32.dll.
Когда Win32-приложение вызывает функцию API Win32, управление передается
одной из клиентских DLLs подсистемы Win32. Эта DLL может:
Выполнить
функцию самостоятельно без обращения к системным сервисам ОС и
вернуть управление вызывающей программе.
Послать
сообщение Win32-cepвepy для обработки запроса в том случае, если сервер
должен участвовать в выполнении заданной функции. Так, функция CreateProcess(),
экспортируемая библиотекой kernel32.dll, требует взаимодействия с Win32-cepBepOM,
который, в свою очередь, вызывает функции «родного» API.
Вовлечь
«родной» интерфейс API для выполнения заданной функции.
Последний вариант встречается наиболее часто. В версиях Windows NT ниже 4.0
функции окон (windowing) и рисования (drawing) были расположены в Win32-сервере
(csrss.exe). Это означало, что, когда приложение использовало такие функции, посылались
сообщения указанному серверу. В версии 4.0 эти функции были перенесены в компонент
режима ядра, называемый win32k.sys. Теперь вместо того, чтобы посылать сообщение
серверу, клиентская DLL обращается к этому компоненту ядра, уменьшая затраты на
создание сообщений и переключение контекстов потоков различных процессов. Это
увеличило производительность графического ввода/вывода. Библиотеки gdi32.dll и
user32.dll стали вторым «родным» API, но оно менее загадочно, чем первое, так как
хорошо документировано.
Функциями библиотеки kernel32.dll, вызывающими «родной» интерфейс API
напрямую, являются функции ввода/вывода, синхронизации и управления памятью.
Фактически, большинство экспортируемых библиотекой kerael32.dll функций используют
«родной» API напрямую. На рис. 3 иллюстрируется передача управления от Win32приложения, выполнившего вызов Win32-функции CreateFile(), библиотеке kernel32.dll,
затем функции NtCreateFile() в ntdll.dll и далее режиму ядра, где управление передается
системному сервису, реализующему создание/открытие файла. Подробнее вызов
системных сервисов рассматривается в следующем параграфе.
Рис. 3. Вызов системных сервисов через "родной" API. (ntdll.dll)
2. Режим пользователя — менее привилегированный по сравнению с режимом ядра
работы процессора. Компоненты режима пользователя:
— не имеют прямого доступа к аппаратуре. Это сделано в целях защиты от неверно
работающих приложений или от несанкционированного доступа. Запросы на
использование аппаратных ресурсов должны быть разрешены компонентом режима ядра;
— ограничены размерами выделенного адресного пространства, что позволяет
обеспечить дополнительную защиту ОС. Системные службы он вызывает через
интерфейсы прикладных программ (Application Program Interface — API);
— могут быть выгружены из физической памяти в виртуальную память на жестком
диске. Виртуальная память (virtual memory, VRAM) использует пространство на жестком
диске как дополнительную оперативную память;
— приоритет процесса пользовательского типа ниже, чем у процессов режима ядра.
Поэтому ему, как правило, предоставляется меньше процессорного времени. Это
предохраняет ОС от снижения производительности или возникновения задержек,
связанных с ожиданием завершения работы приложений.
Компоненты пользовательского режима принято называть защищенными
подсистемами, так как они формируют определенную операционную среду для
приложений. Защищенные подсистемы работают в защищенном адресном пространстве и
обмениваются сообщениями.
Подсистемы принято делить на внутренние и внешние:
1. Внутренние (интегральные) подсистемы — исполняют задачи самой операционной
системы. Включают в себя множество системных процессов — сервисов или служб.
Подсистема безопасности:
— принимают запросы аутентификации пользователя;
— проверка подлинности входа в систему;
— отвечают за аудит в системных ресурсах.
Служба сервера — внутренняя сетевая подсистема, предоставляющая интерфейс IP
для доступа к сетевому серверу. Служба рабочей станции предоставляет IP доступа к
редиректору.
2. Внешние подсистемы среды (окружения) — реализуют соответствующие
интерфейсы приложений. Важнейшая система — Win32.
Функции защищенных подсистем:
1. Обеспечение нескольких программных интерфейсов API.
2. Изолирование базовой ОС от изменений или расширений API.
3. Защита окружения API от прикладных программ и других окружений.
Объектный принцип в организации Windows. Свойства объектов процессов и
потоков.
Единообразная форма именования, совместного использования и учета системных
ресурсов, простой и дешевый способ обеспечения безопасности системы и ее
модификации - все эти преимущества могут быть достигнуты при использовании
объектной модели.
6.
В Windows NT любой ресурс системы, который одновременно может быть
использован более чем одним процессом, реализуется в виде объекта и управляется рядом
функций. Такой подход сокращает число изменений, которые необходимо внести в
операционную систему в процессе ее эксплуатации.
Наиболее фундаментальное отличие между объектом и обыкновенной структурой
данных заключается в том, что внутренняя структура данных объекта скрыта от
наблюдения. Пользователь не может непосредственно изменять данные, находящиеся
внутри объекта. Это отделяет средства реализации объекта от кода, который только
использует его, такая техника позволяет легко изменять в последствии реализацию
объектов.
Не все структуры данных в NT executive являются объектами. В виде объектов
описаны только такие данные, которые нужно разделять, защищать, именовать или делать
видимыми для программ пользовательского режима (с помощью системных функций).
Структуры, которые используются только одним компонентом executive для выполнения
внутренних функций, не являются объектами.
Для реализации объектного подхода основанием служит управление и защита
ресурсов. Объекты – описание ресурсов, объединяют данные и процедуры, методы
управления. Доступ осуществляется через назначенные входы данных. Объекты должны
иметь описание в виде дескрипторов.
Менеджер объектов – это компонент NT executive, который ответственен за создание,
удаление, защиту и слежение за объектами. Менеджер объектов централизует операции
управления ресурсами. Менеджер объектов выполняет следующие функции:
1. Выделяет память для объекта.
2. Формирует для объекта дескриптор безопасности, который определяет, кому
разрешено использовать объект, и что они могут с ним делать.
3. Создает и манипулирует структурой каталога объектов, в котором хранятся имена
объектов.
4. Создает дескриптор объекта и возвращает его вызывающему процессу.
Объекты имеют тип, каждый менеджер получает доступ к объектам только своего
типа. Тип определяет данные, которые хранит объект, и системные функции, которые
могут к нему применяться.
Каждый объект состоит из двух частей – заголовка объекта и тела объекта, которые
содержат стандартные и переменные данные объекта соответственно. Менеджер объектов
работает с заголовком объекта. Заголовок объекта используется менеджером без учета
типа объекта. В заголовке объекта любого типа содержится имя, каталог, дескриптор
безопасности, квоты на использование ресурсов, счетчик открытых описателей
(дескрипторов), база данных открытых описателей, признак постоянный/временный,
режим пользователя/ядра, указатель на тип объекта.
Кроме заголовка объекта, каждый объект имеет тело объекта, формат и содержание
которого уникально определяется типом этого объекта; у всех объектов одного и того же
типа одинаковый формат тела. При создании объекта исполнительная часть может
оперировать данными в телах всех объектов этого типа.
В разных ОС процессы реализуются по-разному. Эти различия заключаются в том,
какими структурами данных представлены процессы, как они именуются, какими
способами защищены друг от друга и какие отношения существуют между ними. В
Windows NT процесс - это просто объект, создаваемый и уничтожаемый менеджером
объектов. Объект-процесс, как и другие объекты, содержит заголовок, который создает и
инициализирует менеджер объектов. Менеджер процессов определяет атрибуты, хранимые
в теле объекта-процесса, а также обеспечивает системный сервис, который
восстанавливает и изменяет эти атрибуты. Свойства процесса (тело объекта):
1. Идентификатор процесса - уникальное значение, которое идентифицирует процесс
в рамках операционной системы.
2. Токен доступа (маркер) - исполняемый объект, содержащий информацию о
безопасности.
3. Базовый приоритет - основа для исполнительного приоритета нитей процесса.
4. Процессорная совместимость - набор процессоров, на которых могут выполняться
потоки процесса.
5. Предельные значения квот - максимальное количество страничной и нестраничной
системной памяти, дискового пространства, предназначенного для выгрузки страниц,
процессорного времени - которые могут быть использованы процессами пользователя.
6. Время исполнения - общее количество времени, в течение которого выполняются
все потоки процесса.
Потоки также оформляются как объекты, процесс порождает как минимум один
поток. Объект-поток имеет следующие атрибуты тела:
1. Идентификатор клиента - уникальное значение, которое идентифицирует поток при
его обращении к серверу.
2. Контекст нити - информация, которая необходима ОС для того, чтобы продолжить
выполнение прерванного потока. Контекст потока содержит текущее состояние регистров,
стеков и индивидуальной области памяти, которая используется подсистемами и
библиотеками. Переключается по кванту времени.
3. Динамический приоритет - значение приоритета потока в данный момент.
4. Базовый приоритет - нижний предел динамического приоритета потока.
5. Процессорная совместимость потоков - перечень типов процессоров, на которых
может выполняться поток.
6. Время выполнения потока - суммарное время выполнения потока в
пользовательском режиме и в режиме ядра, накопленное за период существования потока.
6. Состояние предупреждения - флаг, который показывает, что поток должен ждать
вызов асинхронной процедуры.
7. Счетчик приостановок потока - текущее количество приостановок выполнения
потока.
Кроме перечисленных, имеются и некоторые другие атрибуты.
Как видно из перечня, многие атрибуты объекта-нити аналогичны атрибутам объектапроцесса. Весьма сходны и сервисные функции, которые могут быть выполнены над
объектами-процессами и объектами-нитями: создание, открытие, завершение,
приостановка, запрос и установка информации, запрос и установка контекста и другие
функции.
Состояния потоков:
1. Готовность.
2. Первоочередная готовность (standby). Первый в очереди к каждому процессору.
3. Выполнение.
4. Блокировка или ожидание.
5. Приостановка.
6. Завершение.
7.
Управление процессами и диспетчеризация Windows.
Используются динамические приоритеты. При порождении процессу присваивается
базовый приоритет. Поток наследует приоритет, но может немного изменить его.
Возникает приоритет планирования (для процессов реального времени 31-16, для
процессов разделенного времени 15-0). В Windows определены четыре класса
приоритетов:
_IDLE_PRIORITY_CLASS=4;
_NORMAL__PRIORITY_CLASS=
8;
_HIGH__PRIORITY_CLASS=13; _REALTIME_PRIORITY_CLASS=24.
После истечения кванта времени приоритет потока понижается на 1. Если поток
освобождает ресурсы, то приоритет повышается на 1. Поток освобождает процессор, когда
кончается квант времени, поток завершается сам или вытесняется более приоритетным.
Используется система абсолютных приоритетов, то есть если в очереди готовых процессов
появляется более приоритетный, то происходит смена потоков.
В Windows реализована подсистема вытесняющего планирования на основе уровней
приоритета, в которой всегда выполняется поток с наибольшим приоритетом, готовый к
выполнению.
Диспетчеризация потоков может быть вызвана любым из следующих событий.
Поток готов к выполнению — например, он только что создан или вышел из
состояния ожидания.
Поток выходит из состояния Running (выполняется), так как его квант истек или
поток завершается либо переходит в состояние ожидания
Приоритет потока изменяется в результате вызова системного сервиса или самой
Windows.
Изменяется привязка к процессорам, из-за чего поток больше не может работать на
процессоре, на котором он выполнялся.
В любом случае Windows должна определить, какой поток выполнять следующим.
Выбрав новый поток, Windows переключает контекст. Эта операция заключается в
сохранении параметров состояния машины, связанных с выполняемым потоком, и загрузке
аналогичных параметров для другого потока, после чего начинается выполнение нового
потока.
8.
Принцип установки и удаления приложений. Проблемы зависимостей
установленных приложений и системы и способы их преодоления. Инсталлятор
MSI.
установка приложения:
1. сбор информации
2. установка
3. возможность отката
типовые действия при установке:
1. проверка возможности установка версия ос, аппаратная часть
2. лицензия
3. выбор осстава компонентов
4. разархивирование, перенос файлов в каталоги
изменения, вносимые установщиком:
1. добавление каталога в programFiles, dll в system32, шрифтов, справочных файлов
2.создание параметров конфигурации, реестр или ini файлы
3. меняют свойства реестра, добавление ключей на удаление программы
4. регирстрация в ситсеме OLE – ассоциация файлов с обработчиками
5. установка в интерфейсе – добавление ярлыков, раб стол, пуск
6. настройка автозапуска – в реестре, в каталоге, планировщик заданий, ini-файл
проблема зависимости приложений, влияние одного на другие – решение проблемы:
создание отдельных, изолированных программ от общей системы (песочница). Это
называется виртуализация приложений APP-V.
Расширение MSI – это файл, который обычно связан с сервисом установщика
Microsoft Windows Installer, который является компонентом Windows, начиная с Windows
2000. *.MSI файл содержит установочный пакет для быстрой и безупречной установки на
платформе Windows. MSI файл может быть использован как сторонними разработчиками
для установки программного обеспечения, так и для обновления Windows. Эти файлы
содержат всю информацию, которая необходима установщику Windows для установки или
удаления приложения или продукта, и для конфигурации пользовательского интерфейса.
Каждый такой пакет установки включает в себя файл *.MSI, представляющий собой
составной документ OLE, содержащий установочную базу данных – набор из
взаимосвязанных таблиц, содержащих различную информацию о продукте и процессе
установки. Кроме базы, в .MSI файле можно помещать пользовательские сценарии
(написанные на JScript, VBScript или Eclipse) и вспомогательные DLL, если таковые
требуются для установки, а также сами устанавливаемые файлы, запакованные в формате
.CAB.
9.
Различия программных моделей DOS-, Win16-, Win32-приложений, особенности
их выполнения в Windows.
Установка и выполнение 32-разрядных программ.
Существует два типа установки:
1. Назначенные (assigned) пользователю приложения видны ему как ярлыки в
Главном меню или на Рабочем столе, а файлы соответствующих типов связаны с данным
приложением. Как только пользователь запустит программу через меню или откроет
соответствующий файл, приложение будет установлено на его компьютер. Назначенное
конкретному пользователю приложение доступно ему, на каком бы компьютере он ни
вошел в систему. Приложение может быть также назначено компьютеру — в этом случае
оно автоматически устанавливается при загрузке компьютера (если приложение будет
удалено, оно автоматически переустановится при следующем входе в систему).
2. Приложение может быть опубликовано (published). В данном варианте оно будет
установлено только тогда, когда пользователь сам выберет его из списка доступных
программ в нижней части окна Установка новых программ.
Для каждого 32-разрядного приложения используется отдельная адресная область в
пределах системной виртуальной машины. Приложения работают в режиме вытесняющей
многозадачности, для каждого приложения и для каждого создаваемого ими потока
используются отдельные очереди сообщений. Все это делает ошибку в 32-разрядных
приложениях фактически безопасной для остальных приложений.
Большинство 32-разрядных приложений хранят свою информацию в реестре.
Установка и выполнение 16-разрядных программ.
Для выполнения старых 16-разрядных программ в 32-разрядной операционной
системе Windows XP запускает специальную подсистему — виртуальную машину, —
которая имитирует защищенный режим 386 процессора и рабочую среду Windows 3.x.
Хотя в Windows XP действительно можно выполнять старые 16-разрядные программы,
существуют некоторые ограничения:
1. Большая часть 16-разрядных программ не работает с длинными именами файлов.
Windows XP поддерживает соответствие между длинными и короткими именами, поэтому
длинные имена сохраняются даже в том случае, если 16-разрядное приложение изменяет
файл и сохраняет его с коротким именем.
2. 16-разрядные приложения выполняются медленнее аналогичных 32-разрядных.
Старые программы ограничены одним потоком даже в многопоточной операционной
системе. А вызовы, выполняемые 16-разрядными приложениями, должны
преобразовываться в вызовы 32-разрядной операционной системы. Процесс
преобразования, называемый thunking, замедляет работу программы.
3. Некоторые 16-разрядные приложения требуют наличия 16-разрядных драйверов
устройств, которые не поддерживаются в Windows XP. Приложения, обращающиеся к
оборудованию напрямую, должны быть снабжены драйвером виртуальных устройств для
Windows XP и 32-разрядным драйвером устройства для Windows XP, иначе они не будут
выполняться.
4. Библиотеки динамической компоновки (DLL), предназначенные для 16-разрядных
приложений, не могут использоваться 32-разрядными, и наоборот. Поскольку программы
установки для большинства приложений устанавливают все библиотеки, нужные этим
приложениям, не будет заметно никаких отличий. Но при попытке запустить, например,
макрос для Microsoft Word 6 (16-разрядное приложение), обращающийся к библиотекам
этой программы, в Word 2002 макрос работать не будет, потому что это — 32-разрядное
приложение.
Многие 16-разрядные программы хранят свою информацию в файлах Win.ini и
System.ini, появившихся в Windows 3.x. Некоторые программы работают со своими
собственными файлами .ini. В Windows XP «остовы» таких файлов хранятся в папке
%SystemRoot%.
По умолчанию Windows XP рассматривает каждое 16-разрядное приложение как
поток в одной виртуальной машине. Несколько 16-разрядных приложений выполняются в
одном пространстве памяти, поэтому досрочное завершение одного из них приведет и к
завершению всех остальных. При этом вся несохраненная информация будет утеряна.
Установка и выполнение программ MS DOS.
Все программы, написанные для MS DOS, являются 16-разрядными. По этой причине
они выполняются в виртуальной машине вместе со своими 16-разрядными аналогами,
разработанными для Windows 3.x.
Для управления поведением программ MS DOS используется диалоговое окно
свойств. Настройки для программ хранятся отдельно, в файлах с расширением .pif
(Program Information File). Для одной программы можно создать несколько ярлыков (pifфайлов), в каждом из которых будут храниться свои собственные настройки (например,
рабочая папка или основной файл данных).
Pif-файлы имеют двоичный формат, поэтому их нельзя редактировать иначе как через
диалоговое окно Свойства. Любая программа MS DOS, работающая только в текстовом
режиме, может выполняться либо в полноэкранном режиме, либо в окне. Графические
программы работают только в полноэкранном режиме.
Для корректного выполнения некоторых программ MS DOS может потребоваться
изменение конфигурации виртуальной машины MS DOS. Для этого нужно
отредактировать два файла: Autoexec.nt и Config.nt, которые аналогичны файлам
Autoexec.bat и Config.sys в MS DOS и Windows 95/98 за несколькими отличиями:
1. В Windows XP файлы Autoexec.nt и Config.nt по умолчанию размещены в папке
%SystemRoot%\System32.
2. В Windows XP можно создавать специальные версии Autoexec.nt и Config.nt для
отдельных приложений. Чтобы создать для приложения специализированные файлы
конфигурации, необходимо скопировать основные файлы в другую папку и изменить их
так, как нужно. Затем в свойствах программы MS DOS используя кнопку Дополнительно
на вкладке Программа, можно ввести путь для действительного размещения файлов.
3. Команды из этих файлов влияют только на подсистему MS DOS. Многие команды,
такие как BUFFERS и BREAK, игнорируются, хотя их и можно добавить в том случае,
если какие-то программы требуют наличия этих команд. Windows самостоятельно
подключает свои версии драйверов himem.sys, ansi.sys, country.sys и setver.sys. Не следует
указывать в Config.nt устаревшие и неподдерживаемые драйверы MS DOS, такие как
emm386.exe, smartdrv.sys, ramdrive.sys, dbspace,sys/drvspace.sys. В файле Autoexec.nt
игнорируются все команды, за исключением SET и PATH, добавляющих переменные к
параметрам окружения виртуальной машины.
Виртуальная DOS-машина (Virtual DOS Machine – VDM). Windows XP размещает
каждое приложение MS DOS на собственной VDM. Для достижения наивысшего уровня
надежности системы, необходимого пользователям, Microsoft пришлось обеспечить каждое
приложение собственной средой, полностью отделенной от среды какого-нибудь другого
приложения. В отличие от Windows 9х, 16-разрядные приложения Windows XP используют
индивидуальные VDM. Windows XP всегда запускает VDM, а потом в ней – копию
16#разрядной Windows, чтобы обеспечить поддержку 16-разрядного приложения. В
результате в каждое взаимодействие добавляются два уровня: для VDM и для подсистемы
WIN32. Это дополнительное разбиение на уровни происходит незаметно для пользователя.
Вы продолжаете работать с тем же интерфейсом, что и раньше.
32-разрядные приложения операционной системы Windows. Windows XP имеет
возможность использовать разнообразные 32-разрядные программные приложения, часть
из которых не работает в Windows 9х, поскольку они опираются на применение каталога
Win32 (являющегося разделом интерфейса Windows API). 32-разрядные приложения
обычно характеризуются более гибким поведением в многозадачной среде, чем их 16разрядные аналоги. 32-разрядные приложения также обеспечивают поддержку двух
функций.
первая использует режим вытесняющей многозадачности. В частности, она позволяет
переключаться между задачами более естественно и использовать интервалы ожидания для
корректной инициализации;
вторая функция предполагает активное применение плоского адресного пространства
памяти, что позволяет более гибко выделять приложениям необходимые объемы памяти,
улучшая результаты выполнения приложений.
16-разрядные приложения Windows (Win16) поддерживаются специальным
приложением DOS, которое носит название "Windows-On- Windows" (WOW). WOW
выполняется в виртуальной машине DOS, которая сама запускается как процесс Win32. Все
это нужно для того, чтобы воспроизвести среду Windows 3.x, где помимо DOS работает и
Windows; благодаря такой системе приложения "думают", что они выполняются в среде
Win16. Все 16-разрядные приложения обрабатываются одним экземпляром WOW, в
отличие от приложений DOS, для каждого из которых создается своя виртуальная машина.
Можно, однако, сделать и так, чтобы приложения загружались каждое в своей среде WOW
- для этого нужно модифицировать их Program Information File (PIF) или указать
соответствующие параметры в строке Run (Выполнить) или в командной строке.
10. Базовые свойства командного языка Windows и его расширения. Смысл и
применение переменных окружения. Программирование командных файлов.
Командная оболочка — это отдельный программный продукт, который обеспечивает
прямую связь между пользователем и операционной системой. Текстовый
пользовательский интерфейс командной строки предоставляет среду, в которой
выполняются приложения и служебные программы с текстовым интерфейсом. В
командной оболочке программы выполняются, и результат выполнения отображается на
экране в виде, сходном с интерпретатором Command.com MS-DOS. Командная оболочка
Windows XP использует интерпретатор команд Cmd.exe, который загружает приложения и
направляет поток данных между приложениями, для перевода введенной команды в
понятный системе вид.
Имеется возможность использовать командную оболочку для создания и
редактирования пакетных файлов (также называемых сценариями), что позволит
автоматизировать выполнение обычных задач. Например, можно использовать сценарии
для автоматизации управления учетными записями пользователей и ежедневной
архивацией в нерабочие часы. Также можно использовать сервер сценариев Windows,
CScript.exe, для выполнения в командной оболочке сложных сценариев. Выполнение
операций с помощью пакетных файлов является более эффективным, чем с помощью
интерфейса пользователя. Пакетные файлы принимают все команды, доступные из
командной строки. Имеется возможность настроить окно командной строки для облегчения
просмотра и для увеличения контроля за выполнением программ.
Имеется возможность вкладывать командные оболочки в Cmd.exe, открывая новый
экземпляр Cmd.exe из командной строки. По умолчанию каждый экземпляр Cmd.exe
наследует среду своего родительского приложения Cmd.exe. Вложение экземпляров
Cmd.exe позволяет вносить в локальную среду изменения, которые не повлияют на
родительское приложение Cmd.exe. Это позволяет сохранять исходную среду Cmd.exe и
возвращаться к ней после удаления вложенной командной оболочки. Изменения вложенной
командной оболочки не сохраняются.
По своим функциям команды можно разделить на несколько групп: управление
файлами и каталогами, управление устройствами, управление процессами,
информационные команды ввода-вывода, команды программирования командных файлов,
другие.
1. Команды работы с каталогами и файлами
ATTRIB
Отображение и изменение атрибутов файлов
DEL
Удаление одного или нескольких файлов
COPY
Копирование одного или нескольких файлов в другое
место
MKDIR
Создание папки
CHDIR
Вывод имени либо смена текущей папки.
RMDIR
Удаление папки
DIR
Вывод списка файлов и подпапок из указанной папки
TYPE
Вывод на экран содержимого текстовых файлов
COMPACT
Отображение/изменение сжатия файлов в разделах
NTFS
FINDSTR
Поиск строк в файлах
FIND
Поиск текстовой строки в одном или нескольких файлах
FC
Сравнение двух файлов или двух наборов файлов и
вывод различий между ними
ERASE
Удаление одного или нескольких файлов
REPLACE
Замещение файлов
RENAME
Переименование файлов и папок
XCOPY
Копирование файлов и дерева папок
PRINT
Вывод на печать содержимого текстовых файлов
8.2 Команды управления работой с устройствами и процессами.
BREAK
Включение/выключение режима обработки комбинации
клавиш CTRL+C
CHKDSK
Проверка диска и вывод статистики
CHKNTFS
Отображение или изменение выполнения проверки
диска во время загрузки
CONVERT
Преобразование дисковых томов FAT в NTFS. Нельзя
выполнить преобразование текущего активного диска
DISKCOMP
Сравнение содержимого двух гибких дисков
FORMAT
Форматирование диска для работы с Windows
VERIFY
Установка режима проверки правильности записи
файлов на диск
VOL
Вывод метки и серийного номера тома для диска
FOR
Запуск указанной команды для каждого из файлов в
наборе
MORE
Последовательный вывод данных по частям размером в
один экран
COPY CON
Перенаправление потока ввода информации с консоли в
файл.
8.3 Информационные команды и команды реконфигурация.
MEM
Вывод сведений о полной и свободной системной
памяти
KEYB
Настройка клавиатуры на национальный алфавит
MODE
Отображение статуса и режима работы посимвольных
устройств. Команда выполняет множество функций, для
примера рассмотрим ее применение для поддержки кодовых
страниц. Конфигурирование системных устройств
SET
Установка значения глобальной переменной в
окружении DOS и отображение окружения
ECHO
Вывод сообщений и переключение режима отображения
команд на экране.
PROMPT
Задает формат приглашения DOS
PATH
Установка
и
отображение
маршрутов
поиска
исполняемых файлов
MORE
Последовательный вывод данных по частям размером в
один экран
VER
Отображение номера версии
DATE
Установка и отображение соответственно даты
TIME
Установка и отображение соответственно времени
8.4 Команды, используемые для программирования пакетных файлов
PAUSE
Приостановка выполнения пакетного файла и вывод
сообщения
CALL
Вызов одного пакетного файла из другого
ENDLOCAL
Конец локальных изменений среды для пакетного файла
GOTO
Передача управления в отмеченную строку пакетного
файла
IF
REM
SETLOCAL
SHIFT
Оператор условного выполнения команд в пакетном
файле
Помещение комментариев в пакетные файлы и файл
CONFIG.SYS
Начало локальных изменений среды для пакетного
файла
Изменение
содержимого
(сдвиг)
подставляемых
параметров для пакетного файла
Использование переменных среды в командной оболочке.
Среда командной оболочки Cmd.exe определяется переменными, задающими
поведение командной оболочки и операционной системы. Имеется возможность
определить поведение среды командной оболочки или среды всей операционной системы с
помощью двух типов переменных среды: системных и локальных. Системные переменные
среды определяют поведение глобальной среды операционной системы. Локальные
переменные среды определяют поведение среды в данном экземпляре Cmd.exe.
Системные переменные среды заданы заранее в операционной системе и доступны для
всех процессов Windows XP. Только пользователи с привилегиями администратора могут
изменять эти переменные. Эти переменные наиболее часто используются в сценариях
входа в систему.
Добавление параметров при запуске командного фалйа. Для решения этой задачи
предусмотрен механизм обработки параметров. Работает он довольно просто. Если при
запуске командного файла пользователь указал несколько параметров, то в тексте
командного файла первый из них мы обозначаем записью %1, второй записью %2, третий
записью %3 и т.д.
Команда if позволяет выделять в командном файле группы команд, которые
выполняются или не выполняются в зависимости от определенных условий. Для чего это
нужно? Проверка условия — почти необходимая мера при создании командных файлов,
использующих параметры. Перед тем, как начинать работу, командный файл, вообще
говоря, должен удостовериться в том, что ему передан корректный набор параметров. В
противном случае велик риск, что он выполнится неверно или безрезультатно, а
пользователю останется только гадать, в чем же проблема. Более того, если командный
файл удаляет, перемещает или перезаписывает какие-либо данные, то при некорректных
параметрах он может даже нанести ущерб.
Существует возможность вызвать из одного командного файла другой командный
файл. Для этого служит команда call. Замечательно, переменные, заданные в вызывающем
командном файле «видны» вызванному. И наоборот, после того, как вызванный файл
закончит работу и вернет управление вызвавшему, последний будет «видеть» переменные,
оставленные ему вызванным «в наследство». Это позволяет разработчику командных
файлов действовать, например, следующим образом. Если несколько командных файлов
должны пользоваться одними и теми же значениями, допустим, путями к каким-то файлам,
их можно вынести в отдельный командный файл, который будет играть роль
конфигурационного файла. Каждый рабочий командный файл будет начинаться вызовом
конфигурационного. Выигрыш в том, что при изменении путей вносить изменения
придется только в один конфигурационный файл, а не во множество рабочих.
11. Средства обмена данными между приложениями в Windows. Базовые понятия
OLE, особенности применения связывания и внедрения объектов. Роль
технологии OLE во внутренних механизмах Windows.
Система Windows поддерживает два различных типа обмена данными - статический и
динамический. Статический обмен может быть выполнен с помощью буфера обмена.
Динамический обмен данными основан на связывании и внедрении объектов (OLEтехнологии).
1.2 Статический обмен данными
Форматы файлов:
1. системные: тестк, DDB (битовый формат зависимый оту устройства), DIB
(независимый), метафайл
2. программные – програма может зарегистрировать свой тип данных
Во время своей работы операционная система (OC) Windows выделяет специальную
область памяти — буфер обмена (Clipboard). Он используется для обмена данными между
приложениями и документами. Роль данных могут играть фрагмент текста или весь текст,
рисунок, таблица и т. п. Буфер обмена — это простейшее, но очень эффективное средство
интеграции приложений. В ОС Windows через буфер обмена можно перемещать папки с
файлами и отдельные файлы.
Существует следующий принцип работы с буфером обмена: с помощью инструментальных средств конкретного приложения можно выделить определенный фрагмент
обрабатываемого документа (т. е. участок текста, изображение, таблицу) и поместить его
на хранение (записать) в буфер обмена. Записанный в буфере фрагмент можно вставить
либо в другое место того же документа, либо в другой документ того же приложения, либо
в документ другого приложения. Например, можно переместить картинку (или фрагмент
картинки), нарисованную вами в графическом редакторе, в любое место документа Word
или Excel. Записанный фрагмент сохраняется в буфере до тех пор, пока не дана команда
поместить в буфер другую порцию данных: в этом случае прежнее содержимое буфера
теряется безвозвратно, оно замещается новой информацией. Если такая информация не
поступила, фрагмент сохраняется в буфере до окончания сеанса работы Windows. Запуск и
завершение программ сами по себе на содержимое буфера никак не влияют. Один и тот же
фрагмент можно вставлять в документы несколько раз: при вставке содержимое буфера
обмена не меняется.
Работа с буфером обмена. Во всех приложениях Windows, допускающих
использование
буфера
обмена,
схема
работы
с
ним
стандартизована.
Следует помнить, что буфер обмена одинаково бесстрастно принимает на хранение и один
символ, и графический фрагмент объемом до нескольких мегабайт. Однако в последнем
случае производительность компьютера может снизиться, — поэтому не следует оставлять
в буфере слишком массивные части информации, которые вам уже не понадобятся. После
использования такой информации лучше очистить буфер, послав в него, например любой
текстовый символ. Кратко рассмотрим операции: Вырезать, Копировать и Вставить.
1.2. Динамический обмен данными (DDE)
DDE – это разработанный Microsoft набор специальных соглашений (протокол) об обмене данными
между приложениями
Windows. В самом начале развития
персонального компьютера, когда объем памяти на внешнем запоминающем устройстве
был мал и дорог, при помощи DDE решали проблему недостатка свободного места на
диске. Так как связываемый документ хранится в виде файла только в одном месте, то при
связывании свободное место используется эффективно. Попытаемся пояснить суть этого
метода связывания на простом примере. Допустим, требуется составить документ,
содержащий сведения о различных программных и аппаратных продуктах (как минимум,
краткое описание и цена). Очевидно, что подготовить данный документ необходимо с
помощью текстового редактора, например Word. Представим, что подлежащие внесению в
документ сведения о продуктах и их ценах уже существуют в базе данных, которая
управляется некоторым Windows-приложением, например Access. Для ускорения процесса
подготовки документа разумно по уже известной методике передать необходимые
сведения из базы данных в буфер обмена (Clipboard). Однако вполне возможно, что через
некоторое время цены изменятся. При старой методике (через буфер) это приведет к необходимости подготовить документ заново. Использование DDE-метода позволяет избежать
этого, так как обеспечивает динамический обмен данными и обновление их в
подготавливаемом документе по мере их изменения в источнике. При таких условиях
«выходной» документ всегда будет «первой свежести». Каким же образом происходит
актуализация (динамическое обновление данных в выходном документе)? Разберемся
сначала с происхождением обновляемых данных. Они находятся в документе-источнике и
хранятся там приложением-источником. Сохранение документа источника и лежит в
основе функционирования DDE-метода. Из сохраненного документа-источника требуемые
сведения копируются через Clipboard в выходной документ. Процедура этого копирования
нам знакома. Особенность состоит в том, что DDE-метод устанавливает между
источником и копиями некоторую связь. И связь эта обеспечивает автоматическое (или по
требованию) обновление копии по мере появления изменений в источнике. Многие
Windows-приложения поддерживают методику DDE как для создания источников
связывания, так и для восприятия динамически обновляемых данных. Но при
практическом применении DDE-метода следует учитывать ряд требований.
Первое и наиболее важное состоит в том, что приложения, подлежащие связыванию,
должны поддерживать DDE-метод. Важным является также определение, в каком качестве
данное приложение будет существовать в DDE: в качестве источника или приемника. Не
все приложения можно использовать в обоих качествах. Данные, являющиеся источником
в DDE-операциях, должны быть обязательно сохранены, так как связь осуществляется
непосредственно через файлы документов. Рассмотрим способ актуализации без открытия
окна.
Если файл-источник поврежден или перемещен, то связь нарушается и для её
восстановления необходимо заново создавать все ссылки. Сейчас DDE вытеснено более
новой технологией OLE, которая широко используется в Windows приложениях (об OLE
речь пойдет в следующей главе). Однако все же в ряде случаев DDE применяется.
Глава 2. Технология OLE
Технология OLE (Object Linking and Embedding) ― технология управления и обмена
информацией между программным интерфейсом других приложений. Связывание и
внедрение объектов (Object Linking and Embedding).
При использовании OLE в обмене информацией участвуют два приложения приложение-сервер и приложение-клиент.
Связывание и внедрение
OLE-объекты могут связываться с приложениями клиента или внедряться в них. OLEсвязанный объект подключается к отдельному файлу. Управление появлением OLEобъекта в приложении-клиенте осуществляется на основе информации, хранящейся во
внешнем файле. Когда этот внешний файл изменяется в серверном приложении, OLEобъект соответствующим образом обновляется. Внедренный OLE-объект полностью
содержится в файле приложения-клиента, поэтому он не связан с внешним файлом.
OLE серверы и клиенты взаимодействуют с системными библиотеками при помощи
таблиц виртуальных функций (англ. virtual function tables, VTBL). Эти таблицы содержат
указатели на функции, которые системная библиотека может использовать для
взаимодействия с сервером или клиентом. Библиотеки OLESVR.DLL (на сервере) и
OLECLI.DLL (на клиенте) первоначально были разработаны для взаимодействия между
собой с помощью сообщения WM_DDE_EXECUTE, предоставляемого операционной
системой.
OLE 1.1 позднее развился в архитектуру COM (component object model) для работы с
компонентами программного обеспечения. Позднее архитектура COM была преобразована
и стала называться DCOM.
Когда объект OLE помещен в буфер обмена информацией, он сохраняется в
оригинальных форматах Windows (таких как bitmap или metafile), а также сохраняется в
своём собственном формате. Собственный формат позволяет поддерживающей OLE
программе внедрить порцию другого документа, скопированного в буфер, и сохранить её в
документе пользователя.
OLE 2.0
Следующим эволюционным шагом стал OLE 2.0, сохранивший те же цели и задачи,
что и предыдущая версия. Но OLE 2.0 стал надстройкой над архитектурой COM вместо
использования VTBL. Новыми особенностями стали автоматизация технологии drag-anddrop, in-place activation и structured storage.
ActiveX (OLE 3.0)
В 1996 году Microsoft исходя из рекламных соображений переименовала технологию
OLE в ActiveX. Были представлены элементы управления ActiveX, ActiveX документы и
технология Active Scripting. Эта версия OLE в основном используется веб-дизайнерами
для вставки в страницы мультимедийных данных.
12. Процесс загрузки Windows, управление загрузкой. Роль реестра на этапах
загрузки.
2.1 Предварительная загрузка:
После включения компьютера с Windows XP инициализируется и находит
загрузочный раздел жесткого диска.
Предварительная загрузка проходит в четыре этапа.
1.
Компьютер выполняет процедуру POST для определения объема физической
памяти, проверки наличия аппаратных компонентов и т. д. Если на компьютере
установлена базовая система ввода-вывода (BIOS) Plug and Play, то на этом этапе
происходит просмотр и конфигурирование аппаратных устройств.
2.
BIOS компьютера обнаруживает загрузочное устройство, загружает и
выполняет главную загрузочную запись (MBR).
3.
Главная загрузочная запись просматривает таблицу разделов в поисках
активного раздела, загружает загрузочный сектор активного раздела в память и выполняет
его.
4.
Компьютер загружает и инициализирует файл Ntldr — загрузчик ОС.
Во время установки Windows изменяет загрузочный сектор, чтобы в процессе запуска
системы загружался файл Ntldr.
2.2 Загрузка:
После загрузки в память файла Ntldr процедура загрузки собирает информацию об
аппаратном обеспечении и драйверах. При этом используются файлы Ntldr, Boot.ini,
Bootsect.dos
(необязательно),
Ntdetect.com
и
Ntoskrnl.exe.
Загрузка проходит в четыре этапа: начальная загрузка, выбор ОС, обнаружение
оборудования и выбор конфигурации,
2.2.1 Начальная загрузка:
На этом этапе файл Ntldr переводит процессор из реального режима в 32-разрядный
режим линейной памяти, необходимый для выполнения любых дополнительных функций.
Затем запускаются соответствующие драйверы системы minifile. Они встроены в Ntldr,
поэтому этот файл способен находить и загружать Windows XP данные из разделов,
отформатированных как с помощью FAT, так и NTFS.
2.2.2 Выбор операционной системы:
Во время загрузки Ntldr считывает файл Boot.ini. Если в этом файле задан выбор
одной из нескольких ОС, будет выведен запрос Please select The Operating System To Start
(Выберите операционную систему для запуска) со списком ОС, внесенных в файл Boot.ini.
Если вы не выберете ни один из вариантов до истечения времени ожидания, Ntldr загрузит
ОС, заданную в файле Boot.ini в качестве системы по умолчанию. Setup делает таковой
Windows XP, установленную последней. Если в файл Boot.ini только одна запись, запрос
Please select The Operating System To Start не появится, а соответствующая ОС загрузится
автоматически. Если файл Boot.ini отсутствует, Ntldr пытается загрузить Windows из папки
Winnt первого раздела первого диска.
2.2.3 Поиск оборудования:
В компьютерах с Процессором Intel поиск оборудования осуществляют файлы
Ntdetect.com и Ntoskrnl.exe. Программа Ntdetect.com запускается, если на этапе выбора ОС
выбрана система Windows XP (или по окончании времени ожидания). Если вы выбрали
ОС, отличную от Windows XP, например, Windows 98, Ntldr загружает и выполняет файл
Bootsect.dos, в котором содержится копия загрузочного сектора, находившегося в
системном разделе до установки Windows XP. Передача управления файлу Bootsect.dos
означает начало загрузки выбранной ОС.
Ntdetect.com формирует список установленных аппаратных компонентов и передает
его в Ntldr для включения в реестр в ключе HKEY_LO-CAL_MACHINE\HARDWARE.
Ntdetect.com определяет:
тип
шины/адаптера;
коммуникационные
порты;
математический
сопроцессор;
дисководы для гибких дисков;
клавиатуру;
мышь
или другое указательное устройство;
параллельные
адаптеры
порты;
SCSI;
видеоадаптеры.
2.2.4 Выбор конфигурации:
После окончания сбора информации об аппаратном обеспечении выводится
сообщение Hardware Profile/Configuration Recovery Menu (Меню выбора конфигурации
оборудования). Оно содержит список имеющихся аппаратных конфигураций.
2.3 Загрузка ядра:
После выбора конфигурации загружается и инициализируется ядро Windows XP
(Ntoskrnl.exe). Файл Ntoskrnl.exe также загружает и инициализирует драйверы устройств и
загружает службы. Если вы после вывода сообщения Hardware Profile/Configuration
Recovery Menu нажмете Enter или если Ntldr произведет выбор конфигурации
автоматически, начинается загрузка ядра. Экран очистится, и в нижней его части появится
ряд белых прямоугольников.
На этапе загрузки ядра Ntldr выполняет следующие действия.
Загружает файл Ntoskrnl.exe (но не инициализирует его).
Загружает файл слоя абстрагирования от оборудования (Hardware Abstraction Layer,
HAL) Hal.dll.
Загружает ключ реестра HKEY_LOCAL_MACHINE\SYSTEM
systemroot\System32\Config\System.
из
каталога
Выбирает управляющий набор (control set), который будет использоваться для
инициализации компьютера. Управляющий набор содержит данные о конфигурации,
необходимые для управления системой, например, список драйверов устройств и служб,
которые необходимо загрузить и запустить.
Загружает драйверы устройств, у которых значение параметра Start равно 0x0.
Обычно это драйверы низкого уровня, например, необходимые для работы жесткого
диска. Параметр List из подраздела реестра HKEY_LOCAL_MACHINE\ SYSTEM\
CurrentControlSet\ Control\ ServiceGroupOrder задает порядок их загрузки.
2.3.1 Инициализация ядра:
По завершении загрузки ядро инициализируется, затем ему передается управление. В
этот момент система отображает графический экран, в строке состояния которого можно
увидеть ход загрузки. На этапе инициализации ядра выполняются действия.
1. Создается раздел Hardware. В случае успешной инициализации ядро использует
данные, собранные во время поиска оборудования, для создания раздела реестра
HKEY_LOCAL_MACHINE\HARDWARE,
который
содержит
информацию
об
оборудовании на системной плате и прерываниях, используемых аппаратными
компонентами.
2. Создается управляющий набор Clone. Его создает ядро, копируя набор, ссылка на
который
записана
в
параметре
Current
подраздела
реестра
HKEY_LOCAL_MACHINE\SYSTEM\Select. Управляющий набор Clone никогда не
меняется и должен быть точной копией данных, использованных для конфигурирования
компьютера,
не
отражая
изменения
сделанные
при
запуске.
3. Загружаются и инициализируются драйверы устройств. Создав управляющий набор
Clone, ядро инициализирует драйверы устройств низкого уровня, которые были загружены
на этапе загрузки ядра. Затем ядро просматривает подраздел реестра
HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services в поисках драйверов
устройств, у которых значение параметра Start равно 0x1. Как и на этапе загрузки ядра,
значение параметра Group для драйвера определяет его место в очереди на загрузку. Сразу
после загрузки драйверы устройств инициализируются. Если при загрузке и
инициализации драйвера произошла ошибка, дальнейший ход загрузки определяется
параметром драйвера Error-Control. Возможные значения этого параметра и вытекающие
из них действия см. в таблице 2. В реестре значения ErrorControl содержатся в подразделе
HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\
<имя_службы_или_драйвера>\ЕrrorControl.
4. Запускаются службы. После загрузки и инициализации драйверов устройств Session
Manager (Smss.exe) запускает подсистемы высокого уровня и службы Windows. Session
Manager выполняет команды из элемента BootExecute и разделов Memory Management,
DOS Devices и Subsystems. Назначение этих команд см. в таблице 3.
2.4 Регистрация:
Процесс регистрации начинается по завершении инициализации ядра. Подсистема
Win32 запускает программу Winlogon.exe, которая в свою очередь запускает Local Security
Authority (Lsass.exe) и открывает окно Logon (Вход в Windows), где вы можете
зарегистрироваться, даже если продолжается инициализация драйверов сетевых устройств.
Затем Service Controller выполняет и последний раз просматривает подраздел
HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\ Services в поисках служб, у
которых значение параметра Start равно 0x2, что означает автоматическую загрузку
(например для служб Workstation и Server). В загружаемых на этом этапе службах
используются значения параметров DependOnGroup или DependOnService из подраздела
реестра
HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services.
Загрузка Windows не считается успешной, до тех пор пока пользователь не
зарегистрируется в системе. После успешной регистрации система создает копию
управляющего набора Clone с именем LastKnownGood.
2.5 Протоколирование загрузки:
Enable Boot Logging (Включить протоколирование загрузки) – Задает создание
протокола загрузки и инициализации драйверов и устройств. Журнал ntbtlog.txt находится
в папке Windows\Systemroot или Windows. При использовании любого из видов
безопасного режима журнал создается автоматически.
Процесс запуска операционной системы при холодном старте состоит из следующих
этапов:
Нажатие на кнопку питания приводит к загрузке BIOS компьютера и процедуры
тестирования его основных компонентов — POST (Power-On Self Test). При этом
определяется и физический диск, с которого последует старт операционной системы;
BIOS считывает информацию из MBR (Master Boot Record) и таким образом
запускает утилиту Bootmgr.exe, которая, в свою очередь, ищет загрузчик Windows
(Winload.exe) на диске и запускает его;
Загрузчик инициализирует загрузку основных драйверов для последующего запуска
операционной системы и сервиса сессий (session manager process — Smss.exe);
Загрузка Smss.exe и представляет собой загрузку основной сессии системы (session
0), когда загружаются все драйверы, сервисы и другие элементы операционной
системы;
После успешного запуска основной сессии подгружаются оконный менеджер и
групповые политики для локального ПК и домена, а затем после входа в систему
запускается основная пользовательская сессия (User session) с помощью сервиса
Winlogon.exe;
Начинается загрузка рабочего стола пользователя и старт всех его приложений,
которые промаркированы к автозапуску.
Загрузка операционной системы windows 7 Загрузка Windows является сложным
процессом и содержит серию этапов.
1. После подачи питания запускается процесс самотестирования, управляет которым
программа BIOS. Если на данном этапе выявляется неисправный узел, то загрузка ПК
останавливается и на экран выводится соответствующее уведомление, либо раздается
серия звуковых сигналов.
2. После окончания теста BIOS запускает определение загрузочного сектора на
носителях, которые поддерживает материнская плата (дискета, жесткий диск, оптический
диск). Приоритет поиска загрузочного сектора настраивается в настройках BIOS.
3. После того, как загрузочный накопитель определен, с него считывается первый
сектор, в котором расположена основная загрузочная запись (MBR, Master Boot Record).
MBR также содержит таблицу разделов диска с пометкой с пометкой - какой из них
активный.
4. MBR определяет активный раздел и управление передается загрузочной записи,
которую хранит первый сектор активного раздела. При помощи данной загрузочной записи
активируется менеджер загрузки ОС Windows 7 (называется bootmgr – файл,
расположенный в корневой директории активного раздела).
5. Далее менеджер загрузки проверяет информацию конфигурации системы, которая
записана в файл BCD (аббревиатура от Boot Configuration Data). Если в файле содержится
несколько записей, пользователь увидит меню выбора операционной системы. Расположен
данный файл в каталоге с названием Boot активного раздела.
6. Как только система выбрана, активируются модуль загрузки Windows Winload.exe,
системные службы, компоненты ядра Hal.dll и Ntoskrnl.exe и ряд других компонентов –
данный этап сопровождается анимированным логотипом. Создается ключ hardware –
динамическая информация реестра особых отклонений системы. Создается clone и туда
помещаются параметры из ControlCurrentSet. Загрузка и инициализация драйверов. Особые
утилиты - chdisk проверка дисков, инициализация служб, файл подкачки, загрузка
подсистем среды.
7. Загрузка сервиса сессий (session manager process — Smss.exe). Представляет собой
загрузку основной сессии системы (session 0), когда загружаются все драйверы, сервисы и
другие элементы операционной системы. Запускается подсистема Windows (csrss.exe).
8. Активируется процесс winlogon.exe, необходимый для управления входом
пользователей в Windows. Если в системе всего один пользователь без пароля, вход будет
произведен в автоматическом режиме. Если это не так – будет выведено окно выбора
пользователя с формой для ввода пароля (если он установлен). Продолжается загрузка
сетевых драйверов, загружается система локальной безопасности. Загрузка служб, где
start=2, автозагрузка служб из реестра RunServices (Ones). В процессе входа пользователя в
систему запускаются приложения автозагрузки, которые расположены в папке
«Автозагрузка», а также прописаны в реестре.
9. Загружается оболочка shell из реестра, обычно explorer.
13. Технология UEFI и GPT-формат дисков, проблемы внедрения.
Изменения в UEFI
Итак, UEFI BIOS — это интерфейс между операционной системой и программами,
которые управляют низкоуровневыми функциями оборудования. Его основные задачи:
быстро протестировать все оборудование на работоспособность, провести инициализацию
и передать управление другой программе, которая начнет загружать операционную
систему. В общем, UEFI это лишь улучшенная версия привычного БИОСа.
Если БИОС — это неизменный по своему содержанию код микросхемы CMOS
(прошивка БИОС — это уже другая тема), то UEFI — это гибко настраиваемый интерфейс,
который расположен поверх всех аппаратных компонентов компьютера. Иногда UEFI
называют «псевдооперационной системой», но тем не менее она сама способна получить
доступ ко всему аппаратному обеспечению компьютера.
Внешний вид последней версии БИОС (до UEFI) — это знакомый всем синий экран с
белыми надписями на английском языке (управление осуществлялось только с помощью
клавиатуры). Сейчас же это уже новая графическая оболочка. Графический интерфейс,
который установлен на новых материнских платах Asus, Gigabyte, MSI, может
использоваться и для выполнения других приложений UEFI: настройка, установка
операционной системы, диагностика и т.д. Внешне данный интерфейс выглядит очень
симпатично. Простым пользователям будет намного проще разобраться в таком БИОСе, к
тому же интерфейс UEFI поддерживает управление не только с клавиатуры, но и с
помощью мышки. Также есть поддержка русского языка, к примеру, на тех же материнских
платах от Asus. Вызвав BIOS UEFI теперь можно наблюдать конфигурацию своего
компьютера (процессор и оперативную память), текущую дату и время, рабочую
температуру устройств и пр.
Кроме того, в качестве бонуса к стандартной схеме разметки дисков MBR, UEFI имеет
поддержку GBT (GUID Partition Table), которая свободна от ограничений, присущих MBR.
Переход на платформу BIOS UEFI долгое время откладывался, но когда начали
производить жесткие диски большого объема (более 2 Тб), стал неизбежным. Все дело в
том, что стандартная версия БИОС может «видеть» только 2,2 Тб дискового пространства.
Примерно так же, как и 32-разрядная операционная система может «видеть» только 3,25 Гб
оперативной памяти. А UEFI может поддерживать на данный момент жесткие диски
объемом до 9 млрд Тб (довольно космическое число на сегодняшний день, но, кто знает,
может, через 10-20 лет это будет уже обычной вещью).
В качестве основных функций, которые имеются в BIOS UEFI еще стоит отметить:
тестирование оперативной памяти;
совместимость со старой версией BIOS;
универсальный загрузчик;
резервное копирование данных с винчестера (HDD Backup);
возможность обновления UEFI через интернет (Live Update).
GPT
два режима запуска – холодный страт и гибернация
модульная архитектура
написано на С – независимость от платформы
может поддерживать жесткие диски до 8.8 экзабайт
Существует проблема защищенности от вирусов.
GUID Partition Table, аббр. GPT — стандарт
формата
размещения таблиц
разделов на
физическом жестком
диске.
Он
является
частью Расширяемого
микропрограммного интерфейса (англ. Extensible Firmware Interface, EFI) — стандарта,
предложенного Intel на смену BIOS. EFI использует GPT там, где BIOS
использует Главную загрузочную запись (англ. Master Boot Record, MBR).
В отличие от MBR, которая начинается с исполняемой двоичной программы,
призванной идентифицировать и загрузить активный раздел, GPT опирается на
расширенные возможности EFI для осуществления этих процессов. Однако MBR
присутствует в самом начале диска (блок LBA 0) как для защиты, так и в целях
совместимости.
Собственно
GPT
начинается
с Оглавления
таблицы
разделов (англ. Partition Table Header).
GPT использует современную систему адресации логических блоков (LBA) вместо
применявшейся в MBR адресации «Цилиндр — Головка — Сектор» (CHS). Доставшаяся
по наследству MBR со всей своей информацией содержится в блоке LBA 0, оглавление
GPT — в блоке LBA 1. В оглавлении содержится адрес блока, где начинается сама таблица
разделов, обычно это следующий блок — LBA 2. В случае 64-битной версии ОС Microsoft
Windows NT, за таблицей разделов зарезервировано 16 384 байт (при использовании
сектора размером 512 байт это будет 32 сектора), так что первым используемым сектором
каждого жёсткого диска в ней будет блок LBA 34.
Кроме того, GPT обеспечивает дублирование — оглавление и таблица разделов
записаны как в начале, так и в конце диска.
Теоретически, GPT позволяет создавать разделы диска размером до 9,4 ТБ (9,4 ×
10 байт), в то время как MBR может работать только до 2,2 ТБ (2,2 × 1012 байт).
21
Основная цель помещения MBR в начало диска чисто защитная. MBRориентированные дисковые утилиты могут не распознать и даже переписать GPT диски.
Чтобы избежать этого, указывается наличие всего одного раздела, охватывающего весь
GPT диск. Системный идентификатор (англ. System ID) для этого раздела
устанавливается в значение 0xEE, указывающее, что применяется GPT. Вследствие этого
EFI игнорирует MBR. Некоторые 32-битные операционные системы, не приспособленные
для чтения дисков, содержащих GPT, тем не менее распознают этот Системный
идентификатор и представляют том в качестве недоступного GPT диска. Более старые ОС
обычно представляют диск, как содержащий единственный раздел неизвестного типа и без
свободного места; как правило, они отказываются модифицировать такой диск, пока
пользователь явно не потребует и не подтвердит удаление данного раздела. Таким
способом предотвращается случайное стирание содержимого GPT диска.
Формат GPT имеет следующую структуру:
Из рисунка сразу видны две интересные особенности формата. Во-первых, в начале
диска присутствует область Protective MBR. Сделано это как в целях совместимости, так и
для защиты данных от старых MBR-ориентированных дисковых утилит, которые не
понимают GPT. Во-вторых, GPT обеспечивает дублирование — оглавление и таблица
разделов записаны как в начале, так и в конце диска.
В настоящее время большинство современных ОС поддерживает GPT. Однако переход
на этот формат осложняет тот факт, что большинство систем до сих пор использует BIOS.
Это делает невозможной загрузку Windows с разделов GPT, а это, в свою очередь,
ограничивает применение нового формата размещения таблиц разделов на физическом
жестком диске.
14. Файловые системы в современных версиях Windows. Общие свойства файловой
системы NTFS.
Файловые системы в современных операционных системах. Файловая система - это
часть операционной системы, назначение которой состоит в том, чтобы обеспечить
пользователю удобный интерфейс при работе с данными, хранящимися на диске, и
обеспечить совместное использование файлов несколькими пользователями и процессами.
В широком смысле понятие "файловая система" включает: совокупность всех файлов на
диске, наборы структур данных, используемых для управления файлами, такие, например,
как каталоги файлов, дескрипторы файлов, таблицы распределения свободного и занятого
пространства на диске, комплекс системных программных средств, реализующих
управление файлами, в частности: создание, уничтожение, чтение, запись, именование,
поиск и другие операции над файлами.
FAT32 - замена FAT16 - последняя версия файловой системы FAT и улучшение
предыдущей версии, известной как FAT16. Она была создана, чтобы преодолеть
ограничения на размер тома в FAT16, позволяя при этом использовать старый код
программ MS-DOS и сохранив формат. FAT32 использует 32-разрядную адресацию
кластеров. FAT32 появилась вместе с Windows 95 OSR2. Максимально возможное число
кластеров в FAT32 равно 268 435 445, что позволяет использовать тома (логические диски)
объёмом до 8 ТБ. Максимально возможный размер файла для тома FAT32 — ~ 4 ГБ — 4
294 967 295 байт.
NTFS- стандартная файловая система для семейства операционных систем Microsoft
Windows NT. NTFS заменила использовавшуюся в MS-DOS и Microsoft Windows
файловую систему FAT. NTFS поддерживает систему метаданных и использует
специализированные структуры данных для хранения информации о файлах для
улучшения производительности, надёжности и эффективности использования дискового
пространства. Максимальный размер файла: Теоретически — 2 в 64 степени байт минус 1
килобайт, Практически — 2 в 44 степени байт минус 64 килобайта (~16384 гигабайт или
~16 терабайт).
exFAT (от англ. Extended FAT — «расширенная FAT») — проприетарная файловая
система, предназначенная главным образом для флэш-накопителей. Впервые представлена
фирмой Microsoft для встроенных устройств в Windows Embedded CE 6.0. Уменьшение
количества перезаписей одного и того же сектора, что важно для флеш-накопителей, у
которых ячейки памяти необратимо изнашиваются после определённого количества
операций записи (это сильно смягчается выравниванием износа — wear leveling, —
встроенным в современные USB-накопители и SD-карточки). Это была основная причина
разработки ExFAT. Теоретический лимит на размер файла 2 в 64 степени байт (16
эксабайт). Максимальный размер кластера увеличен до 225 байт (32 мегабайта).
Основными преимуществами exFAT перед предыдущими версиями FAT являются:
Уменьшение количества перезаписей одного и того же сектора, что важно для флешнакопителей, у которых ячейки памяти необратимо изнашиваются после определённого
количества операций записи (это сильно смягчается выравниванием износа (wear leveling),
встроенным в современные USB-накопители и SD-карточки). Это было основной
причиной разработки ExFAT.
Теоретический лимит на размер файла 264 байт (16 эксабайт).
Максимальный размер кластера увеличен до 225 байт (32 мегабайта).
Улучшение распределения свободного места за счёт введения бит-карты свободного
места, что может уменьшать фрагментацию диска.
Введена поддержка списка прав доступа[2].
Поддержка
устройством).
транзакций
(опциональная
возможность,
должна
поддерживаться
CDFS (устарела), или файловая система CDROM (только для чтения), обслуживается
драйвером \Windows\System32\Drivers\Cdfs.sys, который поддерживает над множества
форматов ISO9660 и Joliet. CDFS присущ ряд ограничений:
максимальная длина файлов не должна превышать 4 Гб;
число каталогов не может превышать 65 535.
Файловая система UDF в Windows является UDFсовместимой реализацией OSTA
(Optical Storage Technology Association). (UDF является формата ISO13346 с расширениями
для поддержки CDR, DVDR/RW и т. д.) OSTA определила UDF в 1995 году как формат
магнитооптических носителей, главным образом DVDROM, предназначенный для замены
формата ISO9660.
Файловые системы UDF обладают следующими преимуществами:
длина имен файлов и каталогов может быть до 254 символов в ASCIIкодировке или
до 127 символов в Unicodeкодировке;
файлы могут быть разреженными (sparse);
размеры файлов задаются 64битными значениями
VFAT. В Windows 95 поддерживается файловая система FAT, переписанная в 32разрядный код и названная виртуальной таблицей размещения файлов (virtual file allocation
table — VFAT). VFAT используется вместе с 32-разрядной программой VCACHE (заменившей
16-разрядную программу SMARTDrive из DOS и Windows 3.1), что обеспечивает более
высокую производительность файловой системы. Однако наиболее существенным
улучшением новой файловой системы является поддержка длинных имен файлов. Системы
DOS и Windows 3.1 ограничивались стандартом "восемь-точка-три" при именовании файлов,
поэтому добавление поддержки длинных имен файлов было приоритетной задачей, которую
необходимо было решить разработчикам Windows 95, тем более что пользователи
операционных систем Macintosh и OS/2 уже вовсю применяли эти возможности. Таким
образом, создатели Windows 95 должны были обеспечить обратную совместимость, т.е.
необходимо было реализовать в файловой системе все новые свойства и, кроме того, не
"обделить" пользователей предыдущих версий DOS и Windows. Кстати, обратная
совместимость — одна из самых распространенных проблем в мире персональных
компьютеров.
В системе VFAT файлу или каталогу можно присваивать имя длиной до 255 символов
(включая путь к этому файлу или каталогу). В Windows 95 от трехсимвольного расширения не
отказались, поскольку в этой операционной системе (как и в предыдущих версиях Windows) с
помощью расширения создается ассоциация типа "файл-приложение". В длинных именах
файлов можно использовать пробелы, а также символы + ,; = [], которые нельзя было
использовать
в
стандартных
(восемь-точка-три)
именах
файлов
DOS.
При создании длинного имени файла создается его псевдоним, удовлетворяющий стандарту
"восемь-точка-три". В Windows 9х файловая система VFAT выполняет это следующим
образом.
1. Первых три символа после последней точки в длинном имени файла становятся рас-
ширением псевдонима.
2. Первых шесть символов длинного имени файла (за исключением пробелов, которые
игнорируются) преобразуются в символы верхнего регистра и становятся первыми шестью
символами стандартного имени файла. Недопустимые в стандартном имени файла символы
(+,; = []) преобразуются в символы подчеркивания.
3. VFAT добавляет символы ~1 (седьмой и восьмой) к псевдониму имени файла. Если первых
шесть символов нескольких файлов одинаковы, то для разрешения конфликтов имен
добавляются символы ~2, ~3 и т.д.
VFAT хранит псевдонимы длинных имен в поле стандартных имен файлов записи каталога
файлов. Таким образом, все версии DOS и Windows могут получить доступ к файлу под
длинным именем с помощью его псевдонима. Остается еще одна проблема: как хранить 255
символов имени файла в 32 байтах записи каталога, ведь каждый символ имени файла — это
один байт? Модифицировать структуру записи каталога нельзя, поскольку тогда предыдущие
версии DOS не смогут использовать ее.
Разработчики файловой системы решили эту проблему следующим образом: были добавлены
дополнительные записи каталога для хранения длинных имен файлов. Чтобы предыдущие
версии DOS не повредили этих дополнительных записей каталога, VFAT устанавливает для
них атрибуты, которые нельзя использовать для обычного файла: только для чтения, скрытый,
системный и метка тома. Такие атрибуты DOS игнорирует, а следовательно, длинные имена
файлов остаются "нетронутыми".
Отличие FAT и FAT32. Основными недостатками FAT и VFAT являются большие
потери на кластеризацию при больших размерах логического диска и ограничениях на сам
размер логического диска.
Т.е. необходимо разработать файловую систему с использованием идеи применения
таблицы FAT. Файловая система типа FAT32 является самостоятельной 32- разрядной
файловой системой. Главное ее отличие в более эффективном использовании дискового
пространства.
Прежде всего FAT32 использует кластеры меньшего размера по сравнению с
предыдущими версиями, который ограничивались 65535 кластерами на диске. Даже для
дисков до 8 Гбайт FAT32 может использовать 4 Кбайт – кластеры, в результате
экономится 10-15 % дискового пространства. FAT32 может перемещаться в корневой
каталог и использовать резервную копию вместо стандартной. Корневой каталог FAT32
представлен в виде обычной цепочки кластеров, т.е. корневой каталог находится в любом
месте диска, что снимает ограничения на его размер (512 бит).
Кроме повышения емкости FAT до 4 Тбайт. FAT32 изменяет структуры корневого
каталога. Для хранения имен фалов используются дополнительные элементы каталога, в
т.ч. и для корневых. Длинное имя может занимать до 256 символов и для его хранения
используется 25- элементов каталога. Длина полной файловой спецификации , включая
путь и имя файла ограничена 260-символами, т.е. рекомендуется ограничивать длину
имени файла 75-80 символами для того, чтобы осталось место для пути.
EFS. EFS работает, шифруя каждый файл с помощью алгоритма симметричного
шифрования, зависящего от версии операционной системы и настроек (начиная с Windows
XP доступна теоретическая возможность использования сторонних библиотек для
шифрования данных). При этом используется случайно сгенерированный ключ для
каждого файла, называемый File Encryption Key (FEK), выбор симметричного шифрования
на данном этапе объясняется его скоростью по отношению к асимметричному
шифрованию.
FEK (случайный для каждого файла ключ симметричного шифрования) защищается
путём асимметричного шифрования, использующего открытый ключ пользователя,
шифрующего файл, и алгоритм RSA (теоретически возможно использование других
алгоритмов асимметричного шифрования). Зашифрованный таким образом ключ FEK
сохраняется в альтернативном потоке $EFS файловой системы NTFS. Для расшифрования
данных драйвер шифрованной файловой системы прозрачно для пользователя
расшифровывает FEK, используя закрытый ключ пользователя, а затем и необходимый
файл с помощью расшифрованного файлового ключа.
Поскольку шифрование/расшифрование файлов происходит с помощью драйвера
файловой системы (по сути, надстройки над NTFS), оно происходит прозрачно для
пользователя и приложений. Стоит заметить, что EFS не шифрует файлы, передаваемые по
сети, поэтому для защиты передаваемых данных необходимо использовать другие
протоколы защиты данных (IPSec или WebDAV).
Основные особенности NTFS
работа на дисках большого объема происходит эффективно (намного
эффективнее, чем в FAT);
имеются средства для ограничения доступа к файлам и каталогам - разделы NTFS
обеспечивают локальную безопасность как файлов, так и каталогов;
введен
механизм
транзакций,
при
котором
осуществляется журналирование файловых
операций существенное
увеличение
надежности;
сняты многие ограничения на максимальное количество дисковых секторов и/или
кластеров;
имя файла в NTFS, в отличие от файловых систем FAT и HPFS, может содержать
любые символы, включая полный набор национальных алфавитов, так как данные
представлены в Unicode — 16-битном представлении, которое дает 65535 разных символов.
Максимальная длина имени файла в NTFS — 255 символов.
система NTFS также обладает встроенными средствами сжатия, которые можно
применять к отдельным файлам, целым каталогам и даже томам (и впоследствии отменять
или назначать их по своему усмотрению).
поддержка больших фалов и томов за счет 64bit организаци
высокая скорость операций, низкая фрагментация
добавление новых типов записей
15. Структура системных данных на томе NTFS. Принцип адресации расположения
файлов на томе.
Физическая организация NTFS
Файловая система NTFS была разработана в качестве основной файловой системы для
ОС Windows NT в начале 90-х годов с учетом опыта разработки файловых систем FAT и
HPFS (основная файловая система для OS/2), а также других существовавших в то время
файловых систем. Основными отличительными свойствами NTFS являются:
Структура тома NTFS
В отличие от разделов FAT и s5/ufs все пространство тома NTFS представляет собой
либо файл, либо часть файла. Основой структуры тома NTFS является главная таблица
файлов (Master File Table, MFT), которая содержит по крайней мере одну запись для
каждого файла тома, включая одну запись для самой себя. Каждая запись MFT имеет
фиксированную длину, зависящую от объема диска, — 1, 2 или 4 Кбайт. Для большинства
дисков, используемых сегодня, размер записи MFT равен 2 Кбайт, который мы далее будет
считать размером записи по умолчанию.
Все файлы на томе NTFS идентифицируются номером файла, который определяется
позицией файла в MFT. Этот способ идентификации файла близок к способу,
используемому в файловых системах s5 и ufs, где файл однозначно идентифицируется
номером его записи в области индексных дескрипторов.
Весь том NTFS состоит из последовательности кластеров, что отличает эту файловую
систему от рассмотренных ранее, где на кластеры делилась только область данных.
Порядковый номер кластера в томе NTFS называется логическим номером кластера
(Logical Cluster Number, LCN). Файл NTFS также состоит из последовательности
кластеров, при этом порядковый номер кластера внутри файла называется виртуальным
номером кластера (Virtual Cluster Number, VCN).
Базовая единица распределения дискового пространства для файловой системы NTFS
— непрерывная область кластеров, называемая отрезком. В качестве адреса отрезка NTFS
использует логический номер его первого кластера, а также количество кластеров в
отрезке k, то есть пара (LCN, k). Таким образом, часть файла, помещенная в отрезок и
начинающаяся с виртуального кластера VCN, характеризуется адресом, состоящим из трех
чисел: (VCN, LCN, k).
Для хранения номера кластера в NTFS используются 64-разрядные указатели, что
дает возможность поддерживать тома и файлы размером до 264 кластеров. При размере
кластера в 4 Кбайт это позволяет использовать тома и файлы, состоящие из 64 миллиардов
килобайт.
Структура тома NTFS показана на рис. 7.19. Загрузочный блок тома NTFS
располагается в начале тома, а его копия — в середине тома. Загрузочный блок содержит
стандартный блок параметров BIOS, количество блоков в томе, а также начальный
логический номер кластера основной копии MFT и зеркальную копию MFT.
Рис. 7.19. Структура тома NTFS
Далее располагается первый отрезок MFT, содержащий 16 стандартных, создаваемых
при форматировании записей о системных файлах NTFS. Назначение этих файлов описано
в показанной ниже таблице MFT.
В NTFS файл целиком размещается в записи таблицы MFT, если это позволяет
сделать его размер. В том же случае, когда размер файла больше размера записи MFT, в
запись помещаются только некоторые атрибуты файла, а остальная часть файла
размещается в отдельном отрезке тома (или нескольких отрезках). Часть файла,
размещаемая в записи MFT, называется резидентной частью, а остальные части —
нерезидентными. Адресная информация об отрезках, содержащих нерезидентные части
файла, размещается в атрибутах резидентной части.
Некоторые системные файлы являются полностью резидентными, а некоторые имеют
и нерезидентные части, которые располагаются после первого отрезка MFT.
Нулевая запись MFT содержит описание самой MFT, в том числе и такой ее важный
атрибут, как адреса всех ее отрезков. После форматирования MFT состоит из одного
отрезка, но после создания первого же несистемного файла для хранения его атрибутов
требуется еще один отрезок, так как изначально непрерывная последовательность
кластеров MFT уже завершена системными файлами.
Из приведенного описания видно, что сама таблица MFT рассматривается как файл, к
которому применим метод размещения в томе в виде набора произвольно расположенных
нескольких отрезков.
Некоторые файлы метаданных NTFS хранит в каталоге расширенных метаданных
$Extend, в том числе помещая туда файл идентификаторов объектов ($ObjId), файл квот
($Quota), файл журнала регистрации изменений ($UsnJrnl) и файл точек повторного
разбора ($Reparse). В этих файлах содержится информация, относящаяся к
дополнительным возможностям NTFS. Файл идентификаторов объектов хранит
идентификаторы объектов «файл», файл квот — значения квот и информацию о поведении
томов, на которых используются квоты, файл точек повторного разбора — список файлов
и каталогов, включающих данные точек повторного разбора, а в файле журнала изменений
регистрируются изменения файлов и каталогов.
16. Атрибуты файлов NTFS, форматы записей MFT для файлов и каталогов.
Применение расширенных атрибутов.
Структура файлов NTFS
Каждый файл и каталог на томе NTFS состоит из набора атрибутов. Важно отметить,
что имя файла и его данные также рассматриваются как атрибуты файла, то есть в
трактовке NTFS кроме атрибутов у файла нет никаких других компонентов.
Каждый атрибут файла NTFS состоит из полей: тип атрибута, длина атрибута,
значение атрибута и, возможно, имя атрибута. Тип атрибута, длина и имя образуют
заголовок атрибута.
Имеется системный набор атрибутов, определяемых структурой тома NTFS.
Системные атрибуты имеют фиксированные имена и коды их типа, а также определенный
формат. Могут применяться также атрибуты, определяемые пользователями. Их имена,
типы и форматы задаются исключительно пользователем. Атрибуты файлов упорядочены
по убыванию кода атрибута, причем атрибут одного и того же типа может повторяться
несколько раз. Существуют два способа хранения атрибутов файла - резидентное хранение
в записях таблицы MFT и нерезидентное хранение вне ее, во внешних отрезках. Таким
образом, резидентная часть файла состоит из резидентных атрибутов, а нерезидентная —
из нерезидентных атрибутов. Сортировка может осуществляться только по резидентным
атрибутам.
Системный набор включает следующие атрибуты:
Attribute List (список атрибутов) — список атрибутов, из которых состоит файл;
содержит ссылки на номер записи MFT, где расположен каждый атрибут; этот редко
используемый атрибут нужен только в том случае, если атрибуты файла не умещаются в
основной записи и занимают дополнительные записи MFT;
File Name (имя файла) — этот атрибут содержит длинное имя файла в формате
Unicode, а также номер входа в таблице MFT для родительского каталога; если этот файл
содержится в нескольких каталогах, то у него будет несколько атрибутов типа File Name;
этот атрибут всегда должен быть резидентным;
MS-DOS Name (имя MS-DOS) — этот атрибут содержит имя файла в формате 8.3;
Version (версия) — атрибут содержит номер последней версии файла;
Security Descriptor (дескриптор безопасности) — этот атрибут содержит
информацию о защите файла: список прав доступа ACL и поле аудита, которое
определяет, какого рода операции над этим файлом нужно регистрировать;
Volume Version (версия тома) — версия тома, используется только в системных
файлах тома;
Volume Name (имя тома) — имя тома;
Data (данные) — содержит обычные данные файла;
MFT bitmap (битовая карта MFT) — этот атрибут содержит карту использования
блоков на томе;
Index Root (корень индекса) — корень В-дерева, используемого для поиска файлов в
каталоге;
Index Allocation (размещение индекса) — нерезидентные части индексного списка Вдерева;
Standard Information (стандартная информация) — этот атрибут хранит всю
остальную стандартную информацию о файле, которую трудно связать с каким-либо из
других атрибутов файла, например, время создания файла, время обновления и другие.
Файлы NTFS в зависимости от способа размещения делятся на небольшие, большие,
очень большие и сверхбольшие.
Небольшие файлы (small). Если файл имеет небольшой размер, то он может целиком
располагаться внутри одной записи MFT, имеющей, например, размер 2 Кбайт. Небольшие
файлы NTFS состоят по крайней мере из следующих атрибутов (рис. 7.20):
стандартная информация (SI — standard information);
имя файла (FN — file name);
данные (Data);
дескриптор безопасности (SD — security descriptor).
Из-за того что файл может иметь переменное количество атрибутов, а также из-за
переменного размера атрибутов нельзя наверняка утверждать, что файл уместится внутри
записи. Однако обычно файлы размером менее 1500 байт помещаются внутри записи MFT
(размером 2 Кбайт).
Большие файлы (large). Если данные файла не помещаются в одну запись MFT, то
этот факт отражается в заголовке атрибута Data, который содержит признак того, что этот
атрибут является нерезидентным, то есть находится в отрезках вне таблицы MFT. В этом
случае атрибут Data содержит адресную информацию (LCN, VCN, k) каждого отрезка
данных (рис. 7.21).
Рис. 7.21. Большой файл
Сверхбольшие файлы (extremely huge). Для сверхбольших файлов атрибуте Attribute
List можно указать несколько атрибутов, расположенных в дополнительных записях MFT
(рис. 7.23). Кроме того, можно использовать двойную косвенную адресацию, когда
нерезидентный атрибут будет ссылаться на другие нерезидентные атрибуты, поэтому в
NTFS не может быть атрибутов слишком большой для системы длины.
Очень большие файлы (huge). Если файл настолько велик, что его атрибут данных,
хранящий адреса нерезидентных отрезков данных, не помещается в одной записи, то этот
атрибут помещается в другую запись MFT, а ссылка на такой атрибут помещается в
основную запись файла (рис. 7.22). Эта ссылка содержится в атрибуте Attribute List. Сам
атрибут данных по-прежнему содержит адреса нерезидентных отрезков данных.
Каталоги
index allocation – в этот атрибут записываются сылки на строки в MFT, где записаны
файлы, т.е. атрибут IR.
Запись о файле в каталоге содержит: имя файла, длину имени, номер записи MFT, доп
флаги.
17. Расширенные возможности NTFS: сжатие и шифрация данных, точки повторной
обработки.
1. Сжатие данных.
В NTFS 5.0 сжатие данных встроено в виде прозрачного для пользователя механизма,
регулируемого атрибутом файла/каталога «Сжимать содержимое для …».
Сжатие выполняется блоками по 16 кластеров в файле сквозным образом при записи
на диск, благодаря чему процесс мало отражается на работе с файлами.
Каждый блок при обработке записи сжимается, и, если сжатие дало выигрыш по
размеру хотя-бы в 1-м кластере блока, то данные пишутся в сжатом виде, в противном
случае данные пишутся без сжатия. Сжатый блок пишется в MFT двумя полями: первое
содержит LCN и VCN сжатого отрезка файла, второй – блок, на который различаются
несжатый и сжатый блоки с указанием LCN=0 (выступает признаком того, что
предыдущий блок сжат).
При таком подходе сжатие можно производить любым блочным алгоритмом. NTFS
использует алгоритм LZNT1 (версия LZ77) для сжатия данных без потерь.
Шифрование - EFS
EFS осуществляет шифрование данных, используя схему с общим ключом. Данные
шифруются быстрым симметричным алгоритмом при помощи ключа шифрования файла
FEK (file encryption key). FEK — это случайным образом сгенерированный ключ
определенной длины. Длина ключа в североамериканской версии EFS 128 бит, в
международной версии EFS используется уменьшенная длина ключа 40 или 56 бит.
FEK шифруется одним или несколькими общими ключами шифрования, в результате
чего получается список зашифрованных ключей FEK. Список зашифрованных ключей FEK
хранится в специальном атрибуте EFS, который называется DDF (data decryption field —
поле дешифрования данных). Информация, при помощи которой производится
шифрование данных, жестко связана с этим файлом. Общие ключи выделяются из пар
пользовательских ключей сертификата X509 с дополнительной возможностью
использования «File encryption». Личные ключи из этих пар используются при дешифровке
данных и FEK. Личная часть ключей хранится либо на смарт-картах, либо в другом
надежном месте (например, в памяти, безопасность которой обеспечивается при помощи
CryptoAPI).
FEK также шифруется при помощи одного или нескольких ключей восстановления
(полученных из сертификатов X509, записанных в политике восстановления
зашифрованных данных для данного компьютера, с дополнительной возможностью «File
recovery»).
Как и в предыдущем случае, общая часть ключа используется для шифрования списка
FEK. Список зашифрованных ключей FEK также хранится вместе с файлом в специальной
области EFS, которая называется DRF (data recovery field — поле восстановления данных).
Для шифрования списка FEK в DRF используется только общая часть каждой пары
ключей. Для нормального осуществления файловых операций необходимы только общие
ключи восстановления. Агенты восстановления могут хранить свои личные ключи в
безопасном месте вне системы (например, на смарт-картах). На рисунке приведены схемы
процессов шифрования, дешифрования и восстановления данных.
Процесс шифрования
Незашифрованный файл пользователя шифруется при помощи случайно
сгенерированного ключа FEK. Этот ключ записывается вместе с файлом, файл
дешифруется при помощи общего ключа пользователя (записанного в DDF), а также при
помощи общего ключа агента восстановления (записанного в DRF).
Процесс дешифрования
Сначала используется личный ключ пользователя для дешифрации FEK — для этого
используется зашифрованная версия FEK, которая хранится в DDF. Расшифрованный FEK
используется для поблочного дешифрования файла. Если в большом файле блоки
считываются не последовательно, то дешифруются только считываемые блоки. Файл при
этом остается зашифрованным.
Процесс восстановления
Этот процесс аналогичен дешифрованию с той разницей, что для дешифрования FEK
используется личный ключ агента восстановления, а зашифрованная версия FEK берется из
DRF.
Реализация в Windows 2000
На рисунке показана архитектура EFS:
EFS состоит из следующих компонентов:
Драйвер EFS
Этот компонент расположен логически на вершине NTFS. Он взаимодействует с
сервисом EFS, получает ключи шифрования файлов, поля DDF, DRF и другие данные
управления ключами. Драйвер передает эту информацию в FSRTL (file system runtime
library, библиотека времени выполнения файловой системы) для прозрачного выполнения
различных файловых системных операций (например, открытие файла, чтение, запись,
добавление данных в конец файла).
Библиотека времени выполнения EFS (FSRTL)
FSRTL — это модуль внутри драйвера EFS, который осуществляет внешние вызовы
NTFS для выполнения различных операций файловой системы, таких как чтение, запись,
открытие зашифрованных файлов и каталогов, а также операций шифрования,
дешифрования, восстановления данных при записи на диск и чтении с диска. Несмотря на
то, что драйвер EFS и FSRTL реализованы в виде одного компонента, они никогда не
взаимодействуют напрямую. Для обмена сообщениями между собой они используют
механизм вызовов NTFS. Это гарантирует участие NTFS во всех файловых операциях.
Операции, реализованные с использованием механизмов управления файлами, включают
запись данных в файловые атрибуты EFS (DDF и DRF) и передачу вычисленных в EFS
ключей FEK в библиотеку FSRTL, так как эти ключи должны устанавливаться в контексте
открытия файла. Такой контекст открытия файла позволяет затем осуществлять незаметное
шифрование и дешифрование файлов при записи и считывании файлов с диска.
Служба EFS
Служба EFS является частью подсистемы безопасности. Она использует
существующий порт связи LPC между LSA (Local security authority, локальные средства
защиты) и работающим в kernel-mode монитором безопасности для связи с драйвером EFS.
В режиме пользователя служба EFS взаимодействует с программным интерфейсом
CryptoAPI, предоставляя ключи шифрования файлов и обеспечивая генерацию DDF и DRF.
Кроме этого, служба EFS осуществляет поддержку интерфейса Win32 API.
Win32 API
Обеспечивает интерфейс программирования для шифрования открытых файлов,
дешифрования и восстановления закрытых файлов, приема и передачи закрытых файлов
без их предварительной расшифровки. Реализован в виде стандартной системной
библиотеки advapi32.dll.
Reparse Point
В файловой системе NTFS файл или каталог может содержать в себе reparse point, что
переводится на русский язык как «точка повторной обработки». В файл или каталог
добавляются специальные данные, файл перестаёт быть обычным файлом и обработать его
может только специальный драйвер фильтра файловой системы.
В Windows присутствуют типы reparse point, которые могут быть обработаны самой
системой. Например, через точки повторной обработки в Windows реализуются
символьные ссылки (symlink) и соединения (junction point), а также точки монтирования
томов в каталог (mount points).
Reparse-буфер, присоединяемый к файлу это буфер, имеющий максимальный размер
16 килобайт. Он характеризуется наличием тега, который говорит системе о том, к какому
типу принадлежит точка повторной обработки. При использовании reparse-буфера
собственного типа ещё необходимо задавать в нём GUID в специальном поле, а в reparseбуферах Microsoft он может отсутствовать.
Еще
Точки повторной обработки позволяют приложению связать блок своих данных с
файлом или каталогом, а диспетчеру объектов Object Manager — выполнить повторный
поиск имени, когда прикладная программа обнаруживает точку повторной обработки.
Помимо данных в точке повторной обработки хранится программный код, который
идентифицирует принадлежность точки повторной обработки определенному
приложению. Сами по себе точки повторной обработки бесполезны, но благодаря им
программисты могут наращивать функциональность NTFS. В Windows 2000
предусмотрено несколько типов точек повторной обработки, в том числе точки
монтирования томов, подсоединения каталогов NTFS и управления иерархическими
хранилищами данных (Hierarchical Storage Management, HSM). Я объясню, как работают
все эти функции, а затем подробно расскажу о реализации точек повторной обработки.
Любой том NTFS доступен лишь после того, как ему присвоено символьное
обозначение. Точки монтирования NTFS5 позволяют привязать том к каталогу
монтирования на родительском томе NTFS5, не присваивая символьного обозначения
дочернему тому. В результате появляется возможность объединить несколько томов под
одной буквой. Например, если смонтировать том, содержащий каталог \articles, к точке
монтирования с именем C:\documents, то можно использовать путь C:\articles\documents
для доступа к файлам каталога \documents. Точка монтирования представляет собой точку
повторной обработки, данные которой состоят из внутреннего имени тома. Внутреннее
имя имеет форму \??\Volume{XX-XX-XX-XX}, где X — числа, образующие глобальный
уникальный ID (GUID), присвоенный тому операционной системой.
Если открыть файл C:\articles\documents\column.doc, то NTFS обнаруживает точку
монтирования, связанную с каталогом \documents. NTFS читает хранящиеся в ней данные
точки повторной обработки (имя тома) и передает в Object Manager статус точки
повторной обработки. Диспетчер ввода/вывода перехватывает информацию о статусе,
анализирует данные и определяет, что NTFS обнаружила точку монтирования. Диспетчер
ввода/вывода изменяет искомое имя и заставляет Object Manager (компонент ядра,
который отвечает поиску имен) провести повторный поиск с измененным путем
\??\Volume{GUID}\documents\column.doc. В процессе повторного поиска анализ имени
\documents\co-lumn.doc продолжится на смонтированном томе. Создать точки
монтирования и составить их список можно с помощью оснастки Disk Management
консоли управления Microsoft Management Console (MMC) или инструмента командной
строки Mountvol, поставляемого вместе с Windows 2000.
Точки подсоединения каталогов NTFS похожи на точки монтирования, и диспетчер
ввода/вывода и Object Manager выполняют подсоединение так же, как монтирование.
Однако точки подсоединения устанавливают связь с каталогами, а не с томами. Точки
подсоединения Windows 2000 эквивалентны символьным ссылкам UNIX (но в отличие от
символьных ссылок UNIX, точки подсоединения нельзя применять к файлам). Если
создать точку подсоединения C:\articles\documents, связанную с каталогом D:\documents, то
можно обращаться к файлам в D:\documents, используя путь C:\articles\documents. В точке
подсоединения хранится информация о перенаправленном пути, и если NTFS
обнаруживает точку подсоединения, то, как и в случае с точкой монтирования, диспетчер
ввода/вывода изменяет имя и инициирует повторный поиск имени. Принцип действия
точки подсоединения показан на Рисунке 3. Когда приложение открывает C:\directory1\file,
NTFS обнаруживает точку повторной обработки в каталоге C:\directory1, указывающую на
каталог C:\directory2. Диспетчер ввода/вывода изменяет имя на C:\directory2\file, и
приложение в итоге открывает файл C:\directory2\file.
Управление иерархическим хранением данных (HSM)
18. Расширенные возможности NTFS: монтирование томов, жесткие
символические связи, "консолидированная безопасность", применение VHD.
и
Монтирование томов.
Любой том NTFS доступен лишь после того, как ему присвоено символьное
обозначение. Точки монтирования NTFS5 позволяют привязать том к каталогу
монтирования на родительском томе NTFS5, не присваивая символьного обозначения
дочернему тому. В результате появляется возможность объединить несколько томов под
одной буквой. Например, если смонтировать том, содержащий каталог \articles, к точке
монтирования с именем C:\documents, то можно использовать путь C:\articles\documents
для доступа к файлам каталога \documents. Точка монтирования представляет собой точку
повторной обработки, данные которой состоят из внутреннего имени тома. Внутреннее
имя имеет форму \??\Volume{XX-XX-XX-XX}, где X — числа, образующие глобальный
уникальный ID (GUID), присвоенный тому операционной системой.
Если открыть файл C:\articles\documents\column.doc, то NTFS обнаруживает точку
монтирования, связанную с каталогом \documents. NTFS читает хранящиеся в ней данные
точки повторной обработки (имя тома) и передает в Object Manager статус точки
повторной обработки. Диспетчер ввода/вывода перехватывает информацию о статусе,
анализирует данные и определяет, что NTFS обнаружила точку монтирования. Диспетчер
ввода/вывода изменяет искомое имя и заставляет Object Manager (компонент ядра,
который отвечает поиску имен) провести повторный поиск с измененным путем
\??\Volume{GUID}\documents\column.doc. В процессе повторного поиска анализ имени
\documents\column.doc продолжится на смонтированном томе. Создать точки
монтирования и составить их список можно с помощью оснастки Disk Management
консоли управления Microsoft Management Console (MMC) или инструмента командной
строки Mountvol, поставляемого вместе с Windows 2000.
Связи
1. Hard Links — жёсткие ссылки, как в *nix. Доступны начиная с Windows NT4; (файл)
2. Junction Points — аналог символических ссылок. Доступен начиная с Windows 2000
(NTFS 5); (каталог)
3. Symbolic Links — символьные ссылки. Доступны начиная с Windows Vista.(файл и
каталог)
Жёсткие ссылки действительны в пределах одного раздела, символьные — могут
пересекать границы разделов. В связи с этим символьные ссылки могут поломаться, если
структуру разделов поменять.
Консолидированная безопасность NTFS5.
NTFS всегда располагала функциями безопасности, позволяющими администратору
указать пользователей, которым разрешен или запрещен доступ к тем или иным файлам и
каталогам. В версиях NTFS, предшествовавших Windows 2000, дескриптор безопасности
каждого файла и каталога хранился в его собственном атрибуте безопасности. В
большинстве случаев администраторы назначают единые параметры безопасности всему
дереву каталогов, что приводит к дублированию дескрипторов безопасности для всех
файлов и подкаталогов, к которым применяются параметры. Такое дублирование может
привести к значительным потерям дискового пространства в многопользовательских
средах, таких, как Windows 2000 Server Terminal Services и NT Server 4.0, Terminal Server
Edition (WTS), где дескрипторы безопасности могут содержать элементы для многих
учетных записей. NTFS5 оптимизирует выделение дискового пространства для хранения
дескрипторов безопасности, сохраняя лишь один экземпляр каждого дескриптора
безопасности на томе в центральном файле метаданных с именем $Secure.
Рис 21.1. Как работает файл метаданных $Secure.
В файле $Secure хранятся два индексных атрибута – $SDH и $SII – и атрибут потока
данных, именуемый $SDS (Рисунок 21.1). NTFS5 назначает каждому уникальному
дескриптору на томе внутренний идентификатор безопасности NTFS (не путать с SID,
уникально идентифицирующим компьютеры и учетные записи пользователей) и хеширует
дескриптор безопасности в соответствии с простым хеш-алгоритмом. Хеш-значение –
потенциально неуникальное сокращенное представление дескриптора. Элементы в индексе
$SDH отображают хеш-значения дескриптора безопасности на область хранения
дескриптора безопасности в атрибуте данных $SDS, а индекс $SII отображает на область
хранения дескриптора безопасности в атрибуте данных $SDS идентификаторы
безопасности NTFS5.
Назначив дескриптор безопасности файлу или каталогу, NTFS получает хеш-значение
дескриптора и просматривает индекс $SDH в поисках совпадений. NTFS сортирует
элементы индекса $SDH согласно хеш-значению соответствующего дескриптора
безопасности и сохраняет элементы в B+ дереве. Обнаружив для дескриптора совпадение в
индексе $SDH, NTFS определяет смещение дескриптора безопасности элемента из записи
$SDS Offset и считывает дескриптор безопасности из атрибута $SDS. Если совпадают хешзначения, но не дескрипторы безопасности, то NTFS ищет еще один совпадающий элемент
в индексе $SDH. Если NTFS обнаруживает полное совпадение, то файл или каталог,
которому назначен дескриптор безопасности, может установить связь с дескриптором
безопасности в атрибуте $SDS.
NTFS устанавливает связь, считывая идентификатор безопасности из элемента $SDH и
сохраняя его в атрибуте $STANDARD_INFORMATION файла или каталога. В атрибуте
$STANDARD_INFORMATION системы NTFS, который имеют все файлы и каталоги,
хранится базовая информация о файле, в том числе атрибуты и временные метки. В
Windows 2000 этот атрибут расширен, в нем появилась дополнительная информация,
например идентификатор безопасности файла.
Если NTFS не обнаруживает в индексе $SDH элемента с дескриптором безопасности,
совпадающим с назначаемым, значит, новый дескриптор уникален для тома, и NTFS
назначает ему новый внутренний ID безопасности. Внутренние ID безопасности NTFS
представляют собой 32-разрядные величины, а идентификаторы SID обычно в несколько
раз длиннее, поэтому представление идентификаторов SID идентификаторами
безопасности
NTFS
позволяет
сэкономить
место
в
атрибуте
$STANDARD_INFORMATION. Затем NTFS добавляет дескриптор безопасности в атрибут
$SDS, который сортируется в B+ дереве по ID безопасности NTFS, и дополняет индексы
$SDH и $SII элементами, указывающими на смещение дескриптора в массиве данных
$SDS.
Когда приложение пытается открыть файл или каталог, NTFS отыскивает дескриптор
безопасности файла или каталога с помощью индекса $SII. NTFS читает внутренний ID
безопасности файла или каталога из атрибута $STANDARD_INFORMATION записи MFT,
а затем использует индекс $SII файла $Secure для поиска элемента ID в атрибуте $SDS. По
смещению в атрибуте $SDS система NTFS считывает дескриптор безопасности и завершает
проверку безопасности. NTFS5 не удаляет элементы файла $Secure, даже если с ним не
связано ни одного файла или каталога на томе. Наличие неудаленных элементов не
приводит к значительной потере дискового пространства, так как число уникальных
дескрипторов безопасности на большинстве томов, даже используемых в течение
длительного времени, сравнительно невелико.
Благодаря универсальной индексации NTFS5 файлы и каталоги с одинаковыми
параметрами безопасности эффективно используют общие дескрипторы. С помощью
индекса $SII NTFS быстро отыскивает дескрипторы безопасности в файле $Secure в ходе
проверок безопасности, а индекс $SDH позволяет быстро определить, имеется ли в файле
$Secure ранее сохраненный дескриптор безопасности, пригодный для совместного
использования с данным файлом или каталогом.
VHD
VHD – формат файлового образа, содержащий полную структуру физического
жесткого диска. Таким образом, виртуальный жесткий диск может быть разбит на разделы,
как и физический жесткий диск. VHD используется в программах виртуализации Virtual
PC, Virtual Server 2005, Hyper-V, VirtualBox, Xen, VMWare.
Теперь же операционная система поддерживает функции создания VHD, а также их
подключения к системе. Однако самым главным преимуществом является возможность
загрузки операционной системы из VHD. Преимуществами VHD является:
· Удобство хранения данных, данные одной виртуальной машины хранятся в одном
файле
· Удобство ограничения дискового пространства – теперь не нужно настраивать
дисковые квоты – стоит просто изменить размер VHD
· Экономия физического дискового пространства – можно создать динамически
расширяющийся VHD, который увеличивает свой размер соразмерно с увеличением
хранящейся на нем информации. То есть только что созданный расширяемый VHD почти
не занимает места.
· Удобство резервного копирования – теперь для резервного копирования данных,
хранящихся в VHD вы можете просто скопировать его. Естественно, что поддерживаются
сценарии.
Архитектура VHD
Виртуальные жесткие диски бывают нескольких типов:
·Фиксированного размера VHD занимает ровно столько места, сколько указано при
его создании, не в зависимости от хранящегося там объема информации. Его размер может
быть изменен путем утилиты VhdResizer.
· Динамически расширяющиеся VHD при своем создании почти не занимает место, его
размер расширяется при наполнении информацией. Однако удаление информации из VHD
не уменьшает его размер.
· Дифференциальные. Это диски, которые связаны с уже существующим по связи
«ребенок-родитель». Таким образом, дифференциальный диск хранит в себе лишь
изменения по сравнению с родительским диском
Применение:
1. диск ВМ, запущенной в базовой
2. диск базовой системы, загружаемый самостоятельно
3. архивация, восстановление томов
4. создание образа системы
5. для преобразования физических дисков в виртуальные
19. Модели драйверов в Windows. Общие свойства и функции драйверов.
Модели драйверов Windows
1. драйверы Real Mode (DOS, Win 3.x)
2. Монолитные драйверы ядра (.drv)
3. Виртуальные драйверы VxD
4. Двухуровневая модель минидрайвера
5.WDM
6. WDF
Драйверы поддерживают операции с аппаратным обеспечением. Они принимают
команды от ОС и переводят их в конкретные инструкции, понятные соответствующим
устройствам. Благодаря этому прикладные программы для W95 не зависят от различных
устройств и пользуются указаниями ОС. Для драйверов принтера, экрана и диска в W95
реализованы аппаратно—независимые драйверы, в дополнение к которым разработчики
пишут так называемые мини-драйверы для поддержки аппаратно-зависимых операций
(другое название порт драйверы).
W95 поддерживает три типа драйверов устройств
— драйверы реального времени MS-DOS (SYS — файлы, загружаемые командами
файла CONFIG.SYS).
— 16-разрядные драйверы для W3.x (DRV — файлы)
— 32-разрядный виртуальные драйверы для расширенного режима (VXD — файлы).
Драйверы защищенного режима обеспечивают более быструю работу устройств и
разделяемый доступ к ним. При установке W95 VXD — драйверы копируются в
подкаталог SYSTEM\VMM32 каталога Windows, а затем служат строительным
материалом для файла VMM32.VXD в каталоге SYSTEM, самого главного файла W95.
При добавлении в систему новых виртуальных драйверов устройств файл VMM32.VXD
перекомпонуется, поэтому на различных ПК он имеет различный размер.
Многие стандартные драйверы W95 являются 16 разрядными, например, System.drv
(системный драйвер), keyboard.drv (клавиатура), mouse.drv (мышь), VGA.DRV
(видеоадаптер), COMM.DRV (коммуникационный порт).
Драйверы реального режима приходится использовать для специфических MS-DOS
приложений (вроде переключателей клавиатуры) и для поддержки некоторых аппаратных
средств (например, сканеров). Каждое обращение к драйверу реального режима вынуждает
процессор переключаться в режим V86. Поскольку в течение каждой операции вводавывода посредством драйвера реального режима системе приходится делать достаточно
много переключений в режим V86 и обратно, это требует дополнительного процессорного
времени и сказывается на скорости операций.
VxD Driver. Цель – создать реентерабельный 320-разрядный драйвер защищенного
режима, который создает и переключает контекст устройства. Обеспечивает совместный
доступ нескольких процессов.
В Windows 2000 была добавлена поддержка технологии Plug and Play, настроек
электропитания и расширение модели драйверов Windows NT, названной моделью
драйверов Windows (WDM). Windows 2000 и более поздние версии могут запускать
драйверы, унаследованные у Windows NT 4, но, поскольку они не поддерживают
технологию Plug and Play настройки электропитания, системы, запускающие эти драйверы,
будут вынуждены ограничивать возможности в этих двух областях. С точки зрения WDM,
существуют драйверы трех типов:
- Драйвер шины, обслуживающий контроллер шины, адаптер, мост или любое
устройство, имеющее дочерние устройства. Драйверы шины нуждаются в драйверах, и
Microsoft, как правило, их предоставляет; каждый тип шины (такой как PCI, PCMCIA и
USB), имеющийся в системе, имеет один драйвер шины. Сторонние производители могут
создавать драйверы шины для предоставления поддержки новых шин, таких как VMEbus,
Multibus и Futurebus.
- Функциональный драйвер, являющийся основным драйвером устройства и
предоставляющий для него управляющий интерфейс. Драйвер нужен в том случае, если
устройство не используется напрямую (в варианте реализации, при которой ввод-вывод
осуществляется драйвером шины и любыми драйверами фильтра шины, в качестве
примера можно привести SCSI PassThru). Функциональный драйвер по определению
является драйвером, который знает о конкретном устройстве практически все, и обычно он
является единственным драйвером, обращающимся к специфическим регистрам
устройства.
- Драйвер фильтра, использующийся для добавления функциональности к устройству
(или к существующему драйверу) или для изменения запросов ввода-вывода или ответов
от других драйверов (для настройки оборудования, предоставляющего неверную
информацию о требованиях к аппаратным ресурсам). Драйверы фильтра являются
дополнительными и могут присутствовать в любом количестве, размещаясь выше или
ниже функционального драйвера и выше драйвера шины. Обычно драйверы фильтра
поставляются OEM-производителями или независимыми поставщиками оборудования
(IHV).
В среде окружения WDM все аспекты устройства контролируются не одним
драйвером: драйвер шины занимается отправкой диспетчеру PnP отчетов об устройствах,
подключенных к его шине, а функциональный драйвер управляет самим устройством. В
большинстве случаев драйверы фильтра, находящиеся на нижнем уровне, изменяют
поведение устройства. Например, если устройство сообщает своему драйверу шины, что
ему нужно 4 порта ввода-вывода, в то время как ему фактически нужно 16 портов вводавывода, функциональный драйвер фильтра для данного конкретного устройства может
перехватить перечень аппаратных ресурсов, о котором драйвер шины сообщает
диспетчеру PnP, и исправить количество портов ввода-вывода. Драйверы фильтра,
находящиеся на верхнем уровне, обычно предоставляют устройству какие-нибудь
дополнительные свойства. Например, драйвер фильтра такого устройства, как клавиатура,
находящийся на верхнем уровне, может навязывать дополнительные проверки
безопасности.
Еще
WDM-драйверы взаимодействуют друг с другом через пакеты запроса ввода —
вывода (IRPs).
Технология WDM была разработана для увеличения функциональности и облегчения
написания драйверов для Windows. Хотя WDM в основном был разработан для бинарной
совместимости и совместимости на уровне исходного кода между Windows 98 и Windows
2000, зачастую это не всегда ожидаемо и поэтому специфические драйвера
разрабатываются для каждой операционной системы отдельно.
WDM драйвера предназначены в общем для расширения стандартных возможностей
основного драйвера.
Критика Windows Driver Model
даже несмотря на значительные улучшения по сравнению с предшествующими ему
VxD и Windows NT driver model, критикуется разработчиками драйверов [1], в основном
по следующим причинам:
WDM слишком сложен для изучения.
Сложное взаимодействие с событиями управления питанием и Plug and Play. Это
приводит ко множеству ситуаций, когда компьютеры, управляемые Windows, не могут
перейти в спящий режим или правильно выйти из него из-за ошибок в коде драйвера.
Отмену ввода-вывода практически невозможно правильно определить.
Для каждого драйвера требуются тысячи строк сопровождающего кода.
Нет поддержки для написания «чистых» драйверов пользовательского режима.
Было также много проблем
предоставляемых Microsoft.
из-за
качества
документации
и
примеров,
Windows Driver Foundation (WDF) — набор программных инструментов от
корпорации Microsoft, облегчающих разработку драйверов устройств для Windows 2000 и
более поздних версий Windows.
Основными инструментами, составляющими WDF, являются Kernel Mode Driver
Framework (KMDF) и User Mode Driver Framework (UMDF). Эти наборы инструментов
обеспечивают поддержку новой объектно-ориентированной программной модели
разработки драйверов для Windows. Основной целью фреймворков является
«Концептуальная масштабируемость» («Conceptual Scalability»), которая характеризуется
только требованием к разработчику драйвера знать несколько простых концепций, чтобы
написать простой драйвер, а по мере роста знаний разработчик имеет возможность
использовать более сложные, но в то же время более широкие возможности особенностей
драйверов. Это заметно отличается от Windows Driver Model (WDM), которая требует от
разработчиков драйверов полного знакомства со множеством сложных технических
деталей перед написанием даже простейшего драйвера.
Важным шагом в достижении концептуальной масштабируемости является то, что
KMDF и UMDF используют составную модель. Такая модель позволяет разработчику
расширять и изменять поведение «хорошего драйвера» по умолчанию. Это контрастирует
с более старой Windows Driver Model, которая зависит от того, насколько полно
разработчик реализовал все аспекты поведения драйвера.
20. Структура подсистемы ввода-вывода и стек драйверов Windows.
Для реализации этой функциональности подсистема ввода_вывода в Windows состоит
из нескольких компонентов исполнительной системы и драйверов устройств (рис. 9_1).
Центральное место в этой подсистеме занимает диспетчер ввода_вывода; он
подключает приложения и системные компоненты к виртуальным, логическим и
физическим устройствам, а также определяет инфраструктуру, поддерживающую драйверы
устройств.
Драйвер устройства, как правило, предоставляет интерфейс ввода_вывода для
устройств конкретного типа. Такие драйверы принимают от диспетчера ввода_вывода
команды, предназначенные управляемым ими устройствам, и уведомляют диспетчер
ввода_вывода о выполнении этих команд. Драйверы часто используют этот диспетчер для
пересылки команд ввода_вывода другим драйверам, задействованным в реализации
интерфейса того же устройства и участвующим в управлении им.
Диспетчер PnP работает в тесном взаимодействии с диспетчером ввода_вывода и
драйвером шины (bus driver) — одной из разновидностей драйверов устройств. Он
управляет выделением аппаратных ресурсов, а также распознает устройства и реагирует на
их подключение или отключение. Диспетчер PnP и драйверы шины отвечают за загрузку
соответствующего драйвера при обнаружении нового устройства. Если устройство
добавляется в систему, в которой нет нужного драйвера устройства, компоненты
исполнительной системы, отвечающие за поддержку PnP, вызывают сервисы установки
устройств, поддерживаемые диспетчером PnP пользовательского режима.
Диспетчер электропитания, также в тесном взаимодействии с диспетчером
ввода_вывода, управляет системой и драйверами устройств при их переходе в различные
состояния энергопотребления.
Процедуры поддержки Windows Management Instrumentation (WMI) (Инструментарий
управления Windows), образующие провайдер WDM (Windows Driver Model) WMI,
позволяют драйверам устройств выступать в роли провайдеров, взаимодействуя со
службой WMI пользовательского режима через провайдер WDM WMI. (Подробнее о WMI
см. раздел «Windows Management Instrumentation» главы 4.)
Реестр служит в качестве базы данных, в которой хранится описание основных
устройств, подключенных к системе, а также параметры инициализации драйверов и
конфигурационные настройки (см. главу 4).
Для установки драйверов используются INF_файлы; они связывают конкретное
аппаратное устройство с драйвером, который берет на себя ведущую роль в управлении
этим устройством. Содержимое INF_файла состоит из инструкций, описывающих
соответствующее устройство, исходное и целевое местонахождение файлов драйвера,
изменения, которые нужно внести в реестр при установке драйвера, и информацию о
зависимостях драйвера. В CAT_файлах хранятся цифровые подписи, которые
удостоверяют файлы драйверов, прошедших испытания в лаборатории Microsoft Windows
Hardware Quality Lab (WHQL).
Уровень абстрагирования от оборудования (HAL) изолирует драйверы от
специфических особенностей конкретных процессоров и контроллеров прерываний,
поддерживая API, скрывающие межплатформенные различия. В сущности HAL является
драйвером шины для тех устройств на материнской плате компьютера, которые не
контролируются другими драйверами.
21. Назначение, функции и общий принцип технологии Plug and Play (PnP).
Проблемы внедрения
Plug and Play (PnP) — технология, предназначенная для быстрого определения и
конфигурирования устройств в компьютере. Это способ создания либо реконструкции
абонентской системы быстрой установкой либо заменой ее компонентов. Технология PnP
основана на использовании объектно-ориентированной архитектуры, ее объектами
являются внешние устройства и программы. Операционная система автоматически
распознает объекты и вносит изменения в конфигурацию абонентской системы.
Для реализации технологии PnP необходимо, чтобы эту технологию поддерживали
устройства, BIOS и операционная система.
1. PnP устройства: позволяют динамически распределять устройства; выполнять
информационный
обмен
с
программным
обеспечением;
предоставляют
специализированный программный интерфейс – API.
Если драйвер устройства не поддерживает PnP – все возможности теряются. Для
устройств, не поддерживающих PnP, драйвер с технологией PnP может частично
реализовать функции, теряется динамическое конфигурирование. Можно сообщать
системе о занятых ресурсах, взаимодействовать с системой управления питанием.
Для PnP-драйверов в дереве устройств предоставляются сведения об устройстве и его
свойствах. При загрузке PnP-драйверы регистрируются через диспетчер конфигурации.
2. PnP-BIOS. Нужно обрабатывать динамическое изменение конфигурации. APM
(Advanced Power Manager) – отключение монитора, дисков. ACPI (Advanced Configuration
and Power Interface) – определяет интерфейс между оборудованием BIOS и ОС.
Албо PNP-BIOS:
1) Отключает все устройства PnP.
2) Последовательно определяет, совместимо ли устройство с PnP. Если нет – к пункту
6.
3) BIOS назначает обработчик Card Select Number (CNS).
4) Определяет, необходимо ли устройство для начальной загрузки.
5) Читает ресурсные данные устройства resource data.
6) BIOS сохраняет информацию о ресурсах в виде таблиц.
7) Повторяется для каждого устройства.
8) Включаются все унаследованные устройства в системе.
9) Конфигурируются PnP устройства так, чтобы не было конфликтов.
10) Включаются все PnP устройства, необходимые для загрузки.
11) Инициализируется загрузчик ОС. ОС может получить информацию об
устройствах от BIOS.
Кроме работы на этапе загрузки, BIOS имеет службы динамического оповещения о
событиях. Уведомление позволяет изменять конфигурацию при загрузке.
3. PnP-ОС. Windows обеспечивает следующую поддержку PnP:
1) Автоматическое и динамическое распознавание аппаратных средств.
2) Распределение аппаратных ресурсов.
3) Загрузка соответствующих драйверов.
4) Реализация интерфейса для взаимодействия с драйвером PnP:
- процедуры ввода-вывода;
- пакеты запросов ввода-вывода (IRP);
- точки входа в драйвер.
- информация реестра.
5) Взаимодействие с системой управления питанием.
6) Регистрация событий уведомления устройств. Прикладная программа должна
получать сообщения о событиях PnP. Прикладная программа может фильтровать
сообщения и реагировать только на сообщения от определенного класса устройств.
Менеджер PnP в режиме ядра централизованно управляет драйверами шин и
драйверами устройств (при их добавлении). Менеджер PnP в режиме пользователя
предоставляет API для установки устройств и для программного управления аппаратными
событиями.
Менеджер управления электропитанием обрабатывает вызовы интерфейса управления
питанием, координирует события и генерирует запросы прерывания, связанные с
управлением питанием. Менеджер собирает запросы на отключение и генерирует IRPпакеты.
Менеджер ввода-вывода дает базовые сервисы для драйверов устройств, преобразует
команды чтения/записи в соответствующие IRP-пакеты.
Подсистема ввода-вывода модернизирована в Windows XP, добавлены новые
функции, и драйверы могут иметь новые возможности (восстановление системы, сервис
управления теневыми копиями томов).
С точки зрения технологии PnP драйверы WDM можно разделить на:
1) Шинный драйвер – обслуживает контроллеры шин, то есть те устройства, которые
имеют дочерние устройства. Шинный драйвер выполняет энумерацию устройств, каждому
присваивается идентификатор. Устройства разделяются на стандартизированные списки
узлов. Шинный драйвер выполняет динамические извещения ОС о событиях на шине,
отвечает на IRP, поступающие от менеджеров PnP и электропитания, обеспечивает
мультиплексирование доступа к шине, общее администрирование устройств на шине.
Узлы
Устройства
PnP0000
Контроллер прерываний
PnP0100
Системный таймер
PnP0200
Контроллер DMA
PnP030B
Клавиатура
PnP0A03
Шина PSI
2) Функциональный драйвер – основной драйвер устройства. Драйвер класса —
Минипорт драйвер.
3) Драйвер фильтра – выполняет вспомогательную обработку (принимает и сортирует
запросы IRP, модифицирует поведение аппаратных средств и т.д.). Драйверы увязаны в
объекты и формируют структуру.
МОЕ
Диспетчер PnP — основной компонент, от которого зависит способность Windows к
распознаванию изменений в аппаратной конфигурации. Благодаря этому от пользователя
не требуется знания тонкостей настройки устройств и системы при их установке и
удалении. Так, диспетчер PnP позволяет портативному компьютеру с Windows при
подключении к стыковочной станции автоматически обнаруживать дополнительные
устройства стыковочной станции и делать их доступными пользователю.
Поддержка Plug and Play требует взаимодействия на уровнях оборудования, драйверов
устройств и операционной системы. Эта поддержка в Windows базируется на
промышленных стандартах перечисления и идентификации подключенных к шинам
устройств. Например, стандарт USB определяет способ самоидентификации устройств,
подключенных к шине USB. На этой основе в Windows реализуются следующие
возможности Plug and Play.
_ Диспетчер PnP автоматически распознает установленные устройства, и этот процесс
включает перечисление устройств при загрузке и обнаружение их добавления или удаления
во время работы системы.
_ Диспетчер PnP выделяет аппаратные ресурсы, собирая информацию о требованиях
устройств к аппаратным ресурсам (прерывания, диапазоны адресов ввода_вывода,
регистры ввода_вывода или ресурсы, специфичные для шин). В ходе арбитража
ресурсов (resource arbitration) диспетчер PnP распределяет ресурсы между устройствами с
учетом их требований. Поскольку устройства могут быть добавлены в систему после
распределения ресурсов на этапе загрузки, диспетчер PnP должен уметь перераспределять
ресурсы.
_ Другая функция диспетчера PnP — загрузка соответствующих драйверов. На основе
идентификационных данных устройства он определяет, установлен ли в системе драйвер,
способный управлять этим устройством. Если да, диспетчер PnP указывает диспетчеру
ввода_вывода загрузить его. Если подходящий драйвер не установлен, диспетчер PnP
режима ядра взаимодействует с диспетчером PnP пользовательского режима, чтобы
установить устройство. При этом он может попросить пользователя указать
местонахождение нужных драйверов.
_ Диспетчер PnP также реализует механизмы, позволяющие приложениям и драйверам
обнаруживать изменения в аппаратной конфигурации. Иногда для работы драйверов и
приложений требуется определенное устройство, поэтому в Windows имеются средства,
которые дают возможность таким драйверам и приложениям запрашивать уведомления о
наличии, добавлении и удалении устройств.
22. Структура системы PnP, функции и взаимодействие компонентов.
Что такое и как работает Plug-and-Play ?
Когда вы включаете операционную систему, поддерживающую принцип Plug-andPlay (дословно-литературно с английского означает «подключил и заработало»),
первостепенным арбитром, ответственным за слаженную работу Windows и «железо» ПК
является, как вы уже знаете BIOS. Она изыскивает оборудование в чреве компьютера на
предмет правильности работы и минимального его набора для корректного исполнения
возлагаемых задач со стороны пользователя. BIOS определяет эти устройства, основываясь
на их индивидуальных показателях (идентификаторах) – кусочках кода, которые прошиты
в чипы памяти устройств. После считывания информации об устройстве, BIOS передаёт
контроль Windows. Это вы тоже знаете.
Для понимания дальнейших процессов введём ещё пару понятий. В работу вступает
специальный инструмент операционной системы – конфигуратор Windows. Настоящее его
название модуль управления конфигурацией. В Windows именно он отвечает за ведение
системного реестра – спинного мозга системы. Так вот, это самый конфигуратор добавляет
к своим же записям драйверы специальных устройств, которые называются
нумераторы. Нумератор – программка, которая выполняет роль интерфейса между
операционной системой и каким-то устройством. Существуют нумераторы шин, портов,
специальной шины SCSI (интерфейс малой компьютерной системы) и множество других.
Windows во время работы постоянно опрашивает нумераторы об идентификации
устройства, с которым нумератор будет работать, и что этому устройству будет
необходимо для работы.
Собрав всю информацию с нумераторов, система записывает её на хранение в дерево
аппаратных средств – базу данных, хранящихся в оперативной памяти. Сразу после этого
необходимо проверить дерево на отсутствие аппаратных конфликтов. Попросту говоря, для
каждого устройства должно работать своё прерывание, своя «ирка»(IRQ). Windows и
принимает решение, какое из прерываний для какого из устройств назначить. Нумераторы
просто сохраняют эту информацию (информацию о распределении ресурсов) в
программируемых регистрах (ячейках кэш-памяти чипов).
Наконец, система начинает искать подходящий для каждого из устройств драйвер.
Драйвер, напомню, это кусок кода, который сообщает системе информацию об устройстве.
Если Windows не находит драйвер, она сразу пытается его установить. Когда драйверы
загружены, система сообщает устройству через его драйвер, какими ресурсами
пользоваться. Драйвер включает в работу своё устройство, система полностью загрузилась.
Вы увидели вплывающее окно, которое гласит: «Устройство установлено и готово к
использованию«. Можно работать.
Вот как описывает принцип Plug-and-Play Microsoft в пояснениях к схеме:
Исходное состояние После того, как управляющая программа Plug-andPlay привязала необходимые аппаратные ресурсы к устройству, она посылает пакет запроса
ввода-вывода (IRP), указывая, что все драйверы устройства приведены в состояние боевой
готовности. Устройство могло быть только что установлено и запускается впервые, а
может было перезапущено после остановки в его работе при повторном балансировании
элементов интерфейса системы (под лихо закрученной последней фразой понимается
пероформление, например, списка устройств в окне Мой компьютер при добавлении
нового устройства к системе).
Подготовка к отключению Управляющая программа Plug-and-Play посылает
запрос драйверу, чтобы тот убрал из системы программное обеспечение удаляемого
устройства. Система это делает в тот момент, когда пользователь удаляет устройство с
помощью функции «Удаление устройства из системы», щёлкая по значку в трее, сразу и
без предупреждения выдёргивает шнур USB из гнезда или пытается обновить драйверы
устройства.
Немедленное (внзапное) отключение Управляющая программа Plug-andPlay посылает запрос драйверу, оповещая его, что устройство удалено из системы. В ответ
драйвер прекращает подачу питания на устройство и предпринимает дополнительные (если
необходимо) меры по удалению устройства
Подготовка к удалению Управляющая программа Plug-and-Play посылает запрос
драйверу, может ли он сейчас остановить устройство. Если все загруженные для этого
устройства драйверы отвечают утвердительно, они же и вводят устройство в состояние
«Устройство может быть удалено».
Состояние
«Выключено» Управляющая
программа
Plug-and-Play держит
драйверы устройства в состоянии готовности ко включению.
Архитектура Plug and Play в Windows 2000
Ядро Windows 2000 обеспечивает поддержку Plug and Play в процессе загрузки и
предоставляет интерфейсы для взаимодействия с такими компонентами операционной
системы, как уровень аппаратных абстракций (HAL), исполняющая подсистема (модуль
Executive) и драйверы устройств (рис, 3,5). Функции режима пользователя
взаимодействуют с функциями режима ядра, обеспечивая возможности динамической
конфигурации и интерфейса с остальными компонентами, которые должны поддерживать
Plug and Play, например, с программой Setup и приложениями панели управления.
Следующие разделы подробно описывают модули Plug and Play.
Рис. 3.5. Архитектура Plug and Play в Windows 2000
Plug and Play Manager в режиме ядра
Модуль Plug and Play Manager (PnP Manager), работающий в режиме ядра,
поддерживает функции центрального управления, управляет шинными драйверами при
выполнении перечисления и драйверами устройств при добавлении устройства, его запуске
и т. д.
Например, Plug and Play Manager может направлять запросы, чтобы определить, может
ли устройство быть удалено, и позволить драйверу устройства синхронизировать
незавершенные запросы ввода/вывода с поступающим запросом. Plug and Play Manager
координируется с соответствующим модулем режима пользователя при определении
устройств, доступных для выполнения таких операций.
Power Manager и Policy Manager
Power Manager ≈ это компонент режима ядра, который работает совместно с модулем
Policy Manager и обрабатывает вызовы интерфейса прикладного программирования (API)
управления электропитанием, координирует события и генерирует запросы на прерывания,
связанные с управлением электропитанием IRP. Например, если различные устройства
отправляют запросы на отключение, Power Manager собирает эти запросы, определяет,
какие запросы должны быть сериализованы и генерирует соответствующие IRP. Policy
Manager наблюдает за активностью системы и собирает интегрированную информацию о
статусе пользователей, приложений и драйверов устройств. При определенных
обстоятельствах или по запросу Policy Manager генерирует IRP для изменения статуса
драйверов устройств.
I/O Manager
Диспетчер ввода/вывода (I/O Manager) обеспечивает базовые сервисы для драйверов
устройств. Диспетчер ввода/вывода представляет собой компонент режима ядра, который
выполняет трансляцию команд чтения и записи режима пользователя в соответствующие
IRP. Помимо этого диспетчер ввода/вывода управляет всеми остальными основными IRP
операционной системы. Эти интерфейсы работают точно так же, как они работали в
операционной системе Windows NT 4.0. Обратите внимание, что поскольку диспетчер
ввода/вывода имеется и в Windows NT 4.0 и в Windows 2000, драйвер Plug and Play может
устанавливаться вручную в Windows NT 4.0 и может функционировать как драйвер Plug
and Play в Windows 2000.
Интерфейс WDM для Plug and Play
Система ввода/вывода предоставляет уровневую архитектуру драйверов. В данном
разделе обсуждаются типы драйверов WDM, уровни драйверов и объекты устройств. Более
подробную информацию по данному вопросу можно найти в файле справочной
системы Introduction to Plug and Play, входящем в состав Windows 98 DDK, а также в
файлах документации к Windows 2000 DDK.
Типы драйверов
С точки зрения системы Plug and Play существуют следующие три типа драйверов:
Шинный драйвер (драйвер шины) обслуживает контроллер шины, адаптер, мост или
любое устройство, которое имеет дочерние устройства. Шинные драйверы относятся к
обязательным драйверам и обычно поставляются Microsoft. Для каждого типа шины в
системе имеется собственный шинный драйвер.
Функциональный драйвер ≈ это основной драйвер устройства, который
предоставляет интерфейс с этим устррйством. Этот драйвер является обязательным, за
исключением случаев, когда ввод/вывод устройства осуществляется шинным драйвером
или любыми драйверами фильтра. Функциональный драйвер устройства обычно
реализуется в виде пары драйвер/мини-драйвер. В таких парахдрайвер класса (обычно
разрабатываемый Microsoft) обеспечивает функциональные возможности, необходимые
всем устройствам этого типа, а мини-драйвер (обычно разрабатываемый фирмойпоставщиком конкретного устройства) обеспечивает специфические функциональные
особенности устройства. Plug and Play Manager загружает по одному функциональному
драйверу для каждого устройства.
Драйвер фильтра сортирует запросы ввода/вывода для шины, устройства или класса
устройств. Драйверы фильтра являются необязательными и могут существовать в любом
количестве, располагаясь на различных уровнях ≈ как выше, так и ниже
функционального драйвера и шинного драйвера. Обычно такие драйверы поставляются
фирмами OEM или независимыми поставщиками аппаратных средств (1HV). В
большинстве случаев драйверы фильтров нижнего уровня модифицируют поведение
аппаратных средств. Например, низкоуровневый драйвер фильтра класса для мыши
может обеспечивать ускорение ее работы, выполняя нелинейное преобразование данных
о перемещении мыши. Высокоуровневые драйверы фильтров обычно предоставляют
дополнительные функции для устройства. Например, высокоуровневый драйвер фильтра
у для клавиатуры может вводить дополнительные проверки по безопасности.
Уровни драйверов
Для каждого конкретного устройства существует два или более уровней
драйвера: шинный драйвер для шины ввода/вывода (или Plug and Play Manager ≈ для
устройств, помещенных при перечислении на корневой уровень) и функциональный
драйвер устройства. Помимо этого могут присутствовать один или несколько драйверов
фильтра для шины или устройства.
Объекты устройств
Драйвер создает объект устройства (device object) для каждого устройства, которым
он управляет. Объект устройства представляет устройство для драйвера. С точки зрения
Plug and Play существуют три типа объектов устройств:
Физические объекты устройств (Physical Device Objects, PDO),
Функциональные объекты устройств (Functional Device Objects,
FDO)
Объекты фильтров устройств
PDO представляют устройство на шине; каждый интерфейс прикладного
программирования Plug and Play API, который ссылается на устройство, ссылается на PDO.
FDO представляют функциональные возможности устройства функциональному драйверу.
Объекты фильтров представляют драйвер фильтра. Эти три типа объектов устройств имеют
тип DEVICE_OBJECT, но используются по-разному и могут иметь дополнительные
расширения.
Менеджер PnP в режиме ядра централизованно управляет драйверами шин и драйверами
устройств (при их добавлении). Менеджер PnP в режиме пользователя предоставляет API
для установки устройств и для программного управления аппаратными событиями.
Менеджер управления электропитанием обрабатывает вызовы интерфейса управления
питанием, координирует события и генерирует запросы прерывания, связанные с
управлением питанием. Менеджер собирает запросы на отключение и генерирует IRPпакеты.
Менеджер ввода-вывода дает базовые сервисы для драйверов устройств, преобразует
команды чтения/записи в соответствующие IRP-пакеты.
Подсистема ввода-вывода модернизирована в Windows XP, добавлены новые функции, и
драйверы могут иметь новые возможности (восстановление системы, сервис управления
теневыми копиями томов).
С точки зрения технологии PnP драйверы WDM можно разделить на:
1) Шинный драйвер – обслуживает контроллеры шин, то есть те устройства, которые
имеют дочерние устройства. Шинный драйвер выполняет энумерацию устройств, каждому
присваивается идентификатор. Устройства разделяются на стандартизированные списки
узлов. Шинный драйвер выполняет динамические извещения ОС о событиях на шине,
отвечает на IRP, поступающие от менеджеров PnP и электропитания, обеспечивает
мультиплексирование доступа к шине, общее администрирование устройств на шине.
Узлы
Устройства
PnP0000
Контроллер прерываний
PnP0100
Системный таймер
PnP0200
Контроллер DMA
PnP030B
Клавиатура
PnP0A03
Шина PSI
2) Функциональный драйвер – основной драйвер устройства. Драйвер класса —
Минипорт драйвер.
3) Драйвер фильтра – выполняет вспомогательную обработку (принимает и сортирует
запросы IRP, модифицирует поведение аппаратных средств и т.д.). Драйверы увязаны в
объекты и формируют структуру.
Объект «физическое устройство» (physical device object, PDO) Создается драйвером
шины по заданию диспетчера PnP, когда драйвер шины, перечисляя устройства на своей
шине, сообщает о наличии какоголибо устройства. PDO представляет физический
интерфейс устройства.
_ Необязательные группы объектов_фильтров (filter device objects,FiDO) Одна группа
таких объектов размещается между PDO и FDO (создается драйверами фильтров шин),
вторая — между FDO и первой группой FiDO (создается низкоуровневыми драйверами
фильтров), третья над FDO (создается высокоуровневыми драйверами фильтров).
_ Объект «функциональное устройство» (functional device object,FDO) Создается
функциональным драйвером, который загружается диспетчером PnP для управления
обнаруженным устройством. FDO представляет логический интерфейс устройства.
Функциональный драйвер может выступать и в роли драйвера шины, если к устройству,
представленному FDO, подключены другие устройства. Этот драйвер часто создает
интерфейс к PDO, соответствующему данному FDO, что позволяет приложениям и другим
драйверам открывать устройство и взаимодействовать с ним
Иногда функциональные драйверы подразделяются на драйвер класса,порт_драйвер и
минипорт_драйвер, совместно управляющие вводом_выводом для FDO. Узлы устройств
полагаются на функциональность диспетчера ввода_вывода; поток IRP идет по узлу
устройств сверху вниз. Решение об окончании обработки IRP может быть принято на
любом уровне узла устройств. Например, функциональный драйвер может обработать
запрос на чтение, не пересылая IRP драйверу шины. IRP проходит весь путь сверху вниз и
далее к узлу устройств, содержащему драйвер шины, только если функциональному
драйверу нужна помощь драйвера шины.
еще
До сих пор мы так и не ответили на два важных вопроса: как диспетчер PnP
определяет, какой функциональный драйвер нужно загрузить для данного устройства и как
драйверы фильтров регистрируют свое присутствие, чтобы их можно было загружать при
создании узла устройств?
Ответ на оба вопроса надо искать в реестре. Перечисляя устройства, драйвер шины
сообщает диспетчеру PnP идентификаторы обнаруженных устройств. Эти идентификаторы
специфичны для конкретной шины. Например, для шины USB такой идентификатор
состоит из идентификатора изготовителя (vendor ID, VID) и идентификатора продукта
(product ID, PID), на значенного устройству изготовителем (подробнее о форматах
идентифика торов устройств см. в DDK). В совокупности эти идентификаторы образуют то,
что в терминологии спецификации Plug and Play называется идентификатором
устройства (device ID). Диспетчер PnP также запрашивает у драйвера шины
идентификатор экземпляра (instance ID), который позволяет различать отдельные
экземпляры одного и того же устройства. Идентификатор экземпляра может определять
устройство относительно шины (например, USB_порт) или представлять глобально
уникальный дескриптор (скажем, серийный номер устройства).
Идентификаторы устройства и экземпляра дают идентификатор экземпляра
устройства (device instance ID, DIID), используемый диспетчером PnP для поиска раздела
устройства в ветви реестра HKLM\SYSTEM\CurrentControlSet\Enum. Пример такого
раздела для клавиатуры показан на рис. 9_28. В эти разделы помещаются данные,
характеризующие устройство, и получаемые из INF_файла параметры Service и ClassGUID,
с помощью которых диспетчер PnP находит драйверы, нужныедля данного устройства.
23. Установка и конфигурирование устройств в Windows, распределение аппаратных
ресурсов. Роль INI-файлов.
Установка драйвера
Если диспетчер PnP встречает устройство, драйвер которого не установлен, он
обращается к диспетчеру PnP пользовательского режима, и тот устанавливает нужный
драйвер. Если устройство обнаруживается при загрузке системы, для него определяется
узел устройств, но загрузка драйверов откладывается до запуска диспетчера PnP
пользовательского режима (он реализованв \Windows\System32\Umpnpmgr.dll и
выполняется как сервис в процессеServices.exe).
Компоненты, участвующие в установке драйвера, показаны на рис. 9_30. Серые блоки
на этом рисунке соответствуют компонентам, обычно предоставляемым системой, а
остальные блоки — компонентам, предоставляемым установочными файлами.
1. Сначала драйвер шины информирует диспетчер PnP о перечисленном устройстве,
сообщая его DIID (1). Диспетчер PnP проверяет, определен ли в реестре подходящий
функциональный драйвер.
2. Если нет, он уведомляет диспетчер PnP пользовательского режима (2) о новом
устройстве, сообщая его DIID.
3. Диспетчер PnP пользовательского режима пытается автоматически установить
драйверы для устройства. Если в процессе установки выводятся диалоговые окна,
требующие внимания пользователя, а зарегистрированный в данный момент пользователь
имеет привилегии администратора (3), то диспетчер PnP пользовательского режима
запускает Rundll32.exe (хост_программу апплетов Control Panel) для выполнения мастера
установки оборудования (\Windows\System32\Newdev.dll). Для поиска INF_файлов,
соответствующих драйверам, совместимым с обнаруженным устройством, мастер
установки оборудования использует API_функции Setup и CfgMgr (диспетчера
конфигурации). При этом пользователю может быть предложено вставить в один из
дисководов носитель с нужными INF_файлами; кроме того, просматриваются INF_файлы в
\Windows\Driver Cache\i386\Driver.cab, где содержатся драйверы, поставляемые с Windows.
4. INF_файл определяет местонахождение файлов функционального драйвера и
содержит команды, которые вводят нужные данные в раздел перечисления и раздел класса
драйвера. INF_файл может указать мастеру установки оборудования запустить DLL
установщика класса или компонента, участвующего в установке устройства (4), — эти
модули выполняют операции, специфичные для класса или устройства, например выводят
диалоговые окна, позволяющие настраивать параметры устройства.
Перед установкой драйвера диспетчер PnP пользовательского режима проверяет
системную политику проверки цифровых подписей в драйверах.
5. После установки драйвера диспетчер PnP режима ядра (этап 5 на рис. 9_30)
запускает драйвер и вызывает его процедуру добавления устройства, чтобы уведомить
драйвер о присутствии устройства, для управления которым он был загружен. Далее
формируется узел устройства, как мы уже объясняли.
Plug and Play представляет собой технологию, которая поддерживает автоматическое
конфигурирование ПК и всех установленных на нем устройств. Целью ее разработки
является обеспечение для пользователя возможности подключить новое устройство
(например, звуковой адаптер или факс-модем) и сразу же начать работу без необходимости
вручную конфигурировать это устройство. Реализация технологии Plug and Play
осуществляется на уровне аппаратных средств, операционной системы, драйверов
устройств и BIOS.
Назначение INF-файлов:
• Создание элементов реестра
• Определение инициализационных параметров (INI-settings)
• Копирование файлов с дистрибутива и размещение их в системе
• Инсталляция устройств
• Управление другими INF-файлами
• Конфигурирование опций устройств
• Описывают общую инфморацию об устройстве
INF-файлы представляют собой инициализационные файлы, которые конфигурируют
устройство или приложение в вашей системе и задают его элементы в реестре. INF-файлы
обычно поставляются производителем продукта вместе с устройством или приложением.
INF-файлы понадобятся для многих обычных (не РпР) устройств, которые нужно
конфигурировать для работы с Windows. Как правило, INF-файлы включают список
допустимых логических конфигураций, имена файлов драйверов устройств и т. д. Формат
lNF-файлов аналогичен формату INI-файлов, которые использовались в Windows З.х.
Существует два вида установки драйверов в Windows: ручной и автоматический.
Автоматический способ возможен благодаря технологии Plug and Play. Если диспетчер PnP
встречает устройство, драйвер которого не установлен, он обращается к диспетчеру PnP
пользовательского режима, и тот устанавливает нужный драйвер. Если устройство
обнаруживается при загрузке системы, для него определяется узел устройств, но загрузка
драйверов откладывается до запуска диспетчера PnP пользовательского режима.
Распределение ресурсов
Среди системных ресурсов в архитектуре PC наиболее дефицитными являются: линии
IRQ; каналы DMA; адреса, они же порты, ввода-вывода (I/O ports; «обыкновенная» память
(conventional memory).
Аппаратное прерывание – это реакция процессора на события, происходящие
асинхронно по отношению к исполняемому программному коду. Линии аппаратных
прерываний обозначили значением – IRQ (Interupt ReQuest). Физически у компьютера
имеется 15 линий аппаратных прерываний, но эта цифра сильно уменьшается за счет
прерываний, уже использованных встроенными устройствами. Но современные ОС имеют
систему ACPI. Ее функция -автоматическое распределение системных ресурсов внутри
компьютера. Изменять параметры IRQ нельзя при включенной ACPI. Она поддерживает
APIC. APIC (Advanced Programmable Interrupt Controller) - усовершенствованный
программируемый контроллер прерываний. При этом система видит 256 линий
прерываний.
По шине ISA запросы на прерывание передаются в виде перепадов логических
уровней, причем для каждого из них предназначена отдельная линия, подведенная ко всем
разъемам. Возможно возникновение неопределенной ситуации в том случае, если
несколько плат используют один канал. Чтобы этого не происходило, система
настраивается так, что каждое устройство (адаптер) использует свою линию (канал)
прерывания. Совместное использование прерывания допускается только устройствами PCI.
Эта возможность поддерживается системной BIOS и операционной системой.
Технология совместного использования прерываний для адаптеров PCI называется PCI
IRQ Steering. Эта технология дает возможность Windows с поддержкой устройств Plug and
Play динамически распределять стандартные прерывания для плат, а также назначать одно
прерывание нескольким платам PCI.
Кроме IRQ, некоторые платы расширения требуют возможности прямого доступа к
системной памяти — DMA (Direct Memory Access). Режим DMA позволяет устройству
обмениваться данными с системной памятью напрямую, а не через центральный процессор,
как это делается в режиме PIO (Programmable Input/Output — программный ввод/вывод).
Возможность прямого доступа плат расширения к памяти в принципе делает систему более
эффективной, но стандарт AT предусматривает только 7 каналов DMA (в IBM XT их было
4), что может служить еще одним источником конфликтов в системе.
Следующим дефицитным ресурсом PC-архитектуры являются порты памяти для
устройств ввода-вывода. Порты ввода-вывода — это некоторые зарезервированные группы
адресов памяти, с их помощью центральный процессор находит устройство на системной
шине и может осуществлять правильную адресацию ввода-вывода данных. Архитектура
Intel предусматривает для портов ввода-вывода специальное, отдельное от основной
памяти, адресное пространство. Такая экономия была весьма разумна для той эпохи, когда
вся системная память микрокомпьютера исчислялась единицами килобайт. Но сейчас,
когда объем RAM-памяти на системной плате достигает десятков мегабайт, старая схема
накладывает серьезные ограничения на свободу распределения адресов ввода-вывода.
Всего для адресации устройств ввода-вывода предусмотрено 16 адресных линий, что
теоретически позволяет иметь 64 Кбайта адресного пространства для портов.
Стандартная память - Conventional Memory является самой дефицитной в ПК, когда
речь идет о работе в среде операционных систем типа MS-DOS. На ее небольшой объем
(типовое значение 640 Кбайт) претендуют и BIOS, и ОС реального режима, а остатки
отдаются прикладному ПО. Стандартная память распределяется следующим образом:
• 00000h-003FFh - Interrupt Vectors - векторы прерываний (256 двойных слов);
• 00400h-004FFh - BIOS Data Area - область переменных BIOS;
• 00500h-00xxxh - DOS Area - область DOS;
• 00xxxh-9FFFFh - User RAM - память, предоставляемая пользователю (до 638 Кбайт);
при использовании PS/2 Mouse область 9FC00h-9FFFFh используется как расширение BIOS
Data Area, и размер User RAM уменьшается.
24. Свойства и применение библиотек динамической компоновки DLL. Базовые
библиотеки API Win32. Управление связыванием.
Статическая компоновка
При использовании статической компоновки готовится исходный текст приложения,
затем транслируется для получения объектного модуля. После этого редактор связей
компонует объектные модули, полученные в результате трансляции исходных текстов и
модули из библиотек объектных модулей, в один исполнимый exe-файл. В процессе
запуска файл программы загружается полностью в оперативную память, ему передается
управление.
Таким образом, при использовании статической компоновки редактор связей
записывает в файл программы все модули, необходимые для работы. В любой момент
времени в оперативной памяти компьютера находится весь код, необходимый для работы
запущенной программы.
В среде многозадачной операционной системы статическая компоновка
неэффективна, так как приводит к неэкономному использованию оперативной памяти.
Если приложения собраны с использованием статической компоновки, в памяти будут
находится одновременно несколько копий множества функций.
Очевидно, использование оперативной памяти было бы намного эффективнее, если
бы в памяти находилось только по одной копии функций, а все работающие параллельно
программы могли бы их вызывать.
Динамическая компоновка
Практически в любой многозадачной операционной системе для любого компьютера
используется именно такой способ обращения к функциям, нужным одновременно
большому количеству работающих параллельно программ.
При использовании динамической компоновки загрузочный код нескольких (или
нескольких десятков) функций объединяется в отдельные файлы, загружаемые в
оперативную память в единственном экземпляре. Программы, работающие параллельно,
вызывают функции, загруженные в память из файлов библиотек динамической
компоновки, а не из файлов программ.
Таким образом, используя механизм динамической компоновки, в загрузочном файле
программы можно расположить только те функции, которые являются специфическими
для данной программы. Те же функции, которые нужны всем (или многим) программам,
работающим параллельно, можно вынести в отдельные файлы - библиотеки динамической
компоновки, и хранить в памяти в единственном экземпляре. Эти файлы можно загружать
в память только при необходимости, например, когда какая-нибудь программа захочет
вызвать функцию, код которой расположен в библиотеке.
Код, построенный как DLL, в отличие от статической компоновки загружается по
запросам от программы. Вызывающий код содержит ссылки на модуль DLL: имя DLL,
порядковый номер. Windows-приложения используют вызовы внешних функций и
предоставляют свои функции другим программам. В заголовке файла содержаться
описания импорта и экспорта функций. Проводится соответствие между номером и
именем функции. Приложение описывается в файле *.def.
Преимущества DLL:
- всем задачам доступны все системные функции;
- малый объем кода приложения;
- легкость разделения библиотеки;
- при изменении библиотеки не надо перекомпилировать приложение.
В ХР добавлен каталог DLL Cashe, чтобы хранить разные версии DLL. Здесь хранятся
копии библиотек.
Проблемы программной совместимости. В Windows 9x существуют библиотеки,
использующиеся несколькими приложениями совместно. Так как приложения могут
использовать разные версии одних и тех же библиотек, могут возникнуть проблемы
программной совместимости (т.к. каждое приложение использует функции той версии
библиотеки, под которую было написано). При попытке заменить имеющуюся в системе
библиотеку, система уведомляет об этом пользователя и дает возможность выбрать
нужную версию. В Windows XP эта проблема решается сохранением в системе всех
использующихся библиотек в системе.
Еще
Динамическая компоновка в Windows
Все версии Windows, в том числе Windows NT, поддерживают динамическую
компоновку. При динамической компоновке используется специальный файловый формат,
который называется DLL (Dynamic Link Library - библиотека динамической компоновки).
Библиотеки динамической компоновки могут содержать процедуры, данные или то и
другое вместе. Обычно они применяются для того, чтобы два и более процессов могли
разделять процедуры и данные библиотеки. Большинство DDL-файлов имеют расширение
.dll, но встречаются и другие расширения, например .drv (для библиотек драйверов - driver
libraries) и .fon (для библиотек шрифтов - font libraries).
Самая распространенная форма DLL - библиотека, состоящая из набора процедур,
которые могут загружаться в память и к которым имеют доступ несколько процессов
одновременно. На рисунке 7.7 показаны два процесса, которые совместно используют
DLL-файл, содержащий 4 процедуры, Л, В, С и D. Программа 1 использует процедуру А;
программа 2 - процедуру С, хотя они вполне могли бы использовать одну и ту же
процедуру.
Рис. 7.7. Два процесса используют один DLL-файл
DLL-файл строится компоновщиком из группы входных файлов. Построение DDL
напоминает создание исполняемого двоичного кода, только при создании DLL
компоновщику передается специальный флаг, сообщающий о том, что требуется именно
библиотека DLL. DLL-файлы обычно собираются из набора библиотечных процедур,
которые могут понадобиться нескольким процессам. Типичными примерами DLL-файлов
являются процедуры сопряжения с библиотекой системных вызовов Windows и большими
графическими библиотеками. Применяя DDL-файлы, мы экономим пространство в памяти
и на диске. Если бы та или иная библиотека была связана статически с каждой
использующей ее программой, эту библиотеку пришлось бы включать во все исполняемые
двоичные программы в памяти и на диске, что не экономно. А при наличии DLL-файла на
диске и в памяти будет находиться всего одна библиотека.
Кроме того, такой подход упрощает обновление библиотечных процедур, причем даже
после того, как использующие их программы скомпилированы и скомпонованы. Для
коммерческих программных пакетов, где входная программа пользователям обычно
недоступна, наличие DLL-файлов означает, что поставщик программного обеспечения
сможет исправлять обнаруженные программные ошибки, просто распространяя новые
DLL-файлы через Интернету, причем при этом не потребуется никаких изменений в
двоичных кодах основных программ.
Основное различие между DLL и исполняемой двоичной программой состоит в том,
что DLL-файл не может запускаться и работать сам по себе (поскольку у него нет главной
программы). Он также содержит совершенно другую информацию в заголовке. Кроме того,
DLL-файл имеет несколько дополнительных процедур, не связанных с процедурами в
библиотеке. Например, существует одна процедура, которая вызывается автоматически
всякий раз, когда новый процесс связывается с DLL-файлом, и еще одна процедура,
которая вызывается автоматически всякий раз, когда связь процесса с DLL-файлом
разрывается. Эти процедуры могут выделять и освобождать память или управлять другими
ресурсами, необходимыми DLL-файлу.
Явная и неявная компоновка
Программа может установить связь с DLL-файлом двумя способами: путем неявной
или явной компоновки. При неявной компоновке пользовательская программа статически
компонуется со специальным файлом, так называемой библиотекой импорта. Библиотека
импорта создается специальной утилитой, предназначенной для извлечения определенной
информации из DLL-файла. Библиотека импорта предоставляет связующее звено, через
которое пользовательская программа получает доступ к DLL-файлу. Пользовательская
программа может быть связана с несколькими библиотеками импорта. Когда программа, в
которой имеет место неявная компоновка, загружается в память для исполнения, Windows
проверяет, какие DLL-файлы ей требуются и все ли они находятся в памяти. Те файлы,
которых еще нет в памяти, немедленно туда загружаются (но необязательно целиком,
поскольку они разбиты на страницы). Затем производятся определенные изменения
структур данных в библиотеках импорта так, чтобы можно было определить
местоположение вызываемых процедур (это похоже на изменения, которые иллюстрирует
рис. 7.6). Их тоже нужно отобразить на виртуальное адресное пространство программы. С
этого момента пользовательскую программу можно запускать, поскольку она может
вызывать процедуры из DLL-файлов, как будто они статически с ней связаны.
Очередность поиска библиотек
1. каталог где exe-файл
2. текущий каталог
3. системный каталог (system32)
4. каталог по переменной path
Недостатки:
1. все dll загружаются в АП
2. если не найдена хотя бы одна функция – ошибка
3. поиск dll по фиксированному муханизму
Альтернативой неявной является явная компоновка. Явная компоновка не требует ни
библиотек импорта, ни одновременной загрузки DLL-файлов с пользовательской
программой. Вместо этого пользовательская программа делает явный вызов прямо во время
работы, чтобы установить связь с DLL-файлом, а затем совершает дополнительные вызовы,
чтобы получить адреса процедур, которые ей требуются. Когда все это сделано, программа
совершает финальный вызов, чтобы разорвать связь с DLL-файлом. Когда последний
процесс разрывает связь с DLL-файлом, этот файл может быть выгружен из памяти.
1. программист должен спроецировать бблиоекку в АП
2. можно указать на сканирвоание некоторый каталог и подключать все dll – принцип
plug-in
Важно понимать, что процедура в DLL-файле не имеет отличительных признаков (как
процессы или программные потоки). Она работает в потоке вызывающей программы и для
своих локальных переменных использует стек вызывающей программы. Она может
содержать статические данные, специфичные для процесса (а также общие), а в остальном
работает, как статически скомпонованная процедура. Единственным существенным
различием является способ установления связи.
Явная и неянвая компоновка
Существует два способа загрузки DLL: с явной и неявной компоновкой.
При неявной компоновке функции загружаемой DLL добавляются в секцию импорта
вызывающего файла. При запуске такого файла загрузчик операционной системы
анализирует секцию импорта и подключает все указанные библиотеки. Ввиду своей
простоты этот способ пользуется большой популярностью; но простота - простотой, а
неявной компоновке присущи определенные недостатки и ограничения:
все подключенные DLL загружаются всегда, даже если в течение всего сеанса работы
программа ни разу не обратится ни к одной из них;
если хотя бы одна из требуемых DLL отсутствует (или DLL не экспортирует хотя бы
одной требуемой функции) - загрузка исполняемого файла прерывается сообщением
"Dynamic link library could not be found" (или что-то в этом роде) - даже если отсутствие
этой DLL некритично для исполнения программы. Например, текстовой редактор мог бы
вполне работать и в минимальной комплектации - без модуля печати, вывода таблиц,
графиков, формул и прочих второстепенных компонентов, но если эти DLL загружаются
неявной компоновкой - хочешь не хочешь, придется "тянуть" их за собой.
поиск DLL происходит в следующем порядке: в каталоге, содержащем вызывающий
файл; в текущем каталоге процесса; в системном каталоге %Windows%System%; в
основном каталоге %Windows%; в каталогах, указанных в переменной PATH. Задать
другой путь поиска невозможно (вернее - возможно, но для этого потребуется вносить
изменения в системный реестр, и эти изменения окажут влияние на все процессы,
исполняющиеся в системе - что не есть хорошо).
Явная компоновка устраняет все эти недостатки - ценой некоторого усложнения кода.
Программисту самому придется позаботиться о загрузке DLL и подключении
экспортируемых функций (не забывая при этом о контроле над ошибками, иначе в один
прекрасный момент дело кончится зависанием системы). Зато явная компоновка позволяет
подгружать DLL по мере необходимости и дает программисту возможность
самостоятельно обрабатывать ситуации с отсутствием DLL. Можно пойти и дальше - не
задавать имя DLL в программе явно, а сканировать такой-то каталог на предмет наличия
динамических библиотек и подключать все найденные к приложению. Именно так
работает механизм поддержки plug-in'ов в популярном файл-менеджере FAR (да и не
только в нем).
Таким образом, неявной компоновкой целесообразно пользоваться лишь для
подключения загружаемых в каждом сеансе, жизненно необходимых для работы
приложения динамических библиотек; во всех остальных случаях - предпочтительнее
явная компоновка.
При явном связывании программист проецирует образ DLL на АП процесса.
Некоторые
функции по управлению такими библиотеками:
• LoadLibrary() - возвращает место DLL в АП.
• Main() - инициализация библиотеки.
• GetLastError() - получает код последней ошибки. Может отслеживать правильность
работы программы
• FreeLibrary() - выгрузка библиотеки
Есть возможность подключения всех библиотек из каталога. Система ведёт счётчик
процессов, использующих одну библиотеку. При загрузке счётчик увеличивается, а
FreeLibrary() по-сути декрементирует его. После обнуления счётчика библиотека
некоторое время продолжает висеть в памяти, а затем выгружается. DLL не владеет
никакими объектами, все они принадлежат открывающему процессу. При завершении
DLL необходимо освобождать использованные объекты. Исх.код Объектный код Статич.
Библиотеки Выполн.код Динамич. Библиотеки Компоновка Загрузка
Основные DLL системы Windows
Базовые функциональные возможности Win32 API разделены на три основные
библиотеки динамической компоновки и несколько меньших DLL
Имя
Описание
KERNEL32.DLL
Системные функции низкого уровня. В этой библиотеке
находятся функции управления памятью, управления задачами,
распределения ресурсов и т. д.
USER32.DLL
Функции, управляющие работой Windows. В этой библиотеке
находятся функции для работы с сообщениями, меню, указателями
мыши, курсорами, таймерами и большинство других функций, не
связанных с выводом на экран
GDI32.DLL
Библиотека интерфейса графических устройств (GDI). DLL
содержит функции, связанные с выводом на устройства. В ней
находится большинство функций рисования, работы с контекстами
устройств, метафайлами, координатами и шрифтами
COMDLG32.DLL
Эти DLL обеспечивают дополнительные возможности, в том
LZ32.DLL
числе поддержку стандартных диалоговых окон, сжатия файлов и
VERSION32.DLL контроля версии. Иногда эти возможности доступны напрямую; в
других случаях придется использовать APIGIID32.DLL
APIGID32.DLL
Находится на компакт-диске, прилагаемом к книге. DLL
предоставляет VB-интерфейс к некоторым несовместимым функциям
Windows
API, а
также
содержит ряд дополнительных
вспомогательных функций
25. Назначение и общие свойства реестра Windows. Логическая структура и типы
данных. Физическое хранение данных реестра.
Общие сведения о реестре
Windows 2000 хранит аппаратные и программные параметры централизованно, в
иерархической базе данных, называемой реестром (registry) реестр заменяет многие
конфигурационные INI-, SYS- и СОМ- файлы, пользовавшиеся в ранних версиях Microsoft
Windows. Он предоставляет операционной системе сведения для инициализации
приложений и загрузки таких компонентов, как драйверы устройств и сетевые протоколы.
Назначение реестра.
В реестре содержатся сведения о следующих компонентах:
аппаратном
обеспечении компьютера — центральном процессоре, типе шины,
указательном устройстве или мыши, клавиатуре и т. п.:
установленных
драйверах устройств;
установленных
приложениях;
установленных сетевых протоколах;
параметрах
сетевой платы: номере IRQ, базовом адресе памяти, базовом адресе порта
ввода-вывода, готовности канала ввода-вывода и типе трансивера.
Поддеревья реестра
Чтобы быстро найти определенные разделы и значения в реестре, следует знать
назначение каждого поддерева. на рисунке 3 редактором реестра отображаются
следующие
пять
поддеревьев:
- HKEY_LOCAL_MACHINE - содержит сведения о локальном компьютере, в том числе
об аппаратной организации и операционной системе, например: о типе системной шины,
памяти, драйверах устройств и параметрах загрузки. Приложения, драйверы устройств и
операционная система используют эти сведения для настройки компьютера. Данные в
этом
поддереве
неизменны,
независимо
от
текущего
пользователя.
- HKEY_USERS - содержит параметры системы по умолчанию (стандартный профиль
пользователя) для контроля индивидуальных параметров среды, например, рабочего стола,
отображения
окон
и
доступного
программного
обеспечения.
- HKEY_CURRENT_USER - содержит данные о текущем пользователе. Извлекает копию
каждой учетной записи, применяемой для входа в систему, и сохраняет её в разделе
systemroot\Documents
And
Settings\имя_пользователя.
- HKEY_CLASSES_ROOT - содержит сведения, используемые технологиями OLE, и
привязки расширений имен файлов к приложениям (эквивалент реестра в Windows для
MS-DOS). Указывает на подраздел HKEY_LOCAL_MACHINE\SOFTWARE\Classes.
- HKEY_CURRENT_CONFIG - содержит данные об активном аппаратном профиле,
извлеченные из кустов SOFTWARE и SYSTEM. Эти сведения используются для настройки
загружаемых драйверов и разрешения дисплея.
Как реестр хранится на жестком диске компьютера
Разобравшись с типами папок реестра, давайте посмотрим, как именно они хранятся
на компьютере. Это знание поможет вам в случае форс-мажорных обстоятельств
восстановить вашу систему. Весь реестр, как и следовало ожидать, хранится в обычных
файлах, причем разные папки реестра в разных физических файлах. Как правило, каждая
корневая папка реестра хранится не в одном, а в трех разных физических файлах. Первый,
без расширения, и есть сам бинарный файл содержимого папки. Необходимость второго
файла, с расширением LOG, вытекает из того обстоятельства, что реестр является
журналируемой файловой системой. В файле LOG хранятся протоколы всех транзакций,
проводившихся в реестре. В том случае, если ваш компьютер повиснет на половине дороги
записи каких-либо данных в реестр, система по логам, хранящимся в файле LOG, сделает
откат изменений. За счет этого механизма обеспечивается однозначность всех операций с
реестром. Данные могут быть или записаны в реестр, или нет. "Наполовину" записанных
данных в реестре не бывает — тут дело обстоит как в известном анекдоте про
беременность и файловой системе NTFS.
Третий тип файлов, называющийся SAV, для нас малоинтересен. Эти файлы создает
установщик Windows по окончанию текстовой фазы установки. Если в последующем
графическом режиме что-либо пойдет наперекосяк, Windows пользуется этими файлами
для восстановления реестра. В дальнейшем, насколько я понял, эти файлы не
используются. Если вы переименуете файлы SAV в одноименные файлы без расширения,
этим самым вы вернетесь на этап самого начала установки Windows. Она затребует диск с
дистрибутивом и продолжит установку так, как будто вы только что ее прервали, а не
работали на системе несколько месяцев.
Итак, давайте посмотрим, как именно называются файлы, в которых хранятся
основные папки реестра.
Папка HKEY_LOCAL_MACHINE\SAM
Папка реестра, отвечающая за настройки всех участников безопасности Windows. В
обычном REGEDIT эта папка выглядит пустой, хотя это вовсе не так. У вас просто нет
прав даже на чтение ее содержимого. Существуют альтернативные редакторы реестра
(например, мой любимый RESPLENDENT REGISTRAR), с помощью которых можно
увидеть и даже отредактировать ее ключи. Хранится содержимое этой папки в файлах,
находящихся в каталоге C:\WINDOWS\SYSTEM32\ CONFIG. Файлы называются SAM,
SAM.SAV и SAM.LOG.
Папка HKEY_LOCAL_MACHINE\SECURITY
Папка реестра, также отвечающая за настройки безопасности Windows. Эта папка
вообще не видна в обычном редакторе реестра REGEDIT. Редактор REGISTRAR позволяет
смотреть и редактировать. В этой ветви живут пользователи, группы, относящиеся к ним
политики безопасности и тому подобные вещи. Содержимое этой папки хранится в
файлах, также находящихся в каталоге C:\WINDOWS\SYSTEM32\ CONFIG. Файлы
называются SECURITY, SECURITY.SAV и SECURITY.LOG.
Папка HKEY_LOCAL_MACHINE\SOFTWARE
Папка реестра, в которой хранятся настройки различных приложений и самого
Windows, общие для всех пользователей. Папка доступна для редактирования обычным
REGEDIT, так что сами посмотрите, что именно в ней лежит. Как вы уже, наверно,
догадались, содержимое этой папки, опять-таки, хранится в файлах, находящихся в
каталоге
C:\WINDOWS\SYSTEM32\CONFIG.
Файлы
называются
SOFTWARE,
SOFTWARE.SAV и SOFTWARE.LOG.
Папка HKEY_LOCAL_MACHINE\SYSTEM
Папка реестра, в которой хранятся настройки вашего компьютерного железа. Тут же
лежат описания запускаемых на вашей машине сервисов и тому подобные низкоуровневые
вещи. Папка доступна для свободного редактирования через REGEDIT. Содержимое этой
папки хранится в файлах, находящихся в каталоге... Ну как, догадались? Так и есть:
C:\WINDOWS\SYSTEM32\CONFIG. Файлы называются SYSTEM, SYSTEM.SAV и
SYSTEM.LOG.
Папка HKEY_USERS\.DEFAULT
Папка реестра, в которой хранятся настройки так называемого "пользователя по
умолчанию". Настройки этого пользователя служат своеобразным макетом, на основе
которого формируются настройки всех остальных вновь создаваемых вами пользователей.
Система просто копирует все содержимое этой папки в папку HKEY_USERS вновь
созданного пользователя. Папка доступна для свободного редактирования через REGEDIT.
Содержимое этой папки хранится в файлах, находящихся в каталоге
C:\WINDOWS\SYSTEM32\ CONFIG. Файлы называются DEFAULT, DE-FAULT.SAV и
DEFAULT.LOG.
Папки каждого отдельного пользователя внутри HKEY_USERS
Хранят настройки программ под каждого конкретного пользователя, имеющегося в
вашей системе. В момент установки WINDOWS XP регистрирует как минимум двух
пользователей — "Администратора" и того пользователя, имя которого вы указали на
одном из экранов ее установки. Папка доступна для свободного редактирования через
REGEDIT. Содержимое этой папки хранится в файлах, находящихся в каталоге... а вот и не
угадали! На этот раз — в C:\Documents and Settings\<имя пользователя>. Файл называется
NTUSER. DAT. Рядышком обычно лежат файлы-компаньоны. В файле NTUSER.LOG
хранится содержимое ветви HKEY_ CURRENT_USER. Файлы NTUSER.POL и
NTUSER.INI создаются редактором глобальных политик WINDOWS, в них хранятся
созданные с его помощью политики для этого пользователя. О редакторе политик мы еще
с вами поговорим в последующих статьях цикла.
Папка HKEY_USERS\USER_CLASSES
Эта
папка
является
дополнением
к
папке
HKEY_LOCAL_MACHINE\SOFTWARE\CLASSES. В ней хранятся классы и типы
приложений, зарегистрированные (или измененные) под этого конкретного пользователя.
Например, в этой папке на моем ноутбуке хранятся расширения файлов, которые
зарегистрировал "под себя" медиа-плейер BS PLAY (он идет на доброй половине всех
MPEG4-видеодисков). Эти данные хранятся в файлах USRCLASS.DAT и
USRCLASS.DAT.LOG. Файлы расположены в папке C:\Documents and Settings\ <имя
пользователя>\Local Settings\Ap-plication Data\Microsoft\ Windows.
Если вы внимательно проанализировали соответствие файлов и папок, то наверняка
обратили внимание на то, что в моем списке отсутствуют такие важные папки, как
HKEY_LOCAL_ MACHINE и HKEY_USERS. Так вот, и эти папки также являются
фикцией. В реальности подобных папок просто не существует. Система строит их для
нашего удобства, и не более того. Именно благодаря отсутствию объединяющего начала
для всех этих файлов мы можем свободно комбинировать между собой текущие файлы и
архивные или даже и вовсе файлы, взятые с другого компьютера.
26. Типовые операции с реестром. Обзор ключей реестра HK_Classes_Root и
HK_Local_Machine.
Операции
1. поиск информации
2. резервное копирование
3. экспорт-импрорт
4.редактирование
Она состоит из пяти командных меню, разворачиваемых по щелчку мышью на их
заголовках:
меню Файл (Реестр) позволяет осуществлять операции экспорта - импорта файла
реестра и его отдельных компонентов, выводить содержимое какого - либо фрагмента
реестра на печать или открывать для редактирования файлы реестра других ПК,
расположенных в локальной сети;
меню Правка позволяет выполнять операции создания, удаления, переименования
логических элементов реестра, выполнять процедуры поиска, настраивать режимы
безопасности;
меню Вид управляет настройками интерфейса Редактора реестра;
меню Избранное позволяет устанавливать закладки на различные разделы и
подразделы реестра для последующего быстрого перехода к ним;
меню Справка вызывает встроенную справочную систему программы Редактор
реестра.
HKEY_CLASSES_ROOT — раздел содержит ассоциации между приложениями и
типами файлов (по расширениям имени файла), кроме того, этот ключ содержит
информацию OLE (Object Linking and Embedding), ассоциированную с объектами COM, а
также данные по ассоциациям файлов и классов. Параметры этого ключа совпадают с
параметрами, расположенными под ключом HKEY_LOCAL_MACHINE\Software\Classes.
HKEY_LOCAL_MACHINE — наиболее интересный раздел, так как именно здесь
сосредоточены основные настройки программного обеспечения ОС. Содержит глобальную
информацию об аппаратных средствах и ОС, в том числе: тип шины, системная память,
драйверы устройств. Информация, содержащаяся в этом разделе, действует
применительно ко всем пользователям.
HKEY_CLASSES_ROOT
HKCR включает информацию двух типов: сопоставления расширений файлов и
регистрационные данные COMклассов. Для каждого зарегистрированного типа файлов
существует свой раздел. Большинство разделов содержит параметры типа REG_SZ,
ссылающиеся на другие разделы HKCR, где находится информация о сопоставлениях
классов файлов. Например, HKCR\.xls ссылается на сведения о файлах Microsoft Excel в
разделе HKCU\Excel.Sheet.8 (последняя цифра указывает на версию Microsoft Excel).
Другие разделы содержат детальную информацию о конфигурации COMобъектов,
зарегистрированных в системе.
Раздел HKEY_CLASSES_ROOT формируется на основе:
специфичных для конкретного пользователя регистрационных данных классов в
HKCU\SOFTWARE\Classes (хранятся в \Documents and Settings\ <имя_пользователя>\Local
Settings\Application Data\Microsoft\Windows\ Usrclass.dat);
общесистемных регистрационных данных классов в HKLM\SOFTWARE\Classes.
Причина, по которой регистрационные данные, специфичные для каждого
пользователя, были отделены от общесистемных, заключается в том, что это дает
возможность включать соответствующие настройки и в профили «блуждающих»
пользователей (профили роуминга). Это же устранило дыру в защите:
непривилегированный пользователь не может изменить или удалить разделы в
HKEY_CLASSES_ROOT и тем самым повлиять на функционирование приложений в
системе. Непривилегированные пользователи и приложения могут считывать
общесистемные данные и добавлять новые разделы и параметры в общесистемные данные
(которые отражаются на данные, специфичные для этих пользователей), но изменять
существующие разделы и параметры им разрешается лишь в собственных данных.
HKEY_LOCAL_MACHINE
HKLM — корневой раздел, содержащий подразделы с общесистемной
конфигурационной информацией: HARDWARE, SAM, SECURITY, SOFTWARE и
SYSTEM.
Подраздел HKLM\HARDWARE содержит описание аппаратного обеспечения
системы и все сопоставления драйверов с устройствами. Диспетчер устройств, который
запускается с вкладки Hardware (Оборудование) окна свойствсистемы, позволяет
просматривать информацию об устройствах, получаемую простым считыванием значений
параметров из раздела HARDWARE. Здесь ссылки на устройства в SYSTEM.
В HKLM\SAM находится информация о локальных учетных записях и группах,
например пароли, определения групп и сопоставления с доменами. Система Windows
Server, работающая как контроллер домена, хранит доменные и групповые учетные записи
в Active Directory — базе данных, которая содержит общедоменные параметры и сведения.
(Active Directory в этой книге не рассматривается.) По умолчанию дескриптор защиты
раздела SAM сконфигурирован так, что к нему не имеет доступа даже администратор.
В HKLM\SECURITY хранятся данные, которые относятся к общесистемным
политикам безопасности, а также сведения о правах, назначенных пользователям.
HKLM\SAM связан с подразделом SECURITY в разделе HKLM\SECURITY\SAM. По
умолчанию содержимое HKLM\SECURITY недоступно для просмотра, поскольку
параметры защиты разрешают доступ только по учетной записи System. Вы можете
сменить дескриптор защиты, чтобы администраторы получили доступ к этому разделу для
чтения, или, если вам любопытно, что там находится, запустить Regedit под локальной
системной учетной записью с помощью PsExec (как это сделать, будет показано в
соответствующем эксперименте). Но это почти ничего не даст, так как данные в нем не
документированы, а пароли зашифрованы (по алгоритму необратимогошифрования).
HKLM\SOFTWARE — то место, где Windows хранит общесистемную
конфигурационную информацию, не требуемую при загрузке системы. Кроме того, здесь
сохраняют свои общесистемные настройки приложения сторонних разработчиков (пути к
файлам, каталоги приложений, даты лицензий исроки их окончания).
HKLM\SYSTEM содержит общесистемную конфигурационную информацию,
необходимую для загрузки системы, например списки загружаемых драйверов и
запускаемых сервисов. Поскольку эта информация критична для запуска системы,
Windows делает ее копию, называемую последней удачной конфигурацией (last known
good control set). Она позволяет вернуться к последней работоспособной конфигурации,
если после изменений, внесенных в текущую конфигурацию, система перестала
загружаться. Подробнее об этом — ближе к концу главы.
27. Понятие и свойства учетной записи пользователя Windows. Пофиль пользователя
и его представление в реестре.
Учетная запись пользователя является коллекцией информации, которая сообщает
Windows о файлах и папках, к которым имеет доступ пользователь, какие изменения в
компьютере он может выполнять, а также личные настройки, например фон рабочего стола
и экранную заставку. Применение учетных записей позволяет нескольким пользователям
работать на одном компьютере с использованием собственных файлов и параметров. Для
доступа к учетной записи используется имя пользователя и пароль.
Существуют три типа учетных записей. Каждый тип дает пользователю разные
возможности для управления компьютером.
Стандартные учетные записи пользователей предназначены для повседневной работы.
Учетные записи администратора предоставляют полный контроль над компьютером и
применяются только в необходимых случаях.
Учетные записи гостя предназначены для временного доступа к компьютеру.
Локальный профиль пользователя хранится на компьютере в каталоге, имя которой
совпадает с именем данного пользователя, находящейся в каталоге Documents and Settings.
Если для данного пользователя не существует сконфигурированного или перемещаемого
(находящегося на сервере) профиля, то при первой регистрации пользователя в компьютере
для него создается индивидуальный профиль. Содержимое каталога Default User
копируется в каталог нового профиля пользователя. Информация профиля, вместе с
содержимым папки All Users используется при конфигурации рабочей среды пользователя.
При завершении пользователем работы на компьютере все сделанные им изменения
настроек рабочей среды, выбираемых по умолчанию, записываются в его профиль.
Содержимое Default User остается неизменным.
Каталог профиля пользователя на локальном компьютере содержит файл NTuser.dat и
файл журнала транзакций с именем NTuser.dat.LOG. Он нужен для обеспечения
отказоустойчивости, позволяя Windows восстанавливать профиль пользователя в случае
сбоя при модификации содержимого файла NTuser.dat.
Профиль пользователя создается на основе профиля, назначенного по умолчанию.
Имеются скрытые системные папки Default и All Users, используемые для определения
параметров стандартного профиля и представляющие собой реальные папки файловой
системы. Папка Default User оставлена для совместимости и является ссылкой. Эти папки,
как и папки пользовательских профилей, также хранятся в папке Пользователи (Users)
корневого каталога загрузочного диска.
Состав пользовательского каталога представлен на рисунке (рис. 44). Их назначение на
рис. 45.
рис. 45
рис. 44
HKEY_USERS
HKU содержит подраздел для каждого загруженного профиля пользователя,
регистрационную базу данных классов и подраздел HKU\.DEFAULT, связанный с
профилем для системы (этот профиль предназначен для процессов, выполняемых под
локальной системной учетной записью; см. раздел «Сервисы» далее в этой главе). Данный
профиль используется Winlogon, например, чтобы изменения в параметрах фона рабочего
стола были реализованы на экране входа. Если пользователь входит в систему в первый
раз и если его учетная запись не зависит от доменного профиля роуминга (т. е. профиль
пользователя извлекается из централизованного хранилища в сети по указанию
контроллера домена), система создает профиль для его учетной записи на основе профиля,
хранящегося в каталоге C:\Documents and Settings\Default User.
Каталог, где система хранит профили, определяется параметром реестра
HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\ProfilesDirectory, который
по умолчанию устанавливается в %SystemDrive%\Documents and Settings. Раздел ProfileList
также хранит список профилей, имеющихся в системе. Информация по каждому профилю
помещается в подраздел, имя которого отражает SID учетной записи, соответствующей
данному профилю (сведения о SID см. в главе 8). Информация в разделе профиля
включает время последней загрузки этого профиля (параметры ProfileLoadTimeLow
иProfileLoadTimeHigh), двоичное представление SID учетной записи (параметр Sid) и путь
к кусту профиля на диске в каталоге ProfileImagePath (о кустах см. раздел «Кусты» далее в
этой главе). Windows XP и Windows Server 2003 показывают список профилей в
диалоговом окне управления профилями пользователей, которое представлено на рис. 41.
Чтобы открыть это окно, запустите апплет System (Система) из Control Panel (Панель
управления), перейдите на вкладку Advanced (Дополнительно) и в разделе User Profiles
(Профили пользователей) щелкните кнопку Settings (Параметры).
28. Характеристика ОС Linux. Состав и специфика дистрибутивов, проблемы
стандартизации и распространения.
Устанавливая Linux, вы получаете множество преимуществ:
• Гибкость. Мало того, что практически все в Linux поддается настройке в
соответствии с именно вашими задачами и оборудованием, так вам еще и становятся
доступны исходные тексты ядра и приложений, и вы можете модифицировать систему так,
как вам нужно. Такое можно встретить далеко не в каждой операционной системе,
особенно семейства Windows. Вы видели где-нибудь исходные тексты хотя бы Блокнота
Windows? Мне, например, очень не хватает функции замены текста в этом редакторе. Для
решения этой проблемы я написал собственный редактор, в котором и реализовал эту
функцию. А если мне нужно сделать небольшое изменение в ядре? Не буду же я
полностью переписывать Windows? Остается только надеяться, что новая функция будет
реализована в следующей версии, и ради этой единственной функции устанавливать
«монстра», пожирающего еще больше системных ресурсов.
• Дешевизна. ОС Linux абсолютно бесплатна. Конечно, компакт-диски с
дистрибутивами продаются за деньги, но эти деньги вы платите не за лицензию, а за сам
носитель, подбор программного обеспечения на нем и программу-инсталлятор — все, как
у пиратов, с той лишь разницей, что это: а) полностью легально, б) гарантированно
работает и пользуется технической поддержкой. Вы можете и не покупать дистрибутив, а
анонимно и бесплатно выкачать исходные тексты или уже собранные программы из
Интернета, установив их самостоятель но и заплатив только за трафик — и это тоже
полностью легально. Вам не придется ничего доплачивать, устанавливая Linux на каждый
следующий компьютер, не нужно покупать отдельную лицензию на использование Linux
на сервере. В любом случае стоимость всего программного обеспечения составит всего
несколько долларов. Я не буду сравнивать стоимость построения Linux-сервера со
стоимостью аналогичного сервера на платформе Microsoft, вы сами можете это сделать на
сайте компании Microsoft.
• Простота обслуживания. Сама система и все службы настраиваются путем
редактирования конфигурационных файлов. Это обычные текстовые файлы; зная их
расположение и формат, вы сможете настроить любой дистрибутив, даже если у вас под
рукой нет никаких инструментов, кроме текстового редактора. Кроме того, для об
легчения перехода с ОС Windows NT/2000/2003 Server, где сервисы настраиваются в
основном через графический интерфейс, создано множество графических конфигураторов,
работа с которыми интуитивно понятна и позволяет сосредоточиться на сути
выполняемых действий, а не способе их выполнить.
• Нетребовательность к ресурсам. Системные требования зависят от дистрибутива
(конкретной реализации Linux) и версии ядра. Существуют дистрибутивы, специально
созданные для корректной работы на старых и «бедных» машинах. Например, для
организации интернетсервера на базе дистрибутива Red Hat версии 5.2 вам вполне хватит
компьютера с процессором Intel 80486DX и 32 мегабайтами ОЗУ. А окончательно
устаревшую 386 машину, на которой никакая современная ОС Windows не запустится, под
управлением Linux можно вернуть в строй в качестве маршрутизатора или брандмауэра.
• мощные инструменты средства разработчиков
• ориентация на сетевые задачи
Проблемы
1. переучиваться
2. админ должен иметь хорошую подготовку
3. модульность – приводит к разделдению на множетсво направлений, сложность с
совместимостью
О дистрибутивах можно говорить очень долго. Сегодня существует три основных
дистрибутива: Red Hat, Slackware и Debian. Все остальные дистрибутивы являются
производными от этих трех дистрибутивов.
чем отличаются дистрибутвы:
1. структурой ФС
2. программой установки
3. средствами установки программных пакетов
4ю составом системынх утилит и оболочками, сетевыми программами
В силу того, что исходные коды Linux распространяются свободно и общедоступны, к
развитию системы с самого начала подключилось большое число независимых
разработчиков. Благодаря этому на сегодняшний момент Linux - самая современная,
устойчивая и быстроразвивающаяся система, почти мгновенно вбирающая в себя самые
последние технологические новшества. Она обладает всеми возможностями, которые
присущи современным полнофункциональным операционным системам типа UNIX.
Приведем
краткий
список
этих
возможностей.
Реальная
многозадачность
Все процессы независимы; ни один из них не должен мешать выполнению других задач.
Для этого ядро осуществляет режим разделения времени центрального процессора,
поочередно выделяя каждому процессу интервалы времени для выполнения. Это
существенно отличается от режима "вытесняющей многозадачности", реализованной в
Windows 95, когда процесс должен сам "уступить" процессор другим процессам (и может
сильно
задержать
их
выполнение).
Многопользовательский
доступ
Linux - не только многозадачная ОС, она поддерживает возможность одновременной
работы многих пользователей. При этом Linux может предоставлять все системные
ресурсы пользователям, работающим с хостом через различные удаленные терминалы.
Свопирование
оперативной
памяти
на
диск
Свопирование оперативной памяти на диск позволяет работать при ограниченном объеме
физической оперативной памяти; для этого содержимое некоторых частей (страниц)
оперативной памяти записываются в выделенную область на жестком диске, которая
трактуется как дополнительная оперативная память. Это несколько снижает скорость
работы, но позволяет организовать работу программ, требующих большего объема ОЗУ,
чем
фактически
имеется
в
компьютере.
Страничная
организация
памяти
Системная память Linux организована в виде страниц объемом 4K. Если оперативная
память полностью исчерпана, ОС будет искать давно не использованные страницы памяти
для их перемещения из памяти на жесткий диск. Если какие-либо из этих страниц
становятся нужны, Linux восстанавливает их с диска. Некоторые старые Unix-системы и
некоторые современные платформы (включая Microsoft Windows) переносят на диск все
содержимое ОП, относящееся к неработающему в данный момент приложению, (т. е. ВСЕ
страницы памяти, относящиеся к приложению, сохраняются на диске при нехватке
памяти)
что
менее
эффективно.
Загрузка
выполняемых
модулей
"по
требованию"
Ядро Linux поддерживает выделение страниц памяти по требованию, при котором только
необходимая часть кода исполняемой программы находится в оперативной памяти, а не
используемые
в
данный
момент
части
остаются
на
диске.
Совместное
использование
исполняемых
программ
Если необходимо запустить одновременно несколько копий какого-то приложения (либо
один пользователь запускает несколько идентичных задач, либо разные пользователи
запускают одну и ту же задачу), то в память загружается только одна копия исполняемого
кода этого приложения, которая используется всеми одновременно исполняющимися
идентичными
задачами.
Общие
библиотеки
Библиотеки - наборы процедур, используемых программами для обработки данных.
Существует некоторое количество стандартных библиотек, используемых одновременно
более чем одним процессом. В старых системах такие библиотеки включались в каждый
исполняемый файл, одновременное выполнение которых приводило к непродуктивному
использованию памяти. В новых системах (в частности, в Linux), обеспечивается работа с
динамически и статически разделяемыми библиотеками, что позволяет сократить размер
отдельных
приложений.
Динамическое кеширование диска
Кеширование диска - это использование части оперативной памяти для хранения
часто используемых данных с диска, что существенно ускоряет доступ к часто
используемым программам и задачам. Пользователи MS-DOS работают со SmartDrive,
который резервирует фиксированные области системной памяти для кеширования диска.
Linux использует более динамичную систему кеширования: память, зарезервированная под
кеш, увеличивается, когда память не используется, и уменьшается, если системе или
процессу пользователя требуется больше памяти. 100%-ное соответствие стандарту POSIX
1003.1.
Частичная
поддержка
возможностей
System
V
и
BSD
POSIX 1003.1 (Portable Operating System Interface - интерфейс мобильной операционной
системы) задаeт стандартный интерфейс Unix-систем, который описывается набором
процедур языка Си. Сейчас он поддерживается всеми новыми ОС. Microsoft Windows NT
также поддерживает POSIX 1003.1. Linux 100%-но соответствует POSIX. Дополнительно
поддерживаются некоторые возможности System V и BSD для увеличения совместимости.
System
V
IPC
Linux использует технологию IPC (InterProcess Communication) для обмена сообщениями
между
процессами,
использования
семафоров
и
общей
памяти.
Возможность
запуска
исполняемых
файлов
других
ОС
Linux не является первой в истории операционной системой. Для ранее разработанных ОС,
включая DOS, Windows 95, FreeBSD или OS/2, разработана масса различного, в том числе
очень полезного и очень неплохого программного обеспечения. Для запуска таких
программ под Linux разработаны эмуляторы DOS, Windows 3.1 и Windows 95. Более того,
фирмой Vmware разработана система "виртуальных машин", представляющая собой
эмулятор компьютера, в котором можно запустить любую операционную систему.
Имеются аналогичные разработки и у других фирм. ОС Linux способна также выполнять
бинарные файлы других Intel-ориентированных Unix-платформ, соответствующих
стандарту
iBCS2
(intel
Binary
Compatibility).
Поддержка
различных
форматов
файловых
систем
Linux поддерживает большое число форматов файловых систем, включая файловые
системы DOS и OS/2, а также современные журналируемые файловые системы. При этом
и собственная файловая система Linux, которая называется Second Extended File System
(ext2fs),
позволяет
эффективно
использовать
дисковое
пространство.
Сетевые
возможности
Linux можно интегрировать в любую локальную сеть. Поддерживаются все службы Unix,
включая Networked File System (NFS), удалeнный доступ (telnet, rlogin), работа в TCP/IP
сетях, dial-up-доступ по протоколам SLIP и PPP, и т. д.. Также поддерживается включение
Linux-машины как сервера или клиента для другой сети, в частности, работает общее
использование (sharing) файлов и удаленная печать в Macintosh, NetWare и Windows.
Работа
на
разных
аппаратных
платформах
Хотя ОС Linux первоначально была разработана для ПК на базе Intel 386/486, Так же
успешно Linux работает на различных клонах Intel от других производителей; в Интернете
встречаются сообщения о том, что на процессорах Athlon и Duron от AMD Linux работает
даже лучше, чем на Intel. Кроме того, разработаны версии для других типов процессоров ARM, DEC Alpha, SUN Sparc, M68000 (Atari и Amiga), MIPS, PowerPC и других (отметим,
что в настоящей книге рассматривается только вариант для IBM-совместимых
компьютеров).
29. Структура и функции ядра Linux. Современные тенденции в развитии ядра.
Введение в ядро Linux
Перейдем к общему обзору архитектуры операционной системы GNU/Linux.
Операционную систему можно условно разделить на два уровня, как показано на Рис. 2.
Рис. 2. Фундаментальная архитектура операционной системы GNU/Linux
На верхнем уровне находится пользовательское пространство (пространство
приложений). Здесь исполняются приложения пользователя. Под пользовательским
пространством располагается пространство ядра. Здесь функционирует ядро Linux.
Имеется также библиотека GNU C (glibc). Она предоставляет интерфейс системных
вызовов, который обеспечивает связь с ядром и дает механизм для перехода от
приложения, работающего в пространстве пользователя, к ядру. Это важно, поскольку
ядро и пользовательское приложение располагаются в разных защищенных адресных
пространствах. При этом, в то время как каждый процесс в пространстве пользователя
имеет свое собственное виртуальное адресное пространство, ядро занимает одно общее
адресное пространство. Более подробную информацию можно найти в литературе, ссылки
на которую приведены в разделе "Ресурсы".
Ядро Linux можно, в свою очередь, разделить на три больших уровня. Наверху
располагается интерфейс системных вызовов, который реализует базовые функции,
например, чтение и запись. Ниже интерфейса системных вызовов располагается код ядра,
точнее говоря, архитектурно-независимый код ядра. Этот код является общим для всех
процессорных архитектур, поддерживаемых Linux. Еще ниже располагается архитектурнозависимый код, образующий т.н. BSP (Board Support Package - пакет поддержки
аппаратной платформы). Этот код зависит от процессора и платформы для конкретной
архитектуры.
Свойства ядра Linux
Обсуждая архитектуру большой и сложной системы, можно рассматривать ее со
многих разных точек зрения. Одна из целей архитектурного анализа может состоять в том,
чтобы лучше понять исходный код системы. Именно этим мы здесь и займемся.
В ядре Linux реализован целый ряд важных архитектурных элементов. И на самом
общем, и на более детальных уровнях ядро можно подразделить на множество различных
подсистем. С другой стороны, Linux можно рассматривать как монолитное целое,
поскольку все базовые сервисы собраны в ядре системы. Такой подход отличается от
архитектуры с микроядром, когда ядро предоставляет только самые общие сервисы, такие
как обмен информацией. ввод/вывод, управление памятью и процессами, а более
конкретные сервисы реализуются в модулях, подключаемых к уровню микроядра. Каждая
из этих точек зрения имеет свои достоинства, но я здесь не буду вдаваться в это
обсуждение.
С течением времени ядро Linux стало более эффективным с точки зрения
использования памяти и процессорных ресурсов и приобрело исключительную
стабильность. Однако самый интересный аспект Linux, учитывая размер и сложность этой
системы - это ее переносимость. Linux можно откомпилировать для огромного количества
разных процессоров и платформ, имеющих разные архитектурные ограничения и
потребности. Например, Linux может работать на процессоре как с блоком управления
памятью (MMU), так и без MMU. Поддержка процессоров без MMU реализована в версии
ядра uClinux. Более подробную информацию см. в разделе "Ресурсы".
В начало
Основные подсистемы ядра Linux
Давайте рассмотрим некоторые основные компоненты ядра Linux, следуя структуре,
изображенной на рис. 3.
Рис. 3. Один из возможных взглядов на архитектуру ядра Linux
Интерфейс системных вызовов
SCI - это тонкий уровень, предоставляющий средства для вызова функций ядра из
пространства пользователя. Как уже говорилось, этот интерфейс может быть архитектурно
зависимым, даже в пределах одного процессорного семейства. SCI фактически
представляет собой службу мультиплексирования и демультиплексирования вызова
функций. Реализация SCI находится в ./linux/kernel, а архитектурно-зависимая часть - в
./linux/arch. Более подробные сведения об этом компоненте можно найти в
разделе Ресурсы.
Управление процессами
Управление процессами сконцентрировано на исполнении процессов. В ядре эти
процессы
называются потоками (threads);
они
соответствуют
отдельным
виртуализованным объектам процессора (код потока, данные, стек, процессорные
регистры). В пространстве пользователя обычно используется термин процесс, хотя в
реализации Linux эти две концепции (процессы и потоки) не различают. Ядро
предоставляет интерфейс программирования приложений (API) через SCI для создания
нового процесса (порождения копии, запуска на исполнение, вызова функций Portable
Operating System Interface [POSIX]), остановки процесса (kill, exit), взаимодействия и
синхронизации между процессами (сигналы или механизмы POSIX).
Еще одна задача управления процессами - совместное использование процессора
активными потоками. В ядре реализован новаторский алгоритм планировщика, время
работы которого не зависит от числа потоков, претендующих на ресурсы процессора.
Название этого планировщика - O(1) - подчеркивает, что на диспетчеризацию одного
потока затрачивается столько же времени, как и на множество потоков. Планировщик O(1)
также поддерживает симметричные многопроцессорные конфигурации (SMP). Исходные
коды системы управления процессами находятся в ./linux/kernel, а коды архитектурнозависимой части - в ./linux/arch). Более подробную информацию об этом алгоритме см. в
разделе Ресурсы.
Управление памятью
Другой важный ресурс, которым управляет ядро - это память. Для повышения
эффективности, учитывая механизм работы аппаратных средств с виртуальной памятью,
память организуется в виде т.н. страниц (в большинстве архитектур размером 4 КБ). В
Linux имеются средства для управления имеющейся памятью, а также аппаратными
механизмами для установления соответствия между физической и виртуальной памятью.
Однако управление памятью - это значительно больше, чем просто управление
буферами по 4 КБ. Linux предоставляет абстракции над этими 4 КБ буферами, например,
механизм распределения slab allocator. Этот механизм управления базируется на 4 КБ
буферах, но затем размещает структуры внутри них, следя за тем, какие страницы полны,
какие частично заполнены и какие пусты. Это позволяет динамически расширять и
сокращать схему в зависимости от потребностей вышележащей системы.
В условиях наличия большого числа пользователей памяти возможны ситуации, когда
вся имеющаяся память будет исчерпана. В связи с этим страницы можно удалять из
памяти и переносить на диск. Этот процесс обмена страниц между оперативной памятью и
жестким диском называется подкачкой. Исходные коды управления памятью находятся в
./linux/mm.
Виртуальная файловая система
Еще один интересный аспект ядра Linux - виртуальная файловая система (VFS),
которая предоставляет общую абстракцию интерфейса к файловым системам. VFS
предоставляет уровень коммутации между SCI и файловыми системами,
поддерживаемыми ядром (см. Рис. 4).
Рис. 4. VFS предоставляет коммутационную матрицу между пользователями и
файловыми системами
На верхнем уровне VFS располагается единая API-абстракция таких функций, как
открытие, закрытие, чтение и запись файлов. На нижнем уровне VFS находятся
абстракции файловых систем, которые определяют, как реализуются функции верхнего
уровня. Они представляют собой подключаемые модули для конкретных файловых систем
(которых существует более 50). Исходные коды файловых систем находятся в ./linux/fs.
Ниже уровня файловой системы находится кэш буферов, предоставляющий общий
набор функций к уровню файловой системы (независимый от конкретной файловой
системы). Этот уровень кэширования оптимизирует доступ к физическим устройствам за
счет краткосрочного хранения данных (или упреждающего чтения, обеспечивающего
готовность данных к тому моменту, когда они понадобятся). Ниже кэша буферов
находятся драйверы устройств, реализующие интерфейсы для конкретных физических
устройств.
Сетевой стек
Сетевой стек по своей конструкции имеет многоуровневую архитектуру,
повторяющую структуру самих протоколов. Вы помните, что протокол Internet Protocol
(IP) - это базовый протокол сетевого уровня, располагающийся ниже транспортного
протокола Transmission Control Protocol, TCP). Выше TCP находится уровень сокетов,
вызываемый через SCI.
Уровень сокетов представляет собой стандартный API к сетевой подсистеме. Он
предоставляет пользовательский интерфейс к различным сетевым протоколам. Уровень
сокетов реализует стандартизованный способ управления соединениями и передачи
данных между конечными точками, от доступа к "чистым" кадрам данных и блокам
данных протокола IP (PDU) и до протоколов TCP и User Datagram Protocol (UDP).
Исходные коды сетевой подсистемы ядра находятся в каталоге ./linux/net.
Драйверы устройств
Подавляющее большинство исходного кода ядра Linux приходится на драйверы
устройств, обеспечивающие возможность работы с конкретными аппаратными
устройствами. В дереве исходных кодов Linux имеется подкаталог драйверов, в котором, в
свою очередь, имеются подкаталоги для различных типов поддерживаемых устройств,
таких как Bluetooth, I2C, последовательные порты и т.д. Исходные коды драйверов
устройств находятся в ./linux/drivers.
Архитектурно-зависимый код
Хотя основная часть Linux независима от архитектуры, на которой работает
операционная система, в некоторых элементах для обеспечения нормальной работы и
повышения эффективности необходимо учитывать архитектуру. В подкаталоге ./linux/arch
находится архитектурно-зависимая часть исходного кода ядра, разделенная на ряд
подкаталогов, соответствующих конкретным архитектурам. Все эти каталоги в
совокупности образуют BSP. В случае обычного настольного ПК используется каталог
i386. Подкаталог для каждой архитектуры содержит ряд вложенных подкаталогов,
относящихся к конкретным аспектам ядра, таким как загрузка, ядро, управление памятью
и т.д. Исходные коды архитектурно-зависимой части находятся в ./linux/arch.
В начало
Интересные особенности ядра Linux
Помимо переносимости и эффективности, ядро Linux обладает целым рядом других
интересных функций, которые не были освещены в вышеприведенном рассмотрении.
Linux, как широко используемая на практике операционная система с открытым
исходным кодом, является отличной испытательной площадкой для новых протоколов и
их усовершенствований. Linux поддерживает большое количество сетевых протоколов,
включая традиционный TCP/IP и его высокоскоростные расширения (для сетей быстрее
Gigabit Ethernet [GbE] и 10 GbE). Linux также поддерживает такие протоколы, как Stream
Control Transmission Protocol (SCTP), реализующий множество дополнительных функций,
отсутствующих в TCP (применяется в качестве альтернативного протокола транспортного
уровня).
Следует отметить, что ядро Linux является динамическим (поддерживает добавление
и удаление программных компонентов без остановки системы). Эти компоненты
называются динамически загружаемыми модулями ядра. Их можно вводить в систему при
необходимости, как во время загрузки (если найдено конкретное устройство, для которого
требуется такой модуль), так и в любое время по желанию пользователя.
Еще одно недавнее усовершенствование Linux - возможность ее использования в
качестве операционной системы для других операционных систем (т.н. гипервизора).
Недавно в ядро было внесено усовершенствование, получившее название Kernel-based
Virtual Machine (KVM, виртуальная машина на базе ядра). В результате этой модификации
в пространстве пользователя был реализован новый интерфейс, позволяющий исполнять
поверх ядра с поддержкой KVM другие операционные системы. В таком режиме можно не
только исполнять другие экземпляры Linux, но и виртуализовать Microsoft® Windows®.
Единственное ограничение состоит в том, что используемый процессор должен
поддерживать новые инструкции виртуализации.
Обработка прерываний
Практически все актуальные архитектуры оборудования используют для общения
устройств с программным обеспечением концепцию прерываний. Выглядит это
следующим образом. На процессоре выполняется какой-то процесс (не важно, поток ядра
или пользовательский процесс). Происходит прерывание от устройства. Процессор
отвлекается от текущих задач и переключает управление на адрес памяти, сопоставленный
данному номеру прерывания в специальной таблице прерываний. По этому адресу
находится обработчик прерывания. Обработчик выполняет какие-то действия в
зависимости от того, что именно произошло с этим устройством, затем управление
передаётся планировщику процессов, который, в свою очередь, решает, кому передать
управление дальше.
Аппаратно завис часть: инициализ системы на низком уровне, первичная обработка
прерываний, управление вирт памятью, переключение контекстов потоков, части
драйверов
Развитие ядра:
1. азвитие и оптимизация внутренних функций
2. поддержка аппаратных архитектур
3. фс и диски
а. универсалные фс
б.специализированные фс
в. сетевые фс
4.сетевые технолоогии
5. управление безопасностью
6.виртуализация облачных технологий
30. Свойства и управление процессами Linux. Применение сигналов.
Процессы по типу делятся на:
1. Системные (являются частью ядра, всегда резидентны, запускаются особым
образом при инициализации ядра):
- sched – диспетчер свопинга
- bdfflush – диспетчер буфера кэша
- kmadaemon – диспетчер памяти ядра
- init
2. Демоны – неинтерактивные процессы фонового режима, запускаются из файлов. Не
связаны с пользовательскими сеансами. Обеспечивают работу подсистем терминального
доступа, печати, сетевых служб.
3. Прикладные процессы – запускаются в пользовательском сеансе. Основной процесс
– оболочка shell. В терминале запускаются задания – запущенные в оперативном или в
фоновом режиме.
Атрибуты процесса (хранимые в дескрипторе):
1) PID – уникальный идентификатор.
2) PPID – идентификатор процесса-предка.
3) Nice Number - начальный приоритет, и динамический приоритет.
4) TTY - терминальная линия, есть не у всех процессов.
5) Идентификаторы пользователя: реальный RID (real ID) = (UID) и эффективный
EUID (efficient UID) – используется для проверки доступа к системным ресурсам. Иногда
EUID может получить значение владельца исполнимого файла, если установлен флаг
SUID =1.
Состояние процесса:
R – активный процесс
T – приостановленный процесс
S – процесс в ожидании
D – непрерывное ожидание
Z – зомби
W – процесс выгружен на диск
L – возможность бловикровки виртуальных страиниц
Классические команды:
#ps - отображает процессы, запущенные с данного терминала
#top – выдает информацию о процессах, упорядоченных по использованию ресурсов.
Идентификатор группы: реальный RGID и эффективный EGID.
Дерево процессов: выделяется особый демон (суперсервер), который определяет
запросы к другим демонам и может сам ими управлять. Управляет запуском демонов. При
поступлении запроса загрузки в память, если демон не используется, его можно выгрузить.
Процесс getty запускается для терминала, который при его активизации запускает
процесс login.
/proc/… - псевдофайловая система, не отображается на диск. Отображает внутренние
структуры данных ядра.
Управление заданиями:
Задание – процесс, запущенный в виде команды, которую пользователь запускает с
терминала. При запуске задание получает номер, который используется в командах
управления: % jobID. Задание может находиться в 3х состояниях:
1. текущее (оперативное)
2. фоновое
3. приостановленное – задание не получает квант времени.
В команде нужно указывать номер задания:
% - текущее задание; + - последнее запущенное; – - предыдущее запущенное; ? строка
– задание, в команде которого присутствует данная строка; pref – задание, на которое
можно уникально указать префиксом (% ls)
# mc & - в фоновом режиме
bg % jobid – перевод в оперативный режим
stop % jobid – остановка фонового процесса
wait % jobid – ожидает завершения задания, возвращает код возврата
Ctrl + Z – перевод в приостановленное состояние
bf % jobid – перевод приостановленного задания в background
jobs – отображение заданий с их номерами
Механизм сигналов — это средство, позволяющее сообщать процессамо некоторых
событиях в системе, а процессу-получателю — должнымобразом на эти сообщения
реагировать. Послать сигнал может сам процесс (например, при попытке деления на ноль),
ядро (при сбое оборудования), пользователь или другой процесс (требуя прервать
выполнение задачи).
Пользователь может послать сигнал процессу с идентификатором PID командой
$ k i l l [-s <сигнал>] <PID> , где < сигнал > — это номер или символическое имя.
Некоторые сигналы посылаются по нажатии комбинации клавиш. Так, Ctrl+C
посылает сигнал INT, a Ctrl+\ (обратный слэш) — сигнал QUIT. Получает эти сигналы тот
процесс, который сейчас занимает консоль —например, ожидает вашего ввода.
Команда kill носит такое убийственное название потому, что чаще всего используется
для принудительного завершения процессов, вышедших из-под контроля, забирающих
много ресурсов или просто повисших. По умолчанию она посылает сигнал TERM. Он
отличается от сигнала KILL тем, что приказывает процессу завершиться аккуратно, закрыв
открытые им файлы, удалив временные и т.п. Сигнал же KILL действует на процесс как
выстрел в голову. Понятно, что для того, чтобы прервать выполнение процесса, нужно
быть его хозяином или иметь привилегии суперпользователя.
31. Понятие и свойства учетных записей пользователей Linux. Управление
пользователями.
Система учета пользователей опирается на следующие конфигурационные файлы:
• /etc/passwd — учетная информация о пользователе;
• /etc/shadow — скрытая информация о пользователях: пароли в зашифрованном виде;
• /etc/group — информация о группах;
• /etc/gshadow — скрытая информация о группах;
• /etc/default/useradd — свойства, назначаемые по умолчанию новым учетным записям;
• /etc/login. def s — настройки безопасности пароля (время истечения, минимальная
длина);
• /etc/skel — каталог, содержащий личные файлы настроек по умочанию (когда для
нового пользователя создается домашний каталог, в него помещаются эти файлы).
Структура файла /etc/passwd. Если рассуждать логически, управление
пользователями должно начаться при их наличии, то есть вначале нужно добавить
пользователей в новую систему. Существует несколько способов для выполнения этой
задачи. Каждый из методов изменяет содержимое файла паролей /etc/passwd. Кроме того,
изменяются файл /etc/group, а также некоторые другие файлы, например, файлы запуска
оболочки или файлы псевдонимов электронной почты.
Формат файла /etc/passwd практически един для всех диалектов Unix. Этот файл
содержит строки следующего вида, разделенные двоеточием:
username:pswd:uid:gid:uid comments:directory:shell,
где username - имя пользователя; pswd – пароль; uid - уникальный идентификатор
пользователя в пределах системы; gid - уникальный идентификатор группы в пределах
системы, к которой принадлежит пользователь; uid comments - комментарий, расширенное
описание пользователя, например, ФИО; directory - домашний каталог пользователя; shell имя программы - интерпретатора команд пользователя.
Имя пользователя - это то, что пользователь вводит в ответ на приглашение login:. Это
поле не должно содержать символа двоеточия. Кроме того, не рекомендуется употреблять
в имени точку (.), а также начинать его с символов + или -.
Поле пароля может быть представлено различным образом. Оно может быть пустым,
указывая, что для регистрации пользователя пароль не нужен. Оно может также содержать
до 13 символов зашифрованной версии пароля.
uid является простым числовым обозначением отдельного пользователя. Обычно это
положительное число до 65535, хотя некоторые системы распознают 32-битные
идентификаторы пользователя. Некоторые идентификаторы зарезервированы для
специального использования. К ним относятся 0(суперпользователь), 1-10(демоны и
псевдопользователи), 11-99(системные и зарезервированные пользователи), 100+(обычные
пользователи).
Поскольку /etc/passwd обычно доступен для чтения, в целях обеспечения
безопасности обычно используются схемы со скрытыми паролями. Обычно при этом
зашифрованные пароли перенаправляются в файл с ограниченным доступом, который к
тому же может содержать дополнительную информацию. Эта схема используется,
поскольку достаточно средние машины в состоянии за приемлемое время вскрыть пароль,
если пользователь выбрал его неудачно. В категорию неудачных паролей входят
словарные слова, регистрационное имя, отсутствие пароля или информация, содержащаяся
в поле комментария пользователя. такие пароли хранятся в файле /etc/shadow.
Структура файла /etc/group. Файл /etc/group относится к общей схеме защиты
систем типа Unix: пользователь, группа и права достапу к файлам. Формат записи в
данном файле следующий:
group_name:password:group_id:list.
Поле group_name содержит текстовое имя для группы. В поле password размещается
зашифрованный пароль данной группы. Если это поле пустое, то пароль не требуется.
Поле group_id содержит уникальное число-идентификатор этой группы. Поле list содержит
список пользователей, относящихся к этой группе, разделенный запятыми. Пользователям
не нужно упоминаться в списке тех групп, которые указаны в качестве основной для них в
файле /etc/passwd.
Псевдопользователи. Каждый из вариантов UNIX содержит в файле паролей строки
описания псевдопользователей. Эти описания никогда не редактируются. Пользователи
этих имен не регистрируются в системе и нужны лишь для подтверждения владения
соответствующими им процессами. Наиболее известными являются:
daemon - Используется служебными процессами системы;
bin - Дает права на владение исполняемыми файлами команд;
sys - Владеет системными файлами;
adm - Владеет файлами регистрации;
uucp - Используется программой UUCP;
lp - Используется подсистемами lp или lpd;
nobody - Используется NFS.
Существуют и другие псевдопользователи, например, audit, cron, mail, new или usenet.
Все они нужны для работы ассоциированных с ними процессов и файлов.
Команды работы с учетными записями пользователей.
Создание, изменение и удаление строк в файлах паролей и групп зависит от версии
операционной системы, которой Вы пользуетесь. Обычно файлы паролей редактируются
непосредственно из командной строки, либо используются утилиты с графическим
интерфейсом. Эти утилиты позволяют очень легко и удобно редактировать учетные записи
пользователей.
Основные команды для работы с учетными записями в Linux - useradd, userdel, и
usermod, а также средство редактирования файлов паролей vipw. Интерфейс команд
следующий:
useradd [-c uid comment] [-d dir] [-e expire] [-f inactive] [-g gid]
[-m [ -k skel_dir]] [-s shell] [-u uid [-o]] username
userdel [-r] username
usermod [-c uid comment] [-d dir [-m]] [-e expire] [-f inactive]
[-g gid] [-G gid[,gid]] [-l new username] [-s shell] [-u uid [-o]] username
Основные параметры имеют следующие значения:
username - регистрационное имя пользователя. Это единственный обязательный
параметр во всех командах.
uid comment - это дополнительный комментарий о пользователе с указанным именем.
dir - указывает на домашний каталог пользователя.
expire - указывает точную дату, до которой действует регистрационная запись.
inactive - указывает непрерывное число дней без регистрации в системе до того, как
данная запись будет блокирована.
gid - определяет идентификатор или имя группы, к которой относится пользователь.
new_username - является заменой прежнего имени регистрационной записи.
shell - определяет оболочку интерпретатора команд для данного пользователя.
skel_dir - содержит файлы, которые должны быть скопированы в новый домашний
каталог пользователя.
uid - является уникальным идентификатором пользователя, связанным с этим именем.
-m - указывает на необходимость создания нового домашнего каталога (useradd) или
переноса текущего в новое место (usermod).
-o - позволяет повторяться одному и тому же идентификатору пользователя.
-g - выбирает главную группу для регистрационного имени.
-G - выбирает дополнительные группы.
-r - сообщает, что домашний каталог пользователя будет перемещен. Если домашний
каталог для регистрационной записи устарел, существующие файлы будут перенесены в
новый каталог.
Чтобы переместить каталог пользователя, выполните:
cd /old_dir; tar -cf - . | (cd /new_dir; tar -xpf -)
Сравните результаты, а затем удалите old_dir. При переносе особое внимание следует
уделить скрытым файлам запуска, или дот-файлам (имена начинаются с точки). Вот
наиболее важные из них:
.login - файл, исполняемый после регистрации в оболочках csh и tcsh.
.cshrc - файл, исполняемый после запуска новой копии оболочки csh.
.tcshrc - то же самое для оболочки tcsh.
.profile - файл, исполняемый после регистрации в оболочках sh или ksh.
.kshrc - файл, исполняемый после запуска новой копии оболочки ksh.
.bashrc - файл, исполняемый после запуска новой копии оболочки bash.
.history - содержит список последних команд, выполненных в оболочке.
.rhosts - списки удаленных машин/пользователей, допускаемых к регистрации в
данной системе. Rlogin, rexec, rsh/remsh используют этот файл, чтобы разрешить
регистрацию, доступ к фалам и запуск команд без ввода паролей.
.netrc - используется при автоматической регистрации в FTP.
.forward - позволяет перенаправлять почту на другие адреса, в файлы или в
программы обработки.
.mailrc - стартовый файл для почтового агента, позволяющий установить опции или
почтовые псевдонимы.
.exrc - файл с опциями запуска редакторов ex или vi.
.xinitrc - файл запуска для системы X Window.
При удалении регистрационного имени из файла паролей Вы должны также удалить
все файлы, принадлежащие этому пользователю. Сделать это можно с помощью команды
find / -user username
Чтобы не ошибиться, Вы можете упаковать эти файлы, прежде чем удалять их. Чтобы
удалить их сразу во время поиска, выполните:
find / -user username -exec rm {} \;
Команда смены пароля passwd. Эта команда используется для изменения паролей
пользователей. Формат ее вызова: passwd [-k] [-l] [-u [-f]] [-d] [-S] [username]
32. Командный и графический пользовательский интерфейс в Linux. Общие
свойства командной оболочки bash
Графическая оболочка. Gnome и KDE - почему их два?
В Linux-сообществе постоянно идут дискуссии по этому вопросу. А не лучше ли было
бы создать единую графическую среду в противовес Windows, чтобы Linux смотрелся бы в
графической среде всегда одинаково? Gnome и KDE имеют различные библиотеки
элементов, различное оформление рабочего стола и различные модели разработки.
Существование двух различных графических сред для Linux обьясняется вопросами
лицензирования. Проект KDE, основанный в 1996 году, частично основывался на
библиотеках QT от норвежской компании Trolltech, которая предоставляла их под
лицензией BSD, отличной от GPL. Поэтому в 1997 году появился проект Gnome, целью
которого была разработка графической среды, удовлетворяющей лицензии GPL. Потом
Trolltech сменила лицензию QT на более подходящую для Open Source-проектов, но
Gnome уже развивался. Сейчас у обоих проектов есть свои энтузиасты и защитники, и идет
работа для улучшения их совместимости (например, создан общий стандарт Drag&drop
между KDE и Gnome приложениями).
Сходства и различия:
И KDE и Gnome - интегрированные рабочие среды. Пользователи работают с
элементами интерфейса и программами. Цель обоих проектов - сделать графический
интерфейс более интуитивным, чтобы любой пользователь, пришедший из Windows, смог
работать без проблем. В обоих проектах уже давно есть концепция тем - чтобы интерфейс
можно было изменить полностью.
Различные сравнения приходят к одному выводу, что KDE - более развитая и
стабильная графическая среда, а Gnome - более настраиваиваемая. KDE начинала
разрабатываться централизованно, поэтому она более интегрированная. А Gnome может
использовать различные части от других интерфейсов (например - менеджер окон).
KDE написан на C++, а Gnome - на C, но оба они имеют версии на C, C++ и других
языках. Хотя они и базируются на едином X Window System, но на более высоких уровнях
они могут конфликтовать. Сейчас сотрудничество между KDE и Gnome - важная тема для
разработчиков обоих проектов. Например, если настройки цвета были изменены в Gnomeпрограмме, то нужно сделать, чтобы они работали и под KDE. Один из проектов
разрабатывает единый стандарт иконок и миниатюр для файловых менеджеров.
Так же уделяется внимание и совместимости компонентов. KDE разрабатывается на
мощной архитектуре компонентов под названием KParts, похожей на Microsoft COM, с
собственной системой связи между компонентами. Gnome, написанный на C, имеет
псевдоструктуру компонентов под названием Bonobo и использует легкий компонент
ORB, базированный на CORBA, для связи между компонентами. Разработчики не могут
написать приложения, использующие компоненты обоих сторон одновременно.
Компоненты KDE и Gnome на самом деле не связаны между собой. Но Red Hat, Trolltech и
несколько
других
компаний
разработали
единый
протокол
drag-and-drop,
поддерживающийся обоими системами, и частично сглаживающий несовместимость
компонентов.
Командный интерфейс
Важнейшим из пользовательских процессов является командная оболочка (она же
командный интерпретатор, или просто shell). Именно она обеспечивает взаимодействие
пользователя с системой в текстовом режиме, позволяя вводить команды. Именно она
запускается, когда вы регистрируетесь на текстовой консоли, и предоставляет вам
интерфейскомандной строки.
Не нужно, увлекшись удобствами графического интерфейса, недооценивать
командную строку. Во-первых, многие административные задачи могут быть выполнены
только оттуда; во-вторых, командная строка — самое удобное средство автоматизации
рутинных процедур.
Командой в Linux считается все, что может быть исполнено: исполняемые файлы,
встроенные команды оболочки, псевдонимы команд,пользовательские функции, файлы
сценариев (скрипты) — заранее подготовленные последовательности команд в текстовом
виде. Оболочка принимает вводимые пользователем команды, обрабатывает, если нужно,
их аргументы, отправляет команды на выполнение, принимает возвращаемые ими
значения и выполняет определенные действия в зависимости от этих значений. Кроме
того, в оболочку встроен язык программирования (командный язык), позволяющий писать
сложные разветвленные командные сценарии. Именно командный язык отличает разные
оболочки друг от друга, и именно из него исходят пользователи, выбирая любимую и
нелюбимую оболочки.
Для Linux разработано много командных интерпретаторов. Вот несколькоиз них:
sh Bourne shell, оболочка Борна, стандарт для многих UNIX-подобных систем;
bash . . . Bourne Again shell, «еще одна оболочка Борна»;
csh С shell, оболочка Си: синтаксис ее командного языка похож насинтаксис языка С;
tcsh.... tiny С shell, минимальная оболочка Си;
pdksh . .public domain Korn shell, общедоступная оболочка Корна;
sash stand-alone shell, автономная оболочка, может быть использована в случае, когда
программные библиотеки недоступны.
Список всех установленных в системе программ-оболочек находится в
файле / e t c / s h e l l s . У меня он выглядит так:
/bin/sh
/bin/bash
/sbin/nologin # это "оболочка" для тех,# кому запрещен вход в систему
/bin/ash
/bin/bsh
/bin/ksh
/usr/bin/ksh
/usr/bin/pdksh
/bin/tcsh
/bin/csh
Начальная оболочка для каждого пользователя, запускаемая для него прирегистрации
в системе, указывается в файле /etc/passwd:
$ grep den /etc/passwd # выбрать из файла строки,
# содержащие подстроку den
den:x:501:501:Denis:/home/den:/bin/bash
В дальнейшем вы можете сменить текущую оболочку на любую из установленных
(точнее, войти в подоболочку). Чтобы выйти из нее и вернуться в родительскую оболочку,
введите команду e x i t . В начальной оболочке эта команда завершает сеанс работы.
В любой оболочке можно запускать командные сценарии, состоящие из команд
другой оболочки: первая строка каждого сценария содержит указание на то, в какой
оболочке его следует выполнять, и текущая оболочка запускает для него указанную как
дочерний процесс. По умолчанию новому пользователю назначается оболочка bash.
33. Командные средства управления процессами и заданиями в Linux. Выполнение
программ в оперативном и фоновом режимах. Управление полномочиями
демонов и прикладных процессов.
#ps - отображает процессы, запущенные с данного терминала (-ax)
#top – выдает информацию о процессах, упорядоченных по использованию ресурсов.
Дерево процессов: выделяется особый демон (суперсервер), который определяет
запросы к другим демонам и может сам ими управлять. Управляет запуском демонов. При
поступлении запроса загрузки в память, если демон не используется, его можно выгрузить.
Процесс getty запускается для терминала, который при его активизации запускает
процесс login.
Управление заданиями:
Задание – процесс, запущенный в виде команды, которую пользователь запускает с
терминала. При запуске задание получает номер, который используется в командах
управления: % jobID. Задание может находиться в 3х состояниях:
1. текущее (оперативное)
2. фоновое
3. приостановленное – задание не получает квант времени.
В команде нужно указывать номер задания:
% - текущее задание; + - последнее запущенное; – - предыдущее запущенное; ? строка
– задание, в команде которого присутствует данная строка; pref – задание, на которое
можно уникально указать префиксом (% ls)
# mc & - в фоновом режиме
fg % jobid – перевод в оперативный режим
stop % jobid – остановка фонового процесса
wait % jobid – ожидает завершения задания, возвращает код возврата
Ctrl + Z – перевод в приостановленное состояние
bg % jobid – перевод приостановленного задания в background
jobs – отображение заданий с их номерами
nice – изменяет приоритете процесса
pstree
Команды nice и renice
Для каждого процесса в момент порождения устанавливается его приоритет путем
задания значения специального параметра nice. При обычном запуске команд или
программ это значение принимается равным приоритету родительского процесса. Но
существует специальная команда nice, которая позволяет запускать программы с заданным
значением этого параметра, то есть изменять стандартное значение nice при запуске
программы. Формат использования этой программы:
nice [- adnice] command [args]
где adnice — значение (от –20 до +19), добавляемое к значению nice процессародителя. Отрицательные значения может устанавливать только суперпользователь. Если
опция adnice не задана, то по умолчанию для процесса-потомка устанавливается значение
nice, увеличенное на 10 по сравнению со значением nice родительского процесса.
Очевидно, что если вы не суперпользователь, то применять эту команду имеет смысл
только тогда, когда вы хотите запустить некий процесс с низким значением приоритета.
Команда, renice служит для изменения значения nice для уже выполняющихся
процессов. Суперпользователь может изменить приоритет любого процесса в системе.
Другие пользователи могут изменять значение приоритета только для тех процессов, для
которых данный пользователь является владельцем. При этом обычный пользователь
может только уменьшить значение приоритета. Поэтому процессы с низким приоритетом
не могут породить "высокоприоритетных детей".
Перевод процесса в фоновый режим
При обычном запуске процесс работает, как говорят, "на переднем плане". Это значит,
что процесс "привязывается" к терминалу, с которого он запущен, воспринимая ввод с
этого терминала и осуществляя на него вывод. Но можно запустить процесс в фоновом
режиме, когда он не связан с терминалом, для чего в конце командной строки запуска
программы добавляют символ &.
В оболочке bash имеются две встроенные команды, которые служат для перевода
процессов на передний план или возврата их в фоновый режим. Команда fg переводит
указанный в аргументе процесс на передний план, а команда bg — переводит процесс в
фоновый режим. Одной командой bg можно перевести в фоновый режим сразу несколько
процессов, а вот возвращать их на передний план необходимо по одному. Аргументами
команд fg и bg могут являться только номера заданий, запущенных из текущего
экземпляра shell. Возможные значения заданий можно увидеть, выполнив команду jobs.
34. Управление устройствами в Linux. Назначение и применение специальных
файлов устройств. Система udev.
Для доступа к устройствам в UNIX используется единый интерфейс файлового
доступа в виде специальных файловых устройств. С точки зрения программы устройство
представлено в виде файла. Каждому экземпляру устройства соответствует специальный
файл-устройство в каталоге /dev. Файлы предоставляются и виртуальным устройствам.
Имена специальных файлов условны и коротки – тип/старший номер устрва/младший номер (например – hda0, hda1; hd – тип (Hard Disk), a – HDD ATA, 0,1 - №
разделов).
Однако, в отличие от обычных файлов, специальные файлы устройств в
действительности есть только указатели на соответствующие драйверы устройств в ядре.
По сравнению с обычными файлами файлы устройств имеют три дополнительных
атрибута, которые характеризуют устройство, соответствующее данному файлу:
Класс устройства. В ОС Linux различают устройства блок-ориентированные и байториентированные. (b) Блок-ориентированные (или блочные) устройства, например,
жесткий диск, передают данные блоками. (c) Байт-ориентированные (или символьные)
устройства, например, принтер и модем, передают данные посимвольно, как непрерывный
поток байтов. Взаимодействие с блочными устройствами может осуществляться лишь
через буферную память, а для символьных устройств буфер не требуется. Кроме этих двух
классов устройств имеются еще два — (u) небуферизованные байт-ориентированные
устройства и (p) именованные каналы (FIFO).
Старший номер устройства (major), обозначающий тип устройства, например,
жесткий диск или звуковая плата. (Определяет контроллер – из лекций). Текущий список
старших номеров устройств можно найти в файле /usr/include/linux/major.h. Вот небольшая
выдержка из этого списка
Старшие номера некоторых устройств
1
Оперативная память
2
Дисковод гибких дисков
3
Первый контроллер для жестких IDE-дисков
4
Терминалы
6
Принтер (параллельный разъем)
8
14
22
Жесткие SCSI-диски
Звуковые карты
Второй контроллер для жестких IDE-дисков
Файлы устройств одного типа имеют одинаковые имена и различаются по номеру,
прибавляемому к имени. Например, все файлы сетевых плат Ethernet имеют имена,
начинающиеся на eth: eth0, eth1 и т. д.
Младший номер устройства (minor) применяется для нумерации устройств одного
типа, т. е. устройств с одинаковыми старшими номерами. (Указывает экземпляр
устройства – из лекций).
Для централизованной нумерации разработчики ведут базу номеров контроллеров.
Управление и операции.
Если вы решили подключить к системе какое-то новое устройство, необходимо
вначале проверить, что в каталоге /dev имеется специальный файл (или ссылка на
специальный файл) для этого устройства. Специальные файлы устройств создаются с
помощью
команды mknod (но,
естественно,
использовать
команду mknod без
необходимости и полного понимания последствий не стоит). Эта команда имеет
следующий формат:
mknod [опции] имя_устройства тип_устройства старший_номер младший_номер
Для блок-ориентированных и байт-ориентированных устройств (b, c, u) нужны и
старший и младший номера, для именованных каналов номера не используются. В
следующем примере создается специальный файл для терминала, подключенного к порту
COM3, который в Linux обозначается как /dev/ttyS2:
[root]# mknod -m 660 /dev/ttyS2 c 4 66
Но вот о чем стоит подумать, так это о том, как дать пользователям права,
необходимые для доступа к устройствам. Эти права устанавливаются через атрибуты
специальных файлов. Можно, например, дать всем пользователям полные права (chmod
666) на доступ к таким устройствам, как /dev/cdrom, /dev/floppy, /dev/modem и так далее.
Можете поступить иначе, создав группу "cdrom", сделать /dev/cdrom принадлежащим
группе cdrom, а потом добавлять пользователей в эту группу по мере необходимости.
Аналогичную процедуру можно применить к другим устройствам.
Создание файлов устройств ссылок, при этом обращение к этому файлу к этой ссылке
по одному имени, независимо от того на какой файл уустройства идет сама ссылка.
Проблемы:
1. заранее создавалась огромное количесвто файлов на все случаи жизни
2. 255 значений для major – быстро закончилось
3. младший,minor выдается каждый раз при подключении – одни и те же устройства
получают разные номера
4.отсутствует механизм горячего подключения
Реализация динамического подключения устройств:
1. devfs – ориентируется на динамич. Конфигурацию специальных файлов устройств.
Внедрена в ядро. При загрузке драйверы регистрируют свои устройства системным
вызовом devfs_register(). Devfs хранит БД имен устройств и создает индексные
дескрипторы специальных файлов. Это выполняется на уровне ядра => труность работы с
устройствами в пользовательском режиме.
2. sysfs – псевдо ФС, обеспечивает доступ к информации об устройствах в ядре.
Каталог /sys расширяет старый механизм /proc, который позволяет получать доступ к
техническим данным ядра из кольца 3.
3. udev – технология динамической конфигурации устройств.
Особенности: позволяет работать в режиме пользователя, выполняя динамическое
обновление каталога /dev, поддержка постоянных имен устройств при hotplug, удобный
интерфейс для пользователя, позволяет использовать гибкие имена устройств.
Принцип работы udev
udev запускается как демон и принимает через сокет netlink события uevents от ядра,
которые генерируются при инициализации или удалении устройства из системы.
Задаваемые пользователем (системой) правила сверяются со свойствами события и
соответствующего устройства, и совпавшее правило (которых может быть несколько)
может назвать и создать соответствующий файл устройств, а также выполнить другие
программы для инициализации и конфигурации устройства. Например, таким образом
можно реализовать автоматическое монтирование внешних накопителей при их
подключении.
Правила могут сверяться по таким свойствам, как конкретная ядерная подсистема,
имя устройства в ядре, физическое расположение устройства, либо по серийному номеру
устройства. Правила также могут запрашивать информацию при помощи других программ
или указать, что имя устройства всегда будет одним и тем же, вне зависимости от порядка
обнаружения устройств системой.
Типичный способ использования udev на Linux-системе — позволить посылать
события HAL или DeviceKit, чтобы они произвели последующие зависящие от устройств
действия. Например, HAL/DeviceKit может уведомить остальные программы о новом
устройстве при помощи широковещательного сообщения в D-Bus. Таким образом, рабочие
среды типа GNOME или KDE могут автоматически смонтировать USB-накопитель и
открыть файловый менеджер для просмотра его содержимого.
35. Монтирование файловой системы на томе, основные параметры монтирования.
Монтирование фаловых устройств при загрузке Linux и работа со сменными
носителями.
Монтирование
Корневой каталог в Linux всегда только один, а все остальные каталоги в него
вложены, т. е. для пользователя файловая система представляет собой единое целое4. В
действительности, разные части файловой системы могут находиться на совершенно
разных устройствах: разных разделах жёсткого диска, на разнообразных съёмных
носителях (лазерных дисках, дискетах, флэш-картах), даже на других компьютерах (с
доступом через сеть). Для того, чтобы соорудить из этого хозяйства единое дерево с одним
корнем, используется процедура монтирования.
Монтирование — это подключение в один из каталогов целой файловой системы,
находящейся где-то на другом устройстве. Эту операцию можно представить как
«прививание» ветки к дереву. Для монтирования необходим пустой каталог — он
называется точкой монтирования. Точкой монтирования может служить любой каталог,
никаких ограничений на этот счёт в Linux нет. При помощи команды mount мы объявляем,
что в данном каталоге (пока пустом) нужно отображать файловую систему, доступную на
таком-то устройстве или же по сети. После этой операции в каталоге (точке монтирования)
появятся все те файлы и каталоги, которые находятся на соответствующем устройстве. В
результате пользователь может даже и не знать, на каком устройстве какие файлы
располагаются.
Подключённую таким образом («смонтированную») файловую систему можно в
любой момент отключить — размонтировать (для этого имеется специальная команда
umount), после чего тот каталог, куда она была смонтирована, снова окажется пустым.
Для Linux самой важной является корневая файловая система (root filesystem). Именно
к ней затем будут подключаться (монтироваться) все остальные файловые системы на
других устройствах. Обратите внимание, что корневая файловая система тоже
монтируется, но только не к другой файловой системе, а к «самой Linux», причём точкой
монтирования служит «/» (корневой каталог). Поэтому при загрузке системы прежде всего
монтируется корневая файловая система, а при останове она размонтируется (в последнюю
очередь).
Пользователю обычно не требуется выполнять монтирование и размонтирование
вручную: при загрузке системы будут смонтированы все устройства, на которых хранятся
части файловой системы, а при останове (перед выключением) системы все они будут
размонтированы. Файловые системы на съёмных носителях (лазерных дисках, дискетах и
пр.) также монтируются и размонтируются автоматически — либо при подключении
носителя, либо при обращении к соответствующему каталогу.
Обычно команда mount применяется в формате:
mount -t <тип_ФС> <устройство> <точка_монтирования>
Монтировать можно двумя способами:
1)
Вручную (с помощью команды mount)
2)
Автомотически (с помощью файла /etc/fstab)
Рассмотрим команду монтирования:
# mount [опции]
<устройство>
<точка монтирования>
Опции:
-t – тип монтируемой файловой системы (extr, msdos, hpfs, nfs, swap, iso 9660…)
-r – монтирование файловой системы только по чтению
-w – монтирование файловой системы по чтению/записи
-a – монтировать все файловые системы, описанные в файле конфигурации /etc/fstab
Если надо просмотреть список примонтированных устройств:
# mount
Также список смонтированных устройств содержится в файле /etc/mtab
После работы с томом его можно размонтировать:
# umount устройство
UUID
В новых дистрибутивах Linux вместо названий дисков из /dev каталога часто
указывают UUID — Уникальные Идентификаторы. Выглядят они абсолютно нечитаемо
для человека, например: UUID=»5a179614-0415-48c6-a9ad-3f6ad9596619″.
Для чего нужны UUID’ы?
Когда возникает необходимость перенести содержимое с одного носителя на другой,
потом встает большая проблема правильно внести изменения в файл /etc/fstab вручную. С
UUID’ами же ядро, при помощи специальных программ, автоматически находит и
размечает разделы по соответствующим носителям. Это экономит много сил и времени.
Возможно иногда целесообразнее «старая школа» — именование устройств в стиле
/dev/sda.
В новых дистрибутивах Линукс стало модным называть разделы не по "именам",
скажем, /dev/hda2, а используя UUID'ы - Уникальные Идентификаторы. Выглядят они как
абсолютно нечитаемые для человека многозначные номера, да еще и шестнадцатеричные,
например: UUID="5a179614-0415-48c6-a9ad-3f6ad9596619".
Удобство понимания и заполнения таких конфигурационных файлов как, скажем,
/etc/fstab "значительно повысилось". Стало невозможным понять о каком разделе идет
речь. Хорошо если у вас всего пять-шесть разделов, еще можно помнить, на каком своп, а
на каком корень. А если разделов в три раза больше? Да если еще и постоянно удаляешь
одни, и создаешь другие? Мода требует жертв.
Кому же нужны UUID'ы и для кого они действительно удобны? Сисадминам больших
серверов, у которых одновременно присутствуют носители всевозможных типов, да еще и
объединенные во всякие RAID'ы и прочие сиадминские заморочки. Для них, когда
возникает необходимость перенести содержимое с одного носителя на другой, потом
встает большая проблема правильно внести изменения в ту же /etc/fstab вручную. С
UUID'ами же ядро, при помощи специальных программ, автоматически находит и
размечает разделы по соответствующим носителям. Это им экономит много сил и
времени.
Простым же смертным, имеющим два компьютера с тремя винчестерами на обоих,
эти UUID'ы нужны как зайцу стоп-сигнал. Я лично первым делом безжалостно удаляю все
эти номера из файлов /etc/fstab и /boot/grub/menu.lst. Это позволяет мне избежать головной
боли при клонировании разделов, когда возникают два раздела с одинаковыми
"Уникальными номерами".
etc/fstab
Для того, чтобы разделы жесткого диска автоматически монтировались при загрузке
системы и демонтировались при останове, их нужно прописать в файл /etc/fstab , который
читает команда mount в ходе начальной загрузки. Каждая строка этого файла соответствует
одной файловой системе и состоит из шести полей, разделенных пробельными символами:
<устройство> <точка_монтирования> <тип> <опции> <дамп> <номep_fsck>
Устройство — это файл устройства, к которому подключен раздел (например,
/dev/hda5). Для сетевой файловой системы здесь должно быть указано имя сервера и
каталог на нем.
Точка_монтирования — это имя каталога, к которому файловая система будет
подключена. Он должен существовать и (желательно) быть пустым. Для раздела
подкачки (swap) значение этого поля не используется, но в файле /etc/fstab
присутствовать все равно должно.
Вместо типа ФС можно указать значение auto: в этом случае команда mount
попытается определить тип самостоятельно.
Опции
exec - Разрешение на запуск исполняемых файлов. Опция включена по-умолчанию.
noexec - Запрет на запуск исполняемых файлов.
auto - Раздел будет автоматически монтироваться при загрузке системы. Поумолчанию.
noauto - Раздел не будет автоматически монтироваться при загрузке системы.
ro - Монтирование только для чтения.
rw - Монтирование для чтения и записи. По-умолчанию.
user - Разрешение простым пользователям монтировать/демонтировать этот раздел.
nouser - Запрещает простым пользователям монтировать/демонтировать этот раздел.
По-умолчанию.
defaults - Использование всех параметров по-умолчанию.
Дамп — это отметка о необходимости резервного копирования данной ФС
программой dump. Значение 1 говорит о том, что резервировать нужно, значение 0
— нет.
Номер_fsск: утилита fsck обычно запускается перед автоматическим монтированием
ФС, проверяет ее на целостность и пытается исправить найденные ошибки. Это
процедура долгая, и для ускорения загрузки можно либо отключить проверку для
некоторых ФС (значение 0), либо для некоторых разделов запускать ее параллельно.
Значение этого поля задает порядок проверки разных ФС: если номера одинаковые,
то системы будут проверяться параллельно. Ясно, что ускорение может получиться
только в том случае, когда параллельно проверяемые разделы находятся на разных
физических дисках.
36. Общие свойства файловых систем в Linux, основные типы поддерживаемых
файловых систем, именование и атрибуты файлов.
Поддержка ФС встроена в ядро.
1.
Стандартная AT&T – S5fs
2.
3.
bfs – UNIX Berkley fs, ffs (fast fs)
ext2fs – Linux
4.
hpfs (OS/2)
5.
vfs
6.
nfs
7.
ext3fs, riser, vxfs (Virtual Journaly fs)
Современные *NIX обладают свойствами виртуальной ФС. Эти свойства позволяют
работать с несколькими физическими ФС разных типов.
Качества ФС:
1. Организация файлов
в файловой системе UNIX файлы представлены однотипно в виде байтового потока
(массив пронумерованных байтов). Структурирование идет на прикладном уровне. Это
дает простоту на уровне ядра.
Выделяются файлы текстового типа (plain) построенные из строк переменной длины.
Признак конца строки - <LF> (linefeet) без <CR> как в Windows.
2. Типы файлов.
Важно отметить, что типы файлов не различаются по именам. Тип файлов задан в
индексном дескрипторе файла.
6 типов файлов (по способу обработки):
Обычный файл данных на устройстве (ordinary)
Каталог (directory)
FIFO файл (поименованный конвейер)
Файлы устройств (Special Device file)
Связь (link)
Сокеты (socket)
Элемент каталога Directory реализует однонаправленную связь между именем и
индексным дескриптором файла.
2 байта
14 байт
i-node
name1
i-node
name2
…
…
Имя файла – атрибут ФС, а не набор данных на диске. Name – однонаправленная
ссылка на i-node (м.б. несколько ссылок, т.е. hardlink).
Структура i-node (дисковый, при обращении к памяти считывается в память ядра):
di_mode = тип | SUID|SGID|sticky bit|r,w,x| r,w,x| r,w,x|
owner, group,other
di_nlinks – количество жестких связей
di_uid, di_gid – ID владельца пользователя и владельца группы
di_size – размер в байтах
Для файла устройства в поле size хранится major и minor.
di_atime – время последнего доступа
di_mtime – время последней модификации
di_ctime – время последней модификации i-node (исключая atime и mtime)
di_addr[13] – массив номеров блоков файла
При операции открытия файла ядро помещает копию i-node в таблицу in_coreinode
FIFO файл (именованный канал IPC) – имеют глобальные имена, являются очередью
Файлы устройств представляют файловый интерфейс к устройству. Запросы
переадресуются к драйверу.
Link:
Hardlink – несколько различных записей каталогов указывают на один i-node.
Symlink – отдельный файл, представляющий собой индексный дескриптор и
свойства. Содержит спецификацию целевого файла. При обращении к символической
связи ОС обрабатывает косвенную ссылку и переадресует доступ к целевому файлу.
Sockets – являются виртуальными объектами, предназначены для связи процессов в
коммуникационном домене.
3. Иерархическая структура каталогов.
Каталоги и файлы независимо от физического расположения вписаны в общую
структуру.
/путь/имя файла – путь к файлу
Путь может быть:
1)
абсолютный (начинается со знака / и отсчитывается от корневого каталога)
2)
относительный (ведет путь от текущего каталога)
. / - текущий каталог
.. / - родительский каталог
~/ - домашний каталог пользователя
Примечания:
Заглавные и строчные буквы различаются.
/Home/user – домашний каталог, пользователь является его владельцем,
содержит скрипты автозапуска, становится текущим при загрузке. $HOME, ~/
.
4. Монтируемость томов.
Том – носитель с организованной на нем файловой системой и набором данных.
Монтирование – подкличение структуры каталогов на томе к точке монтирования
файловой системы.
Для монтируемых томов есть специальный каталог /mnt
Операция монтирования выполняется командой:
#mount [опции] устройство точка_монтирования
Основная цель монтирования: организовать связанную структуру дерева каталогов.
Базовая файловая система UNIX S5FS
В составе тома выделяются 4 части:
Блок
начальной
загрузки
Супер блок
i-list
Блоки данных
Суперблок - содержит общую информацию о томе, необходимую для монтирования и
управления файловой системой в целом, к примеру, для размещения новых файлов. В
каждой файловой системе существует всего лишь один суперблок, который размещается в
начале раздела. Суперблок считывается в память при монтировании файловой системы и
находится там до ее размонтирования.
Суперблок содержит следующую информацию:
1) s_type - тип файловой системы;
2) s_fsize - размер файловой системы в логических блоках, включая сам суперблок, массив
файловых дескрипторов и блоки хранения данных;
3) s_isize - размер массива индексных дескрипторов;
4) s_tfree - число свободных блоков, доступных для размещения;
5) s_tinod - число свободных индексных дескрипторов, доступных для размещения;
6) s_fmod - флаг модификации;
7) s_fronly - флаг режима монтирования;
8) размер логического блока (512, 1024, 2048);
9) список номеров свободных индексных дескрипторов;
10) список адресов свободных блоков.
Стоит отметить, что число свободных файловых дескрипторов и блоков хранения данных
может быть большим, списки свободных индексных дескрипторов и и списки свободных
блоков целиком в суперблоке не хранятся.
Для индексных дескрипторов хранится всего лишь часть списка. Когда число
свободных индексных дескрипторов в этом списке приближается к нулю, ядро
операционной системы просматривает массив индексных дескрипторов и вновь формирует
список свободных индексных дескрипторов. Индексные дескрипторы имеют специальное
поле, по которому можно определить, занят он или свободен.
По содержимому блоков хранения данных нельзя определить, занят этот блок или
свободен, поэтому необходимо хранить список адресов свободных блоков целиком.
Суперблок содержит всего лишь один блок из этого списка. Первый элемент этого блока
указывает на блок, хранящий продолжение этого списка и т.д.
Выделение свободных блоков для размещения файлов производится с конца списка
суперблока. Когда в списке остается единственный элемент, ядро интерпретирует его как
указатель на блок, содержащий продолжение этого списка. В этом случае содержимое
этого блока считывается в суперблок и блок становится свободным. Такой подход даёт
возможность эксплуатировать дисковое пространство под списки, пропорциональное
свободному месту в файловой системе, то есть когда свободного места становится мало,
список адресов свободных блоков помещается целиком в суперблоке.
Адресация данных:
в индексном дескрипторе есть массив addr[13]
типы файлов:
В ОС Linux можно выделить следующие типы файлов:
• обычные файлы — последовательность байтов (текстовые документы,
исполняемые программы, библиотеки и т.п.);
• каталоги — именованные наборы ссылок на другие файлы;
• файлы физических устройств, подразделяющихся на:
• файлы блочных устройств, драйверы которых буферизуют ввод-вывод с
помощью ядра и
• файлы байт-ориентированных, или символьных, устройств, позволяющих
связанным с ними драйверам выполнять буферизацию собственными
средствами;
• символические ссылки (symlink, symbolic link);
• именованные каналы (named pipes);
• гнезда (sockets).
Атрибуты файлов
-rwxr-xr-- 1 den users 0 Feb 14 19:08 /home/den/README
Что это за свойства?
Первый символ выведенной строки, в данном случае дефис, обозначает тип файла.
Другие значения этого свойства: d — каталог, b — блочное устройство, с — символьное
устройство, 1 — символическая ссылка, р —именованный канал и s — гнездо.
Следующие 9 символов означают права доступа к файлу. Они делятся на три тройки,
обозначающие права: владельца, членов его группы и всех остальных. Внутри каждой
тройки может присутствовать или отсутствовать: право чтения (г), записи (w) и
исполнения (х, от execute). Отсутствие права обозначается символом дефиса. С файлом
README из нашего примера владелец (в общем случае, пользователь, создавший его)
имеет право делать все, что угодно; члены его группы — только читать и запускать файл
на выполнение; все остальные — только читать.
О следующем свойстве, количестве ссылок на файл, будет сказано в параграфе о
символических ссылках.
Далее указаны имя владельца файла и имя его группы; размер файла в байтах; дата и
время последней модификации и имя файла.
37. Типы файлов в Linux. Структура системных данных файловой системы:
индесные дескрипторы и каталоги.
Идентификация типов файлов в Linux
Для того, чтобы идентифицировать и классифицировать все семь типов файлов,
имеющихся в Linux, вам нужно знать всего одну команду:
$ ls -ld
Ниже пример вывода этой команды.
$ ls -ld /etc/services
-rw-r--r-- 1 root root 19281 Feb 14 2012 /etc/services
Команда ls показывает тип файла в кодированном виде как первый символ части
вывода, показывающего права доступа. В данном случае это "-", что значит "обычный
файл". Важно отметить, что в Linux невозможно изменить тип файла, ошибочно присвоив
ему другое расширение. Давайте посмотрим на краткое описание всех семи различных
типов файлов в Linux и их идентификаторы для команды ls:
2.1. Обычный файл
Обычный файл - это самый распространенный тип файлов в системе Linux. Он
объединяет самые различные виды файлов, такие как текст, изображения, бинарные
файлы, библиотеки и т.д. Обычный файл вы можете создать с помощью команды:
$ touch linuxcareer.com
$ ls -ld linuxcareer.com
-rw-rw-r-- 1 lubos lubos 0 Jan 10 12:52 linuxcareer.com
Первый символ в выводе команды ls, в данном случае "-", представляет собой код
идентификации для обычного файла. Для удаления обычного файла используется команда:
$ rm linuxcareer.com
2.2. Директория
Директория - это второй самый распространенный тип файлов в Linux. Директории
могут быть созданы с помощью команды mkdir:
$ mkdir FileTypes
$ ls -ld FileTypes/
drwxrwxr-x 2 lubos lubos 4096 Jan 10 13:14 FileTypes/
Как уже говорилось ранее, директории идентифицируются по символу "d" в выводе
команды ls. Для удаления директорий используется команда rmdir.
$ rmdir FileTypes
Если вы попытаетесь с помощью команды rmdir удалить директорию, в которой есть
файлы, то получите сообщение об ошибке:
rmdir: failed to remove 'FileTypes/': Directory not empty
В этом случае необходимо использовать команду:
$ rm -r FileTypes/
2.3. Символьное устройство
Файлы символьных и блочных устройств позволяют пользователям и программам
обмениваться данными с периферийными устройствами, например:
$ ls -ld /dev/vmmon
crw------- 1 root root 10, 165 Jan 4 10:13 /dev/vmmon
В данном случае символьное устройство - это модуль vmware.
2.4. Блочное устройство
Блочные устройства похожи на символьные. Это главным образом такие устройства
как жесткие диски, память и т.д.
$ ls -ld /dev/sda
brw-rw---- 1 root disk 8, 0 Jan 4 10:12 /dev/sda
2.5. Сокеты локального домена
Сокеты локального домена используются для обмена данными между процессами. В
основном они используются такими службами, как X windows, syslog и т.д.
$ ls -ld /dev/log
srw-rw-rw- 1 root root 0 Jan 4 10:13 /dev/log
Сокеты могут быть созданы с помощью системного вызова socket, а удалены с
помощью системной функции unlink или команд rm.
2.6. Именованные каналы
Как и локальные сокеты, именованные каналы позволяют осуществлять обмен
данными между локальными процессами. Они могут быть созданы с помощью команды
mknod, а удалены с помощью команды rm.
2.7. Символические ссылки
С посощью символических ссылок администратор может присвоить одному файлу
или директории несколько идентичностей. Символическая ссылка является указателем на
оригинальный
файл.
Существует
два
типа
символических
ссылок:
жесткие
ссылки;
- мягкие ссылки.
Различие между твердыми и мягкими ссылками в том, что мягкие ссылки ссылаются
на имя файла, в то время как жесткие ссылки прямо ссылаются на оригинальный файл.
Кроме того, жесткие ссылки не работают с файлами, расположенными на других разделах
или файловых системах. Для создания мягкой символической ссылки используется
команда:
$ echo file1 > file1
$ ln -s file1 file2
$ cat file2
file1
$ ls -ld file2
lrwxrwxrwx 1 lubos lubos 5 Jan 10 14:42 file2 -> file1
Для удаления символической ссылки мы можем использовать команды unlink или rm.
21.3. Индексные дескрипторы файлов
Каждому файлу на диске соответствует один и только один индексный дескриптор
файла, который идентифицируется своим порядковым номером - индексом файла. Это
означает, что число файлов, которые могут быть созданы в файловой системе, ограничено
числом индексных дескрипторов, которое либо явно задается при создании файловой
системы, либо вычисляется исходя из физического объема дискового раздела.
Индексный дескриптор файла имеет следующее строение:
7
В UNIX-подобных системах имя файла есть атрибут не самого файла, а файловой
системы, понимаемой как логическая структура каталогов. Имя файла хранится только в
каталоге, к которому файл приписан, и больше нигде. Из этого вытекают любопытные
следствия.
Во-первых, одному индексному дескриптору может соответствовать любое
количество имен, приписанных к разным каталогам, и все они являются настоящими.
Количество имен (жестких ссылок) учитывается в индексном дескрипторе. Именно это
количество вы можете увидеть по команде Is -1.
Во-вторых, удаление файла означает просто удаление записи о нем из данных
каталога и уменьшение на 1 счетчика ссылок.
В-третьих, сопоставить имя можно только номеру индексного дескриптора внутри
одной и той же файловой системы, именно поэтому нельзя создать жесткую ссылку в
другуфайловую систему (символическую можно, у нее другой механизм хранения).
38. Управление файлами в Linux. Операции над файлами, группами файлов и
каталогами.
Команды для работы с файлами и каталогами
В предыдущих разделах мы уже упоминали некоторые команды для работы с
файлами и каталогами: pwd, cd, ls, ln, chmod. В этом разделе рассмотрим (очень кратко)
еще несколько часто используемых команд.
4.6.1. Команды chown и chgrp
Эти команды служат для смены владельца файла и группы файла. Выполнять смену
владельца может только суперпользователь, смену группы может выполнить сам владелец
файла или суперпользователь. Для того, чтобы иметь право сменить группу, владелец
должен дополнительно быть членом той группы, которой он хочет дать права на данный
файл. Формат этих двух команд аналогичен:
[root]# chown vasja имя-файла
[root]# chgrp usersgrp имя-файла
4.6.2. Команда mkdir
Команда mkdir позволяет создать подкаталог в текущем каталоге. В качестве
аргумента этой команде надо дать имя создаваемого каталога. Во вновь созданном
каталоге автоматически создаются две записи: . (ссылка на этот самый каталог) и .. (ссылка
на родительский каталог). Чтобы создать подкаталог, вы должны иметь в текущем
каталоге право записи. Можно создать подкаталог не в текущем, а в каком-то другом
каталоге, но тогда необходимо указать путь к создаваемому каталогу:
[user]$ mkdir /home/kos/book/glava5/part1
Команда mkdir может использоваться со следующими опциями:
-m
-p
mode — задает режим доступа для нового каталога (например, -m 755);
— создавать указанные промежуточные каталоги (если они не существуют).
4.6.3. Команда cat
Команда cat часто используется для создания файлов (хотя можно воспользоваться и
командой touch). По команде cat на стандартный вывод (т. е. на экран) выводится
содержимое указанного файла (или нескольких файлов, если их имена последовательно
задать в качестве аргументов команды). Если вывод команды cat перенаправить в файл, то
можно получить копию какого-то файла:
[user]$ cat file1 > file2
Собственно, первоначальное предназначение команды cat как раз и предполагало
перенаправление вывода, так как эта команда создана для конкатенации, т. е. объединения
нескольких файлов в один:
[user]$ cat file1 file2 ... fileN > new-file
Именно возможности перенаправления ввода и вывода этой команды и используются
для создания новых файлов. Для этого на вход команды cat направляют данные со
стандартного ввода (т. е. с клавиатуры), а вывод команды — в новый файл:
[user]$ cat > newfile
После того, как вы напечатаете все, что хотите, нажмите комбинацию
клавиш <Ctrl>+<D> или <Ctrl>+<C>, и все, что вы ввели, будет записано в newfile.
Конечно, таким образом создаются, в основном, короткие текстовые файлы.
4.6.4. Команда cp
Хотя для копирования файлов иногда пользуются командой cat, но в Linux
существует для этого специальная команда cp. Ее можно применять в одной из двух форм:
[user]$ cp [options] source destination
[user]$ cp [options] source_directory new_directory
В первом случае файл или каталог source копируется, соответственно, в файл или
каталог destination, а во втором случае файлы, содержащиеся в каталоге source_directory
копируются в каталог new_directory. Для копирования надо иметь права на чтение файлов,
которые копируются, и права на запись в каталог, в который производится копирование.
Если в качестве целевого указывается существующий файл, то его содержимое будет
затерто, поэтому при копировании надо соблюдать осторожность. Впрочем, можно
использовать команду cp с опцией -i, тогда перед перезаписью существующего файла
будет запрашиваться подтверждение (очень рекомендую вам всегда использовать эту
опцию!).
4.6.5. Команда mv
Если вам необходимо не скопировать, а переместить файл из одного каталога в
другой, вы можете воспользоваться командой mv. Синтаксис этой команды аналогичен
синтаксису команды cp. Более того, она сначала копирует файл (или каталог), а только
потом удаляет исходный файл (каталог). И опции у нее такие же, как у cp.
Команда mv может использоваться не только для перемещения, но и для
переименования файлов и каталогов (т. е. перемещения их внутри одного каталога). Для
этого надо просто задать в качестве аргументов старое и новое имя файла:
[user]$ mv oldname newname
Но учтите, что команда mv не позволяет переименовать сразу несколько файлов
(используя шаблон имени), так что команда mv *.xxx *.yyy не будет работать.
При использовании команды mv, также как и при использовании cp, не забывайте
применять опцию -i для того, чтобы получить предупреждение, когда файл будет
перезаписываться.
4.6.6. Команды rm и rmdir
Для удаления ненужных файлов и каталогов в Linux служат команды rm (удаляет
файлы) и rmdir (удаляет пустой каталог) . Для того, чтобы воспользовался этими
командами, вы должны иметь право записи в каталоге, в котором расположены удаляемые
файлы или каталоги. При этом полномочия на изменение самих файлов не обязательны.
Если хотите перед удалением файла получить дополнительный запрос на подтверждение
операции, используйте опцию -i.
Если вы попытаетесь использовать команду rm (без всяких опций) для удаления
каталога, то будет выдано сообщение, что это каталог, и удаления не произойдет. Для
удаления каталога надо удалить в нем все файлы, после чего удалить сам каталог с
помощью команды rmdir. Однако можно удалить и непустой каталог со всеми входящими
в него подкаталогами и файлами, если использовать команду rm с опцией -r.
Если вы дадите команду rm *, то удалите все файлы в текущем каталоге. Подкаталоги
при этом не удалятся. Для удаления как файлов, так и подкаталогов текущего каталога
надо тоже воспользоваться опцией -r. Однако всегда помните, что в Linux нет команды
восстановления файлов после их удаления (даже если вы спохватились сразу же после
ошибочного удаления файла или каталога)!
Так что дважды подумайте до удаления чего-либо и не пренебрегайте опцией -i.
сd– смена рабочего каталога;
ls– просмотр каталогов и информации о файлах;
chown– изменение владельца;
chgrp– изменение группы;
chmod– установка и изменение прав доступа;
ln– создание ссылок;
less, more– управление постраничным выводом;
cat– объединение файлов;
touch– изменение временных атрибутов файла;
echo– вывод текста на экран;
mkdir– создание каталога;
rmdir– удаление каталога;
rm– удаление каталога, файла, ссылки;
cp– копирование файлов;
mv– перемещение файлов;
pwd– показывает текущую директорию;
39. Управление доступом к файлам и каталогам в Linux. Основные режимы доступа
и дополнительные признаки SetUID, SetGID, StikyBit. Применение и механизм
проверки доступа к файловой системе.
Операционная система Linux - это многопользовательская система, которая дает
огромные возможности манипулирования доступом к данным для каждого пользователя
отдельно. Это позволяет гибко регулировать отношения между пользователями, объединяя
их в группы, что позволит защитить данные одного пользователя от нежелательного
вмешательства других.
Бессмысленно считать, что файловая система это не самая важная часть
операционной системы, поскольку все данные пользователей хранятся именно в файлах.
В UNIX-подобных системах файлы также обеспечивают доступ к периферийным
устройствам, дисковым накопителям, принтерам и т.п.
UID, GID
Каждый пользователь в системе имеет свой уникальный идентификационный
номер (user-ID, или UID). Также пользователи могут объединяться в группы, которые в
свою очередь имеют group-ID, или GID. Чтобы узнать свой UID и GID, т.е. уникальный
номер пользователя и номер группы, к которой Вы принадлежите, необходимо ввести
команду id:
[dmitry@localhost dmitry]$id
uid=502 (dmitry) gid=503(users) groups=503(users)
Права доступа к файлам
В свою очередь файлы имеют двух владельцев: пользователя (user owner)
и
группу пользователей (group owner). Для каждого файла есть индивидуальные права
доступа, которые разбиты на три группы:
1. Доступ для пользователя-владельца файла (owner).
2. Доступ для группы-владельца файла (group).
3. Доступ для остальных пользователей (others).
Для каждой категории устанавливаются три вида доступа: (x) - право на запуск
файла, (r) - право на чтение файла, (w) - право на изменение (редактирование) файла.
Для того, чтобы увидеть права доступа к файлам необходимо ввести команду ls с
ключом -l:
[dmitry@localhost dmitry]$ls -l /home/file.tmp
-rwxr-xr-- 1 dmitry users 33 Dec 1 00:38 file.tmp
Для данного примера мы видим, что владелец имеет права на чтение, запись, и
выполнение (первые три буквы rwx), группа пользователей
может лишь читать и
выполнять этот файл (следующие три r-x), ну а остальные пользователи могут только
читать данный файл (последние символы r--).
Изменение прав доступа
Права пользователя могут быть изменены только владельцем файла или
пользователем с правами администратора системы. Для изменения прав используется
команда
chmod [ u | g | o | a ] [+ | - | = ] [r | w | x ] name1 [name2 ...].
В качестве аргументов команда принимает указание классов доступа ('u'
владелец-пользователь, 'g' - владелец-группа, 'o' - остальные
пользователи, 'a' - все
вышеперечисленные группы вместе), права
доступа ('r' - чтение, 'w' - запись, 'x' выполнение) и операцию, которую необходимо произвести ('+' - добавить, '-' -убрать, '=' присвоить).
Таким образом, чтобы разрешить выполнение файла prog.pl всем
необходимо выполнить команду:
пользователем
[dmitry@localhost dmitry]$ chmod a+x prog.pl
Далее, чтобы оставить права записи только для владельца файла
выполнить:
[dmitry@localhost dmitry]$ chmod go-w prog.pl
Рассмотрим еще несколько примеров:
необходимо
$ chmod go=w prog.pl установить право на запись для всех пользователей
кроме владельца
$ chmod a+x prog.pl предоставить право на запись для всех
пользователей
$ chmod g+x-w prog.pl Добавить для группы право на выполнения файла,
но снять право на запись
Права доступа можно представить в виде битовой строки, в которой каждые 3
бита определяют права доступа для соответствующей категории
пользователей, как
представлено в таблице:
rwx rwx rwx
421 421 421
user group others
владелец группа остальные
Таким образом, для команды chmod 666 prog.pl имеем:
[dmitry@localhost dmitry]$ chmod 666 prog.pl
[dmitry@localhost dmitry]$ ls -l prog.pl
-rw-rw-rw- 1 dmitry users 78 Nov 20 prog.pl
Команда chmod 644 somefile устанавливает "обычные" права доступа, т.е.
владелец может читать и записывать в файл, а все остальные пользователи - только
читать.
Особенности прав доступа для каталогов
Права доступа для каталогов не столь очевидны. Это в первую очередь связано с
тем, что система трактует операции чтения и записи для каталогов отлично от остальных
файлов. Право чтения каталога позволяет Вам получить имена (и только имена) файлов,
находящихся в данном каталоге. Чтобы получить дополнительную информацию о файлах
каталога (например, подробный листинг команды ls -l), системы придется "заглянуть" в
метаданные файлов, что требует права на выполнения для каталога. Право на выполнение
также потребуется для каталога, в
который Вы захотите перейти (т.е. сделать его
текущим) с помощью команды cd.
T-бит, SUID и SGID
Наиболее внимательные пользователи быстро замечают, что помимо стандартных
"rwx" значений существуют еще и буквы "s" и "t". В действительности, битовая маска
прав доступа к файлам содержит 4 группы по 3 бита в каждой. Таким образом, команда
chmod 755 это всего лишь краткая запись полной формы команды: chmod 0755.
t-бит обычно используется с каталогами. Обычно, когда t-бит для каталога не
установлен, файл в данном каталоге
может удалить любой пользователь, имеющий
доступ на запись к данному файлу. Устанавливая t-бит на каталог мы меняем это правило
таким образом, что удалить файл из каталога может только владелец этого каталога или
файла.
Установить t-бит можно при помощи команд chmod a+tw somefile или chmod
1777 somefile.
Атрибуты SUID и SGID позволяют изменить права пользователя при запуске на
выполнения файла, имеющего эти атрибуты. Запускаемая программа получает права
доступа к системным ресурсам на
основе прав доступа пользователя, запустившего
программу. Установка же флагов SUID и SGID изменяет это правило таким образом, что
назначает права доступа к системным ресурсам исходя из прав доступа владельца файла.
Т.е. запущенный исполняемый файл, которым владеет суперпользователь, получает права
доступа к системным ресурсам на
уровне суперпользователя (фактически
неограниченные). При этом установка SUID приведет к наследованию прав владельцапользователя файла, а установка SGID -владельца-группы.
В завершении хочется отметить, что пользоваться такими мощными атрибутами
как SUID и SGID нужно с крайней осторожностью, особенно подвергать пристальному
вниманию программы и скрипты, владельцем которых является root (суперпользователь),
т.к. это потенциальная угроза безопасности системы.
40. Общая структура тома в Linux. Адресация расположения файла на томе.
Ограничения классической файловой системы s5fs.
Структура жёсткого диска
Сектора
Любой жёсткий диск можно представить как огромный «чистый лист», на который
можно записывать данные и откуда потом их можно считать. Чтобы ориентироваться на
диске, всё его пространство разбивают на небольшие «клеточки» — сектора. Сектор — это
минимальная единица хранения данных на диске, обычно его размер составляет 512 байт.
Все сектора на диске нумеруются: каждый из n секторов получает номер от 0 до n–1.
Благодаря этому любая информация, записанная на диск, получает точный адрес — номера
соответствующих секторов. Так что диск ещё можно представить как очень длинную
строчку (ленточку) из секторов. Можете посчитать, сколько секторов на вашем диске
размером в N гигабайт.
Разделы
Представлять жёсткий диск как единый «лист» не всегда бывает удобно: иногда
полезно «разрезать» его на несколько независимых листов, на каждом из которых можно
писать и стирать что угодно, не опасаясь повредить написанное на других листах. Логичнее
всего записывать раздельно данные большей и меньшей важности или просто относящиеся
к разным вещам.
Конечно, над жёстким диском следует производить не физическое, а логическое
разрезание, для этого вводится понятие раздел (partition). Вся последовательность (очень
длинная ленточка) секторов разрезается на несколько частей, каждая часть становится
отдельным разделом. Фактически, нам не придётся ничего разрезать (да и вряд ли бы это
удалось), достаточно объявить, после каких секторов на диске находятся границы разделов.
Таблица разделов
Технически разбиение диска на разделы организовано следующим образом: заранее
определённая часть диска отводится под таблицу разделов, в которой и написано, как
разбит диск. Стандартная таблица разделов для диска IBM-совместимого компьютера —
HDPT (HardDisk Partition Table) — располагается в конце самого первого сектора диска,
после предзагрузчика (Master Boot Record, MBR) и состоит из четырёх записей вида
«тип начало конец», по одной на каждый раздел. Начало и конец — это номера тех
секторов диска, где начинается и заканчивается раздел. С помощью такой таблицы диск
можно поделить на четыре или меньше разделов: если раздела нет, тип устанавливается
в 0.
Однако четырёх разделов редко когда бывает достаточно. Куда же помещать
дополнительные поля таблицы разбиения? Создатели IBM PC предложили универсальный
способ: один из четырёх основных разделов объявляется расширенным (extended
partition); он, как правило, является последним и занимает всё оставшееся пространство
диска.
Расширенный раздел можно разбить на подразделы тем же способом, что и весь диск:
в самом начале — на этот раз не диска, а самого раздела — заводится таблица разделов, с
записями для четырёх разделов, которые снова можно использовать, причём один из
подразделов может быть, опять-таки, расширенным, со своими подразделами и т. д.
Разделы,
упомянутые
в
таблице
разделов диска,
принято
называть основными (primary partition), а все подразделы расширенных разделов —
дополнительными (secondary partition). Так что основных разделов может быть не более
четырёх, а дополнительных — сколько угодно.
Чтобы не усложнять эту схему, при разметке диска соблюдают два правила: вопервых, расширенных разделов в таблице разбиения диска может быть не более одного, а
во-вторых, таблица разбиения расширенного раздела может содержать либо одну запись —
описание дополнительного раздела, либо две — описание дополнительного раздела и
описание вложенного расширенного раздела.
Тип раздела
В таблице разделов для каждого раздела указывается тип, который
определяет файловую систему, которая будет содержаться в этом разделе. Каждая
операционная система распознаёт определённые типы и не распознаёт другие, и,
соответственно, откажется работать с разделом неизвестного типа.
Следует всегда следить за тем, чтобы тип раздела, установленный в таблице разделов,
правильно указывал тип файловой системы, фактически содержащейся внутри раздела. На
сведения, указанные в таблице разделов, может полагаться не только ядро операционной
системы, но и любые утилиты, чьё поведение в случае неверно указанного типа может быть
непредсказуемым и повредить данные на диске.
Логические тома (LVM)
Работая с разделами, нужно учитывать, что производимые над ними действия связаны
непосредственно с разметкой жёсткого диска. С одной стороны, разбиение на разделы —
это наиболее традиционный для PC способ логической организации дискового
пространства. Однако если в процессе работы появится потребность изменить логику
разбиения диска или размеры областей (т. е. когда возникает задача масштабирования),
работа с разделами не очень эффективна.
Например, при необходимости создать новый раздел или увеличить размер
существующего, можно столкнуться с рядом трудностей, связанных с ограничением
количества дополнительных разделов или перераспределением данных. Избежать их очень
просто: нужно лишь отказаться от «привязки» данных к определённой области жёсткого
диска. В Linux эта возможность реализуется при помощи менеджера логических
томов (LVM — Logical Volume Manager). LVM организует дополнительный уровень
абстракции между разделами с одной стороны и хранящимися на них данными с другой,
выстраивая собственную иерархическую структуру.
Дисковые разделы (в терминологии LVM — физические тома) объединяются
в группу томов, внутри которой создаются логические тома. Таким образом, группа
томов выстраивает соответствие между физическим и логическим пространством диска.
Технологически это организуется следующим образом. Физические тома разбиваются
на отдельные блоки — физические экстенты, которые объединяются в группу томов.
Логические тома разбиваются на блоки такого же размера — логические экстенты. В
разных группах томов размер экстента может быть различным.
Отношения между логическими и физическими томами представлены в
виде отображения логических экстентов в физические. Возможны два способа
отображения — линейное и расслоённое (striped). В первом случае логические экстенты
располагаются последовательно соответственно физическим, во втором поочерёдно
распределяются между несколькими физическими томами.
В свою очередь, между логическим томом и группой томов возникают отношения,
аналогичные таковым между разделом и жёстким диском, с отличием в уровне абстракции
и, соответственно, колоссальной разнице в гибкости манипуляции. Поскольку раздел —
конкретная область физического диска между двумя определёнными секторами, а том —
логическая категория, принимаемая для удобства использования дискового пространства,
производить манипуляции со вторым значительно проще. Можно свободно
перераспределять логические тома внутри группы, изменять их размер, увеличивать размер
группы томов за счёт внесения в неё нового раздела (только при линейном отображении) и
многое другое.
Дисковые массивы (RAID)
Иногда обычной производительности жёсткого диска может не хватать. В случаях,
когда во главу угла ставится скорость работы с данными (скорость записи и чтения) или
надёжность их хранения, используется технология RAID (Redundant array of independent
disks — избыточный массив независимых дисков). Технология RAID позволяет объединять
несколько физических дисковых устройств (жёстких дисков или разделов на них)
в дисковый массив. Диски, входящие в массив, управляются централизованно и
представлены в системе как одно логическое устройство, подходящее для организации на
нём единой файловой системы.
Существует два способа реализации RAID: аппаратный и программный. Аппаратный
дисковый массив состоит из нескольких жёстких дисков, управляемых при помощи
специальной платы контроллера RAID-массива. Программный RAID в Linux-системах
(Linux Software RAID) реализуется при помощи специального драйвера (Multiple Device
driver — драйвер MD-устройства). В программный массив организуются дисковые
разделы, которые могут занимать как весь диск, так и его часть, а управление
осуществляется посредством специальных утилит (mdadm).
Программные RAID-массивы, как правило, менее надежды, чем аппаратные, но
обеспечивают более высокую скорость работы с данными (производительность процессора
и системной шины обычно намного выше, чем у любого дискового контроллера). Также их
преимущество по сравнению с аппаратными массивами: независимость от форматов
данных на диске и как следствие — большая совместимость с различными типами и
размерами дисков и их разделов. Использование программного RAID также позволяет
сэкономить на покупке дополнительного оборудования. Однако обратной стороной медали
станет увеличение нагрузки на процессор и системную шину, это следует иметь в виду,
принимая решение об использовании программного RAID.
Системы файлов Linux
С точки зрения пользователя файловая система Linux представляет
иерархическое дерево директорий, подчиняющееся семантикеUNIX.
собой
С внутренней точки зрения, ядро скрывает детали реализации и управляет многими
различными файловыми системами через общийуровень абстракции, то есть виртуальную
файловую систему (VFS).
Linux VFS спроектирована по объектно-ориентированным принципам и использует
набор определений, задающий структуру файлов. Системные структуры inode-object и fileobject представляют отдельные файлы. Объект file system object представляет файловую
систему в целом. Существует уровень абстракции для манипулирования этими объектами.
Файловая система Ext2fs – основная файловая система Linux. Она использует
механизм, сходный с UNIX BSD Fast File System (ffs)для поиска блоков данных,
принадлежащих некоторому файлу.
Основные различия между ext2fs и ffs касаются их политик распределения дисковой
памяти.
В системе ffs диск делится на файлы, состоящие из блоков по 8Kb, а блоки
разбиваются на фрагменты по 1Kb для хранения маленьких файлов или частично
заполненных блоков в конце файла.
Система Ext2fs не использует фрагменты; она распределяет память более мелкими
единицами. Размер блока по умолчанию в ext2fs -1Kb, хотя блоки в 2Kb и 4Kb также
поддерживаются.
Система Ext2fs использует политики распределения, спроектированные с целью
размещения логически смежных блоков файла в физически смежных блоках на диске, так
чтобы можно было использовать одну операцию ввода-вывода для нескольких смежных
блоков.
Структурная схема системы файлов Ext2fs показана в таблица 2.
Таблица 2. Структурная схема системы файлов Ext2fs в
Linux
Суперблок (Superblock)
Описание группы блоков (Group Descriptors)
Битовая карта блоков (Block Bitmap)
Битовая карта индексных дескрипторов (Inode Bitmap)
Таблица индексных дескрипторов (Inode Table)
Данные (Data)
Группы блоков в Ext2fs.Все блоки ext2fs разделяются на группы блоков. Для каждой
группы блоков создается отдельная запись в глобальной дескрипторной таблице, в этой
записи хранятся основные параметры:
номер блока битовый карты блоков
номер блока битовой карты inode
номер блока таблицы inode
число свободных блоков в группе
число inode, содержащих каталоги.
Битовая карта блоков — это структура, каждый бит которой показывает, отведён ли
соответствующий ему блок какому-либо файлу. Если бит равен 1, то блок занят.
Аналогичную функцию выполняет битовая карта индексных дескрипторов, показывая
какие именноиндексные дескрипторы заняты, а какие нет. Ядро Linux, используя
число inode, содержащих каталоги, пытается равномерно распределить inode каталогов по
группам, а inode файлов помещает, если это возможно, в группу с родительским
каталогом.
Все оставшееся место, обозначенное в таблице как данные, отводится для хранения
файлов.
Адресация файлов в Ext2fs.Система адресации данных — одна из самых
существенных составных частей файловой системы. Именно система адресации позволяет
находить нужный файл среди множества как пустых, так и занятых блоков на диске.
Файловая система ext2 использует следующую схему адресации блоков файла. Для
хранения адреса файла выделено 15 полей, каждое из которых состоит из 4 байтов.
Если размер файла меньше или равен 12 блокам, то номера этих кластеров
непосредственно перечисляются в первых двенадцати полях адреса. Если размер
файла превышает 12 блоков, то следующее 13-е поле содержит адрес кластера, в котором
могут быть расположены номера следующих блоков файла.
Таким образом, 13-й элемент адреса используется для косвенной адресации. При
максимальном размере блока, равном 4096 байтов, 13-й элемент может содержать до 1024
номеров следующих кластеров данных файла. Если размер файла превышает 12+1024
блоков, то используется 14-е поле, в котором находится номер блока, содержащего 1024
номеров блоков, каждый из которых хранит 1024 номеров блоков данных файла. Здесь
применяется уже двойная косвенная адресация. И, наконец, если файл включает более
12+1024+1048576 = 1049612 блоков, то используется последнее 15-е поле для
тройной косвенной адресации.
Таким образом, описанная выше система адресации, позволяет при максимальном
размере блока 4 Кб иметь файлы размера до 2 терабайт или больше.
Схема адресации файлов в системе Ext2fs изображена на рис. 26.3.
Развитие файловых систем UNIX
Описанная выше классическая файловая система UNIX является по-своему весьма
стройной и мощной, способной удовлетворить разнообразные требования пользователей.
В то же время эта система давно уже подвергалась критике за два существенных
недостатка, определяемых выбором описанных выше структур данных. Эти недостатки
следующие:
1. ненадежность;
2. низкая производительность.
Поговорим сначала о ненадежности. Можно назвать следующие опасные места в
структуре файловой системы UNIX.
Широкое использование сцепленных списковых структур для хранения жизненно
важной информации о размещении файлов и свободных блоков. Программистам известен
основной недостаток сцепленных списков: при минимальном искажении хотя бы одного
из указателей теряется, в лучшем случае, вся последующая часть списка. Возможна и
потеря данных, не входящих в поврежденный список. Попробуйте представить себе, что
произойдет на диске, если в качестве номера косвенного блока вследствие аппаратного
сбоя будет записан номер ни в чем не повинного блока данных из совсем другого файла…
Интенсивное использование суперблока для хранения часто изменяющейся
информации. Поскольку каждая операция записи связана с возможностью искажения
данных, под угрозой оказываются жизненно важные параметры файловой системы,
которые тоже хранятся в суперблоке, но не требуют частых изменений: размеры всей
файловой системы и ее частей, размер блока и т.п.
Компактное размещение в начале дискового тома наиболее важных метаданных
(суперблок, массив дескрипторов) приводит к тому, что при механическом повреждении
начальных дорожек диска теряется возможность доступа ко всем данным на диске.
Давно известны и факторы, влияющие на снижение производительности работы:
использование косвенных блоков приводит к тому, что для поиска нужного места в
большом файле могут потребоваться дополнительные операции чтения с диска.
используемые алгоритмы выделения и освобождения дисковых блоков по принципу
«последним освободился - первым занят» способствуют фрагментации дискового
пространства, а это, как нам известно, приводит к снижению скорости доступа.
Неудивительно, что в качестве замены системы s5fs были предложены различные
более надежные и производительные файловые системы. К их числу относятся, например,
система FFS, используемая в версии UNIX 4BSD, а также система ext2, поставляемая с
Linux. Все эти системы поддерживают привычную архитектуру UNIX, включая структуру
каталогов, жесткие и символические связи, типы файлов, набор атрибутов. Различия
заключаются в реализующих эту архитектуру структурах дисковых данных и в алгоритмах
работы с ними.
Постараемся дать общее представление о направлениях усовершенствования
файловых систем UNIX, не вдаваясь в детали конкретных систем.
Дисковый том разбивается на несколько групп цилиндров. Каждая группа содержит
копию общего суперблока, а также отдельный массив дескрипторов и блоки данных. В
случае повреждения основного экземпляра суперблока его содержимое может быть
восстановлено по сохранившейся копии. Повреждение метаданных в одной из групп
цилиндров не ведет к потере информации в остальных группах.
Данные о количестве и местонахождении свободных блоков вынесены из суперблока
и хранятся отдельно в каждой группе цилиндров.
Для хранения данных о свободных блоках используется не списковая структура, а
битовая карта, в которой каждый блок из группы цилиндров помечается как свободный
или занятый. Это уменьшает тяжесть последствий в случае повреждения данных.
Алгоритм размещения файлов старается по возможности размещать все файлы одного
каталога, а также их дескрипторы, в пределах одной группы цилиндров. Напротив,
подкаталоги по возможности не размещаются в той же группе цилиндров, что
родительский каталог. Таким способом обычно удается уменьшить количество
перемещений головок при работе программы с файлами.
Нужно отметить, что в современных версиях UNIX, как и в других современных ОС,
поддерживается одновременное использование разных файловых систем на разных
дисковых томах. Этой цели служит понятие виртуальной файловой системы (VFS). Она
позволяет подключать к единому дереву каталогов файловые системы различных типов, в
том числе такие чужеродные для UNIX, как FAT или NTFS. Для работы с файлами
используется единый набор файловых функций, однако при их вызове, в зависимости от
того, к какой файловой системе принадлежит данный файл, будут вызываться различные
подпрограммы.
41. Развитие структуры и свойств файловых систем в Linux. Журнализация.
ext (extended filesystem) — появилась в апреле 1992 года, это была первая файловая
система, изготовленная специально под нужды Linux ОС. Разработана Remy Card с целью
преодолеть
ограничения
файловой
системы
Minix.
ext2 (second extended file system) — была разработана Remy Card в 1993 году. Не
журналируемая файловая система, это был основной её недостаток, который исправит
ext3.
ext3 (third extended filesystem) — по сути расширение исконной для Linux ext2, способное
к журналированию. Разработана Стивеном Твиди (Stephen Tweedie) в 1999 году, включена
в основное ядро Linux в ноябре 2001 года. На фоне других своих сослуживцев обладает
более скромным размером пространства, до 4 тебибайт (4*240 байт) для 32-х разрядных
систем. На данный момент является наиболее стабильной и поддерживаемой файловой
системой
в
среде
Linux.
Reiser4 — первая попытка создать файловую систему нового поколения для Linux.
Впервые представленная в 2004 году, система включает в себя такие передовые технологии
как транзакции, задержка выделения пространства, а так же встроенная возможность
кодирования и сжатия данных. Ханс Рейзер (Hans Reiser), главный разработчик системы,
рекламировал использовать своё детище непосредственно как БД с улучшенными
метаданными. После того, как Ханс Рейзер был осуждён за убийство в 2008 году,
дальнейшая
судьба
системы
стала
сомнительной.
ext4 — попытка создать 64-х битную ext3 способную поддерживать больший размер
файловой системы (1 эксбибайт). Позже добавились возможности — непрерывные области
дискового пространства, задержка выделения пространства, онлайн дефрагментация и
прочие. Обеспечивается прямая совместимость с системой ext3 и ограниченная обратная
совместимость при недоступной способности к непрерывным областям дискового
пространства.
Журналируемая файловая система — файловая система (ФС), в которой осуществляется
ведение журнала, хранящего список изменений и, в той или иной степени, помогающего
сохранить целостность файловой системы при сбоях.
Принцип работы[править | править вики-текст]
Журналируемая файловая система сохраняет список изменений, которые она будет
проводить с файловой системой, перед фактическим их осуществлением. Эти записи
хранятся в отдельной части файловой системы, называемой журналом (англ. journal) или
логом (англ. log). Как только изменения файловой системы внесены в журнал, она
применяет эти изменения к файлам или метаданным, а затем удаляет эти записи из журнала.
Записи журнала организованы в наборы связанных изменений файловой системы.
При
перезагрузке
компьютера
программа монтирования может
гарантировать
целостность журналируемой файловой системы простой проверкой лог-файла на наличие
ожидаемых, но не произведённых изменений и последующей записью их в файловую
систему. То есть, при наличии журнала в большинстве случаев системе не нужно
проводить проверку целостности файловой системы. Соответственно, шансы потери
данных в связи с проблемами в файловой системе значительно снижаются.
По типу внесения в журнал журналируемые ФС подразделяются на:[1]
в режиме обратной связи (журналируются только метаданные): XFS, ext3fs;
упорядоченные (журналируются только метаданные синхронно относительно
данных): JFS2, ext3fs (по умолчанию), ReiserFS (основной);
в режиме данных (журналируются как метаданные, так и данные): ext3fs;
Примеры[править | править вики-текст]
В Mac OS X — HFS+.
Во FreeBSD журналирование транзакций файловой системы UFS может осуществляться
на уровне GEOM модулем gjournal.
В Linux существует несколько доступных журналируемых файловых систем. Наиболее
известные из них:
XFS — журналируемая файловая система, разработанная Silicon Graphics, но сейчас
выпущенная с открытым исходным кодом;
ReiserFS (Reiser4) — журналируемая файловая система разработанная специально для
Linux;
JFS (JFS1 и JFS2) (Smart File System) — журналируемая файловая система,
первоначально разработанная IBM, но сейчас выпущенная с открытым исходным кодом;
ext3fs (extended file system) — журналируемое расширение (можно подключать и
отключать ( tune2fs ), а также выбирать режим журналирования) файловой системы ext2,
используемой на большинстве версий GNU/Linux;
ext4fs — логическое продолжение ext3;
btrfs — разрабатываемая (альфа-версия) ФС, возможна прямая и обратная конвертация
с ext3fs.[2]
Установка и обновление программ, поставляемых в исходных текстах и rpmпакетах. Использование утилит для работы с репозиториями Linux.
В операционной системе Linux существуют три способа установки программного
обеспечения:
42.
Традиционный.
Из пакетов RPM.
Из пакетов, содержащих исходный код.
Рассмотрим по порядку все три способа.
1. Как правило, исходный текст распространяется в архиве. Обычно файл, содержащий
исходный текст, имеет двойное расширение: например, tar.gz или tar.bz2. Это означает, что
данный файл сжат двумя архиваторами: сначала tar, а потом gzip. После этого вам нужно
внимательно прочитать файл README, и следует ввести три команды:
. /configure
make
make install
Первая команда конфигурирует устанавливаемую программу для работы с вашей
системой. Эта программа также проверяет, может ли устанавливаемая программа работать
в вашей системе. Если работа программы невозможна,
вы увидите соответствующее сообщение и процесс установки будет прерван.
Обычно такое случается, когда в вашей системе не установлена одна из необходимых
новой программе библиотек. Для продолжения установки необходимо установить
требуемую библиотеку и попытаться заново ввести команду ./configure. После успешного
завершения работы программы ./configure будет создан файл Makefile, в котором будут
указаны необходимые параметры (пути к библиотекам, путь для установки программы) для
программы make.
Вторая команда (make) «собирает» программу. На этом этапе программа
компилируется, то есть создаются бинарные исполнимые файлы из исходных текстов.
Третья команда — make install — устанавливает программу и файлы справочной
системы в соответствующие каталоги. Обычно программы устанавливаются в каталог
/usr/bin, но это зависит от содержимого конфигурационного файла Makefile.
После успешной установки программы вы можете ее запустить, предварительно
прочитав документацию по этой программе.
2. Установка программного обеспечения в дистрибутивах Red Hat и Mandrake
производится с помощью программы rpm. RPM (Red Hat Package Manager) — это менеджер
пакетов Red Hat. Несмотря на то, что в названии присутствует «Red Hat», он полностью
предназначен работать как открытая пакетная система, доступная для использования кем
угодно. Она позволяет пользователям брать исходный код для нового программного
обеспечения и упаковывать его в форме исходного и двоичного кода, так что двоичные
файлы могут быть легко установлены и отслежены, а исходный код легко
построен. Эта система также сопровождает базу данных всех пакетов и их файлов, что
может быть использовано для проверки пакетов и запроса информации о файлах и/или
пакетах.
В отличие от привычных мастеров InstallShield, которые используются для установки
программ для Windows, пакеты RPM (файлы с расширением .rpm) не являются
выполняемыми файлами, то есть программами. В пакетах содержатся файлы (как в архиве),
которые нужно установить, а также различная информация об этом пакете: какой пакет
необходим для работы этого пакета, с каким пакетом конфликтует, информация о
разработчике, а также информация, указывающая, какие действия нужно выполнять при
установке этого пакета, например, какие каталоги нужно создать. Менеджер пакетов RPM
используется во многих дистрибутивах Linux (Red Hat, Mandrake, ASP, Black Cat) и
является довольно легкой и гибкой в использовании системой, что обусловливает его
популярность.
В простейшем случае команда установки пакета выглядит так:
rpm -i <пакет>
Перед установкой программы менеджер RPM проверит зависимости пакета, то есть
установлены ли в вашей системе другие пакеты, которые необходимы новой программе
или конфликтуют с ней. Если установлены все нужные
программе пакеты (или для работы программы вообще не нужны никакие
дополнительные пакеты), а также, если новая программа не конфликтует ни с одним уже
установленным пакетом, менеджер RPM установит программу.
В противном случае вы получите сообщение, что для работы программы нужен какойто дополнительный пакет или программа конфликтует с уже установленным пакетом.
3. Менеджер пакетов RPM является мощным средством для произведения операций
над пакетами — создания, установкя, обновления, удаления. Однако интерфейс командной
строки может понравиться далеко не всем, а особенно начинающему администратору.
Существуют и графические (под X Window) реализации менеджера пакетов — например,
kpackage из KDE, gnorpm и другие.
Также стоит упомянуть о программе APT. Программа APT — это система управления
пакетами программного обеспечения. Первоначально система APT была разработана для
Debian Linux. Сейчас входит в состав некоторых Red Hat совместимых
дистрибутивов (например, apt-get и входит в состав AltLinux, но ее вы не найдете в
Red Hat Linux). Для управления пакетами используется программа apt-get. Формат вызова
программы apt-get такой:
apt-get [опции] [команды] [пакет . . .]
еще
Иногда в пакетах RPM находятся не откомпилированные версии программ, а их
исходный код. Признаком этого является слово src вместо названия архитектуры. Для
установки такого пакета введите:
rpm --rebuild software-2.00-1.src.rpm
Разумеется, вместо software-2.00-l.src.rpm нужно указать реальное имя файла. Перед
установкой программы ее исходный текст будет откомпилирован, и потом программа будет
установлена.
Программы для работы с репозиторием
Менеджер пакетов RPM является мощным средством для произведения операций над
пакетами — создания, установкя, обновления, удаления. Однако интерфейс командной
строки может понравиться далеко не всем, а особенно начинающему администратору.
Существуют и графические (под X Window) реализации менеджера пакетов — например,
kpackage из KDE, gnorpm и другие.
Я рекомендую использовать программу gnorpm, которая обладает интуитивным
графическим интерфейсом. RPM больше подходит для создания новых пакетов, а также
для обновления большого числа пакетов. Для установки одного-двух пакетов лучше и
удобнее использовать gnorpm.
Функции программы gnorpm:
• Установка пакетов.
• Удаление пакетов.
• Получения сведений о пакете.
• Проверка пакета.
• Поиск пакета в базе RPM.
Для установки какого-либо пакета нажмите на кнопку «Установить». Если в приводе
CD-ROM находится инсталляционный CD, то в появившемся окне вы увидите список еще
не установленных в системе пакетов.
Если пакета нет в списке или вы хотите установить пакет, который не входит в состав
дистрибутива, нажмите на кнопку «Добавить» и добавьте в список пакеты, которые вы
хотите установить. Нажмите на кнопку «Запрос» для получения сведений о пакете.
Если пакет еще не установлен и у вас достаточно места на диске для его установки,
нажмите на кнопку «Установка». После этого будет выполнена проверка пакета на предмет
удовлетворения зависимостей: не требует ли этот пакет наличия какого-нибудь
неустановленного пакета и не конфликтует ли он с уже установленными пакетами. Если
все в порядке, вы увидите окно состояния установки пакета.
Найти пакет вы можете с помощью операции Поиск. Для этого нажмите на кнопку
«Поиск» на панели инструментов gnorpm или выполните команду меню Операции ->
Поиск. В открывшемся окне вы можете установить критерии поиска и нажать на кнопку
«Поиск».
В состав KDE входит программа с графическим интерфейсом пользователя,
управляющая пакетами — kpackage. По своим функциям она аналогична программе
gnorpm. Какую из этих программ использовать — дело вкуса и привычки.
Также стоит упомянуть о программе APT. Программа APT — это система управления
пакетами программного обеспечения. Первоначально система APT была разработана для
Debian Linux. Сейчас входит в состав некоторых Red Hat совместимых
дистрибутивов (например, apt-get и входит в состав AltLinux, но ее вы не найдете в
Red Hat Linux). Для управления пакетами используется программа apt-get. Формат вызова
программы apt-get такой:
apt-get [опции] [команды] [пакет . . .]
В дистрибутив Linux Mandrake входит собственное средство управления пакетами rpmdrake. К десятой версии дистрибутива оно немного видоизменилось. Теперь оно
состоит из трех частей:
• /usr/sbin/edit-urpm-media — менеджер источников пакетов (что такое источники, я
уже сказал, поэтому останавливаться на этом не будем);
• rpmdrake — менеджер установки пакетов;
• rpmdrake-remove — менеджер удаления пакетов.
Запустить любую из частей можно из меню К: Система| Настройка | Пакеты.
Установка ПО с использованием rpm
RPM Package Manager (RPM) является свободно распространяемым средством
управления пакетами программ, и работает на многих системах Linux и UNIX. Фирма Red
Hat поощряет использование RPM в качестве единого средства для распространения и
установки ПО. RPM поставляется по условиям лицензии GPL.
Для конечного пользователя RPM предоставляет массу возможностей, облегчающих
поддержку ОС в рабочем состоянии. Инсталляция, деинсталляция и обновление пакетов
RPM производятся спомощью простых команд, а все несущесвенные детали скрыты от
глаз пользователя. RPM поддерживает базу данных установленных пакетов и файлов,
позволяя Вам выполнять поиск и проверку состояния Вашей системы.
Во время обновления RPM специальным образом обрабатывает конфигурационные
файлы, так что Вы никогда не потеряете свои настройки - возможность, недоступная при
использовании файлов типа .tar.gz.
Основными целями при создании RPM были:
Обновляемость
С помощью RPM Вы можете обновить отдельные компоненты Вашей системы без
полной переустановки. Когда Вы получаете новую версию операционной системы,
дистрибутив которой основан на RPM (например, Red Hat Linux), Вам не нужно
переустанавливать ее на своей машине. RPM позволяет аккуратное, автоматическое
обновление Вашей системы. Конфигурационные файлы для пакетов не подвергаются
обновлению, так что Ваши настройки сохранятся.
RPM имеет пять основных режимов работы (не считая создания пакетов): установка,
удаление, обновление, поиск и проверка пакетов.
Репозиторий - это место в сети интернет, где хранятся какие-либо
данные. Репозиторий операционной системы линукс - это место где хранятся
программы (пакеты) этой операционной системы. В репозитории содержаться практически
все необходимые Вам программы, здесь же содержаться и их зависимости (пакеты,
которые необходимы для работы других пакетов). То-есть если Вам необходимо
установить какую-либо программу (пакет) и у Вас есть доступ к сети интернет, то это
делается очень просто. Я покажу на примере установки пакета mc (консольный
файловый менеджер) в операционной системе linux Ubuntu, так же этот метод подойдет
и для Debian, и для AltLinux (только если из команды убрать sudo и выполнять команду
от администратора). Все зависимости будут определены автоматически и будут
доустановлены необходимые для работы пакеты.
В командной строке вводим:
sudo apt-get install mc
Здесь:
sudo - предоставление временных административных прав пользователю. После ввода
всей команды будет необходимо вести Ваш пароль.
apt-get - запуск программы для работы с пакетами (программами).
install - указание, что происходит установка пакета.
mc - это само название пакета, который необходимо установить.
После ввода этой команды в консоли, Ubuntu произведет соединение с репозиторием,
найдет пакет mc, получит информацию об этом пакете, определит необходимые
зависимоти (если они есть) и спросит согласны ли Вы установить этот пакет, на что
необходимо будет ответить вводом команды y или русской буквой д, что означает yes или
да. После того, как Вы согласитесь с установкой система начнет закачку этого пакета на
Ваш компьютер (время закачки будет зависить от скорости Вашего соединения с сетью).
Далее произведет все необходимые манипуляции (распаковывание пакета, его установку и
т.д.) и завершит установку.
Теперь мы можем удостовериться, что пакет mc у нас установлен. Вводим в консоли
mc и вуаля, у нас запустился консольный файловый менеджер.
Далее мы научимся удалять установленные программы. Давайте рассмотрим пример
на том же самом mc. Для удаления этого пакета необходимо набрать в консоли команду:
sudo apt-get remove mc
После выполнения этой команды также будет необходимо ввести пароль и
согласиться или отказаться от удаления этого пакета. Вот и все! Я думаю вы заметили что
заменилась только команда install на команду remove, то-есть удаление.
Проверяем удаление пакета командой mc.
mc: command not found
Все мы научились устанавливать или удалять пакеты из системы.
Но иногда нам программ из репозитрия, используемого по умолчанию в Ubuntu и
других дистрибутивов линукс, недостаточно. Для этого нам необходимо будет добавить
репозиторий. Сейчас рассмотрим как это сделать на примере любимой нами Ubuntu. Для
начала открываем конфигурационный файлс помощью програмым gedit:
sudo gedit /etc/apt/sources.list
Откроется окно текстового редактора с этим конфигурационным файлом. Находим
строчки вида: "deb http://ru.archive.ubuntu.com/ubuntu/ karmic universe" - это и есть
репозитории.
Для добавления своего нужно для начала найти репозиторий, далее с новой строчки
напиcать: deb http://адрес репозитория/ karmic universe, где deb - это тип пакетов (deb - это
пакеты Debian), далее идет адрес найденого Вами репозитория, karmic - это кодовое
название версии ОС (Ubuntu 9.10 имеет кодовое название karmic koala, отсюда и karmic),
universe - это тип пакетов по разработкам (может быть update, multiverse и т.д.). Сохраняем
конфигурационный файл. И в консоли вводим:
sudo apt-get update
Update - здесь выполняет роль обновления информации о всех доступных пакетах.
После этой команды, система соединиться со старыми и новым добавленным
репозиторием и обновит список доступных пакетов, что может занять несколько минут (в
зависимости от скорости соединения с сетью). Все, мы добавили свой репозиторий в нашу
любимую Ubuntu.
43. Обновление компонентов Linux. Сборка и обновление ядра Linux.
HOW-TO: Сборка ядра Linux
Шаг 1. Получение исходного кода ядра
Шаг 2. Получение необходимых для сборки пакетов
Шаг 3. Применение патчей
Шаг 4. Конфигурация будущей сборки ядра
Шаг 5. Сборка ядра
Шаг 6. Установка образов и заголовков ядра
Шаг 7. Генерация начального RAM-диска
Шаг 8. Обновление конфигурации загрузчика GRUB
Шаг 9. Проверка ядра
Этапы сборки ядра
-> 1 Приобретение исходников ядра.
-> 2 Подготовка каталогов с исходниками ядра.
-> 3 Конфигурирование ядра.
-> 4 Компиляция ядра и установка модулей.
-> 5 Перемещение ядра.
-> 6 Настройка и запуск lilo.
Для нормальной сборки и компиляции ядра следует выполнять все этапы по порядку.
Рассмотрим каждый из этапов подробнее.
1. Приобретение исходников ядра:
Исходники своего ядра можно найти на дистрибутиве со своей осью. Но на нем
невсегда последняя версия ядра =(. Исходники последней версии ядра для Linux
можнонайти на ftp://ftp.kernel.org (или на каком-нибудь зеркале). Там ядра лежат
в/pub/linux/. Загрузи ядро себе на хард и помести его в каталог /usr/src. Там-же создай
каталог для файлов и каталогов ядра (обычно создают что-то типа linux-2.X.X, где 2.X.X версия нового ядра) командой mkdir linux-2.X.X. После этого создай связь с каталогом
linux (ln -s linux-2.X.X linux). Если каталог linux-2.X.X уже существует, то его
предварительно надо удалить. Ну все, вроде сырцы нашли, да папку создали...
Продолжаем...
2. Подготовка каталогов с исходниками ядра.
После успешно завершенного этапа 1 пришло время подготовить древо каталогов для
файлов исходных кодов ядра.
Синтаксис команды для восстановления древа зависит от формата скаченного файла.
В нашем случае это могут быть файлы linux-2.X.X.tar.gz и linux-2.X.X.tar.bz2.
Для каждого из файлов используется определенный набор команд.
Для linux-2.X.X.tar.gz:
tar xzvf linux-2.X.X.tar.gz
Для linux-2.X.X.tar.bz2:
bzcat linux-2.X.X.tar.bz2 | tar xv
При выполнении этих команд содержимое файлов развернется в каталог,
определенный связью linux. После этого командой cd перейди в каталог linux
(cd linux). Этот каталог называется каталогом верхнего уровня исходного древа.
В нем много каталогов, одним из которых является Documentation, в котором
хранится дополнительная информация по ядру.
Для начала компиляции нового ядра выполни команду:
make mrproper
Ядро скомпилировано... Попробуем его настроить для своих потребностей...
3. Конфигурирование ядра.
На этом этапе придется выбрать опции, которые будут использоваться в новом
ядре. Не обязательно вникать в подробности массы опций. В большинстве из них
можно воспользоваться настройками по умолчанию (плохо не посоветуют =)).
Существуют три метода создания файла конфигурации, используемого при сборке
нового ядра (подробно опишу метод 3):
1 make config
2 make menuconfig
3 make xconfig
make config - это наиболее простой пошаговый сценарий.
make menuconfig - это более удобный метод (требует наличие ncurses).
make xconfig - это графическая утилита для настройки ядра. Перед тем, как ей
воспользоваться необходимо перейти в среду X Window. После выполнения этой
команды
диалоговое
сначала
скомпилируются
необходимые
элементы,
затем
появится
окно.
Для каждой из представленных опций есть 3 установочных параметра: y,m,n.
y(yes) - Включает или встраивает опцию в ядро.
m(module) - Создает для выбранной опции загружаемый в динамическом режиме
модуль (без reboot'a). Существует не для всех опций.
n(no) - Отключает поддержку опции.
Для использования конфигуратора на базе X в системе должны буть установлены
библиотеки TCL/TK.
Вроде все... Ядро настроено...
4. Компиляция ядра и установка модулей.
В свою очередь этот этап делится на шаги:
1 Подготовка
-> make dep
-> make clean
2 Непосредственно сборка ядра
-> make bzImage|bzdisk|bzlilo
3 Сборка и установка модулей
-> make modules
-> make modules_install
Первый из них - make dep и make clean - являются типа подготовкой. После
выполнения make dep создаются файлы зависимостей (.depend), которые располаются
в каждом из подкаталогов древа исходных кодов. Если нет нарушений в
расположении
компонентов древа, то процесс пройдет спокойно. Далее используется команда
make clean, которая удалит все лишние (вспомогательные) файлы, созданные от
предыдущих процессов компиляции.
Далее идет шаг, при котором необходимо непосредственно собрать ядро. Для сборки
ядра придется выбрать одну из 3-х команд: make bzImage, make bzdisk или make
bzlilo. Каждая из команд выполняет фактически одну и ту-же операцию, только
две последние выполняют одно дополнительное действие.
Рассмотрим подробнее каждую из команд:
make bzImage - стандартная операция, при которой будет только скомпилировано
ядро. Если все прошло без проблем, то созданное в результате компиляции ядро
будет расположено в каталоге /usr/src/linux/arch/i386/boot. В этом случае ядру
присваивается имя bzImage. Диспетчер загрузки lilo|grub должен найти это ядро и
загрузить его. Для этого достаточно скопировать файл bzImage и выполнить команду
lilo для переустановки диспетчера загрузки.
make bzdisk - этот метод позволяет выполнить практически ту-же задачу, что и
bzImage, но после завершения компиляции будет автоматически выполнено
копирование нового ядра на дискету. В дальнейшем эту дискету можно будет
использовать для загрузки системы.
make bzlilo - это рекомендуемый метод формирования и инсталляции нового ядра,
требующий предварительной подготовки lilo. При использовании этого метода
map-файл ядра не перемещается в другой каталог. Более того новое ядро может быть
записано поверх уже существующего, причем записано с ошибками, поэтому его
использование не рекомендуется. Этот метод очень похож на bzImage и отличается
только наличием дополнительной операцией, которая выполняется после совершения
компиляции ядра. После компиляции ядра происходит копирование файлов
созданного
ядра в каталог / в качестве vmlinuz (при этом сохраняется резервная копия
файла vmlinuz), затем выполняется команда lilo, в результате чего происходит
переустановка диспетчера загрузки (и распознавание нового ядра).
Третим шагом является сборка и установка модулей ядра.
Этот процесс выполняется с помощью 2-х команд make modules и
make modules_install. Название команды make modules говорит само за себя: при
выполнении этой команды происходит сборка модулей, которые соответствуют ядру,
созданному на предыдущем этапе. Команда make modules_install, в сою очередь,
перемещает созданные модули из исходного древа ядра в каталог
/lib/modules/<kernel-version>/kernel/<module-type>. В качестве типа модуля
(<module-type>) используется имя категории, к которой относятся созданные
модули (Например: block, misk, net, pcmcia, etc...).
еще
Шаг 1. Получение исходного кода ядра
1. Перейдите на сайт kernel.org либо выполните
sudo apt-get install linux-source
1. Загрузите полный архив необходимой вам версии ядра в домашнюю папку, нажав справа от неё на ссылку
[Full Source]
2. Распакуйте полученный архив, используя команды:
cd ~/
tar -xjf linux-2.6.x.y.tar.bz2
Или в случае с linux-source:
cd /usr/src
tar -xjf linux-source-2.6.x.y.tar.bz2
Шаг 2. Получение необходимых для сборки пакетов
Данный шаг необходимо выполнить, только если ядро собирается на компьютере в первый раз
Выполните следующие команды для установки основных пакетов:
sudo apt-get update
sudo apt-get build-dep linux
sudo apt-get install kernel-package
Далее всё зависит от того, каким способом вы хотите произвести конфигурацию ядра. Это можно сделать
несколькими способами.
config - традиционный способ конфигурирования. Программа выводит параметры конфигурации по одному,
предлагая вам установить для каждого из них свое значение. Не рекоммендуется для неопытных
пользователей.
oldconfig - файл конфигурации создаётся автоматически, основываясь на текущей конфигурации ядра.
Рекомендуется для начинающих.
defconfig - файл конфигурации создаётся автоматически, основываясь на значениях по-умолчанию.
menuconfig - псевдографический интерфейс ручной конфигурации, не требует последовательного ввода
значений параметров. Рекомендуется для использования в терминале.
xconfig - графический (X) интерфейс ручной конфигурации, не требует последовательного ввода значений
параметров.
gconfig - графический (GTK+) интерфейс ручной конфигурации, не требует последовательного ввода
значений параметров. Рекомендуется для использования в среде GNOME.
localmodconfig - файл конфигурации, создающийся автоматически, в который включается только то, что
нужно данному конкретному устройству. При вызове данной команды большая часть ядра будет
замодулирована
localyesconfig - файл конфигурации, похожий на предыдущий, но здесь большая часть будет включена
непосредственно в ядро. Идеальный вариант для начинающих.
В
случае,
если
использовать config, oldconfig, defconfig, localmodconfig или localyesconfig,
вы
вам
хотите
больше
не
нужны
никакие дополнительные пакеты. В случае же с оставшимися тремя вариантами необходимо установить также
дополнительные пакеты.
Для установки пакетов, необходимых для использования menuconfig выполните следующую команду:
sudo apt-get install libncurses5-dev
Для установки пакетов, необходимых для использования gconfig выполните следующую команду:
sudo apt-get install libgtk2.0-dev libglib2.0-dev libglade2-dev
Для установки пакетов, необходимых для использования xconfig выполните следующую команду:
До Ubuntu 12.04:
sudo apt-get install qt3-dev-tools libqt3-mt-dev
C Ubuntu 12.10:
sudo apt-get install libqt4-dev
Шаг 3. Применение патчей
Данный шаг не является обязательным
Если вы никогда до этого не применяли патчей к исходному коду, то выполните следующую команду:
sudo apt-get install patch
Эта команда установит программу patch, необходимую для, как можно догадаться, применения патчей.
Теперь скачайте файл патча в папку, куда вы распаковали ядро. Это может быть либо архивный файл (напр.
Bzip2 или Gzip), либо несжатый patch-файл.
На данный момент подразумевается, что вы уже сохранили файл в ту папку, куда ранее распаковали
ядро,
и
установили
программу
patch.
Если скачанный вами файл был в формате Gzip (*.gz), тогда выполните следующую команду для распаковки
содержимого архива:
gunzip patch-2.6.x.y.gz
Если скачанный вами файл был в формате Bzip2 (*.bz2), тогда выполните следующую команду для
распаковки содержимого архива:
bunzip2 patch-2.6.x.y.bz2
где 2.6.x.y - версия патча ядра. Соответствующие команды распакуют файл патча в папку с исходным
кодом ядра. Прежде чем применить патч, необходимо удостовериться, что он заработает без ошибкок. Для
этого выполните команду:
patch -p1 -i patch-2.6.x.y --dry-run
где 2.6.x.y - версия патча ядра. Эта команда сымитирует применение патча, не изменяя сами файлы.
Если при её выполнении не возникнет ошибок, то изменения можно смело внедрять в сами файлы. Для
этого выполните команду:
patch -p1 -i patch-2.6.x.y
где 2.6.x.y - версия патча ядра. Если не было никаких ошибок, значит к исходному коду был успешно
применён патч.
Внимание! Перед
тем,
как
применять
патч,
проведите
следующие
действия:
1.
Скачайте
сhttp://www.kernel.org патч той же версии, что и ваших исходников. 2. Выполните следующую команду:
patch -p1 -R <patch-2.6.x.y
где 2.6.x.y - версия патча и ваших исходников
Шаг 4. Конфигурация будущей сборки ядра
Перейдите в папку, куда вы распаковали ядро, выполнив команду
cd ~/linux-2.6.x.y
где 2.6.x.y - версия загруженного вами ядра.
На данный момент вы уже должны были определиться с методом конфигурации ядра (если нет, то
ознакомьтесь с ними в разделе «Получение необходимых для сборки пакетов». В зависимости от этого,
выполните следующую команду для запуска выбранного вами способа конфигурации:
config - традиционный способ конфигурирования. Программа выводит параметры конфигурации по одному,
предлагая вам установить для каждого из них свое значение. Вызывается командой
make config
.
oldconfig - файл конфигурации создаётся автоматически, основываясь на текущей конфигурации ядра.
Рекомендуется для начинающих. Вызывается командой
make oldconfig
defconfig - файл конфигурации создаётся автоматически, основываясь на значениях по-умолчанию для
данной конкретной архитектуры. Вызывается командой
make defconfig
menuconfig - псевдографический интерфейс ручной конфигурации, не требует последовательного ввода
значений параметров. Рекомендуется для использования в терминале. Вызов:
make menuconfig
gconfig и xconfig - графические конфигураторы для ручной настройки. Вызов:
make gconfig
и
make xconfig
соответственно
localmodconfig и localyesconfig -
автоматические
конфигураторы.
Конфиг
создается
на
основе
вызванных в данных момент модулей и запущенного ядра. Разница между этими двумя конфигураторами в
количестве модулей. В первом случае их будет не менее 50% ядра, а во-втором не больше 2 модулей.
Вызов:
make localmodconfig
и
make localyesconfig
соответственно
После вызова соответствующая программа конфигурации будет запущена. Произведите необходимые
настройки в соответствии с вашими потребностями, сохраните файл конфигурации и переходите к следующему
шагу.
Шаг 5. Сборка ядра
Итак, приготовления завершены. Теперь можно запустить процесс сборки ядра. Чтобы это сделать,
выполните команду:
fakeroot
make-kpkg
-j
5
--initrd
--append-to-version=-custom
kernel_image
kernel_headers #-j <количество ядер>+1
Сборка ядра может занимать от 20 минут до нескольких часов в зависимости от конфигурации ядра и
технических параметров компьютера.
Шаг 6. Установка образов и заголовков ядра
Когда сборка ядра подошла к концу, в вашей домашней папке появятся два deb-пакета. Их и необходимо
установить. Для этого выполните команды:
cd ~/
sudo dpkg -i linux-image-2.6.x.y-custom_2.6.x.y-custom-10.00.Custom_arc.deb
sudo dpkg -i linux-headers-2.6.x.y-custom_2.6.x.y-custom-10.00.Custom_arc.deb
где 2.6.x.y - версия собранного ядра, arc - архитектура процессора (i386 - 32-бит, amd64 - 64-бит).
Если вы не знаете точного названия пакета, выведите список файлов в домашнем каталоге командой
ls -l
и найдите эти самые два пакета.
Шаг 7. Генерация начального RAM-диска
Для корректной работы Ubuntu требует наличия образа начального RAM-диска. Чтобы его создать,
выполните команду:
sudo update-initramfs -c -k 2.6.x.y-custom
где 2.6.x.y - версия собранного ядра.
Внимание! Если вы во время сборки ядра добавили ключ –initrd, этот шаг можно пропустить.
Шаг 8. Обновление конфигурации загрузчика GRUB
Для того, чтобы новая версия ядра была доступна для выбора при загрузке компьютера, выполните
следующую команду:
sudo update-grub
Файл menu.lst (для GRUB версии 1) или grub.cfg (для GRUB версии 2) обновится в соответствии с
наличием установленных операционных систем и образов ядер.
Этот шаг тоже можно пропустить, потому что во время установки ядра команда update-grub вызывается
postinst-скриптом
Шаг 9. Проверка ядра
Сборка и установка ядра успешно выполнены! Теперь перезагрузите компьютер и попробуйте загрузить
систему с новым ядром. Чтобы удостовериться, что система запущена с новым ядром, выполните команду
uname -r
Она выведет на экран используемую версию ядра.
Если всё сделано правильно, то вы можете удалить архивы с исходным кодом и весь каталог linux-2.6.x.y
в вашей домашней папке. Это освободит около 5 ГБ на вашем жёстком диске (размер освобождаемого
пространства зависит от параметров сборки).
На этом процесс сборки и установки завершён, поздравляю!
