с двойной загрузкой значительно проще,

Создать систему с двойной загрузкой значительно проще, если уже установлена ОС Windows 98. Нужно просто запустить программу установки Windows 2000 Professional, не выбирая режим модернизации, как это показано на Экране 1. Также не следует преобразовывать раздел в NTFS (параметр Convert the partition to NTFS), так как Windows 98 не работает с разделами файловой системы. Если по неосторожности преобразовать корневой раздел (т. е. логический диск C) в формат NTFS, то Windows 98 уже не загрузится. На других разделах можно установить NTFS, но Windows 98 не будет их "видеть". Если процедура установки Windows 2000 Professional шла в обычном режиме, появляется меню, в котором можно выбрать операционную систему (Windows 2000 Professional или Windows 98) для загрузки. Добавить Windows 2000 Professional к Windows 98 очень просто, поэтому при создании системы с двойной загрузкой "с чистого листа" рекомендуется сначала установить Windows 98.

ЭКРАН 1. Отказ от немедлненного обновления.

Пространства имен WMI

Классы определяют свойства объектов, и экземпляры класса представляют объекты в системе. WMI использует пространство имен, содержащее несколько подпространств, которые WMI упорядочивает иерархически, чтобы организовать экземпляры объектов. Прежде, чем управляющее приложение сможет обращаться к объектам в пределах пространства имен, оно должно подключиться к нему.

WMI называет пространство имен корневого каталога root. Все варианты установки WMI имеют четыре предопределенных пространства имен, которые постоянно находятся ниже корня: CIMV2, Default, Security и WMI. Некоторые из этих пространств имен имеют внутри себя другие пространства. Например, CIMV2 включает пространства имен Applications и ms_409, как подпространства имен. Провайдеры иногда определяют свои собственные пространства имен; встречаются пространства имен WMI (которые определяет провайдер WMI драйверов устройств Windows) ниже корня Windows 2000. В отличие от пространства имен файловой системы, которая включает иерархию каталогов и файлов, у пространства имен WMI - только один уровень в глубину. Вместо использования имен для идентификации объектов, как это делается в файловой системе, WMI задействует свойства объектов, которые определены как ключи. Управляющие приложения определяют имена класса с ключевыми названиями, чтобы указать определенные объекты в пределах пространства имен. Таким образом, каждый экземпляр класса должен быть уникально идентифицирован по своим ключевым параметрам. Например, провайдер EventLog использует класс Win32_NTLogEvent для представления записей в журнале событий. У этого класса два ключа: LogFile и RecordNumber, тип обоих - строка. Управляющие приложения, которые делают запрос WMI на экземпляры записей в журнале событий, получают от провайдера ключевые пары, идентифицирующие запись. Приложение ссылается на запись, используя синтаксис, который показан в примере: \\MARKLAPTOP\CIMV2: Win32_ NTLogEvent .Logfile="Application", RecordNumber="1".

Первый компонент в имени идентификатора - компьютер, на котором объект расположен, а второй - пространство имен, в котором объект постоянно находится. Имя класса следует за двоеточием, а ключевые названия и их связанные значения следуют за точкой. Запятая отделяет ключевые значения.

Протоколирование в сети

Как было сказано, сообщения системы протоколирования могут отправляться демоном syslogd на удаленный хост, но там его кто-то должен принять. Оказывается, делает это такой же демон syslogd, запущенный на этом удаленном хосте. Точнее, syslogd на любом компьютере может прослушивать не только сокет /dev/log (принимая тем самым сообщения от местных источников), но еще и порт 514/UDP, что обеспечивает прием сообщений с других компьютеров локальной сети (и последующую запись их в локальный файл). Тем самым обеспечивается возможность создания , что может оказаться очень удобно для системного администратора (в одном месте отслеживаются все события в сети), а также повышается безопасность, поскольку сообщения о проникновении хакера на один из хостов сети не могут быть тут же этим хакером удалены из протокола. Однако для организации такого необходимо предпринять некоторые дополнительные усилия.

Во-первых, поскольку для приема и отправки сообщений по сети используется порт 514/UDP, он должен быть доступен на обоих компьютерах (клиенте и сервере). Для этого в файле /etc/services на обоих компьютерах должна присутствовать строка

syslog 514/udp.

Если такая строка отсутствует, syslogd не может ни принимать сообщения, ни отправлять их в сеть, поскольку не может открыть UDP-порт. Если такая ситуация возникает, syslogd немедленно прекращает записывать какие-либо сообщения даже в локальный протокол. При этом, как показывает команда ps, он остается в памяти и даже сохраняет сообщения в каких-то буферах, поскольку, если указанную строку восстановить в файле /etc/services на клиенте, то, по крайней мере часть сообщений все же появляется в протоколе (после перезапуска syslogd). Во-вторых, при запуске демона syslogd на сервере должна быть указана опция -r, которая обеспечивает возможность приема сообщений из сети (по умолчанию демон syslogd ждет сообщения только от локального сокета). В-третьих, должны быть соответствующим образом исправлены настройки в файлах /etc/syslog.conf на обоих компьютерах. Например, если вы хотите все сообщения перенаправить на сервер протоколирования, необходимо на компьютере-клиенте прописать в файле /etc/syslog.conf строку вида:

*.* @hostname

Если в вашей сети несколько доменов, которые обслуживаются одним сервером протоколирования, то не удивляйтесь, что в протоколе на сервере будут указаны полные имена клиентов (с указанием домена). Правда, при запуске syslogd можно использовать опции -s список_доменов или -l список_хостов, которые обеспечивают замену в протоколе полных имен хостов на их краткие имена (без указания домена). Не забудьте после корректировки опций запуска и файла /etc/syslog.conf перезапустить демон, поскольку sysklogd не перечитывает конфигурационные файлы автоматически.

Провайдеры

В основе WBEM лежит спроектированная в DMTF спецификация Common Information Model (CIM). CIM определяет, КАК системы управления представляют структуру компьютера, приложения или устройства. Разработчики провайдера используют CIM для представления управляемых компонентов, составляющих приложение. Для удобства реализации компонентов в стандарте CIM разработчики применяют язык Managed Object Format (MOF).

Помимо определения объектов провайдер должен связать с ними WMI. WMI классифицирует провайдеров согласно свойствам, которые те обеспечивают. В перечислены спецификации WMI-провайдера. Стоит отметить, что провайдер может выполнять не одну функцию; поэтому провайдером может быть, например, и класс, и источник событий. Чтобы прояснить определения свойств в , приведу пример провайдера, который наделен большинством этих свойств. Источник (провайдер) событий EventLog определяет несколько объектов, включая EventLog Computer, EventLog Record, EventLog File. Провайдер EventLog Computer - поставщик классов, поскольку он определяет объекты, используя классы, и должен предоставлять описания этих классов WMI. Данный провайдер является также поставщиком экземпляров, так как он может предоставить несколько экземпляров для каждого из своих классов. Один из таких классов - EventLog File. Провайдер EventLog предоставляет экземпляры для каждого из журналов системных событий (system's event logs) (например, журналы системных событий, прикладных событий, событий в системе безопасности).

Провайдер EventLog определяет экземпляр данных и предоставляет управляющим приложениям возможность нумеровать записи, а также запрашивать определенные свойства записей журнала событий. Это свойство позволяет классифицировать провайдера EventLog как поставщика свойств. Чтобы обеспечить управляющим программам возможность использовать WMI для архивирования и восстановления журналов событий, провайдер EventLog дополняет объекты класса Event Log File методами Backup и Restore. Это позволяет отнести провайдера EventLog к числу поставщиков методов. Наконец, управляющая программа может зарегистрироваться для получения сообщений о появлении новых записей в одном из журналов. Таким образом, провайдер EventLog, использующий WMI для уведомления о появлении новых записей в журнале событий, является поставщиком событий.

Проведите ревизию своего ПО

В проверке на готовность к Windows 2000 нуждаются и прикладные программы. (Сразу отметим: если у вас есть ПО, которым вы не пользуетесь, деинсталлируйте его. Это упростит процесс модернизации.) С Windows 2000 совместимы тысячи программ, но есть ли среди них жизненно важные для вас? Чтобы это узнать, щелкните на ссылке Software на уже знакомой вам странице Windows 2000 Product Compatibility и поищите информацию об интересующем вас ПО по его названию, производителю или типу. Нам очень повезло с программами - главные прикладные пакеты в большинстве своем работали без сучка без задоринки. Однако продукты, тесно связанные с аппаратурой, такие как игры или средства подготовки CD-дисков, не всегда оказывались совместимыми с Windows 2000.

Программа в списке может иметь характеристику "сертифицированная" (certified), "готовая" (ready) или "планируемая" (planned). "Сертифицированные" - это протестированные на совместимость независимой организацией, поэтому можно быть (более или менее) уверенным, что они заработают. "Готовые" - те, разработчики которых выполнили необходимую проверку и собираются предоставлять техническое сопровождение клиентам, использующим продукт с Windows 2000. Слово "планируемые" означает, что версии, работающей с Windows 2000, придется подождать.

Однако само по себе отсутствие программного продукта в списке не означает, что он обязательно станет источником проблем. В действительности большинство программ (и устройств), изготовленных в последние два-три года, заработают легко и непринужденно. И все же осторожность не повредит, особенно в отношении ПО, необходимого вам для работы. Выясните вопрос о совместимости программы с Windows 2000 у разработчиков и посмотрите, нет ли на их Web-узле бесплатного модуля корректировки.

Проверка DMA

Одной из вещей, которую мы не можем обеспечить, является предотвращение причинения ущерба системе по причине неверного DMA (Direct Memory Access, прямой доступ к памяти). Для предотвращения перезаписи драйвером через DMA произвольной части реальной памяти требуется аппаратная защита. Однако мы можем обнаружить некоторые ошибки DMA следующим образом. DMA обычно запускается путем записи адреса DMA в некоторый порт ввода-вывода. Мы можем предоставить библиотечную процедуру, которая вызывается для записи в некоторый порт ввода-вывода с предварительным декодированием (способом, зависящим от устройства) записей в этот порт ввода-вывода с целью нахождения используемых адресов DMA и проверки их допустимости. В злонамеренных драйверах такая проверка может обходиться, но в добропорядочных драйверах этот способ позволяет выловить хотя бы некоторые ошибки при умеренных накладных расходах.

В зависимости от аппаратуры мы можем поступить еще лучше. Если бы на периферийной шине имелось MMU (Memory Management Unit, устройство управления памятью) ввода-вывода, мы могли бы точно ограничить доступ к памяти для каждого драйвера [16]. Для систем с шиной PCI-X мы собираемся возложить на свой сервер шины PCI ответственность за инициализацию таблиц MMU ввода-вывода. Это часть нашей будущей работы.

Проверка параметров

Поскольку все вызовы ядра производятся путем генерации внутреннего прерывания, ядро может выполнить ограниченную валидацию параметров до диспетчеризации вызова. Эта валидация включает проверки как исправности (sanity), так и прав доступа (permission). Например, если драйвер просит ядро записать блок данных с использованием физической адресации, то этот вызов может быть отвергнут, поскольку не у всех драйверов имеется право на такие действия. Используя виртуальную адресацию, ядро, по-видимому, не сможет сказать, является ли этот адрес записи правильным, но оно, по крайней мере, сможет проверить, что этот адрес действительно является допустимым адресом в сегменте данных или стека пользовательского процесса, а не относится к сегменту текста и не является каким-то случайным недействительным адресом.

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

Работа с linuxconf

Программная оболочка linuxconf сделана специально для того, чтобы пользователи могли легко настроить ОС соответственно своим потребностям. Фактически это централизованный редактор различных конфигурационных файлов с разъяснениями значений для каждого поля. В случае телефонного соединения важно правильно настроить программу pppd, которая организует передачу данных по телефонной линии, и написать сценарий для программы chat, инициирующей телефонный звонок и вашу авторизацию у провайдера. При настройке телефонного соединения linuxconf создает для него chat-сценарий и конфигурирует программу реализации протокола PPP, причем linuxconf работает как с графической оболочкой, так и в текстовом режиме.

Рис. 1. Первоначальный вид окна конфигуратора

Чтобы приступить к созданию конфигурационных файлов для соединения с Internet, нужно запустить конфигуратор командой linuxconf или выбрать соответствующий пункт меню в графической оболочке. Внешний вид окна linuxconf после запуска показан на рис. 1. Для конфигурирования модемного подключения необходимо выбрать раздел Config.Networking.Client Tasks.PPP/SLIP/PLIP. После этого в правой части окна приложения открывается список существующих конфигураций для протоколов PPP, SLIP или PLIP. Поскольку протокол PPP наиболее популярен среди провайдеров, то именно его настройку мы и будем рассматривать в дальнейшем, хотя другие протоколы телефонного соединения настраиваются аналогично.

При первом запуске конфигуратора список соединений пуст. Чтобы создать новую конфигурацию соединения, следует нажать кнопку Add, после чего откроется закладка с перечнем типов протокола. Выбираем протокол PPP и нажимаем на кнопку Accept. Возникает следующая закладка, в которой нужно указать телефон провайдера, свое регистрационное имя и пароль. Затем нажимаем Accept и опять возвращаемся к первоначальному списку конфигураций, но в нем уже появился новый пункт, соответствующий только что созданному соединению.

Рис. 2. Закладка для конфигурирования модема

Теперь, при правильной настройке и работе оборудования, уже можно попробовать подключиться к Internet. Для этого достаточно дважды щелкнуть мышкой на соответствующем пункте в списке соединений. Откроется закладка, содержащая всю информацию о соединении: настройки оборудования (закладка Hardware, рис. 2), конфигурацию chat-сценария (закладка Communication, рис. 3) и различные дополнительные сетевые опции (закладки Networking и PAP). В этой "общей" закладке можно попытаться установить соединение с помощью кнопки Connect. Работу сгенерированных сценариев можно проверить и из командной строки, перейдя в каталог /etc/ sysconfig/network-scripts и набрав команду ./ifup ifcfg-"имя соединения".

Работе с графикой

Первое, о чем тут хочется сказать - это о программке ksnapshot (рис. 4), предназначенной для снятия экранных копий (так называемых скриншотов). Она несколько напоминает Capture из Corel'овского комплекта, хотя и попроще. Позволяет снять весь экран или только активное окно, скрыв или, напротив, выведя на первый план окно самого ksnapshot'а; в отличие от Capture, нельзя скопировать объект произвольной формы. Результаты можно сохранить в виде gif, jpeg, bmp и пара мне неизвестных типов. Как ни странно, среди выходных форматов отсутствует tiff.

Рис. 4. Knapshot - программа для снятия экранных копий.

Следующий графический инструмент - GIMP (рис. 5). Это развитый растровый редактор, может быть, и не дотягивающий до PhotoShop'а. Но функционально не уступает по крайней мере Picture Publisher или Corel PhotoPaint. Весьма удобен в обращении, все манипуляции можно выполнить щелчком правой клавиши мыши. Понимает все основные растровые форматы, в том числе и PhotoShop. Впрочем, GIMP заслуживает отдельного (и подробного) разговора. Пока же отметим, что инструмент для элементарной (и не только) обработки растровой картинки в штатном наборе - имеется.

Рис. 5. Растровый редактор GIMP

Наконец, последний из предметов первой необходимости - редактор векторный. В этом качестве выступает Killustrator (рис. 6). С ним дело обстоит похуже. Если относительно GIMP'а можно спорить, лучше он PhotoShop'а или хуже, то здесь никакие споры неуместны: Killustrator не дотягивает до уровня даже рисовальных модулей из ранних версий презентационных пакетов, вроде Freelance.

Рис. 6. Векторный редактор Killustrator

Имеется базовый набор рисовальных средств - линий, кривых Безье, овалов и многоугольников. И средства изменения их атрибутов. И все. Ни спецэффектов, ни возможности растровой подложки, ни текстурирования. И из выходных форматов - фактически только EPS. О импорте из других векторных рисовалок - и речи нет (впрочем, и пакеты для Windows этим не очень грешат).

Однако что-то я все об инструментах да об инструментах. Ведь не инструментом единым жиива работа. Не менее важна комфортная обстановка. Что заставляет обратиться

RAID нужно продумать

Многодисковые тома и так ложатся дополнительным бременем на ресурсы компьютера, а новые динамические диски Windows 2000 создают еще и проблему совместимости. Так что многодисковые тома - не всегда лучшее решение.

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

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

Несмотря на эти предостережения, использовать новые средства администрирования дисков в Windows 2000 довольно просто. По сравнению с Disk Administrator утилита Disk Management проще и обладает массой новых возможностей.

Распределение Административных Ролей

В стандартной среде UNIX системный администратор имеет полномочия супервизора, позволяющие ему производить любые действия, возможные в рамках этой системы. При этом, случайные ошибки или злонамеренные действия администратора могут иметь самые серьезные последствия. Продукт DG/UX B2 Security Option устраняет полномочия супервизора; они распределяются между множеством администраторов, каждому из которых отводится определенная административная роль. Каждая из функций супервизора, независимо от других, может быть присвоена отдельной административной роли. Таким образом, DG/UX B2 Security Option позволяет определять роли, полномочия которых ограничиваются лишь несколькими определенными функциями. Администратор, которому присвоена такая роль, не может случайно или преднамеренно произвести останов системы, получить доступ к конфиденциальным файлам пользователей или выполнять функции, принадлежащие другим администраторам. DG/UX B2 Security Option позволяет определить столько административных ролей требуется для нужд организации и реализуемой стратегии защиты.

Разделы диска и таблица разбиения диска.

Физические диски в Intel-системах принято разбивать на разделы. Повелось это, кажется, из-за того, что первые версии MS-DOS не могли обеспечить доступ к большим дискам (а объемы дисков росли быстрее, чем возможности DOS). Тогда придумали разбиение дисков на разделы. Для этого в нулевой сектор диска (нулевой сектор первой дорожки на нулевом цилиндре) стали записывать так называемую таблицу разбиения диска на разделы (partition table). Каждый раздел может трактоваться как отдельный физический диск. В частности, в разные разделы могут быть установлены разные операционные системы.

Таблица разделов содержит 4 записи по 16 байт для 4 разделов, которые называют первичными. Каждая запись имеет следующую структуру:

struct partition { char active; /* 0x80: раздел активный (загрузочный), 0: не активный */ char begin[3]; /* CHS первого сектора, 24 бита */ char type; /* тип раздела (например, 83 — LINUX_NATIVE, /* 82 — LINUX_SWAP, 85 — LINUX_EXTENDED) */ char end[3]; /* CHS последнего сектора, 24 бита */ int start; /* номер начального сектора (32-бита, счет начинается с 0) */ int length; /* число секторов в разделе (32 бита) */ };

Таблица разделов диска создается обычно с помощью программы fdisk. В ОС Linux имеется как стандартная программа fdisk (которая, впрочем, существенно отличается от программы fdisk в MS-DOS и Windows), так и еще две программы для работы с разделами диска: cfdisk и sfdisk. Программа cfdisk, как и fdisk, предназначена для работы с таблицей разделов диска: она не обращает никакого внимания на информацию, которая уже имеется на диске. Отличается она только несколько более удобным интерфейсом, предоставляющим пользователю не просто подсказку по командам, а систему меню. Программа sfdisk обладает несколько более широкими возможностями, в частности, она позволяет произвести некоторые операции над существующими разделами диска.

DOS использует поля begin и end таблицы разбиения диска и функции прерывания 13 BIOS (Int 13h) для доступа к диску, и поэтому не может использовать диски объемом более 8,4 Гбайт, даже с новым BIOS (об этом будет рассказано ниже), а разделы не могут быть более 2,1 Гбайт (но это уже из-за ограничений файловой системы FAT16).

Linux использует только поля start и length таблицы разбиения диска и поддерживает разделы, содержащие до 232 секторов, т. е. размер раздела может достигать 2 Тбайт.

Поскольку в таблице разбиения отведено только 4 строки для задания разделов, число первичных разделов на диске с самого начала ограничено: их может быть не более 4. Когда стало ясно, что и 4-х разделов мало, были изобретены логические разделы. Для этого один из первичных разделов объявляется "расширенным" (тип раздела — 5, или F, или 85 в шестнадцатеричной системе), и в нем создаются "логические разделы". Расширенные разделы сами по себе не используются, они могут лишь хранить логические разделы. Первый сектор расширенного раздела хранит таблицу разделов с четырьмя входами: один используется для логического раздела, другой для еще одного расширенного раздела, а два не используются. Каждый расширенный раздел имеет свою таблицу разбиения, в которой, как и в первичном расширенном разделе, используются только две строки, задающие один логический и один расширенный раздел. Таким образом, получается цепочка из таблиц разделов, где первая описывает три основных раздела, а каждая следующая — один логический раздел и положение следующей таблицы.

Программа sfdisk в Linux показывает всю цепочку:

[root]# sfdisk -l -x /dev/hda

Disk /dev/hda: 784 cylinders, 255 heads, 63 sectors/track Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

Device Boot Start End #cyls #blocks Id System /dev/hda1 * 0+ 189 190- 1526143+ 6 FAT16 /dev/hda2 190 783 594 4771305 5 Extended /dev/hda3 0 — 0 0 0 Empty /dev/hda4 0 — 0 0 0 Empty

/dev/hda5 190+ 380 191- 1534176 6 FAT16 — 381 783 403 3237097+ 5 Extended — 190 189 0 0 0 Empty — 190 189 0 0 0 Empty

/dev/hda6 381+ 783 403- 3237066 7 HPFS/NTFS — 381 380 0 0 0 Empty — 381 380 0 0 0 Empty — 381 380 0 0 0 Empty

Число логических разделов в принципе не ограничено, потому что каждый логический раздел может содержать таблицу разделов и вложенные логические разделы.

Однако реально ограничения все же существуют, например, Linux может работать не более чем с 15 разделами на SCSI-дисках и не более чем с 63-мя разделами на IDE-дисках.

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

В Linux диск в целом (т. е. физический диск) доступен по имени устройства /dev/hda, /dev/hdb, /dev/sda, и т.п. Первичные разделы обозначаются дополнительной цифрой в имени устройства: /dev/hda1, /dev/hda2, /dev/hda3, /dev/hda4, а логические разделы в Linux доступны по именам /dev/hda5, /dev/hda6 ... (начиная с номера 5). Из сказанного выше должно быть ясно, почему могут быть пропущены имена /dev/hda3 и /dev/hda4 (третий и четвертый первичные разделы просто не были созданы) и сразу после /dev/hda2 вы увидите /dev/hda5 (логический раздел в расширенном разделе /dev/hda2), а далее нумерация идет последовательно.

В Windows логические разделы получают однобуквенные имена, начиная с последнего задействованного имени первичного раздела. Если, например, имеется один жесткий диск с двумя простыми первичными разделами (C: и D:) и одним расширенным разделом, в котором созданы два логических раздела, то эти логические разделы именуются E: и F:. Впрочем, в Windows NT и 2000 с помощью администратора дисков разделам могут быть присвоены другие буквенные имена.

Размер файла подкачки

В диалоговом окне System Properties есть вкладка Advanced. Она позволяет задавать значения трех групп параметров: Performance (настройка производительности), Environment (настройка переменных окружения) и Startup and Recovery (настройка параметров запуска и восстановления). Если в группе Performance нажать кнопку Change, откроется диалоговое окно Virtual Memory, в котором можно установить параметры файла подкачки. Окно Virtual Memory показано на Экране 1.

экран 1. Изменение размера файла подкачки.

Страничный файл следует хранить на отдельном диске.

Кроме того, рекомендуется присвоить исходному размеру файла (Initial size) и его максимальному размеру (Maximum size) одно и то же значение. Это значение должно быть достаточно велико, чтобы обеспечить нормальный объем виртуальной памяти. Вначале можно установить размер, рекомендуемый по умолчанию, а затем, используя утилиту Performance Monitor, убедиться, не исчерпала ли система объем виртуальной памяти (и, что то же самое, файла подкачки). Присвоение исходному и максимальному размеру одного и того же значения предотвращает разрастание файла и замедление работы системы из-за необходимости поиска и выделения дополнительного пространства.

Кроме того, на вкладке Advanced имеется группа параметров Startup and Recovery. Здесь можно изменить продолжительность времени, в течение которого система отображает меню выбора ОС при загрузке. Принятое по умолчанию значение 30 с слишком велико. Если в течение 10 с пользователь не решил, какую ОС ему нужно загрузить, значит, он смотрит не на экран, а в другую сторону.

Размер кода

Скорость – это не единственный показатель, представляющий интерес; очень важным является и число ошибок. К сожалению, мы не можем напрямую пересчитать все ошибки, но разумным заменителем числа ошибок, вероятно, является число строк кода. Напомним: чем больше код, тем больше ошибок.

Подсчитать число строк кода не так просто, как может показаться на первый взгляд. Во-первых, пустые строки и комментарии не добавляют в код сложности, и поэтому мы их не учитываем. Во-вторых, #define и другие определения в файлах заголовков также не добавляют в код сложности, и поэтому файлы заголовков тоже не учитываются. Подсчет числа строк выполнялся с использованием Perl-скрипта sclc.pl, доступного в Internet. Результаты для ядра, четырех серверов (файловой системы, сервера процессов, сервера реинкарнации, информационного сервера), пяти драйверов (жесткого диска, флоппи-диска, RAM-диска, терминала, устройства журнализации) и программы init показаны на рис. 9.

На рисунке можно видеть, что ядро состоит из 2947 строк на языке C и 778 строк на языке ассемблера (для программирования низкоуровневых функциональных возможностей, таких как перехват прерываний и сохранение регистров ЦП при переключении процессов). Всего имеется 3725 строк кода. И только этот код исполняется в режиме ядра. Другим способом измерения размера кода для C-программ является подсчет числа точек с запятой, поскольку многие операторы языка C завершаются точкой с запятой. В коде ядра имеется 1729 точек с запятой. Наконец, размер откомпилированного ядра составляет 21,312 байт. Это число задает только размер кода (т.е. сегмента текста). Инициализированные данные (3800 байт) и стек в это число не входят.

Рис. 9. Статистика размера кода MINIX 3. Для каждой части показано число файлов, число строк кода на языке C и языке ассемблера, число точек с запятой и размер сегмента текста в байтах.

Интересно, что статистика размеров кода, показанная на рис. 9, представляет минимальную, но функционирующую операционную систему. Общий размер ядерной части и части, работающей в режиме пользователя, составляет всего 18,000 строк кода, необыкновенно мало для POSIX-совместимой операционной системы. Мы сравним эти цифры с другими системами в разд. 6.

Разработка операционной системы

Этот проект посвящен построению более надежной операционной системы. Прежде чем подробно описывать свою разработку, мы кратко обсудим, каким образом выбор структуры операционной системы может непосредственно влиять на ее надежность. В своих целях мы будем проводить различие между двумя структурами операционных систем: монолитными системами и системами с минимальным ядром. Существуют и другие типы операционных систем, такие как экзоядра [10] и виртуальные машины [24]. Они не имеют непосредственного отношения к данной статье, но мы вернемся к ним в разд 6.

Разработки минимальных ядер

Хотя извлечение драйверов из ядра является большим шагом вперед, еще лучше извлечь из ядра операционную систему. Именно здесь начинают применяться минимальные ядра с чрезвычайным сокращением числа реализуемых в них абстракций. Вероятно, первым минимальным ядром была система RC4000 Бринка Хансена (Brinch Hansen), датируемая началом 1970-х гг. [13]. С середины 1980-х гг. был написан ряд минимальных ядер, включая Amoeba [21], Chorus [5], Mach [1] и V [6]. Однако ни в одном из них не применялось безопасное программное обеспечение: у всех имелись не изолированные драйверы внутри ядра.

QNX является коммерческой UNIX-подобной системой реального времени с закрытыми кодами [17]. Хотя у нее имеется минимальное ядро, называемое Neutrino, по поводу системы опубликовано мало статей, и точные детали нам неизвестны. Однако на основе последних проспектов мы заключаем, что Neutrino является гибридным ядром, поскольку менеджер процессов работает в адресном пространстве ядра.

В начале 1990 гг. покойный Йохан Лидтке (Jochen Liedtke) написал минимальное ядро L4 на языке ассемблера для архитектуры x86. Быстро стало понятно, что оно не является переносимым, и его трудно поддерживать, и поэтому он переписал ядро на языке C [20]. После этого оно продолжало развиваться. В настоящее время имеются две основные ветви: L4/Fiasco, поддерживаемое в техническом университете Дрездена, и L4Ka::Pistachio, поддерживаемое в университете Карлсруэ и университете New South Wales. Они написаны на C++.

Ключевыми идеями в L4 являются адресные пространства, нити и IPC между нитями в разных адресных пространствах. Менеджер ресурсов, выполняемый в пользовательском режиме и запускаемый при загрузке системы, управляет системными ресурсами и распределяет их между пользовательскими процессами. L4 – это одно из немногих действительно минимальных ядер с драйверами устройств, работающими в пользовательском режиме. Однако отсутствует реализация, в которой каждый драйвер выполнялся бы в отдельном адресном пространстве, и API L4 совсем отличается от нашего API, поэтому мы не можем запустить на нем какие-либо тесты.

Однако оказалось нетрудно запустить скрипт подсчета числа строк над текущей версией ядра L4Ka::Pistachio. Результаты показаны на рис. 10, и их можно сравнить с данными на строке «Kernal» рис. 9. Размер исходного кода почти в два раза превышает размер нашего ядра, а бинарный код в шесть раз больше, однако функциональные возможности L4Ka::Pistachio являются совсем другими, так что трудно сказать что-нибудь еще, кроме того, что это ядро значительно больше по размеру.

Рис. 10. Статистика размера кода для L4Ka::Pistachio.

Реализация WMI

Инфраструктура WMI представлена прежде всего исполняемым файлом \winnt\system32\wbem\winmgmt.exe. Это служба Windows 2000, которая запускается при старте управляющего приложения через Service Control Manager или при первом обращении провайдера WMI к WMI API. Большинство компонентов WMI постоянно находятся в \winnt\system32 и \winnt\system32\wbem, включая MOF-файлы Win32, встроенный провайдер DLL и управляющее приложение WMI DLL. В каталоге \winnt\system32\wbem можно найти ntevt.mof - MOF-файл провайдера журнала событий EventLog, а также ntevt.dll, библиотеку DLL провайдера EventLog, которую загружает winmgmt.exe.

Каталоги ниже \winnt\system32 \wbem вмещают репозитарий, файлы журналов и MOF-файлы. WMI реализует репозитарий, называемый Object Management CIM (CIMOM) репозитарием, как файл \winnt\system32\wbem\repository\cim.rep. Служба WinMgmt выбирает многочисленные параметры настройки, связанные с репозитарием (включая различные параметры, такие, как расположение резервной копии CIMOM и интервалы копирования), из раздела системного реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM.

Разработчики Microsoft хотели расширить возможности управления всеми аспектами Windows 2000, так что пришлось создать механизм взаимодействия драйверов устройств с WMI. Драйверы устройств используют несколько новых интерфейсов для предоставления данных WMI и исполнения команд, получаемых от WMI. Команды WMI System Control commands названы в Microsoft командами управления системой. Разработчики присвоили название провайдера Windows Driver Model (WDM) провайдеру драйверов устройств, потому что одинаковые интерфейсы WMI в драйверах Windows 2000 существуют и для Win98-драйверов. Поскольку это кросс-платформенные интерфейсы, они включены в зону ответственности WDM, кросс-платформенную архитектуру драйверов устройств. Windows 2000 размещает объекты WDM в пространстве имен \root\wmi.

Редактирование Реестра

Ольга Артюхова

Журнал "", #02/2000

Большинству пользователей Windows, наверное, знакома ситуация, когда якобы бесплатно распространяемые программы (будь то полезное ПО или игрушки) были "успешно установлены" на ваш компьютер, а по истечении некоторого времени они "отказывались работать" и начинали, например, просить за свое использование денег. В этом случае действием пользователя, как правило, бывает... нет, не оплата программы, а ее удаление. Если она "прописана" в "Установке и удалении программ", то достаточно просто нажать кнопку "Удалить" - и ненужного приложения как не бывало. Можно воспользоваться и утилитой Uninstall, которая также поможет убрать программу из вашей системы. Но далеко не все программы имеют утилиту Uninstall и уж точно не все "располагаются" в "Установке и удалении программ". И тогда неопытный пользователь просто стирает программу с диска. После этого в системе появляются различные ошибки и выдаются ужасающие предупреждения. Попытки переустановить продукт обычно не приводят к успеху. Дело в том, что многие программы для Windows 9х хранят в Системном реестре информацию о дате инсталляции, и потому после повторной установки они находят уже имеющуюся там запись и "заявляют" о своих претензиях. Можно довольно просто выйти из сложившейся ситуации (т. е. найти в Реестре запись, оставленную программой при инсталляции и удалить ее), однако в случае ошибок могут возникнуть значительные затруднения. Чтобы разрешить все проблемы, связанные с устранением записей в Реестре, остающихся после удаления программ, нужны утилиты, позволяющие редактировать сам Реестр. В большинстве случаев эти редакторы должны помочь найти и стереть запись, соответствующую удаленной программе, но уже корректным способом.

К сожалению, ОС Windows не настолько "умна", чтобы всегда автоматически "содержать" Реестр в надлежащем состоянии, и зачастую пользователю приходится редактировать его самостоятельно.
Системный Реестр Windows - это база данных, в которой хранятся настройки ОС. Перед "вторжением" в "недра" ОС следует сделать резервную копию Реестра, т. е. записать файлы c:\Windows\ system.dat и c:\Windows\ user.dat на дискету. Это позволит в случае неудачи быстро восстановить работоспособность Windows (перезагрузите ПК в режиме MS DOS и перепишите сохраненные файлы в каталог c:\Windows). Это за вас может сделать и специальная программа.

Редактировать Реестр можно с помощью входящей в стандартный набор программ Windows утилиты regedit.exe. Фактически вся системная информация хранится в двух скрытых файлах в каталоге Windows: system.dat и user.dat. Реестр представлен в виде иерархической структуры, состоящей из ветвей, которые, в свою очередь, делятся на ключи. В Реестре имеется шесть главных ветвей:

HKEY_CLASSES_ROOT - включает все типы соответствий файлов, а также информацию об OLE и ярлыках.

HKEY_CURRENT_USER - представляет собой ссылку на подраздел HKEY_USERS, имеющий такое же название, как и имя пользователя.

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

HKEY_USERS - включает все настройки для каждого пользователя.

HKEY_CURRENT_CONFIG - ссылка на подраздел KEY_LOCAL_ MACHINE, название которого соответствует имени пользователя, работающего в данный момент.

HKEY_DYN_DATA - указывает на ту часть раздела HKEY_LOCAL_ MACHINE, которая нужна для Plug & Play устройств. При добавлении или удалении устройств из системы этот раздел изменяется.

Редактирование системного реестра в автономном режиме

Существует еще один способ решения проблем, связанных с загрузкой служб или драйверов. Это редактирование системного реестра с целью отключения неисправного драйвера или службы. Но как можно редактировать реестр, не загрузившись в NT? Имея альтернативный путь доступа к тому с первоначальной системой, можно редактировать реестр. Для получения доступа к данным реестра со стороны используется параллельная установка системы NT на том же компьютере либо подключение диска с системным разделом NT (содержащим системный каталог NT и файлы ветвей реестра) к компьютеру с другой системой NT.

Получить доступ к системному реестру через параллельно установленную на этом же компьютере систему NT гораздо проще, чем подключать диск к другому компьютеру, так как в данном случае можно избежать проблем, возникающих при физическом перемещении диска из одной системы в другую. Однако вне зависимости от типа файловой системы (FAT или NTFS), на которой размещается системный раздел, необходимо загрузить NT. Редактирование данных реестра осуществляется через редактор реестра NT Registry Editor, а он не может быть запущен вне системы NT. К сожалению, еще никто не придумал такого редактора реестра NT, который бы работал в другой операционной системе, например в DOS.

После того как доступ к файлам системного реестра первоначальной системы получен, можно начинать редактирование в автономном режиме. И хотя многие пользователи хорошо знакомы с редактором реестра NT Registry Editor, вероятно, не все знают о возможности открывать файлы реестра других установленных на этом компьютере NT-систем или создавать дополнительные ветви реестра с помощью редактора реестра системы. Для редактирования реестра в автономном режиме запускают regedt32.exe (утилита regedit.exe не поддерживает такой способ редактирования реестра), указывают ключ HKEY_LOCAL_MACHINE, затем вариант Load Hive в меню Registry редактора реестра и выбирают файл ветви реестра, который необходимо редактировать. Требуется изменить параметры запуска драйвера/службы; эта информация хранится системой NT в ветви реестра SYSTEM.
После выбора нужного файла система попросит указать имя подключа, под которым будет храниться содержимое выбранного файла (cм. Экран 2). Эти действия не изменяют имя указанного файла ветви реестра и не оказывают никакого влияния на системный реестр системы Windows NT, которая была загружена. Кроме того, не имеет никакого значения имя, присвоенное ветви, поскольку редактор реестра использует его только для временного обозначения данных, загруженных из ветви реестра первоначальной системы. После присвоения имени дополнительная ветвь появится в окне HKEY_LOCAL_MACHINE.

ЭКРАН 2. Загрузка внешнего файла куста реестра в редактор regedt32.exe.

С этого момента уже можно редактировать ветвь SYSTEM реестра первоначальной системы и, соответственно, попытаться решить проблему неудачного старта. Как и при любой другой операции с системным реестром, вначале следует сделать резервную копию. Однако содержимое нового ключа, SYSTEM2 в данном случае, будет немного отличаться от того, что обычно находится под ключом SYSTEM. Доступными подключами ключа ControlSet будут только подключи ControSetxxx, где xxx - число типа 001. На экране не будет ключа CurrentControlSet, который появляется при редактировании реестра загруженной системы. Ключ не виден, поскольку это только псевдоним того ключа, который был использован при загрузке системы Windows NT.

ЭКРАН 3. Определение значений для наборов Current, Default, Last Known Good и Failed.

Чтобы удостовериться в том, что редактируется нужный подключ, а не задаваемый по умолчанию для параллельной установки, выбирается подключ Select вновь созданного ключа. В правой панели редактора реестра будет выведено несколько значений (см. Экран 3). Система NT использует эти параметры и их значения для того, чтобы выяснить, какой именно набор данных будет задаваться по умолчанию при старте (DefaulControlSet), какой является текущим (CurrentControlSet), какой будет определять набор LastKnownGoodMenu и какой был задействован при загрузке, когда произошел сбой.

На Экране 3 значение параметра Current указывает на номер той конфигурации NT, которая была загружена при последней загрузке системы. Представленное этим параметром значение используется как номер набора данных CurrentControlSet. В большинстве случаев значения данного параметра и задаваемого по умолчанию одинаковы. В данном примере значение параметра Current равно 0x2. Это означает, что необходимо редактировать набор ControlSet002. После определения правильного набора данных можно изменить состояние службы или драйвера на момент загрузки системы.

ТАБЛИЦА 1: Значения параметров запуска для служб и драйверов устройств

Тип запуска Значение для устройства (шестнадцатеричное) Значение для службы (шестнадцатеричное)

Boot (загрузка)	0x0	N/A
System (система)	0x1	N/A
Automatic (автоматически)	0x2	0x2
Manual (ручное)	0x3	0x3
Disabled (отключено)		0x4 0x4

Значения параметров реестра, связанные с установленной службой или драйвером первоначальной системы, находятся в значениях ключа HKEY_LOCAL_MACHINE\SYSTEM2\ControSet00x\имя подозрительной службы или драйвера. В этом ключе SYSTEM2 ссылается на подключ в представленном примере, ControSet00x соответствует тому набору данных, который был определен по процедуре, приведенной выше, а имя подозрительной службы или драйвера - службе или драйверу, который предположительно вызывает сбой. Для каждой из перечисленных в подключе Services служб (или драйверов) хранится несколько значений. В их числе значение параметра Start (значение типа REG_DWORD). Значение этого параметра определяет текущее состояние данной службы или драйвера при старте системы. Присваивание параметру Start значения 0х4 деактивирует данную службу или драйвер, и NT не будет загружать его при старте системы. В Таблице 1 перечислены все возможные значения параметра Start для служб и драйверов устройств. После того как редактирование реестра в автономном режиме будет закончено, необходимо выгрузить импортированный ранее файл ветви реестра. Это делается указанием ветви с присвоенным ранее именем и выбором опции Unload Hive в меню Registry редактора реестра.

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

В настоящее время RedHat работает

В настоящее время RedHat работает на платформах Intel (начиная с процессоров 386), Alpha и SPARC, но при рассмотрении мы ограничились только компьютерами Intel. Дистрибутив RedHat Linux 6.1 основан на версии ядра 2.2.12.

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

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

Типы инсталляции подразделяются на серверную конфигурацию, рабочую станцию GNOME и рабочую станцию KDE, а также интерактивный (custom) режим инсталляции. При типе инсталляции "сервер" предварительно уничтожаются все разделы на всех винчестерах, а при типе "рабочая станция" - все имеющиеся разделы Linux. Причем в этих случаях процедура инсталляции сама принимает решение, какое ПО и куда будет установлено. Интерактивный тип инсталляции позволяет гибко управлять всем процессом инсталляции, поэтому, с точки зрения администратора, он - самый привлекательный.

Инсталляция программ происходит очень быстро: на ПК с процессором Pentium II на 400 МГц установка всего дистрибутива (1400 Мбайт) занимает около 16 мин.

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

В RedHat 6.1 значительно улучшена поддержка устройств по принципу Plug'n'Play, но такое улучшение нередко выходит боком. Дистрибьютор сделал ставку на умение системы распознавать устройства Plug'n'Play, при этом она, к сожалению, не предоставляет возможности менять настройки вручную.
Так, на одном из компьютеров процедура инсталляции не смогла обнаружить сетевую плату 3Com 509B, и компьютер остался без сетевых настроек. Только после инсталляции, затратив много времени, настройку удалось произвести вручную.

Раз уж затронута тема сетевых настроек в процессе инсталляции, то надо сказать, что ситуация изменилась в худшую сторону по сравнению с RedHat 6.0. Почему-то возможность задания имени домена, куда входит компьютер, более не предоставляется, так что файл /etc/resolv.conf приходится настраивать после инсталляции. Кроме того, список запускаемых по умолчанию в момент загрузки системы демонов теперь нельзя задать в процессе установки ОС.

RedHat допускает инсталляцию ОС со следующих носителей: CD-ROM, винчестеров (IDE, SCSI, PC Card), а также с серверов ftp, NFS и HTTP.

Неприятной особенностью RedHat и Linux в целом являются принципы поддержки оборудования процедурой инсталляции (а фактически - начальным образом ядра). Вот конкретный пример: на одном из тестируемых компьютеров была установлена мощная SCSI-плата компании Initio, все винчестеры имели интерфейс SCSI и были подключены к этой плате. Данная плата поддерживается Linux, но только в качестве отдельного модуля и не в составе исходного initrd. Как следствие, процедура инсталляции не сумела обнаружить ни SCSI-плату, ни винчестеры, и поэтому установка Linux закончилась неудачей. Для устранения проблемы либо SCSI-плату надо заменить на более распространенную, либо все винчестеры поменять на жесткие диски IDE. В принципе, вы можете создать свой initrd, но для этого потребуется второй компьютер.

Проблемы некорректной поддержки оборудования (сетевых плат, SCSI-устройств, звуковых плат, видеоадаптеров и т. д.), в том числе сертифицированного для Linux, можно перечислять еще долго, но я не буду этого делать, чтобы лишний раз не пугать пользователей. Я хотел бы только предупредить: если в компьютере есть несколько устройств ISA с поддержкой Plug'n'Play, то, скорее всего, файл /etc/isapnp.conf придется исправлять вручную.

Несмотря на критику RedHat, я не могу не отметить и его достоинств. В RedHat Linux для повышения удобства работы с системой сделано очень многое - это и прекрасные средства администрирования, и продуманный интерфейс, и простота настроек.

Рисунок 1. Программа GnoRPM реализует возможности RPM в графической среде GNOME.

Главным козырем RedHat является менеджер пакетов RPM. Некоторые специалисты считают, что именно благодаря этой программе компания RedHat сделала себе имя. RPM предназначен для установки, обновления, верификации и удаления приложений из системы. По каждому пакету RPM позволяет получить информацию о назначении, структуре и составе пакета, местонахождении документации и многом другом, а также определить, к какому пакету принадлежит тот или иной файл. Учитывая огромное количество программ для Linux, хорошая программа управления способна серьезно облегчить жизнь администратору. На мой взгляд, по своим возможностям RPM не имеет аналогов как среди некоммерческих, так и среди коммерческих ОС, включая Windows. Кстати, RPM сейчас используется не только в RedHat, но и в других дистрибутивах Linux. Комплекты оболочек GNOME и KDE содержат графические варианты RPM (см. Рисунок 1).

Рисунок 2. Графическая оболочка GNOME.

Основной графической оболочкой в RedHat является GNOME (см. Рисунок 2). Тем не менее в состав дистрибутива входит также оболочка KDE, а кроме того, менеджеры Afterstep, WindowMaker и другие. Однако составители RedHat отдают предпочтение GNOME, поскольку в отличие от KDE она, во-первых, работает с различными менеджерами окон, а во-вторых, не зависит от коммерческих библиотек, т. е. полностью соответствует лицензии GNU.

Еще одной удобной утилитой Linux (не только RedHat, но и других дистрибутивов) является linuxconf (см. Рисунок 3). Эта утилита позволяет управлять большинством параметров системы, в том числе учетными записями пользователей и групп пользователей, сетевыми настройками, службой доменов, файловыми системами, почтовым сервисом и многим другим.

Более того, с помощью linuxconf настройки можно менять с любого сетевого компьютера через браузер Web (см. Рисунок 4).

Рисунок 3. Утилита администрирования linuxconf из состава RedHat.

Приятно, что некоммерческая система обладает единой средой управления, почти ничем не уступающей по своим возможностям SCOadmin из состава SCO UnixWare. Единственное, что не под силу linuxconf, так это конфигурирование ядра, настройка принтеров и управление дополнительными приложениями. Еще одним недостатком я бы назвал не очень качественную справочную систему подсказок в linuxconf. Будем надеяться, что положение изменится в лучшую сторону в самое ближайшее время, поскольку linuxconf быстро совершенствуется.

Многие функции linuxconf продублированы в панели управления (см. Рисунок 5), причем, в отличие от linuxconf, панель управления позволяет осуществлять настройки принтеров и управлять загрузкой модулей ядра.

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

Рисунок 4. Управление настройками Linux через браузер Web.

Хотя системные утилиты и структура man (страницы документации) соответствуют спецификации BSD, процедура начальной загрузки init осуществляется согласно спецификации AT&T UNIX. Весьма удобно, что в момент загрузки системы, ее остановки и перехода с одного уровня (runlevel) на другой на консоль выводятся сообщения о работе демонов.

Аутентификация в Linux осуществляется с помощью подключаемых модулей аутентификации (Pluggable Authentication Module, PAM). Система PAM позволяет гибко управлять правами доступа к различным сетевым службам, хотя и считается достаточно сложной.

Еще одна особенность RedHat Linux состоит в том, что в момент загрузки системы в однопользовательском режиме любой желающий может получить права root (т. е. права на все ресурсы системы), даже не зная его пароля.

Рисунок 5. Панель управления RedHat.

Что касается русификации RedHat, то много полезной информации можно почерпнуть на серверах http://www.iplabs.ru, http://www.opennet.ru, http://www.linux.org.ru и других.

Решение: правильная изоляция сбоев

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

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

Мы не рассчитываем на то, что вскоре появится код, свободный от ошибок, а если и появится, то, конечно, не в операционных системах, которые обычно пишутся на C или C++. К сожалению, в программах, написанных на этих языках, интенсивно используются указатели, обильный источник ошибок. Поэтому наш подход основан на идеях модульности и изоляции сбоев. Путем разбиения системы на большое число изолированных модулей, каждый из которых выполняется в отдельном процессе в режиме пользователя, нам удалось сократить часть системы, выполняемую в режиме ядра, до абсолютного минимума и предотвратить распространение сбоев, возникающих в других модулях. Уменьшение размеров ядра значительно сокращает число ошибок, которые оно, вероятно, должно содержать. Малый размер также позволяет понизить уровень сложности ядра и облегчить его понимание, что также способствует надежности.
Поэтому мы последовали максиме Сент-Экзюпери и сделали ядро настолько небольшим, насколько это позволяют человеческие возможности: менее 3800 строк кода.
Одно из замечаний, постоянно возникающее по поводу таких разработок минимального ядра, касается замедления работы системы из-за дополнительных переключений контекста и копирования данных, которое требуется для обеспечения коммуникаций различных моделей, выполняемых в пользовательском адресном пространстве. Это опасение, в основном, существует по историческим причинам, и мы утверждаем, что эти причины, большей частью, теперь отсутствуют. Во-первых, результаты новых исследований показывают, что разработка минимального ядра не обязательно наносит ущерб эффективности [3, 23, 15]. Уменьшение размеров ядра при наличии разумных протоколов взаимодействия серверов помогает ограничить масштабность проблемы эффективности. Во-вторых, значительное возрастание мощности компьютеров в последнее десятилетие существенно ослабляет проблему гарантированной производительности, возникающую при модульной разработке. В третьих, мы полагаем, что наступает время, когда большая часть пользователей с удовольствием пожертвует некоторой эффективностью ради улучшенной надежности.
Подробное обсуждение эффективности нашей системы мы представляем в разд. 5. Однако здесь мы кратко упомянем три предварительных показателя эффективности в поддержку нашего довода о том, что системы с минимальным ядром не обязательно должны быть медленными. Во-первых, измеренное время выполнения простейшего системного вызова getpid составляет 1.01 мсек на процессоре Athlon с частотой 2.2 Ггц. Это означает, что программа, производящая 10000 системных вызовов в секунду, тратит на переключение контекста всего 1% времени ЦП, а 10000 системных вызовов в секунду производят лишь немногие программы. Во-вторых, наша система способна в течение 4 секунд полностью произвести свою компоновку, включая ядро и все части, выполняемые в режиме пользователя (при этом компилируются 123 файла и совершается 11 редактирований связей).В третьих, время начальной загрузки системы с момента выхода из монитора многовариантной загрузки до выдачи приглашения ко входу в систему составляет менее 5 секунд. После этого операционная система, полностью совместимая с POSIX, готова к использованию.

Резервные копии: подальше положишь...

Постоянное обновление информации на дисках восстановления ERD для каждой системы NT является несомненно обязательным, но не единственным средством предохранения от бед. В предыдущей статье я уже говорил о методах создания и хранения резервных копий системного реестра. Например, утилита regback.exe из состава Windows NT Server 4.0 Resource Kit позволяет создавать копии индивидуальных файлов ветвей реестра в несжатом виде. Такие несжатые копии файлов реестра особенно удобны при необходимости заменить какую-либо ветвь реестра (более подробно об утилите regback.exe рассказано во врезке "Причуды regback.exe"). Однако здравый смысл подсказывает, что сохранение резервных копий данных системы на локальном жестком диске этой же системы не обеспечивает защиту от сбоев, поскольку сбой может произойти и с локальным диском. Скорее имеет смысл позаботиться о создании дополнительных (избыточных) копий, т. е. сохранении важных данных о конфигурации системы, например копии системного реестра Windows NT, на жестком диске другого компьютера, и наоборот. Иными словами, если говорить о резервных копиях, то чем их больше, тем лучше, а если хранить их перекрестно на других системах, то это совсем хорошо.

Неплохо было бы не только создавать резервные копии данных системного реестра, но и делать избыточные копии другой важной информации. Например, я периодически создаю резервные копии баз данных Microsoft Exchange Server (а именно dir.edb, pub.edb, priv.edb) в автономном режиме (с остановкой служб сервера Exchange на время резервного копирования) на другом сервере сети. Используемая мною программа резервного копирования имеет специальный модуль для создания копий баз сервера Exchange во время его работы, но опытным путем я определил, что полностью восстановить Exchange Server гораздо проще с помощью его недавней копии, созданной в автономном режиме (полностью восстанавливать Exchange Server приходится после проблем с жесткими дисками). Однако следует помнить, что предложенный метод только дополняет стандартный план восстановления системы после сбоя и ни в коей мере не заменяет основные способы (например, резервное копирование данных на магнитную ленту). Если нет желания тратить дефицитное дисковое пространство на хранение таких данных, можно копировать их на другие сменные носители: диски CD-R и CD-RW, картриджи Zip и Jazz, магнито-оптические диски и т. п. Лучше выбрать один из этих вариантов, поскольку утилита создания дисков ERD поддерживает только трехдюймовые дискеты, а это далеко не самый надежный носитель.

Результаты проверки надежности

Для проверки надежности своей системы мы вручную внесли сбои в некоторые из своих драйверов, чтобы протестировать некоторые виды ошибок и посмотреть на то, что получится. В простейшем случае мы завершали драйвер с применением сигнала SIGKILL. Более серьезные тестовые случаи вынуждали драйверы разыменовывать плохие указатели или впадать в бесконечный цикл. Во всех случаях сервер реинкарнации распознавал проблему и заменял неисправный драйвер свежей копией. Результаты тестов показаны на рис. 4.

Рис. 4. Результаты тестирования серьезных сбоев в драйверах устройств. Если сервер реинкарнации распознает проблему, он автоматически предпринимает корректирующие действия

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

Другое наблюдение состоит в том, что некоторые драйверы были реализованы таким образом, что инициализация происходит только при первом вызове OPEN. Однако для прозрачного восстановления после сбоя драйвера на уровне приложений не должен требоваться повторный вызов OPEN. Вместо этого, выполнение вызова READ или WRITE в восстановленном драйвере должно заставить драйвер произвести повторную инициализацию.

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

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

Результаты тестирования дискового ввода-вывода

Во втором пакете тестов мы читали из файла и писали в файл порции от 1 килобайта до 64 мегабайт. Тесты пропускались много раз, так что читаемый файл размещался в 12-мегабайтном кэше файлового сервера, кроме случая 64-мегабайтных обменов, когда объема кэша не хватало. Использование внутреннего кэша дискового контроллера не блокировалось. Результаты показаны на рис. 6.

Рис. 6. Время чтения и записи порций большого файла. Значения времени приводятся в микросекундах, кроме 64-мегабайтных операций, для которых время указывается в секундах.

Как мы видим, разница в производительности составляет от 3% до 18%, в среднем – 8.4%. Однако заметим, что худший показатель производительности получен для 1-килобайтных записей, но абсолютное время возросло всего на 457 наносекунд. Это соотношение уменьшается при увеличении объема ввода-вывода, поскольку сокращаются относительные накладные расходы. В трех 64-магабайтных тестах, результаты которых показаны на рис. 6 и 7, это соотношение составляет всего от 3% до 5%.

В другом тесте производится чтение из непосредственного блочного устройства, соответствующего жесткому диску. Запись на непосредственное устройство разрушила бы его содержимое, поэтому такой тест не выполнялся. Результаты показаны на рис. 7. При выполнении этих тестов не используется буферный кэш файловой системы, и проверяется только перемещение битов с диска. Как мы видим, в этом случае средний показатель накладных расходов составляет всего 9%.

Рис. 7. Время чтения из непосредственного дискового блочного устройства. Значения времени приводятся в микросекундах, кроме 64-мегабайтных операций, для которых время указывается в секундах.

Результаты тестирования приложений

Следующий набор тестов состоял из реальных программ, а не простых измерений времени выполнения системных вызовов. Результаты приведены на рис. 8. Первый тест состоял в построении области начальной загрузки (boot image) в цикле, содержащем вызов system(”make image”); тем самым, построение производилось много раз. При каждом построении компилятор языка C вызывался 123 раза, ассемблер – 4 раза и компоновщик – 11 раз. Построение ядра, драйверов, серверов и программы init, а также сборка области начальной загрузки заняли 3.878 секунд. Среднее время компиляции составляло 32 мсек на файл.

Рис. 8. Время выполнения в секундах различных тестовых программ. Первые два теста выполнялись в цикле, а остальные пропускались только по одному разу для исключения влияния со стороны кэша файловой системы.

Второй тест содержал цикл, в котором компилировались тесты соответствия стандарту POSIX. Набор из 42 тестовых программ компилировался за 1,577 секунды, или примерно за 37 мсек на файл теста. Тесты с третьего по седьмой состояли в сортировке к 64-мегабайтного файла и применении к нему sed, grep, prep и uuencode соответственно. В этих тестах в разных объемах смешивались вычисления и обмены с диском. Каждый тест пропускался только по одному разу, так что кэш файловой системы практически не использовался; каждый блок брался с диска. Среднее падение производительности составило в этих случаях 6%, аналогично последним строчкам на рис. 6 и 7.

Если взять среднее значение для последнего столбца показателей 22 тестов, отраженных на рис. 6-8, мы получим 1.08. Другими словами, версия с драйверами, выполняемыми в режиме пользователя, оказалась примерно на 8% медленнее версии с ядерными драйверами для операций, вовлекающих обмены с дисками.

Результаты тестирования системных вызовов

Первый пакет тестов содержал тесты чистых POSIX-совместимых системных вызовов. Пользовательская программа должна была зафиксировать реальное время в тактах системных часов (на частоте 60 Гц), затем миллионы раз произвести системный вызов, после чего снова зафиксировать реальное время. Время обработки системного вызова вычислялось как разность между конечным и начальным временем, деленная на число вызовов, за вычетом накладных расходов на организацию цикла, которые измерялись отдельно. Число итераций цикла было разным для каждого теста, поскольку тестирование 100 миллионов раз вызова getpid было разумным, но чтение 100 миллионов раз из 64-магабайтного файла заняло бы слишком много времени. Все тесты выполнялись на незагруженной системе. Для этих тестов частоты успешных обращений к кэшу ЦП и кэшу файлового сервера предположительно составляли 100%. Результаты показаны на рис. 5.

Рис. 5. Время системных вызовов для драйверов, выполняемых в режиме ядра, и драйверов, выполняемых в пользовательском режиме. Все значения времени представлены в микросекундах.

Кратко проанализируем результаты этих тестов. Выполнение системного вызова getpid заняло 0.831 мсек при использовании ядерных драйверов и 1.011 мсек при использовании драйверов, работающих в режиме пользователя. При выполнении этого вызова от пользовательского процесса менеджеру памяти посылается одиночное сообщение, на которое немедленно получается ответ. При использовании драйверов, выполняемых в режиме пользователя, вызов выполняется медленнее из-за наличия проверки прав процессов на посылку таких сообщений. При выполнении такого простого вызова существенное замедление вызывают даже несколько дополнительных строк кода. Хотя в процентах разница составляет 22%, на каждый вызов тратится лишь 180 дополнительных наносекунд, так что даже при частоте 10,000 обращений в секунду потери составляют всего 2.2 мсек в секунду, гораздо меньше 1%. При выполнении вызова lseek производится гораздо большая работа, и поэтому относительные накладные расходы снижаются до 11%. При выполнении открытия и закрытия файла этот показатель составляет всего 9%.

Чтение и запись 64-килобайтных участков данных занимает менее 90 мсек, и падение производительности составляет 8%. При использовании драйверов, выполняющихся в режиме пользователя, создание файла, запись в него 1 килобайта данных и удаление этих данных занимают 13.465 мсек. Из-за использования буферного кэша файлового сервера ни в одном из этих тестов не вызывались драйверы, и поэтому мы можем заключить, что другие изменения, не связанные с драйверами, замедляют систему примерно на 12%.

Пример последовательности сообщений программы Regback.exe.

C:\REGBACK>regback 072899.PRE saving SECURITY to 072899.PRE\SECURITY saving SOFTWARE to 072899.PRE\software saving SYSTEM to 072899.PRE\system saving .DEFAULT to 072899.PRE\default saving SAM to 072899.PRE\SAM ***Hive = \REGISTRY\USER\S-1-5-21-36516332-637091160-1803697834-1001 Stored in file \Device\Harddisk1\Partition2\WINDOWS\Profiles\Sean\NTUSER.DAT Must be backed up manually regback <filename you choose> users S-1-5-21-36516332-637091160-1803697834-1001 C:\REGBACK>regback NTUSER.DAT users S-1-5-21-36516332-637091160-1803697834-1001 saving S-1-5-21-36516332-637091160-1803697834-1001 to NTUSER.DAT

На Рисунке 1 показана последовательность сообщений, выводимых утилитой regback.exe. Но, кроме этого, она сообщает о невозможности создания копии файла ветви реестра с именем ntuser.dat, хранящего настройки системы текущего пользователя. Приходится делать копию этого файла вручную. Если не задействован профиль пользователя, хранящийся централизованно на сервере, то для сохранения ваших настроек системы придется это делать обязательно. Инструкции по сохранению файла ntuser.dat, приведенные на Рисунке 1, выглядят устрашающе, тогда как сам процесс достаточно прост. Нужно щелкнуть правой кнопкой мыши в левом верхнем углу окна с командной строкой и воспользоваться опциями появившегося меню Edit, Mark и Edit, Copy для формирования верной команды. Или же можно сконфигурировать окно командной строки для работы с функцией QuickEdit, которая позволяет проводить операции выделения, копирования и вставки с помощью мыши. Необходимо скопировать строку сообщения, которую утилита regback.exe выводит в качестве примера (например, regback users S-1-5-21-36516332-637091160-1803697834-1001), и вставить ее в командную строку. Надеюсь, что в дальнейшем Microsoft исправит этот недостаток, а пока можно воспользоваться предлагаемой последовательностью действий.

<<<

Родственные исследования

Мы являемся не первыми исследователями, пытающимися предотвратить отказы систем по вине драйверов устройств, содержащих ошибки. И мы не первые пытаемся применить минимальное ядро в качестве возможного решения. Мы даже не являемся первыми среди тех, что реализовывал драйверы, работающие в режиме пользователя. Тем не менее, мы считаем, что мы первыми построили полностью POSIX-совместимую операционную систему с отличными свойствами изоляции сбоев поверх минимального ядра из 3800 строк; в этой системе каждый драйвер выполняется в режиме пользователя в отдельном процессе, а вся ОС выполняется в виде нескольких пользовательских процессов. В этом разделе мы обсудим проекты других исследовательских групп, которые отчасти похожи на то, что делаем мы.

Роль аппаратного обеспечения

Давать какие-либо советы по восстановлению систем после сбоев достаточно опасно. Так, первое, что приходит на ум при виде "голубого экрана смерти" в ходе установки системы NT, это мысль о проблемах с программным обеспечением. Но реальным виновником может быть и неисправное оборудование, и просто сбой в работе какого-либо элемента системы (например, жесткого диска или его контроллера, ошибки в работе оперативной или кэш-памяти, неверно выбранные параметры в установках BIOS). Т. е. ни в коем случае нельзя исключать вероятность того, что сбой в работе аппаратуры может привести к появлению "голубого экрана смерти" и сообщения об ошибке, относящегося к работе программного обеспечения.

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

Роль и место некоммерческих UNIX

"Вы много внимания уделяете Novell и Microsoft. Поверьте, это уже мертвые системы. Они будут цепляться за любую соломинку, чтобы выжить. Но в лице Linux им уже вынесен приговор. Пройдет немного времени, и приговор будет приведен в исполнение."

"Многие линуксоиды живут в мире мифов и иллюзий. Это, прежде всего, относится к "бесплатности" системы и ПО, высокой производительности, нетребовательности к аппаратному обеспечению, простоте администрирования, отказоустойчивости и т. п.."

Из писем в редакцию

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

Среди свыше десятка имеющихся в мире некоммерческих ОС наибольшей известностью пользуются Linux, FreeBSD, OpenBSD, NetBSD, GNU Hurd, Minix, Cynus, FreeDOS, Freedows, BPMK, VSTa. Многие из этих ОС работают не только на платформе Intel, но и на платформах SPARC, PowerPC, Alpha и других. Несмотря на такое разнообразие некоммерческих систем, широкой популярности добилась, пожалуй, лишь ОС Linux, лавинообразный всплеск интереса к которой наблюдается как со стороны пользователей, так и со стороны разработчиков. Второе место по популярности, правда, с большим отставанием, занимает система FreeBSD. Исходя именно из этих реалий, для рассмотрения возможностей бесплатных ОС мы выбрали Linux и FreeBSD, причем в качестве дистрибутивов Linux были взяты RedHat Linux и Linux Mandrake.

Следует сразу оговориться, что тестирование операционных систем проводилось лишь для определения их совместимости с различным аппаратным обеспечением и оценки удобства и возможностей администрирования и работы пользователей. Тесты выполнялись на пяти разных компьютерах, начиная от совсем старой машины с 486-м процессором до суперсовременной модели с Pentium III.

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

Ротация файлов протокола

Если система интенсивно используется, то файлы протоколов быстро растут, порождая проблему протоколов. В Red Hat это решается скриптом logrotate из каталога /etc/cron.daily ежедневно запускаемого демоном cron. Этот скрипт позволяет обрабатывать не только журналы системы syslog, но и любые другие программы. Скрипт обеспечивает так называемую ротацию этих файлов в случае, если они превысили указанный размер (или по истечению указанного временного интервала). Ротация - последовательное копирование предыдущих версий архивных файлов примерно следующим образом:

messages.1 -> messages.2 messages.0 -> messages.1 messages -> messages.0

и создание нового файла messages для записи последующих сообщений.

Перечень файлов для обработки скриптом logrotate и параметры этой обработки определяются конфигурационными файлами, которых может быть несколько. Имена конфигурационных файлов задаются в командной строке запуска скрипта. В Red Hat Linux по умолчанию в качестве конфигурационных файлов для logrotate используется файл /etc/logrotate.conf, который может иметь примерно такой вид:

weekly rotate 4 create compress include /etc/logrotate.d /var/log/wtmp /var/log/lastlog { monthly create 0664 root utmp rotate 1 }

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

В приведенном примере конфигурационного файла сначала описываются глобальные параметры, а затем в отдельной секции - параметры обработки файлов /var/log/wtmp и /var/log/lastlog. Кроме того, среди глобальных параметров дается ссылка на каталог /etc/logrotate.d куда каждый пакет записывает локальные параметры для своих журналов.
В секции глобальных параметров в первую очередь задается один из следующих параметров, определяющих критерий ротации файлов: daily - смена ежедневно, weekly - еженедельно, monthly - ежемесячно, size байт - смена версии происходит, если размер журнала превысил указанное число байт. Параметр rotate число может находиться как среди глобальных, так и среди локальных параметров и определяет, сколько старых версий надо хранить; если число равно 0, то архивные версии протокола не создаются.

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

С помощью других параметров конфигурационного файла можно переопределить права доступа к файлам протоколов; задать опции сжатия архивных файлов; указать, кому посылать сообщения об ошибках функционирования системы протоколирования; послать архивную копию журнала указанному пользователю; задать каталог, в который будут перемещаться протоколы во время смены версий (каталог должен находиться на том же физическом устройстве, что и /var/log) или задать список суффиксов-исключений для директории include, но об этом вы должны будете узнать из man logrotate.

Виктор Костромин () -независимый эксперт (Казань)

RTLinux

RTLinux () - это дополнение к ядру Linux, реализующее режим "жесткого" реального времени, которое позволяет управлять различными чувствительными ко времени реакции системы процессами. По сути дела, RTLinux - это операционная система, в которой маленькое ядро реального времени сосуществует со стандартным POSIX-ядром Linux.

Разработчики RTLinux пошли по пути запуска из ядра реального времени Linux-ядра как задачи с наименьшим приоритетом. В RTLinux все прерывания обрабатываются ядром реального времени, а в случае отсутствия обработчика реального времени - передаются Linux-ядру. Фактически Linux-ядро является простаивающей (idle) задачей операционной системы реального времени, запускаемой только в том случае, если никакая задача реального времени не исполняется. При этом на Linux-задачу накладываются определенные ограничения, которые, впрочем, для программиста прозрачны.

Нельзя выполнять следующие операции: блокировать аппаратные прерывания и предохранять себя от вытеснения другой задачей. Ключ к реализации данной системы - драйвер, эмулирующий систему управления прерываниями, к которому обращается Linux при попытке блокировать прерывания. В этом случае драйвер перехватывает запрос, сохраняет его и возвращает управление Linux-ядру.

Все аппаратные прерывания перехватываются ядром операционной системы реального времени. Когда происходит прерывание, ядро RTLinux решает, что делать. Если это прерывание имеет отношение к задаче реального времени, ядро вызывает соответствующий обработчик. В противном случае, либо если обработчик реального времени говорит, что хочет разделять это прерывание с Linux, обработчику присваивается состояние ожидания (pending). Если Linux потребовала разрешить прерывания, то прерывания, которые находятся в состоянии "pending", эмулируются. Ядро RTLinux спроектировано таким образом, что ядру реального времени никогда не приходится ожидать освобождения ресурса, занятого Linux-процессом (рис. 1).

Рис. 1. Механизм работы RTLinux - Linux-расширения жесткого реального времени

Для обмена данными между операционными системами реального времени и Linux могут использоваться следующие механизмы:

разделяемые области памяти;

псевдоустройства, предоставляющие возможность обмена данными с приложениями реального времени.

Ключевой принцип построения RTLinux - как можно больше использовать Linux и как можно меньше собственно RTLinux. Действительно, именно Linux заботится об инициализации системы и устройств, а также о динамическом выделении ресурсов. "На плечи" RTLinux ложится только планирование задач реального времени и обработка прерываний. Для простоты запуска в контексте ядра, сохранения модульности и расширяемости системы процессы реального времени реализованы в виде загружаемых модулей Linux. Как правило, приложение реального времени с RTLinux состоит из двух независимых частей: процесса, исполняемого ядром RTLinux, и обыкновенного Linux-приложения.

Для иллюстрации работы приложения реального времени рассмотрим прикладной модуль, который использует ядро реального времени RTLinux в виде загружаемого модуля Linux: #define MODULE #include <linux/module.h> /* необходимо для задач реального времени */ #include <linux/rt_sched.h> #inlcude <linux/rt_fifo.h> RT_TASK mytask;

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

Рис. 2. Механизм межпроцессной связи через очереди сообщений FIFO

Модуль реального времени читает данные из устройства и кладет их в очередь сообщений, откуда их потом забирает обыкновенное приложение Linux.

Как и каждый модуль Linux-ядра, процесс реального времени должен выполнить процедуры инициализации и завершения аналогичные модулям Linux: int init_module(void) { /* определить номер очереди сообщений */ #define RTFIFODESC 1 /* взять локальное время */ RTIME now = rt_get_time() rt_task_init(&mytask, mainloop, RTFIFODESC,3000, 4); rt_task_make_periodic(&mytask, now+1000, 25000); return 0; }

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

На наш взгляд, оба подхода в реализации механизмов реального времени, заложенные в KURT и RTLinux, применимы для большинства задач реального времени. Правда, до определенного времени проект KURT находился в "подвешенном" состоянии и почти год не развивался, что вывело команду RTLinux в лидеры этого технологического направления. Однако совсем недавно вышла новая версия KURT 2.0 для Linux-ядер версий 2.2.5, 2.2.9 и 2.2.13.

Многие разработчики уже приняли Linux и внедряют ее в своих коммерческих проектах как основную операционную систему для серверов приложений. Однако до сих пор при реализации вертикальных проектов на нижнем уровне применялись специализированные ОС реального времени. Ситуация может существенно измениться благодаря использованию расширений реального времени для Linux. Теперь не надо тратить средства на изучение и покупку специализированной ОС, а весь проект можно реализовать в рамках одной системы и без чрезмерных затрат.

Ручная проверка работы фильтра пакетов

Если вы хотите проверить, как будет работать фильтр на некотором пакете, используйте команду '-C' (check). Параметры этого фиктивного пакета задаются точно так же, как и в правилах: '-p' для протокола, '-s' для адреса отправителя, '-d' для адреса получателя, '-i' для интерфейса. Если используется протокол TCP или UDP, то в адресах отправителя и получателя должен быть указан порт, а для ICMP - код и тип ICMP, кроме случая, когда проверяется не первый фрагмент пакета ('-f') - там этой информации быть не должно. Для протокола TCP и в отсутствие флага '-f' (т.е. проверяемый пакет не является фрагментом) можно указать флаг -y для имитации SYN-пакета. Пример: проверяем по входной цепочке TCP SYN-пакет от 192.168.1.1 порт 60000 на 192.168.1.2 порт www, пришедший через интерфейс eth0, (типичный запрос на установку www-соединения): ipchains -C input -p tcp -y -i eth0 -s 192.168.1.1 60000 -d 192.168.1.2 www

В ответ на эту команду ipchains сообщит судьбу пакета, например 'Packet accepted'.

Руководства - man

Если надо получить информацию по какой-либо команде, дайте команду "man имя_команды". На экран это будет выдаваться через программу "more" - посмотрите, как с ней управляться на вашем Unix'е командой `man more`.

document.write('');

This Web server launched on February 24, 1997

Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав.

С каких носителей его можно инсталлировать?

FreeBSD можно инсталлировать с дискет (классический способ), с FAT-раздела, с FreeBSD-раздела, с CD-ROM (ну, это нынче все могут), со стримера (у меня его никогда не было), а также по сети: по NFS и по FTP (обычному и сквозь FireWall). Как правило, на CD-ROM не самая свежая версия, с дискет довольно мучительно, для инсталляции с FreeBSD-раздела нужно иметь дистрибутив, записанный на этот раздел (а значит, иметь установленный с FreeBSD). NFS вообще используется довольно редкоБ по крайней мере для NFS, как и для FreeBSD-раздела надо иметь уже установленный Unix, Так что остаются FAT-раздел и FTP. Для FTP нужно иметь быструю, а главное - стабильную связь с FTP-сервером, поэтому для первой инсталляции рекомендую закачать FreeBSD на FAT-раздел локального диска. Это отрежет часть места на диске, но потом можно будет снести FAT-раздел и сделать на его месте что-нибудь полезное или же держать его для загрузки в DOS.

SAM на различных носителях информации

NT может помещать базу данных SAM на различные носители информации, включая дискеты, магнитные ленты и жесткие диски. Копирование базы на дискету или ленту требует определенных действий со стороны пользователя, такая операция не является частью обычной работы NT. В процессе ежедневного функционирования NT может размещать базу данных SAM в двух каталогах на жестком диске: %systemroot%\repair и %systemroot%\system32\config. Хотя каталог \config и содержит рабочую копию базы данных SAM, используемую "живой" системой, к этой базе нельзя получить доступ (например, для копирования) из таких программ, как Windows Explorer (Проводник), пока работает ОС. Это связано с тем, что системный процесс Local Security Authority (LSA) (lsass.exe) захватывает файл базы данных SAM для монопольного использования.

Тем не менее кто-нибудь все же может, используя загрузочный диск NT, скопировать данный файл. То есть взломщик имеет возможность перезагрузить систему со своего диска и скопировать либо переместить базу данных SAM. Еще раз заметим, что технология системного ключа может защитить SAM от подобной атаки с использованием загрузочного диска, так как база данных будет зашифрована. Это справедливо и для архивов на магнитных лентах, поскольку взятая оттуда копия базы данных SAM, зашифрованная с помощью системного ключа, окажется совершенно бесполезной для взломщика. Однако архивы на лентах все равно следует хранить под замком для защиты от потери, искажения и кражи информации.

Каталог \repair содержит ту же информацию, что и дискета ERD, создаваемая утилитой rdisk.exe и используемая для восстановления системы. И каталог \repair, и дискета ERD содержат копии базы данных SAM, поэтому они должны быть надежно защищены. Дискета ERD должна храниться в столь же безопасном месте, что и ленты с архивами данных.

Для защиты каталога \repair назначайте права таким образом, чтобы злоумышленники не могли получить доступ к данному каталогу и содержащимся в нем файлам, в особенности к файлу sam._, в котором находится база данных SAM.
Чтобы защитить файлы в каталоге \repair, используйте утилиту calcs.exe, входящую в состав Microsoft Windows NT Server 4.0 Resource Kit или другую аналогичную программу. Выполните следующие действия.

В окне Command Prompt перейдите в каталог %systemroot% (обычно это C:\winnt) и выполните команду: cacls repair /g administrators:F system:F /t

Либо вы можете, используя программу Windows Explorer, сделать следующее.

Откройте Windows Explorer.

Перейдите в каталог repair (обычно это C:\winnt\repair), нажмите правую клавишу мыши и выберите в открывшемся меню Properties.

Выберите закладку Security.

Выберите Permissions.

Отметьте Replace Permissions on Subdirectories и Replace Permissions on Existing Files.

Удалите из списка всех пользователей, кроме Administrators и SYSTEM.

Убедитесь, что и Administrators, и SYSTEM имеют права Full Control.

Нажмите OK.

Теперь вы назначили пользователям Administrators и SYSTEM права Full Control на данный каталог и все файлы, которые в нем содержатся. Поскольку режим редактирования ACL выбран не был, права всех остальных пользователей удалены системой.

В зависимости от конфигурации системы помимо каталогов \repair и \config NT может записывать информацию, имеющую отношение к SAM, в следующие файлы: pagefile.sys, memory.dmp или user.dmp. NT использует файл pagefile.sys как дополнительное пространство для организации виртуальной памяти, которое добавляется к физической памяти, установленной в компьютере. Файл memory.dmp создается при аварийном завершении работы операционной системы, если в конфигурации NT выбран режим записи образа памяти на диск. Файл user.dmp создается при аварийном завершении работы какой-либо прикладной программы, если в конфигурации программы Dr. Watson выбран режим записи образа памяти в файл.

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

Чтобы уменьшить опасность, связанную с использованием файлов user.dmp и memory.dmp, вам необходимо предпринять одно из следующих действий:

написать командный файл, который будет удалять указанные файлы при входе в систему.

установить права для этих файлов так, что только администраторы смогут иметь доступ к ним.

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

в конфигурации программы Dr. Watson отключить режим создания файлов.

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

Чтобы отключить создание файлов user.dmp программой Dr. Watson запустите утилиту drwtsn32.exe, отключите параметр Create Crash Dump File и закройте программу.

Чтобы отключить в параметрах настройки NT создание файла memory.dmp, запустите в Панели Управления (Control Panel) программу System и выберите закладку Startup/Shutdown.

Затем отключите параметр Write debugging information to. Если вам все же необходимо иметь образы памяти на момент аварийного завершения работы NT, постарайтесь настроить параметры ОС и программы Dr. Watson таким образом, чтобы файлы, содержащие образ памяти, помещались в защищенный каталог, доступный только администраторам.

Что касается файла pagefile.sys, то его открывает и защищает от попыток непосредственного доступа со стороны взломщиков только операционная система. Однако следует упомянуть прошлогодний инцидент, когда клиентская служба NetWare для Windows NT помещала в память пароли пользователей NetWare в открытом виде. Эти пароли могли быть записаны в файл pagefile.sys при переписывании соответствующей страницы памяти на диск. Любой человек, имеющий копию файла pagefile.sys и текстовый редактор, мог без труда получить пароли. Разработчики Novell решили эту проблему.

Теперь, прежде чем поместить пароли в pagefile, они шифруются с использованием недокументированного API-интерфейса. Однако взломщики могут пробить эту защиту. Так, изобретательные российские программисты нашли способ расшифровки информации, получаемой из файла pagefile.sys. Чтобы защититься от подобных атак, настраивайте NT таким образом, чтобы файл pagefile.sys удалялся при завершении работы системы. (Как это сделать, мы расскажем далее.) И не забывайте о необходимости физической защиты компьютера с целью предотвращения нежелательного доступа к файлу pagefile.sys.

Да, вы можете сконфигурировать NT так, чтобы pagefile удалялся при нормальном завершении работы системы. Но таким способом вы обеспечите защиту только от тех взломщиков, которые копируют или изменяют файл, загрузившись с другой копии ОС (т. е. используя загрузочный диск или загрузив NT из другого системного каталога). Большинство взломщиков понимают, что в таком случае у них есть возможность получения доступа к системе путем перемещения базы данных SAM, следовательно, взлом файла pagefile.sys становится бессмысленным

Несмотря на это, в ситуациях, когда условия эксплуатации системы требуют установки и использования нескольких копий ОС, удаление файла pagefile при нормальном завершении работы можно считать достаточной мерой безопасности. Следует иметь в виду, что если NT сконфигурирована так, чтобы удалять pagefile во время завершения работы системы, то неизбежна некоторая задержка в процессе начальной загрузки и останова ОС. Однако эта задержка несущественна, если принять во внимание уровень безопасности, которого мы в результате достигаем. Для того чтобы включить режим удаления файла pagefile.sys во время нормального завершения работы ОС, следует модифицировать (или создать) в системном реестре параметр ClearPageFileAtShutdown (типа REG_SZ) в ключе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management, присвоив ему значение 1.

SAM в сети

ОС Windows NT использует протокол SMB (Server Message Block - блок серверных сообщений), разработанный совместно фирмами Microsoft, IBM и Intel. Данный протокол определяет алгоритмы функционирования файловой службы в сетевой среде. Нетрудно предположить, что во время сеанса SMB по сети должны передаваться пакеты, содержащие информацию конфиденциального характера. Среди прочего эти пакеты обычно включают в себя зашифрованные данные протокола NTLM, передаваемые NT во время фазы аутентификации.

Взломщики, используя существующие сетевые анализаторы, могут легко перехватывать данные, передаваемые по сети. Задача перехвата нужных пакетов и получения из них информации о паролях всегда считалась нелегкой. Но ситуация в корне изменилась с появлением продукта SMB Packet Capture, выпущенного компанией L0pht Heavy Industries. Это сетевой анализатор, который тесно интегрирован с программой L0phtCrack. Имея в своем распоряжении L0phtCrack, можно легко "выхватывать" из сети хэш-коды паролей, передаваемые в соответствии с протоколом SMB.

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

Для защиты от подобных атак нужно использовать протокол NTLMv2, поставляемый в составе пакетов обновления SP4 и SP5, либо применять механизм создания виртуальных частных сетей (VPN - Virtual Private Network) типа Microsoft PPTP. Протокол NTLMv2 позволяет защитить данные, передаваемые по внутренней локальной сети, а PPTP обеспечивает защиту информации, передаваемой через такие "небезопасные" сети, как, например, Internet. Если вы реализуете PPTP, то обязательно установите последние сервисные пакеты, включая дополнения и исправления к ним (hotfix). Мы предупреждаем вас об этом, потому что в свое время PPTP-соединение считалось очень ненадежным.
Microsoft внесла необходимые корректировки, устраняющие недостатки PPTP. Но эти корректировки будут вам недоступны, если вы не установите hotfix к пакету SP3 или более позднему пакету.

Следует иметь в виду, что при отсутствии в вашей системе механизма VPN и технологии подписей SMB взломщик может использовать сеанс SMB для получения несанкционированного доступа в систему. Microsoft реализовала технологию подписей SMB в пакете обновления SP3 и также включила ее во все последующие пакеты обновления. При использовании подписей пакетов SMB операционная система проверяет подлинность каждого пакета, прежде чем принять его к исполнению. Однако реализация подписей SMB не всегда безопасна. Для получения более подробной информации обязательно прочитайте статью Microsoft How to Enable SMB Signing in Windows NT ().

Для борьбы со средствами взлома типа L0phtCrack можно запретить NT посылать в сеть хэш-коды паролей, формируемые по протоколу LAN Manager (LM). Хэш-коды LM являются более простыми, чем коды NTLM, так как NTLM позволяет задействовать пароли, учитывающие регистр. Также NTLM допускает возможность применения дополнительных символов клавиатуры. Это расширяет диапазон символов ключа шифрования на 26. Заметим, что сложные пароли труднее поддаются расшифровке даже при наличии таких инструментов, как L0phtCrack.

Целесообразно включать в пароль символ "возврат каретки", так как L0phtCrack не умеет нормально обрабатывать этот символ. Чтобы вставить "возврат каретки", нажмите клавиши Alt+0+1+3 на цифровой панели клавиатуры.

Для решения описываемой проблемы Microsoft реализовала в составе дополнений и исправлений к сервисному пакету SP3 новый ключ реестра. Он был включен во все сервисные пакеты, вышедшие после SP3. Новый параметр реестра, LMCompatibilityLevel, имеет тип REG_DWORD и размещается в HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa.

При использовании NTLMv2 можно установить значение этого параметра равным 0, 1, 2, 3, 4 и 5. Если это значение равно 0, то NT при аутентификации сетевого соединения передает по сети пароли как в формате NTLM, так и в формате LM (этот метод аутентификации обеспечивает совместимость с другими системами и используется в NT по умолчанию).

Если значение равно 1, то NT передает оба типа хэш-кодов только тогда, когда этого требует сервер. Если значение равно 2, то хэш-коды паролей в формате LM не используются ни при каких обстоятельствах. Если значение равно 3, применяется только аутентификация по протоколу NTLMv2. Значение параметра, равное 4, запрещает контроллеру домена использовать аутентификацию LM, а значение 5 указывает на необходимость применять при аутентификации только протокол NTLMv2. Наиболее безопасной является установка значения этого параметра равным 2. Но следует иметь в виду, что системы, поддерживающие только протокол LM (т. е. Windows 95 и Windows for Workgroups), не смогут установить соединение с данной системой NT. Полный перечень особенностей конфигурации описан в статье Microsoft How to Disable LM Authentication on Windows NT (). Заметим, что при установке пакета обновления SP4 данный ключ реестра способен принимать шесть различных значений.

Еще один способ взлома системы может иметь место, если взломщик располагает возможностью физического доступа к компьютеру. Используя такие средства, как NT Locksmith или ERD Commander (оба можно найти на ), ничего не стоит получить доступ в систему с правами любого пользователя. Для защиты от этого метода взлома следует принять меры, препятствующие физическому доступу к компьютеру.

Scanreg: резервирование и восстановление в различных режимах

Возможности При работе в среде DOSПри работе в среде Windows

Создание резервных копий файлов Реестра	Да	Да
Команда для запуска	scanreg	sanregw
Выправление испорченного Реестра	Да	Нет
Восстановление Реестра по резервной копии	Да	Нет
Автоматическое выполнение	Только при обнаружении поврежденного файла	При каждом запуске Windows
Выполнение в защищенном режиме	Нет	Да
Сканирование Реестра для обнаружения повреждений	Да	Да

Утилита "Проверка реестра" работает лучше, если создавать резервные копии файлов Реестра в среде Windows, а восстанавливать их в среде DOS

Если вы хотите вручную создать резервную копию Реестра с помощью утилиты "Проверка реестра", нажмите кнопку "Пуск", укажите пункт "Выполнить", введите в командную строку regscan.exe и подтвердите свое намерение сделать это, ответив "Да". В этом случае, как и описано выше, появится CAB-файл. Чтобы он не был замещен другим, переименуйте его, дав ему имя того оборудования или ПО, которое вы собираетесь установить, и дополнив это имя словом before ("до") или after ("после"), например sblaster_after.cab.

По умолчанию утилита "Проверка реестра" сжимает в CAB-файле еще четыре: system.dat, user.dat, system.ini и win. ini. (Два последних являются реликтами Windows 3.1, сохраненными, чтобы обеспечивалась совместимость с более старыми программами, которые обращаются к ним за конфигурационными данными.) Если вы хотите добавить к этим файлам другие, например autoexec.bat и config.sys, то укажите их имена и расположение в строке Files=файла scanreg.ini. Утилита "Проверка реестра" бывает двух видов - для Windows (scanregw.exe) и для DOS (scanreg.exe), каждая со своим набором возможностей (см. врезку "Scanreg: резервирование и восстановление в различных режимах"). Если вы хотите восстановить Реестр по резервной копии или же создать резервные копии из DOS, то должны использовать команду scanreg из командной строки DOS в режиме MS-DOS. Для этого нажмите кнопку "Пуск", укажите пункт "Завершение работы" и отметьте "Перезагрузить компьютер в режиме MS-DOS". Если попытаться запустить scanreg. exe в среде Windows, то стартует утилита scanregw.exe.

После запуска scanreg.exe выберите "ЗапускПросмотр копий" - перед вами появится список всех имеющихся резервных файлов. Отметьте какой-либо из них, и утилита "Проверка реестра" восстановит его. Однако программа scanreg "видит" и, следовательно, позволяет восстанавливать только файлы с именами в формате rbxxx.cab. Чтобы восстановить файлы с нестандартными именами, откройте Проводник, найдите нужный CAB-файл и дважды щелкните на его имени - вы увидите хранящиеся там файлы. Затем просто замените испорченные файлы их сохраненными исправленными копиями и перезагрузите ПК.

Сеансовый Монитор

Сеансовый Монитор, с помощью которого создаются все пользовательские сеансы, использует в расширенном виде ту же концепцию, что и Монитор Обращений. Аналогично Монитору Обращений, Сеансовый Монитор является посредником между субъектом, посылающим запрос на предоставление некоторой услуги, и объектом, предоставляющим эту услугу. После идентификации субъекта, Сеансовый Монитор осуществляет проверку - удовлетворяет ли данный запрос имеющимся ограничениям, таким как тип запрашиваемой услуги (разрешена ли она), время запроса, а также локализация запроса. Такая дополнительная проверка создаваемого сеанса на соответствие заданным ограничениям позволяет клиентам легко конфигурировать стратегию защиты узлов сети (site), а также корпоративную стратегию защиты.

Любой метод создания сеансов (например такой, как telnet, ftp или login) является потенциальной услугой, которая может быть предоставлена имеющему соответствующие полномочия субъекту. Специальные услуги, доступные любому пользователю в системе, определены в базе данных идентификации и санкционирования (authentication and authorization database - A&A database). Сеансовый Монитор является шлюзом (gateway), с помощью которого создаются сеансы; основой для создания сеанса с помощью Сеансового Монитора служит информация, хранимая в базе данных A&A.

Неразвитые средства защиты файла паролей, которыми снабжены многие другие платформы UNIX, попросту перемещают пары имя_пользователя/зашифрованный_пароль, хранимые в широко известном формате, в какой-то другой файл. База данных A&A хранит зашифрованные пароли в уникальном формате, доступном только для системных вызовов, поступающих от уполномоченного администратора. Специализированный идентификационный механизм базы данных A&A позволяет отдельным пользователям иметь разные пароли для локального и удаленного доступа в дополнение к средству коммутации пользователя (switch user facility - suf). Каждая из этих возможностей может ограничиваться определенным временем и/или локализацией. В дополнение, отдельные пользователи могут иметь множество полномочий, дающих право на получение определенной услуги.

Сеансы работы пользователей

ЭКРАН 1. Настройка аудита системы.

Многие администраторы просматривают журнал безопасности Windows NT и видят события входа пользователей в систему и выхода из нее, однако часто не могут правильно оценить увиденное. Здесь следует обращать внимание на отдельные параметры событий. Так, событие успешной регистрации пользователя в системе имеет номер (ID) 528 (см. Рисунок 1). При отказе в регистрации пользователя фиксируется событие с другим номером, который зависит от причины отказа. Полный список событий можно найти в документе Microsoft "Описание событий аутентификации" (см. ). Событие с номером 538 означает завершение сеанса, начало которого зафиксировано событием 528. Событие номер 528 имеет несколько очень важных дополнительных параметров. Имя пользователя и домен определяют вошедшего в систему пользователя или то, чья учетная запись была при этом задействована. Номер сеанса пользователя Logon ID - это уникальный для системы код, присваиваемый любому активному сеансу работы пользователя с системой. Именно он будет записан в событии завершения сеанса. Это позволяет определить общее время работы пользователя при анализе событий 528 и 538 с одним и тем же номером сеанса.

РИСУНОК 1. Событие номер 528.

Событие входа в систему также фиксирует информацию о типе входа Logon Type, т. е. то, как пользователь вошел в систему. Тип входа 2 соответствует интерактивному входу с консоли, например, с помощью монитора и клавиатуры. Если пользователь подключается к диску на другом компьютере или как-либо еще использует сетевой ресурс, то выполняется сетевой вход с типом 3. Так, если был зафиксирован тип входа 2, то кто-то вошел в систему с локальной консоли именно этого компьютера, а если тип 3, значит, кто-то подключился к системе по сети. Тип входа 5 фиксируется при запуске службы с указанием конкретной учетной записи пользователя. При использовании планировщика задач производства независимых компаний, например Argent Queue Manager компании Argent Software, система фиксирует событие номер 528 с типом входа 4, что соответствует заданию на выполнение командного файла.
При разблокировании рабочей станции записывается событие с типом входа 7.

Фиксируются также все неудачные попытки входа в систему Logon Failure. При этом чаще всего записывается системное событие 529, соответствующее указанию неверного имени пользователя или пароля - Unknown user name or bad password.

ЭКРАН 2. Выбор рабочих станций, с которых пользователь имеет право войти в систему.

Если учетная запись пользователя недоступна или заблокирована, то попытка входа отвергается, и записывается событие с номером соответственно 531 или 539. Событие номер 530 указывает, что пользователь пытался войти в систему в недозволенное ему время или день недели. Если учетная запись пользователя просрочена или устарел пароль, то фиксируется соответственно событие 532 или 535. Если пользователь ограничен входом лишь на некоторые рабочие станции (см. Экран 2), а он пытается войти с другого компьютера, то запишется событие номер 533. Можно ограничить права пользователя на выполнение определенных типов входа в различные системы. Если пользователь, которому запрещен доступ к какому-то компьютеру по сети, все же пытается обратиться к его ресурсу или реестру, то он получит отказ, а в журнал безопасности запишется событие с номером 534. Такое же событие будет зафиксировано при попытке пользователя войти в систему с консоли, если это ему запрещено. При попытке запустить службу с использованием учетной записи пользователя, не имеющей права на запуск служб (права Logon as a service), также будет зафиксировано событие номер 534. Кроме того, событие 534 запишется и при попытке запуска задания с исполнением командного файла от имени учетной записи без права Logon as a batch job. При всех других отказах в аутентификации фиксируется событие с номером 537, т. е. An unexpected error occurred during logon - отказ по неизвестной причине. Тип входа фиксируется при всех попытках входа в систему, независимо от их результата. Более подробную информацию можно найти в документе Microsoft "Аудит аутентификации пользователей" (см. ).

Аутентификация в Windows NT имеет распределенную природу. Особенно ярко это проявляется при слежении за входом в систему и выходом из нее. Зачастую аудит на рабочей станции, имеющей учетную запись в домене, воспринимается уже как "вход в домен", вместо настоящего момента входа в домен или же входа на контроллер домена с использованием учетной записи домена. Аудит на рабочей станции означает лишь регистрацию на рабочей станции. Но поскольку используется учетная запись домена, сама рабочая станция не может аутентифицировать пользователя. Рабочая станция лишь посылает сведения о пользователе на контроллер домена по протоколу NTLM (NT LAN Manager). Контроллер домена проверяет правильность пароля и сразу же забывает о пользователе. Сеанс работы пользователя поддерживает сама рабочая станция до самого момента выхода из системы. Разумеется, именно рабочая станция и записывает в свой журнал системы безопасности информацию о сессии пользователя.

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

Необходимо отслеживать использование локальных учетных записей на отдельных системах.

Входящие в домен рабочие станции и обычные серверы аутентифицируют пользователей на контроллерах доменов, а также ведут собственные локальные базы пользователей (SAM). И пользователи, и взломщики могут задействовать эти локальные учетные записи, чтобы попытаться войти в систему локально или через сеть. Во всех системах существует встроенная административная учетная запись Administrator. О том, как предотвратить нежелательные попытки ее использования, рассказано в мартовском номере Windows NT Magazine/RE в статье Франклина Р. Смита "Защитим права администратора!".

Для эффективного наблюдения за сеансами работы пользователей нужно хорошо знать, что и где проверять. Для отслеживания входа в систему в первую очередь следует просматривать журналы безопасности на рабочих станциях и простых серверах и искать в них события с номерами 528 и 538. Возможные попытки незаконного проникновения в систему отслеживаются среди событий с номерами от 529 до 537, а также 539 на всех потенциально доступных для нападения компьютерах.

Селекторы

Здесь "селектор" следует понимать, как

расширение понятия "шаблон", поскольку там где в структуре

команды указан шаблон, в общем случае может стоять любой селектор.

Замечание. Открывающая

скобка действия "{" должна быть в строке селектора.

В качестве селектора может быть:

выражение;

шаблон;

их комбинация.

Соответствующие примеры:

1) $3 != $4 && $3 > 1970

$3 % 2 == 1

$1=="Иванов" - кавычки, чтобы воспринималось, как строка.

2) /ab/ отлично от /a b/, / ab/ и /ab /

Nполя ^шаблон - по совпадению

Nполя !^шаблон - по несовпадению

Пример:

awk '$3~0 {print} ' < f-awk

echo

awk '$3!~0 {print} ' < f-awk

Иванов И.И. 1980 50

Хведоров И.Х. 1970 60

Петров А.В. 1979 40

Сидоров С.К. 1979 40

3) Шаблон может формировать множество образцов или

указывать, в каком месте поля искать:

/^a/	поле начинается с "a"
/a$/	поле кончается "a"
\+	экранирует оператор
[abc]	любой из символов "a", "b" и "c"
[a-р]	любой символ диапазона
*	0 или больше вхождений регулярного выражения
+	1 или больше вхождений регулярного выражения
?	0 или 1 вхождение регулярного выражения
ab\|cd	"ab" или "cd"

Примеры сочетаний:

awk ' $3~/(7[0-9])$/ {print} ' f-awk

Результат:

Петров А.В. 1979 40

Сидоров С.К. 1979 40

Хведоров И.Х. 1970 60

То есть в третьем поле выделить 70-е годы (7 и еще

одна цифра от конца поля).

Серия первая:

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

Серия третья:

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

Программы, которые я использую в работе: Norton ghost - для создания образов. PQMagic для создания разделов на HDD.

1. Создание разделов на диске.

Я рекомендую создавать, по возможности, как минимум 2 раздела. 1-й системный (Диск C), на котором будет храниться операционная система и установленные программы. 2-й (диск D) - для хранения рабочих файлов пользователя, а также некоторых дистрибутивов программ. Такое разделение нужно для быстрого восстановления системного раздела целиком из образа, без предварительного сохранения пользовательских файлов, на которое иначе придется затрачивать рабочее время. К тому же сбои в работе ОС или отключение электроэнергии может привести к порче файлов, созданных пользователем. Так проще и надежнее. На современных жестких дисках от 20 Gb и выше я выделяю для диска C 10 Gb.

2. Компьютер, установленный дома.

Вы настраиваете, как вам нужно, устанавливаете драйвера, необходимые программы. Потом перезагружаетесь, загружаетесь с дискеты в MS-DOS, запускаете программу ghost и делаете резервную копию системного раздела на диск D. Причем программа ghost копирует полностью диск с системными данными и загрузочной областью, но в образ включаются только занятое программами дисковое пространство, а не весь диск. Есть опции сжатия данных, что ощутимо сокращает размер образа. Так размер полностью установленной и настроенной ОС Windows 98Se c полным пакетом MS Office 2000, ACDSee, Antivirus, Windows Commander и тд в образе занимает около 450 Мб, что не так много для современного компьютера. Windows2000 - 850 Мб, WindowsXP - 1200 Мб. Теперь в случае какого-либо сбоя или возникновения ситуации неработоспособности вашей ОС вы, загрузившись с дискеты, с помощью программы ghost за 4-10 минут полностью восстановите свою рабочую среду.
Красота, не так ли? Поиск и исправление неисправности может занять более продолжительное время.

Вы можете создать несколько промежуточных образов - 'голая' ОС с драйверами, ОС+Оффис - решайте сами. Во всяком случае, потратив 10-15 минут на сохранение только что установленной и настроенной ОС единожды, вы сэкономите свое время в будущем. Так же это очень 'красиво' для обслуживания техники в организациях.

3. Единый образ на все случаи жизни.

a) Выбираете рабочий компьютер, с диском без badblock. Разбиваете диск на разделы.

b) Устанавливаете ОС обычным образом. Не устанавливаете никакие драйвера. Устанавливаете программы (Office, DIVX, AntiVirus и тд). Производите все необходимые донастройки.

c) ВАЖНО!!! устанавливаете драйвер контроллера жесткого диска как Standart IDE Controller, заменяя существующий.

Удаляете все драйвера, имеющие название относящиеся к chipset (intel, via, sis). В данном случае ваша настройка никак не привязана к конфигурации компьютера и может быть загружена и донастроена на любом оборудовании. Я для удобства копирую также часто используемые программы и драйвера, не занимающие много места (например, в директорию addon).

Теперь перезагружаемся. Загружаемся с дискеты и создаем образ с максимальным сжатием. Данный образ вы можете хранить либо на диске D, либо записать на CD-RW.

Теперь вы приходите к пользователю, загружаетесь с загрузочного CD-RW. И в случае, если диск C можно спокойно перезаписать, в течении 5 минут разворачиваете образ и в оставшиеся 25 минут устанавливаете драйвера под его оборудование и, если нужно, дополнительные программы, необходимые пользователю, и которых нет в образе. В любом случае вы сэкономите себе огромное количество времени и нервов.

Комментарии:

В случае если у вас компьютеры находятся в сети - не забудьте изменить имя компьютера.

Windows 98 SE: Я лично удаляю все драйвера, которые имеют отношение к набору логики данной материнской платы. В данном случае я просто остановился на этом варианте и у меня все работает на других компьютерах.

Искать, что еще можно оставить, у меня не было времени, и не стоило оно того. Рекомендую также в образ скопировать дистрибутив Windows 98 SE, поскольку после первой загрузки на только что установленной из образа ОС начнется процесс поиска новых устройств и система попросит дистрибутив, а CD-ROM еще не доступен. Также обратите внимание на ACPI менеджер, отвечающий за управление питания компьютера, наверное, его для подготовки образа тоже стоит удалить, поскольку система автоматически его не настроит. Это касается компьютеров с AT и ATX питанием. Еще стоит провести полный поиск всех устройств. ПУСК->Панель управления->Установка оборудования.

Windows 2000, Windows XP. Здесь особых проблем нет. Главное - до подготовки образа оставить в системе Standart IDE Controler, иначе система может вообще не загрузится!!! А после удачной загрузки произойдет автоматический поиск устройств. Доустановите драйвера, и всё будет хорошо.

Windows ME - не пробовал.

Windows NT - в принципе все с нее начиналось, но тут надо иметь в виду, что с PnP у нее слабовато. Поэтому опыта кроме как подготовки образа для однотипной конфигурации у меня нет.

Для NTFS не забудьте перебить SID - для этого есть специальная утилита ghostwalk из пакета Norton Ghost.

Сервер реинкарнации

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

Периодический мониторинг состояния.

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

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

Серверы AViiON

Системы AViiON компании Data General помогают пользователям добиваться максимальной производительности их критичных бизнес-приложений. Операционная система компании Data General - DG/UX благодаря реализованной в ней функции симметричной многопроцессорной обработки и другим своим возможностям получила признание у специалистов по оценке технологий, как передовая UNIX-подобная операционная система. Системы AViiON компании Data General кроме DG/UX позволяют использовать и две другие операционные системы - Windows NT Server и SCO UnixWare 2.1.

Развитые средства хранения данных CLARiiON компании Data General, позволяют пользователям максимизировать доступность данных и приложений фактически в любой точке предприятия. Продукты CLARiiON могут использоваться совместно с системами AViiON компании Data General, а также с аналогичными системами компаний IBM, Digital Equipment Corporation, Sun Microsystems, NCR и других основных поставщиков систем. Продукты CLARiiON могут также использоваться совместно с системами, работающими под управлением операционных систем Novell NetWare, NT, OS/2 и SCO UNIX.

Компания Data General занимается открытыми компьютерными системами. Она специализируется на серверах AViiON, сопутствующих им средствах хранения данных, программных продуктах, а также сервисных услугах, оказываемых клиентам по всему миру. Data General разрабатывает передовые системы, используя лучшие на сегодняшний день промышленные технологии; создает пакеты программ, предоставляя ведущие решения для предприятий; оказывает комплексные услуги по разработке, внедрению и поддержке всех решений для вычислительных систем.

Серверы и рабочие станции домена

экран 1. Использование утилиты SU.

Регулярный мониторинг параметров системы безопасности серверов и рабочих станций домена, на которых работают сотрудники, имеющие доступ к критически важным ресурсам, - важнейший аспект защиты домена, поскольку эти системы также могут стать мишенью для тех, кто хочет завладеть правами администратора. Каждый такой сервер и рабочая станция хранят локальную копию базы учетных данных, которая служит для назначения пользователям локальных прав и определения их принадлежности к той или иной локальной группе. Многие дополнительные привилегии пользователей, например Act as part of the operating system, а также привилегии, относящиеся к управлению маркерами доступа, позволяют злоумышленнику захватить управление системой и получить доступ к административным привилегиям. Встроенные локальные группы Administrators и Power Users также имеют в системе особые привилегии.

И, наконец, важно убедиться в том, что за развертывание рабочих станций отвечают достаточно компетентные сотрудники. Эту задачу зачастую выполняют либо начинающие, либо контрактники, а поскольку именно они устанавливают операционную систему, они выбирают и пароль для встроенных административных учетных записей. Многие пользователи не подозревают о существовании встроенной учетной записи Administrator, а большинство администраторов забывают об этом, как только рабочая станция установлена. По умолчанию на рабочей станции NT активизируется служба Server, и станция может функционировать как файловый сервер. Должны ли посторонние специалисты или младший технический персонал иметь возможность доступа с правами администратора к рабочей станции после того, как она передана в распоряжение того или иного пользователя? Скорее всего, нет, но часто это происходит именно так - все зависит от методики развертывания рабочих мест, принятой в организации. Допустим, младший IT-специалист, проработавший в компании всего лишь несколько месяцев, имеет доступ к рабочей станции вице-президента по маркетингу или вице-президента по персоналу.
Именно такую картину я нередко наблюдал в организациях, куда меня приглашали для анализа системы защиты. Подобные рабочие станции - настоящий клад для злоумышленника, поскольку на локальных дисках приложения кэшируют временные файлы, а пользователи хранят конфиденциальную информацию, несмотря на требования поступать наоборот. Не стоит облегчать взломщикам жизнь, позволяя им с легкостью проникнуть в систему. Советую сбросить пароль учетной записи Administrator на серверах и рабочих станциях домена и рассмотреть возможность отключения службы Server.

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

Сетевая производительность

Мы тестировали также и сетевую производительность системы с драйверами, выполняемыми в режиме пользователя. Тестирование производилось с использованием карты Intel Pro/100, поскольку у нас не было драйвера для карты Intel Pro/1000. Мы смогли управлять Ethernet на полной скорости. Кроме того, мы запускали тесты возвратной петли с отправителем и получателем, находящимися на одной машине, и наблюдали пропускную способность в 1.7 Гб/сек. Поскольку это эквивалентно использованию сетевого соединения для посылки на скорости 1.7 Гб/сек и одновременного приема на той же скорости, мы уверены, что управление гигабитной аппаратурой Ethernet с единственным однонаправленным потоком на скорости в 1 Гб/сек не должно создать проблему при использовании драйвера, выполняемого в режиме пользователя.

Сходства и различия

Disk Management и Disk Administrator во многом похожи. Новое средство по-прежнему поддерживает RAID уровней 0, 1 и 5, дисковые массивы с чередованием и с четностью (состоят из трех и более дисков, на один из которых записывается информация, позволяющая восстановить данные при выходе из строя любого диска), дисковые массивы с чередованием без четности (данные размещаются с чередованием на нескольких физических дисках), а также дублирование (для каждого тома создается зеркальная копия на другом физическом диске). Кроме того, поддерживаются многодисковые тома, объединяющие свободное пространство на нескольких дисках в один логический том.

Хотя интерфейс может показаться знакомым, следует иметь в виду некоторые особенности Disk Management. Необходимость полной реализации новых свойств несколько изменила и расширила терминологию. Кроме того, преодолено прежнее ограничение в 26 логических дисков. Новый интерфейс упрощает создание и изменение томов, причем после этих операций перезагрузка больше не требуется. Теперь вся информация обо всех дисках (нормально ли они работают, их объем, тип файловой системы, а также количество свободного места и процент использования) собрана в одном месте, причем тут же отображаются сведения о структуре тома. Это позволяет отказаться от постоянного переключения режимов просмотра, что приходилось делать в Disk Administrator. Ну и, наконец, теперь можно восстановить данные без перезагрузки, поскольку при замене вышедшего из строя диска в томах с дублированием и RAID 5-го уровня эти тома становятся работоспособны сразу же после автоматической регенерации данных.

Символические ссылки

Символическая ссылка - относительно новое понятие в Unix. Это особый файл с информацией о том, что требуемый файл в действительности находится в другом месте, и о том, где именно его искать. Например, файл /usr/bin/gzip представляет собой символическую ссылку, указывающую на файл /bin/gzip; благодаря ей можно использовать /bin/gzip, обращаясь к нему как к /usr/bin/gzip. Близким аналогом символических ссылок являются ярлыки Windows 9X и NT 4.0, но ярлыки интерпретируются Проводником Windows, а символические ссылки - непосредственно ядром ОС.

В отличие от обычной, или, как еще говорят во избежание путаницы, жесткой ссылки, символическая ссылка может указывать на файл из другой файловой системы (например, находящийся на другом диске). Заметим, что при создании жесткой ссылки мы получаем два равноправных объекта (при удалении файла /usr/bin/unzip файл /usr/bin/zipinfo будет работать по-прежнему), а вот символическая ссылка при удалении (или переименовании/перемещении) объекта, на который она указывает, "провисает" и становится неработоспособной.

Во второй части статьи мы рассмотрим права доступа к файлам и работу Linux с другими файловыми системами.

Окончание в следующем номере.

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

Операционная система	Требует
Windows 95	100 Мбайт
Windows 98	200 Мбайт
Windows NT	200 Мбайт
Windows 2000	700 Мбайт