Монтирование: подробности для любознательных

Как уже было сказано, монтирование файловых систем выполняется командой mount, а их размонтирование - командой umount. Исключение составляет корневая файловая система, которая обслуживается отдельно и до всех остальных систем. Действительно, только при ее наличии становятся доступными и сама команда mount, и каталог /dev, где находятся файлы устройств, и подкаталоги для монтирования. Чтобы файловые системы можно было монтировать при запуске ОС и размонтировать при ее остановке, используются два файла, которые традиционно размещаются в подкаталоге /etc: /etc/fstab и /etc/mtab.

Файл /etc/fstab содержит список файловых систем, которые могут быть смонтированы. Конечно, необходимые параметры всегда можно указать при вызове команды mount, но гораздо удобнее, когда они извлекаются из файла. Содержимое моего файла /etc/fstab показано на рис. 3.

Рис. 3. Пример файла fstab

Каждой точке монтирования в нем соответствует одна строка, состоящая из шести полей: название устройства, на котором расположена файловая система, точка монтирования, тип файловой системы, параметры монтирования, "уровень дампа" и порядковый номер файловой системы для программы fsck. Рассмотрим эти поля по порядку.

Название устройства

Чаще всего в этом поле задается имя блочного устройства, на котором размещена файловая система, но так бывает не всегда: для файловой системы procfs, дающей доступ к внутренним структурам ядра, здесь может находиться любой текст (в примере - слово none), для сетевой файловой системы указывается имя сервера и подкаталога на нем и т.д. Даже для обычных файловых систем данное поле иногда содержит нечто отличное от имени устройства: скажем, в трех последних строках моего файла /etc/fstab это имена файлов с образами дисков CD-ROM. Кроме того, разрешается указать вместо имени устройства метку диска или его серийный номер, например:

LABEL=temp /tmp ext2 defaults 1 2 UUID=3a30d6b4-08a5-11d3-91c3-e1fc5550af17 /usr ext2 defaults 1 2

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

auto - система может быть смонтирована при автоматическом монтировании;

defaults - установки по умолчанию: rw + suid + dev + exec + auto + nouser + async;

dev - система может содержать файлы блочных и символьных устройств;

exec - она может содержать исполняемые файлы;

loop - для размещения системы можно использовать обычный файл (стандартно файловые системы размещаются на устройствах, к каковым обычные файлы не относятся, но если указать параметр loop, программа mount находит свободное loop-устройство, "связывает" с ним с помощью программы losetup заданный файл и передает имя этого устройства системному вызову mount; именно так монтируются образы CD-ROM в трех последних строках моего файла fstab);

noatime, noauto, nodev, noexec, nosuid, nouser - параметры, противоположные по значению соответствующим параметрам без "no-";

remount - повторно смонтировать уже смонтированную файловую систему (например, чтобы сменить параметры монтирования);

ro - смонтировать файловую систему только для чтения;

rw - смонтировать файловую систему для чтения и записи (установка по умолчанию);

suid - разрешить интерпретацию битов SUID и SGID (подробнее мы рассмотрим их в разделе, посвященном правам доступа);



sync - весь ввод-вывод осуществляется синхронно;

user - обычный пользователь (не суперпользователь) наделяется правом монтировать и размонтировать данную файловую систему; этот параметр влечет за собой noexec, nosuid и nodev, если после него явно не указано exec, dev или suid.

"Уровень дампа"

Это поле - самое мистическое в /etc/fstab. Оно используется программой dump, предназначенной для создания резервных копий. Если файловая система должна участвовать в процессе резервного копирования, то здесь должно стоять число 1, если нет - 0 (в действительности возможны и другие значения, но чтобы объяснить их смысл, пришлось бы вникать в тонкости работы программы dump).

Порядковый номер файловой системы для программы fsck

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


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

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

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

В файле /etc/mtab хранится информация о том, какие файловые системы сейчас смонтированы и с какими параметрами монтирования это было сделано. Данные о смонтированных файловых системах содержатся также в файле /proc/mounts (и там они точнее, поскольку отображают соответствующую внутреннюю таблицу ядра), но параметров, с которыми эти системы были смонтированы, в нем нет, поскольку они в ядре не хранятся (а те из них, которые интерпретируются программой mount, вообще не доходят до ядра), поэтому /etc/mtab также находит применение.

*Другое исключение - специальная файловая система devfs, содержащая файлы устройств.

Можно немного расслабиться

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

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

Мультисерверные операционные системы

Более сложный подход состоит в расщеплении операционной системы на части и выполнении каждой части в собственной области защиты. Одним из таких проектов был SawMill Linux [12]. Однако в 2001 г. проект был неожиданно остановлен после того, как многие из его основных участников ушли из IBM.

Другим мультисерверным проектом является DROPS, в котором ОС также строится поверх минимального ядра L4/Fiasco [14]. Этот проект ориентирована на мультимедийные приложения. Однако большинство драйверов устройств выполняется в составе большого серверного процесса L4-Linux, и только мультимедийные подсистемы выполняются отдельно. После некоторой настройки проигрыш в производительности снизился до 2-4%.

Еще одной мультисерверной операционной системой с драйверами, выполняемыми в пользовательском режиме, является Nemesis [23]. В этой системе имеется единое адресное пространство, разделяемое всеми процессами, но используется аппаратная защита между процессами. Подобно DROPS эта система была ориентирована на мультимедийные приложения, но не являлась POSIX-совместимой и даже UNIX-подобной.

На каких именно серверах можно взять FreeBSD?

Для получения списка серверов обратитесь на , а для России - и . К сожалению, ftp.gamma.ru не позволяет анонимный вход, если ваша машина не известна ReverseDNS-серверу, отвечающему за вашу зону IP-номеров, так что если вы только собираетесь строить свою Internet-сеть на базе FreeBSD, то это место не самое удачное.

Начала PAM.

Stanislav Ievlev,

Первая публикация произошла на

Надежная и Безопасная Передача Данных в Сети

Надежная и безопасная передача данных в сети обеспечивается продуктом DG/UX B2 Security Option с помощью расширений Межсетевого Протокола (Internet Protocol - IP), соответствующих промышленному стандарту. Используемые в DG/UX B2 Security Option надежные расширения IP присваивают каждому сеансу в сети атрибуты защиты с помощью Стандартной Опции Безопасности Межсетевого Протокола (Common Internet Protocol Security Option - CIPSO). Опция CIPSO определяет согласованный метод IP-оформленной пакетной передачи информации, безопасность которой должна быть обеспечена, по сети - между узлами, серверами, клиентами и маршрутизаторами; передача информации может быть как сквозной, так и с использованием промежуточных систем.

Надежный IP широко используется фирмами, обеспечивающими сетевые коммуникации. Он удовлетворяет всем требованиям U.S. Department of Defense Intelligence Information System Network Security Information Exchange (DoDIIS NSIX)

Надежность уровня приложений

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

Рис. 3. Различные сценарии восстановления на уровне приложений для разных типов сбойных драйверов устройств

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

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

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

Нарушения в реестре

Системный реестр - сердце системы NT. Поэтому в зависимости, от вида и степени нарушения целостности, поврежденный реестр весьма часто вызывает сбой при загрузке операционной системы. Нарушения целостности реестра могут быть физические и логические. Физическое нарушение подразумевает, что какие-то неполадки (обычно сбои в работе дисковой подсистемы) вносят путаницу в файлы реестра (например, в файлы SOFTWARE или SYSTEM в системном каталоге \%winntroot%\system32\config). Логические нарушения означают, что приложение, пользователь или сама операционная система записали в реестр неверные данные, которые в свою очередь могут вызвать сбой при загрузке, если значение данного ключа в реестре достаточно критично.

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

Если имеются основания подозревать, что проблемы с загрузкой связаны именно с реестром, можно начать восстановление с использованием варианта загрузки предыдущей конфигурации (Last known good configuration). Это можно сделать несколькими путями.

Вариант Last known good configuration. Вы можете воспользоваться этой опцией при появлении соответствующей подсказки и нажатии клавиши пробела в период загрузки системы. Выбрав эту опцию, вы загрузитесь с предыдущей работоспособной конфигурацией. Это самый быстрый и легкий способ, если, конечно, он срабатывает. К сожалению, шансы на успех в реальной ситуации не так уж велики, поскольку данный способ ограничивается восстановлением только одной части реестра (а именно, ветви ControlSet00X в ключе HKEY_LOCAL_MACHINE\SYSTEM). То есть вы сможете восстановить систему данным способом, только если проблема ограничена данной ветвью реестра и вы сразу использовали вариант Last known good configuration.
Однако в большинстве случаев предложенный метод не поможет.

Восстановление через процесс установки и с помощью дискеты восстановления ERD (Emergency Repair Disk). Можно воспользоваться процедурой установки NT для проверки и замены индивидуальных файлов реестра, если первый способ не сработал. После установки дискеты восстановления ERD в дисковод вы должны будете указать, какую часть существующей операционной системы требуется проверить (см. экран 2). Если вы выберете пункт Inspect registry files, появится список файлов реестра, и вы сможете указать, какие из них нужно заменить. Заменяющие файлы берутся либо с диска ERD, либо из каталога \%systemroot%\repair. Файлы на диске ERD и в каталоге \%systemroot%\ repair хранятся в сжатом виде, и каждый из них имеет расширение в виде подчерка "_" (например, SYSTEM._, SOFTWARE._).

ЭКРАН 2: Экран выбора опций при процедуре восстановления программы установки

Использование самых последних копий заменяющих файлов позволит не потерять важную информацию о конфигурации приложений и системы. Созданию диска ERD с последними копиями файлов реестра посвящена статья Майка Рейли, опубликованная в январском номере журнала за 1997 год. Добавлю, что не следует восстанавливать ветви SAM и SECURITY на контроллере домена, если только вы не запускали программу создания дискеты восстановления rdisk с ключом /s или s- (то есть Rdisk /s). В противном случае программа установки перепишет вашу базу SAM ее версией, создаваемой в процессе установки, что вызовет череду новых затруднений. Кроме того, следует убедиться в том, что файлы реестра на дискете ERD и заменяемые файлы созданы операционной системой, на которую был установлен один и тот же сервисный пакет. Важно помнить, что Service Pack 3 и последующие проводят изменения в ветвях SAM и SECURITY, связанные с усилением системы безопасности NT. Если не соблюдать это правило, то вы не сможете войти в систему после завершения процедуры восстановления. Далее заметим, что исправление файлов SAM и SECURITY вряд ли разрешит проблему нарушения целостности реестра, поскольку сбой при загрузке системы вызывают по большей части ветви SYSTEM и SOFTWARE.


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

Альтернативная/параллельная установка NT. Использование альтернативной/параллельной установки для восстановления реестра - на наш взгляд, оптимальное средство решения проблемы. Загрузка альтернативной системы позволяет вам получить доступ к томам с NTFS, которые в противном случае были бы недоступны. А запуск параллельной системы дает вам доступ к первоначальной версии файлов реестра, так что вы можете скорректировать или заменить их. Вы можете достичь того же результата, используя ERD Commander от Systems Internals по или NTFS-DOS от Winternals Software по . После загрузки альтернативной системы вы имеете возможность выполнить те же действия по восстановлению, что и при использовании программы установки и выборе опции восстановления, но с большей гибкостью и избирательностью. И хотя специалисты из Microsoft не рекомендуют применять данный способ, мы считаем, что он лучше всего подходит для опытных пользователей NT. Более подробная информация об использовании параллельно установленной системы находится во врезке "Параллельное мышление".

Прежде чем начать операцию восстановления, сделайте копии своих файлов реестра. Я обычно копирую существующие файлы в подкаталог каталога, содержащего файлы реестра (например, \%systemroot%\system32\config\backup). Только после этого можно начинать эксперименты с заменой отдельных файлов реестра. Однако вы не можете просто скопировать файлы, которыми будете заменять поврежденные, поскольку на дискете ERD и в каталоге \%systemroot%\repair эти файлы хранятся в сжатом виде. Перед использованием этих файлов примените к ним команду expand.exe, чтобы разархивировать их вручную. Например, чтобы развернуть сжатую копию ветви SYSTEM с дискеты ERD или из каталога \%systemroot%\repair, наберите в командной строке NT: Expand system._ system



Скопируйте получившийся файл в \%systemroot%\system32\config первоначальной системы и перезагрузитесь.

Если вы не хотите иметь дело со сжатыми файлами, можете использовать утилиту regback.exe из Microsoft Windows NT Server 4.0 Resource Kit для создания дополнительных копий реестра. Она создает копию, которая содержит все файлы реестра в несжатом виде. Кроме того, данная утилита копирует ветви SAM и SECURITY, так что вам не нужно будет помнить о необходимости указывать дополнительные переключатели. Однако здесь нужно учесть, что несжатые копии реестра могут не уместиться на трехдюймовую дискету. Безопасным местом для хранения копий реестра, созданных с помощью regback.exe, может служить раздел диска, отличный от загрузочного. Предпочтительно вообще хранить их на другом физическом диске. Для достижения максимальной защиты от аппаратных сбоев, которые могут сделать полученные копии файлов реестра недоступными, рекомендую хранить дополнительную копию реестра одного сервера на другом сервере и наоборот.

Редактор журнала Windows NT Magazine,

Журнал , #02/2000

Майкл Д. Рейли - Редактор журнала Windows NT Magazine, а также один из основателей и вице-президент компании Mount Vernon Data Systems, специализирующейся на консультационных услугах и разработке прикладных баз данных. Рейли имеет сертификаты системного инженера

Назначение и "сверхзадача" стандарта POSIX

Как следует из названия, POSIX (Portable Operating System Interface) - это стандарт на сопряжение (интерфейс) между операционной системой и прикладной программой. Времена, когда программисты писали программы для "голой" машины (реализуя собственные пакеты программ ввода/вывода, тригонометрических функций и т.п.), прошли безвозвратно. В тексте POSIX неоднократно подчеркивается, что стандарт не выдвигает никаких требований к деталям реализации операционной системы; его можно рассматривать как совокупность договоренностей между прикладными программистами и разработчиками операционных систем. Таким образом (опять же вопреки довольно распространенному мнению), POSIX представляет интерес не только для разработчиков операционных систем, но прежде всего для гораздо более многочисленной категории программистов - прикладных.

Потребность в стандарте такого рода была осознана еще в 1980-е годы, когда получили широкое распространение операционные системы UNIX. Оказалось, что хотя эта система и задумывалась как унифицированная, различия между конкретными ее реализациями приводили к тому, что прикладные программы, написанные для одной системы, далеко не всегда могли исполняться в другой. На решение именно этой проблемы, известной как проблема мобильности программного обеспечения, нацелен POSIX. Первая редакция стандарта была выпущена в 1988 году (имеется перевод, см. [2]), в которой все многообразие вопросов, связанных с мобильностью программ, было разбито на две части: (1) интерфейс прикладных программ, (2) командный интерпретатор и утилиты (интерфейс пользователя); эти части получили название POSIX.1 и POSIX.2 соответственно.

Уточним, что в данной статье речь пойдет только о стандарте на интерфейс прикладных программ, POSIX.1, вторая (и последняя к настоящему времени) редакция которого была утверждена 12 июля 1996 года.

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

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

Некоторые легко опровергаемые возражения против целей GNU

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

"Вы должны будете назначить цену за программу, чтобы оплатить обеспечение сопровождения."

Если люди охотнее заплатят за GNU плюс обслуживание вместо получения GNU бесплатно и без обслуживания, то компания по обеспечению только обслуживания тех, кто получил GNU бесплатно, может стать прибыльной.3

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

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

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

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

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

"Бесполезно рекламировать программу, которую люди могут получить бесплатно."

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

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

"Моей компания нужна собственная операционная система, чтобы получить преимущество в конкурентной борьбе."

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

Я хотел бы увидеть дальнейшее развитие GNU, поддерживаемое дарами от многих производителей и пользователей, это сократит затраты для каждого.5

"Разве программисты не заслуживают вознаграждения за свое творчество?"

Если уж что-то и заслуживает вознаграждения, так это общественный вклад.


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

"Может ли программист просить вознаграждение за свое творчество?"

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

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

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

"Не будут ли программисты голодать?"

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

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


По общему мнению --- все или ничего.

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

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

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

"Разве люди не имеют права контролировать, как используется их творение?"

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

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

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


Они не мешают большинству людей, которые используют запатентованные продукты.

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

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

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

"Конкуренция заставляет все делать лучше и лучше."

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


Если бегуны для начала ударятся в кулачный бой, то все они придут к финишу позже.

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

"Не прекратят ли все программировать без денежного вознаграждения?"

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

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

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

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

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



" Нам отчаянно нужны программисты. Если они потребуют, чтобы мы прекратили помогать нашим соседям, то мы должны будем подчиниться."

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

"Программистам как-то же надо зарабатывать на жизнь."

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

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

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

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

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

Все виды развития могут финансироваться с помощью налога на программный продукт:

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

Но если покупатель компьютера сделает пожертвование на развитие программного обеспечения сам, то он может получить кредит в уплату налога. Он может сделать денежное пожертвование на проект по своему выбору, причем выбор проекта часто объясняется тем, что он надеется воспользоваться его результатами.


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

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

Следствия:

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

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

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

Необязательный графический интерфейс

Включенный в состав Windows NT графический пользовательский интерфейс (Graphical User Interface, GUI) облегчает работу с компьютером и упрощает процесс обучения начинающих администраторов по сравнению с предыдущими сетевыми операционными системами типа NetWare версий 3.x и 2.x. Вместе с тем, GUI истощает ресурсы компьютера, занимая память и загружая своими задачами процессор, что ограничивает возможности серверных приложений. Поэтому порой мне хочется, чтобы 32-разрядная Windows NT, подобно DOS, запускалась бы только в режиме командной строки. Тогда при необходимости можно было бы подключать GUI для использования с инструментарием администратора и отключать его при выполнении стандартных серверных работ. Если графический интерфейс не занимает память и процессорные ресурсы, то они высвобождаются, и при этом повышаются скорость и устойчивость работы операционной системы. В результате сервер смог бы лучше справляться с ролью контроллера домена или сервера служб WINS, DNS, DHCP. Но, к сожалению, графический интерфейс Windows NT слишком тесно интегрирован с операционной системой.

В противоположность этому, графический интерфейс Linux не встроен в ядро. Соответственно, операционную систему можно загрузить в режиме командной строки, не подключая GUI. Это одно из важнейших преимуществ Linux, позволяющее запускать ее на компьютерах с минимальной конфигурацией. Например, компьютер со стомегагерцевым процессором Pentuim и 32 Мбайт оперативной памяти может отлично работать под Linux в качестве DNS- или Web-сервера.

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

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

Для загрузки Linux с графической оболочкой проще всего использовать программы инсталляции ее клонов Red Hat и Caldera. Однако сначала следует установить на дисплее максимально возможное разрешение. Графическая оболочка Red Hat - GNOME - содержит набор шрифтов, которые при разрешении 640_480 выглядят просто ужасно. Вполне подойдет разрешение 800_600, но чем оно больше, тем лучше. Мало, чтобы графическая оболочка нормально работала, потребуются значительные аппаратные ресурсы. Я бы порекомендовал как минимум Pentium II с 64 Мбайт памяти. Приходилось слышать утверждения, что Linux не так требовательна к возможностям оборудования, как Windows NT, но, это, вероятно, относится к другим вариантам GUI. (Конечно, можно запустить GNOME на стомегагерцевой системе с памятью объемом 32 Мбайт, как в случае Windows 2000, но я сомневаюсь, что кто-то получит удовольствие от такой работы.)

Нить и задача

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

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

Но псевдографика же соответствует Alt-кодировке, а не KOI-8?

В Internet принята кодировка KOI-8 - кодировка Unix и Acorn, кодировка

E-mail, FTP и Usenet (News). (WWW/HTTP, как правило, в многокодовой форме).

Поэтому обратимся к /etc/sysconfig для версий до 2.1.* или

/etc/rc.conf для версий, начиная с 2.2.*. Этот файл - всего

лишь запускаемый (исполняемый), да и не делает ничего, кроме определения

переменных, которые будут использоваться в /etc/rc и запускаемых

из него /etc/rc.* и /etc/netstart. Если интерсно, как именно:

grep имя_переменной /etc/sysconfig /etc/rc.* /etc/netstart

Ну да ладно, вернемся к проблеме русификации. В комментариях

к переменным написано много интересного, позволяющего разобраться,

что с этой переменной делать и какие значения она может принимать.

Вот так я настраиваю клавиатуру:

keymap="ru.koi8-r"

keyrate="fast"

keychange="NO"

cursor="blink"

Русификацию экрана можно провести двумя путями: загрузить шрифты KOI-8

или загрузить шрифты Alt и карту перекодировки. Разница в том, что символы

Alt-псевдографики отображаются видеоконтроллером с расширением на один

столбец вправо, из-за чего горизонтальные линии в KOI-8 получаются разрывными

(как будто использовались знаки равенства "="). Но а предпочел KOI-8:

scrnmap="NO"

font8x16="koi8-r-8x16"

font8x14="NO"

font8x8="NO"

blanktime="NO"

saver="NO"

Для того, чтобы эти изменения возымели действие, надо перезагрузить

систему. Опытный администратор часто может произвести настройку без этого,

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

reboot

Новые концепции

В Windows 2000 появились понятия "обычный диск" (basic disk) и "динамический диск" (dynamic disk). Под диском теперь понимается практически любой носитель, способный хранить информацию. Устройством (drive) и томом (volume) называются участки этих дисков. Обычными являются те жесткие диски, которые поддерживает дисковая подсистема Windows NT 4.0; по умолчанию все жесткие диски обычные. На обычных дисках могут располагаться простые тома, например основные разделы диска, дополнительные разделы и логические устройства. При модернизации Windows 2000 с предыдущих версий Windows NT в число обычных дисков попадут все тома с защитой от сбоев, такие, как тома с дублированием и дисковые массивы с чередованием и четностью. На обычных дисках нельзя создать новые многодисковые тома.

Но именно многодисковые тома очень важны. В основном для них и предназначена утилита Disk Management, поскольку иначе можно было бы обойтись более простыми средствами типа Fdisk. Многодисковые тома позволяют лучше манипулировать свободным пространством, комбинируя нераспределенное пространство на разных дисках (термином "нераспределенное пространство" в Windows 2000 обозначается не используемое и не поделенное между томами пространство на диске, т. е. то, что в Disk Administrator называлось свободным пространством. В Windows 2000 же свободным пространством называется любая часть дополнительного раздела, которая пока не подключена ни к какому логическому устройству). С помощью многодисковых томов можно повысить производительность, поскольку в операциях чтения и записи задействовано сразу несколько дисков. К тому же многодисковые тома позволяют применять RAID-технологию защиты данных от сбоев. Однако для использования многодисковых томов в Windows 2000 необходимо создать динамические диски, которые поддерживаются службой управления логическими дисками.

Для того чтобы обычный диск превратить в динамический, нужно щелкнуть правой кнопкой мыши на изображении диска в окне Disk Management и выбрать в контекстном меню команду Upgrade Dynamic Disk.
В появившемся списке можно выбрать один или несколько дисков, которые следует преобразовать в динамические, а затем нажать кнопку OK. Если на диске достаточно свободного места*, выполняется автоматическое конвертирование, после чего дисками можно пользоваться без перезагрузки системы.

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

Другим новшеством в Windows 2000 стало монтирование устройств. Утилита Disk Administrator Windows NT позволяла назначить тому букву латинского алфавита. Этот довольно простой метод дает возможность обратиться к любому дисковому устройству из стандартного меню открытия файла. Естественным ограничением на количество локальных и подключенных сетевых устройств было число 26, соответствующее числу букв латинского алфавита. Данное ограничение преодолевает монтирование устройств, ассоциирующее устройство с пустой папкой на локальном томе NTFS. Например, при монтировании нового основного раздела к папке D:\My Work Stuff все последующие обращения к этой папке будут автоматически переадресованы на соответствующий новый основной раздел, даже если он расположен на другом физическом диске, чем устройство D:. Если новый том является отказоустойчивым, то и папка D:\My Work Stuff считается отказоустойчивой, даже если само устройство D: этим качеством не обладает. Если диск содержит папки со смонтированными томами, при резервном копировании эти папки также автоматически включаются в процесс архивирования, если только их специально не исключить.


Один и тот же том при необходимости монтируется на несколько папок. Одновременно с монтированием ему также может быть присвоено обычное однобуквенное обозначение. Для монтирования необходима пустая папка на томе файловой системы NTFS, причем к одной папке можно монтировать только один том. Нельзя монтировать тома на устройства, доступные через сеть. Отличить в Windows Explorer папки с монтированными томами от обычных довольно легко - для их отображения применяется значок устройства. Итак, монтирование преодолевает ограничение на число устройств и может быть использовано для увеличения объема существующего тома, а также для создания отказоустойчивой папки на обычном томе.

ЭКРАН 2. Монтирование нового тома к пустой папке

При создании раздела, логического устройства, динамического диска и т.д. с помощью мастера Create Volume Wizard можно либо присвоить новому тому букву, либо смонтировать его на папку, либо вообще никак не идентифицировать его. При монтировании нового тома (см. Экран 2) можно ввести полный путь к папке для монтирования вручную либо выбрать подходящую папку с помощью кнопки Browse (см. Экран 3). Если же подходящей пустой папки для монтирования нет, ее можно создать с помощью кнопки New Folder.



ЭКРАН 3. Выбор папки для нового тома

Disk Management обеспечивает большую гибкость в именовании устройств и томов. Несмотря на то что мастер Create Volume Wizard предлагает выбрать один способ идентификации нового тома, с помощью Disk Management всегда можно присвоить ему новый символ или смонтировать на другую папку (см. Экран 4). Кнопка Add позволяет монтировать том на дополнительную папку, а кнопка Edit - откорректировать путь или сменить символ.



ЭКРАН 4. Присваивание новой буквы или папки для тома

О чем это я?

Этот опус не претендует на полноту описания. Более того, в целях

упрощения сознательно опущены некоторые подробности. Сначала цикл

задумывался как FAQ (ЧаВо - часто задаваемые вопросы), но видимо

получится "Курс молодого бойца" или "Сержантская школа".

Я попытался дать сравнительное описание разных операционных систем -

именно этого на мой взгляд не хватает большинству учебников и технических

пособий.

Не дожидаясь разоблачения со стороны опытных Unix'оидов, делаю

добровольное признание - я не могу претендовать на роль великого знатока

Unix, а мои знания в основном вокруг FreeBSD. Надеюсь, это не помешает.

Этот файл еще долго будет находиться в состоянии "under construction". :-)

О чем это вообще?

Это о пересылке (forwarding), маскарадинге (masquerading) и фильтрации IP-пакетов на Линуксе с ядрами 2.1.* и выше и, в частности, о программе ipchains. Ссылки на более подробные материалы смотри . В этой статье не рассматриваются вопросы маршрутизации, подробности работы протоколов семейства TCP/IP и проксирования, а также подробности настройки и конфигурирования ядер, сетевых интерфейсов и комплексной защиты от хакеров ;-)

Как известно, все коммуникации, использующие протокол IP, передают данные в виде пакетов. В начале каждого пакета есть заголовок, в котором написано, от кого и кому этот пакет (в виде IP-адресов), к какому протоколу более высокого уровня он относится (ICMP, TCP, UDP и т.п.), в некоторых случаях (для протоколов UDP и TCP) - номера портов отправителя и получателя, а также другая специфическая информация.

На пути от отправителя к получателю пакет может проходить через промежуточные узлы. В зависимости от информации, которая содержится в заголовке IP-пакета, они могут этот пакет переслать на следующий узел (forward), передать локальной программе для обработки, уничтожить (deny), отвергнуть, т.е. уничтожить и отправить об этом уведомление отправителю (reject). Выбор и осуществление одного из этих действий и называется фильтрацией пакетов.

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

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

Маскарадинг - это подмена некоторых параметров в заголовках IP-пакетов, позволяющая машинам, не имеющим реальных IP-адресов, практически полноценно работать в интернете.

Прозрачное проксирование (transparent proxying) - это переадресация пакетов на другой порт машины. Обычно используется для того, чтобы заставить пользователей из локальной сети пользоваться местным proxy-сервером без дополнительного конфигурирования их клиентских программ.

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

О семантике

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

Как передать смысл при переводе

Прежде всего, нужно напомнить, что стандарт POSIX изложен на английском языке, который по своей природе провоцирует двусмысленности (например, одно и то же слово может быть существительным, прилагательным и глаголом), и "семантические ловушки" подстерегают чуть ли не на каждой странице. Хорошей иллюстрацией сказанному служит пример из художественной литературы. Одно из самых известных произведений Оскара Уайльда, который блестяще пользовался этой особенностью английского языка, - The Importance of being Earnest - известно на русском под названием "Как важно быть серьезным". Однако английское название имеет второй смысл: Earnest (серьезный) - фамилия одного из персонажей, и название можно было бы перевести иначе: "Как важно быть Эрнстом". Есть русская фамилия Серебряный, и если бы была фамилия Серьезный, перевод был бы идеально точным, с передачей обоих смыслов.

Аналогично обстоит дело с самим названием стандарта: Portable Operating System Interface. Прилагательное Portable (мобильный) относится и к операционной системе, и к прикладной программе, но выразить это так же коротко по-русски не удается, можно перевести как "Интерфейс мобильной операционной системы" или "Интерфейс операционной системы, обеспечивающий мобильность прикладных программ". Второй вариант лучше отражает намерения разработчиков стандарта, но при этом теряется первый смыл (при переводе был сохранен более привычный первый вариант).

Семантика слова "стандарт"

Основной текст стандарта предваряется преамбулой, в которой разъясняется смысл слов IEEE Standards. Как следует из этих разъяснений, существует по крайней мере три смысловых отличия от русскоязычного термина ГОСТ:

Интуитивно считается, что ГОСТ имеет силу закона, нарушение которого преследуется; POSIX - совокупность требований, следование которым - дело исключительно добровольное.

ГОСТ действует вплоть до отмены (многим, наверное, приходилось слышать выражение "ГОСТ никто не отменял"); в преамбуле к POSIX говорится, что если стандарт не пересматривался в течение 5 лет, это означает, что рассматриваемые в нем вопросы, скорее всего, потеряли актуальность, и его можно считать отмененным автоматически;

ГОСТ анонимен; во вводной части POSIX приводится список тех лиц, которые участвовали в разработке этого стандарта, а также дается адрес, по которому можно направлять запросы по интерпретации; говорится также, что ответ на каждый запрос подвергается процедуре согласования (иными словами, авторы стандарта договариваются между собой, прежде чем дать ответ).

Таким образом, перевод даже такого общеизвестного слова как Standard словом "стандарт" требует комментариев.

Семантика слов "должен", "не специфицировано", "не определено", "определяется реализацией"

Раздел 2 стандарта называется "Терминология и общие требования". В нем содержатся определения не только специальных терминов (вроде "процесс" или "семафор"), но и таких, казалось бы, самоочевидных слов, как "должен" или "может". Поскольку POSIX.1 - стандарт на интерфейс, то его требования относятся как к операционной системе, так и к прикладной программе. Явное требование выражается словом "должен" (shall), например: "В случае успешного завершения функция link() должна возвращать нулевое значение". В данном примере речь идет о требовании к операционной системе: функция link() должна быть реализована так, чтобы при успешном завершении возвращала нулевое значение.

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


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

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

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

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

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



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

Вот еще один пример: "В случае успешного завершения функция read() должна возвратить целое число, обозначающее количество фактически прочитанных байт. В противном случае функция должна присвоить переменной errno код ошибки и возвратить -1, причем содержимое буфера, на который указывает аргумент buf, не определено."

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

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

Семантика умолчания

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


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

Процессы и потоки управления

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

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

Нужно подчеркнуть, что идея многопоточности реализована во многих операционных системах реального времени, и реализована по-разному в том смысле, что каждому потоку управления соответствуют разные множества атрибутов и интерфейсных функций; иногда вместо термина "поток управления" (thread) используется термин "задача" (task).Для того чтобы избежать недоразумений, в стандарте подчеркивается, что речь в нем идет исключительно о потоках управления POSIX, а названия соответствующих интерфейсных функций имеют префикс pthread_ (например, pthread_create(), pthread_join() и т.д.).

О сигналах

Постойте, но ведь приглашение командного интерпретатора появилось и тогда, когда мы нажали <Ctrl>+Z, хотя программы не заканчивали работу, и, следовательно, вызов wait* не мог вернуть управление! Выдача сообщения Stopped (процесс остановлен) и затем приглашения к вводу была реакцией на сигнал CHLD, который ядро посылает при нажатии <Ctrl>+Z предкам - в данном случае одному предку - процессов, работающих с терминалом (сами процессы получают свой сигнал).

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

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

Работа с нитями требует особой техники, поскольку одни сигналы должны "доводиться до сведения" всех нитей, а другие - посылаться индивидуально. В Linux 2.2 это делалось путем довольно хитрых манипуляций со специальной нитью, единственным назначением которой было управление другими нитями. В версии 2.4 ядро может следить за нитями за счет нового флага CLONE_PARENT (таким образом, если одна нить породит другую и закончит работу, то порожденная нить не останется "сиротой") и нескольких специальных правил доставки сигналов, так что надобность в специальной нити отпала.

О стандартах вообще

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

они изначально бессмысленны, так как их авторы не пишут компьютерных программ;

они сковывают инициативу программистов;

программисты всегда договорятся и без стандартов.

Может быть, на это мнение не следовало бы обращать внимания, если бы не два обстоятельства:

его высказывают практики, то есть именно те, кто "выдает программную продукцию";

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

Слово "стандарт" ассоциируется обычно с чем-то материальным (стандартные габариты, стандартное электрическое напряжение и т.д.), в то время как компьютерная программа - объект нематериальный ("The new intangible"), и может быть, стандарты в нематериальной сфере действительно бессмысленны?

Существует, однако, опровергающий пример. Совокупность правил орфографии русского языка по существу представляет собой стандарт, хотя и не утвержденный органами стандартизации. Далее, кроме правил (или, если угодно, требований) орфографии, существуют синтаксические правила и, самое главное, семантика. Последнее хорошо иллюстрирует "детский" вопрос: почему кошку называют кошкой? На этот вопрос существует точный ответ: потому, что наши предки так договорились; предки англичан договорились называть этого же зверя cat, предки немцев - kitten, и т.д. И вообще, смысл, или семантика, или правила интерпретации любого слова или сочетания слов - вопрос договоренности.

О статье

Статья эта развивалась долго и нудно. Первая версия появилась на linux.ru.net и составляла только первую часть этого труда. Но время шло, знаний прибавлялось и захотелось прололжения. Систематизировать свои знания так интересно. Присоединяйтесь.

ОБ АВТОРАХ

Скотт Спэнбауэр и Стэн Мястковски - редакторы и авторы PC World. В работе над статьей принимал участие также штатный редактор Эрик Дал.

Основы перехода на Windows 2000

Хотя Windows 2000 Professional - сложная система, переход на нее на удивление легок, поскольку эта процедура в большой степени автоматизирована. Проще всего осуществить полную модернизацию, при которой Windows 2000 "затирает" предыдущую ОС, но и провести "чистую" инсталляцию, оставив на машине Windows 95, Windows 98 или Windows NT, труднее не намного.

И все же перед тем, как засунуть в дисковод CD-ROM с Windows 2000, нужно проделать кое-какую подготовительную работу.

1 Сделайте полную копию системы. Вы собрались произвести на своем ПК серьезные изменения. Поэтому обеспечьте себе возможность вернуться, если что-то пойдет не так во время инсталляции (например, отключится электропитание) или после нее (например, обнаружатся серьезные проблемы с совместимостью). Кроме того, вы можете потерять все файлы, находящиеся в Корзине, поэтому проверьте, нет ли там чего-нибудь нужного. Мы копировали и восстанавливали имевшиеся на компьютерах системы Windows 98 и Windows NT 4.0 с помощью утилиты Drive Image компании PowerQuest. Неплохо также подготовить загрузочную дискету Windows с драйвером CD-ROM.

Можно установить Windows 2000 как поверх существующей версии Windows, так и наряду с ней

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

2 Выберите модернизацию или "чистую" инсталляцию. Запустите имеющуюся у вас версию Windows и вставьте в дисковод CD-ROM диск Windows 2000 upgrade. Мастер установки запустится автоматически. Сразу же после начала инсталляции вы окажетесь перед решающим выбором: нужно будет указать, следует ли заменить нынешнюю версию Windows или выполнить "чистую" инсталляцию.
Прочтите раздел "Какой путь избрать?" - он поможет вам определить наиболее приемлемый способ.

3 Установите пакеты корректировки (если требуется). В NT 4.0 до установки Windows 2000 необходимо установить пакет корректировки Service Pack 4 (или более позднюю версию). Убедитесь, что это сделано (и скопируйте систему).

Планируете сконфигурировать двухвариантную загрузку с Windows 2000 и 95 или 98? Тогда хорошенько подумайте, прежде чем выбирать NTFS

Пакет корректировки нужен для двухвариантной загрузки NT и Windows 2000. Инсталляционная программа Windows 2000 независимо от типа установки проверяет все локальные жесткие диски компьютера и преобразует разделы с файловой системой NTFS в NTFS5. А поскольку исходные версии Windows NT 4.0 не способны читать разделы NTFS5, существующая установка NT может быть погублена. (Согласно описанию, Windows 2000 должна выдать предупреждение перед преобразованием, но Release Candidate 3 подобных сигналов ни разу не подала.) Пакет Service Pack 4 и более поздние (самый последний SP6) обеспечивают в NT 4.0 возможность чтения разделов NTFS5, что позволяет работать попеременно с NT и с Windows 2000. Так что если вы хотите после установки Windows 2000 снова загрузить раздел NT 4.0, проверьте, на месте ли пакет корректировки.

4 Решите вопрос об NTFS. У NTFS - основной файловой системы Windows 2000 Professional - есть ряд преимуществ перед старой FAT, применяемой в Windows 9x. Она обеспечивает более эффективное использование дискового пространства и лучшую защиту информации. Поэтому NTFS будет разумным выбором, если старая система уничтожается, а также при "чистой" установке Windows 2000 на машину с NT. Но в случае "чистой" установки, предполагающей двухвариантную загрузку Windows 2000 и Windows 9x, для NTFS нужно отвести особый раздел диска, который не будет распознаваться системой Windows 9x.

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


Если вы следовали предыдущим указаниям, на этой стадии вас вряд ли будет ожидать много сюрпризов. Заметим, что если вы инсталлируете Windows 2000 поверх Windows 95 или 98 (а не выполняете "чистую" инсталляцию, сохраняя другую ОС), в отчете скорее всего будет указано, что некоторые записи файлов autoexec.bat и config.sys несовместимы с Windows 2000. Обычно это не повод для беспокойства.



С этого места инсталляция идет автоматически. Неплохое время для перерыва и чашечки кофе

6 Откиньтесь на спинку кресла. Если вы уничтожаете предыдущую ОС, процедура становится практически автоматической, хотя может продлиться час или больше. Программа установки несколько раз перезапустит компьютер, скопирует все необходимые файлы и перенесет в Windows 2000 настройки и программы из предыдущей версии Windows. В течение длительных периодов времени (по 5-10 минут) машина (включая жесткий диск) не будет подавать признаков жизни. Не пугайтесь: процесс идет.



"Чистая" инсталляция требует чуть больше усилий, чем установка поверх старой версии Windows

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



Это диалоговое окно сигнализирует, что установка закончена и новая ОС готова принять первого пользователя

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

Стэн Мястковски

Об авторе

Криста Андерсон - независимый автор и консультант, редактор журнала Windows NT Magazine. Ее последняя книга, вышедшая в издательстве Sybex, - Mastering Local Area Networks. С автором можно связаться по адресу .

ОТ ПЕРЕВОДЧИКА: читателю может быть также полезна статья о принципах построения современных RAID-массивов по адресу: ]

* Для преобразования раздела или диска в динамический диск необходим как минимум 1 Мбайт свободного пространства (в терминологии Windows 2000). Этот мегабайт используется системой для хранения метаданных, описывающих динамический диск. - Прим. ред.

Валерий Коржов - обозреватель еженедельника ComputerWorld Russia.

Контактный телефон: (095) 253-92-06, e-mail: .

Алексей Черемисин и Олег Кобызев - менеджеры компании "РТСофт". С ними можно связаться по электронной почте по адресам и соответственно.

Шон Дейли - сертифицированный инженер Microsoft и президент iNTellinet Solutions - интеграторской и консалтинговой компании, занимающейся вопросами сетей. Дейли ведет рубрику в журнале Windows NT Magazine и является автором книг Optimazing Windows NT (IDG Books) и Migrating to Windows NT 4.0 (29th Street Press). С ним можно связаться по адресу .

Шон Дейли - один из редакторов журнала Windows NT Magazine и президент компании iNTellinet Solutions, занимающейся консалтингом и сетевой интеграцией. Имеет звание MCSE. Последней из его книг была Optimizing Windows NT, выпущенная издательством IDG Books. С ним можно связаться по адресу электронной почты

Сергей Романюк - старший научный сотрудник Научно-исследовательского института системных исследований, руководитель группы переводчиков стандарта POSIX. С ним можно связаться по электронной почте по адресу:

Следует добавить, что работа над стандартом продолжается в течение многих лет; выявляются новые вопросы, и они либо включаются в одну из имеющихся частей, либо оформляются в виде отдельной части, которая впоследствии может быть аннулирована. Так произошло, например, с интерфейсными средствами реального времени, которые вначале были объявлены как POSIX.4, а впоследствии включены в POSIX.1.

IEEE - организация, в которой разработан стандарт POSIX.

Здесь "умолчание" означает silent, а не default; речь идет не о каких-то подразумеваемых значениях, которые на самом деле декларированы, а об отcутствии упоминаний вообще.

Перевод стандарта на русский язык будет опубликован в начале 2000 года.

Об офисных комплектах под Linux

Эталоном за последние годы стал основоположник принципа их комплектования - Microsoft Office. Изрядно потеснивший офисные наборы Corel (бывший WordPerfect) и Lotus (ныне фракция IBM). А в нашей стране о существовании чего-либо отличного от MS Office забыли даже те, кто никогда о них не знал.

И так, если считать MS Office за образец офисного комплекта, рядом с ним можно поставить три столпа (или три ножки) Linux-конторы: ApplixWare, StarOffice и KOffice.

Кроме того, для Linux есть еще несколько бесплатных офисных набора. Это, например, Siag и его модификация под KDE - KSiag, основой которых является одноименная электронная таблица, дополненная текстовым процессором и презентационной программой; AndrewSuite - как можно понять из описания, примерно аналог Siag; в эмбриональном виде существует офисный комплект для GNOME, из которого в более-менее завершенном виде доступны текстовый процессор Go и табличный - Gnumeric. Однако все это - облегченные комплекты, не являющиеся функциональными аналогами большой тройки для Windows.

ApplixWare - продукт коммерческий, и достаточно дорогой (где-то под две сотни ихних денег). А поскольку сохранность кошелька вкупе с чистотой совести - один из серьезных аргументов в пользу Linux, говорить о нем не буду.

KOffice, напротив, распространяется бесплатно и в исходных текстах. И по замыслу должен являться полнофункциональным пакетом, включающим, помимо обязательных текстового процессора (KWord) и электронной таблицы (KSpread), также презентационный пакет, СУБД, редакторы формул и диаграмм, векторный и даже растровый графические редакторы, Однако состояние этого пакета весьма далеко от завершения. В настоящее время с дистрибутивами Linux распространяется только Killustrator (векторный редактор на уровне третьего CorelDraw). Прочие же компоненты находятся на различных стадиях бета- и альфа-тестирования. Поэтому говорить о KOffice как о некоей конторской целостности - рано.

StarOffice занимает как бы промежуточное положение, будучи бесплатным для некоммерческого использования (хотя и не является Open Source).
И доведенность его - значительно выше, чем KOffice. Хотя пределов совершенства и не достиг. Интересно, доведет ли его до ума нынешний хозяин (Sun), или, превратив в придаток к Java-машине, угробит окончательно (подобно тому, как IBM угробило Lotus SmartSuite, превратив в придаток к Notes)...

О StarOffice в последнее время написано немало (например: Никита Кожекин. Звездный путь пакета StarOffece. Мир ПК, #2, 1999, с. 40-46; Алексей Выскубов. StarOffice 5.0. Byte/Россия, # 3, 1999, с. 85-88). Однако все же рассмотрим StarOffice в сравнении с продуктом Microsoft. Тем более что производители и позиционируют его как альтернативу последнему.

Должен предупредить, что все сказанное ниже - не более, чем своего рода путевые заметки: я пошел туда-то и увидел то-то. Иной, вероятно, сделает что-то иное, и результат, соответсвенно, будет другим. Но ведь таким методом (именуемым в науке ползучим эмпиризмом) тоже можно приблизиться к истине, не так ли?

Пакет доступен для бесплатного скачивания на сайте бывшей StarDivision и множестве зеркал. В чем следует усматривать благотворное влияние Sun - раньше он был только на собственном, крайне перегруженном, сервере, и скачать его (60-80 мегабайт, в зависимости от реализации), было непросто. К тому же ныне искоренили и крайне зловредную систему регистрации, проходившей в два этапа (до начала скачивания и при первом запуске) и возможной только on line. Ныне достаточно заполнить простенькую форму и придумать себе идентификатор и пароль.

Помимо версии для Linux, существуют также версии для Windows и OS/2. Относительно последней - не знаю, а первая и внешне, и функционально идентична Линуксовой.

StaOffice для Linux (текущая версия - 5.1a) - tar,gz-архив объемом более 60 мегабайт. Установка StaOffice возможна в трех режимах - администраторском, пользовательском и администраторском для нескольких пользователей. И в любом варианте проблем, как будто, не вызывает, если в системе имеются все необходимые библиотеки (а они имеются во всех современных дистрибутивах Linux).


Сначала архив распаковывается в промежуточный каталог, затем ( желательно после прочтения документации) запускается инсталляционный скрипт (именуемый по микрософтовской традиции setup). После этого предлагается выбрать вариант инсталляции - типичный, минимальный и заказной. Предпочтителен - последний: во первых, можно избавиться от ненужного, во вторых - включить интеграцию с KDE, если таковая имеется. Затем после довольно долгого шелестения винчестера вы обнаруживаете в определенной вами же точке монтирования каталог под названием StarOffice51 (в отличие от многих других, StarOffice не раскидывает свои файлы по ветвям необъятного древа каталогов). Все, можно работать.

Это относилось к инсталляции пользователем. Административный вариант ничем не отличается, а многопользовательский (проводимый, естественно, root'ом) - проводится с ключем /net; после чего каждый желающий инсталлирует себе в домашний каталог минимально необходимые компоненты путем выбора инсталляции из сети.

Установив StarOffice, можно его и запустить, после чего на весь экран нахально распахивается окно Desktop-менеджера (рис. 1). Сделать которое поскромнее - не удается, можно только свернуть. И при каждом переключении оно настойчиво лезет на первый план. Впрочем, кому-то это может и понравиться. Степень интеграции - непревзойденная, в сущности, отдельные приложения как таковые не открываются, а открываются (или создаются) типы документов.

Рис. 1. StarOffice

Тем не менее отдельные приложения все же можно вычленить. Это текстовый процессор, электронная таблица, векторная рисовалка и презентационный пакет, а также настольная СУБД. Есть также почтовая программа и что-то вроде органайзера, но их я не рассматривал за ненадобностью.

Центральное место, безусловно, занимает текстовый процессор, именуемый

Об офисных комплектах вообще

Такой набор пакетов (дополняемый всякими иными компонентами, типа верстальных программ или web-редакторов), утвердился для Большой Тройки конторского Windows - MS Office, Corel WordPerfect Office и Lotus SmartSuite. На кого он ориентирован - сказать трудно. Вряд ли человек, использующий все изобилие форматирующих средств современного текстового процессора, нуждается в инженерных и финансовых функциях электронных таблиц, а бухгалтер, сводящий в последних годовые отчеты - пишет что-нибудь сложнее докладной записки. И ни тот, ни другой не делают презентаций и не занимаются разработкой баз данных, даже для себя лично.

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

Объекты стандартизации и структура стандарта

Если говорить кратко, то объектами стандартизации POSIX.1 являются имена и семантика. Более конкретно, речь идет о следующем.

Имена интерфейсных функций. Стандартизовано 357 функций, причем 107 функций взяты из стандартных Си-библиотек (математические, обработка строк, ввод/вывод и др.); эти функции считаются частью стандарта POSIX.1, однако их полное описание содержится в стандарте на язык программирования Си [3].

Имена системных типов данных. Эти имена имеют суффикс _t.

Имена заголовочных файлов, а также минимальный состав этих файлов.

Имена общесистемных глобальных переменных (например, errno).

Символьные имена кодов ошибок, которые могут быть установлены при отработке функций. Эти имена начинаются с буквы E (EPERM, ENOTEMPTY и т.д.).

Имена конфигурационных констант. Эти имена имеют префикс _POSIX_.

Символьные имена номеров сигналов; эти имена имеют префикс SIG. В дополнение к 20 "традиционным" сигналам (SIGABRT, SIGALRM и др.) стандартизированы сигналы реального времени, номера которых должны занимать некоторый сплошной диапазон от SIGRTMIN до SIGRTMAX включительно, содержащий не менее RTSIG_MAX номеров.

Символьные имена, соответствующие значениям отдельных аргументов некоторых функций (например, аргумент cmd функции fcntl() может принимать значения F_DUPFD, F_GETFD, F_GETLK и т.д.).

Имена макросов, констант, битовых флагов, переменных окружения.

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

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

Представление о том, какие именно виды услуг операционной системы охватываются стандартом, дает врезка "Краткое содержание разделов стандарта".

Обеспечение надежного IPC

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

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

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

Если бы меня спросили, как

Если бы меня спросили, как до предела увеличить скорость работы Windows NT Workstation 4.0, я бы ответила так: выгрузите оболочку Explorer и работайте только с командной строкой, не запуская надоевшие графические приложения, - и Windows NT Workstation 4.0 понесется вскачь. Такой подход, который я называю "методика запрета излишеств", широко распространен среди поклонников UNIX, полагающих, и иногда справедливо, что графические приложения замедляют работу системы. Однако независимо от того, насколько быстро функционирует ядро операционной системы, Windows NT Workstation 4.0 все-таки работает в графической среде и запускает графические приложения. Поэтому в большинстве случаев отключить оболочку Windows Explorer, не жертвуя функциональностью, нельзя.

Исходя из этого, предлагаю подойти к проблемам оценки и настройки скорости работы приложений Windows NT Workstation 4.0 с другой стороны и попытаться получить от операционной системы максимум производительности иным способом. Так, для выявления ресурсоемких приложений можно использовать счетчики Performance Monitor, а также прибегнуть к помощи ряда утилит из Resource Kit, позволяющих оценить уровень производительности.

Обработка сообщений демоном syslogd

Все сообщения, формируемые отдельными программами с помощью функции syslog, отправляются через сокет /dev/log системному демону syslogd. Надо сказать, что вообще-то в системе запускаются два демона протоколирования: syslogd и klogd, входящие в состав пакета sysklogd (). Демон klogd отвечает за протоколирование событий, происходящих в ядре системы. Ядро не может использовать стандартную функцию syslog - стандартные библиотеки предназначены для использования только обычными приложениями, а поскольку ядро тоже нуждается в аналогичных функциях, в него включены свои библиотеки, недоступные приложениям, поэтому ядро использует свой собственный механизм генерации сообщений.

Обработка сообщений демоном syslogd состоит в том, что он постоянно отслеживает появление сообщений и сравнивает каждую пришедшую запись с правилами, которые находятся в файле /etc/syslog.conf и записываются в виде строки, состоящей из двух полей. Левое поле () задает один или несколько шаблонов, по которым отбираются сообщения. Правое () определяет порядок обработки отобранных сообщений. Каждый шаблон в поле имеет вид . Значениями поля может служить одно из условных наименований категорий, несколько таких наименований или символ (все категории). Значениями поля может служить одно из условных наименований уровня, символ (все сообщения данной категории, независимо от уровня) или слово none (не записывать сообщения данной категории).

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

имя файла протокола; название именованного канала (FIFO); указание на терминал или консоль (как на устройство: /dev/tty1); указание на удаленный хост; список пользователей, на терминалы которых будет послано сообщение по данному правилу.

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

Кроме строк с правилами в файле /etc/syslog.conf, могут содержаться пустые строки и строки комментариев. Подробнее о структуре файла /etc/syslog.conf можно прочитать на man-страничке syslog.conf.

Если сообщение соответствует шаблонам двух или более строк, оно будет обрабатываться по каждому из этих правил. Кроме того, если в поле перечислены несколько пар , то последующие пары могут отменить действие предыдущих. Пример такой отмены дан на рис. 1 - в файл /var/log/messages записываются все сообщения, уровень которых равен или выше info, однако при этом пропускаются (не записываются) сообщения категорий mail, authpriv и cron.

# Выдавать все сообщения от ядра на консоль. #kern.* /dev/console # Записывать в протокол все сообщения уровня info или выше, # кроме сообщений почтовой системы, содержащих конфиденциальную # информацию аутентификационных сообщений и сообщений демона cron. *.info;mail.none;authpriv.none;cron.none /var/log/messages # Записывать в отдельный файл сообщения, содержащие конфиденциальную # информацию аутентификации, независимо от их уровня. authpriv.* /var/log/secure # Все сообщения почтовой системы тоже записывать отдельно. mail.* /var/log/maillog # Протоколировать действия демона cron. cron.* /var/log/cron # Сообщения о чрезвычайных ситуациях должны немедленно # получить все пользователи системы *.emerg * # Сообщения от служб новостей уровня crit и выше записывать в отдельный файл. uucp,news.crit /var/log/spooler # Сообщения, выдаваемые на этапе загрузки, копировать в файл boot.log local7.* /var/log/boot.log

Рис. 1. Пример файла /etc/syslog.conf для Red Hat Linux 7.1

Из рис. 1 видно, что большинство сообщений просто записывается в различные файлы протоколов, расположенные в каталоге /var/log или его подкаталогах, причем основным файлом системного протокола в Red Hat Linux является файл /var/log/messages.В него не попадают только сообщения категорий mail, authpriv и cron (для которых выделены отдельные файлы).

Односерверные операционные системы

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

Одним из примеров этой технологии является ОС Berkeley UNIX поверх Mach (переименованная в Darwin компанией Apple), которая является основой системы Apple Mac OS X [28]. Однако в этой системе UNIX выполняется в ядре, что делает его просто иначе структурированным монолитным ядром. Второй пример – ОС MkLinux, в которой Linux выполняется в единственном пользовательском процессе поверх Mach. Третий пример – L4-Linux, в которой полный вариант Linux выполняется поверх L4 [15]. В последней из перечисленных систем пользовательские процессы получают сервисы операционной системы путем вызова удаленных процедур в сервере Linux с использованием механизма IPC L4. Измерения показывают падение производительности по сравнению с обычной ОС Linux на 5-10%, что очень близко к нашим наблюдениям. Однако единственная строка с ошибочным кодом в драйвере Linux может привести к фатальному сбою всей операционной системы, так что единственным преимуществом этой архитектуры с точки зрения надежности является более быстрая загрузка.

Ограничение функциональных возможностей драйвера

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

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

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

Ограничение IPC

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

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

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

Ограничение злоупотреблений переполнениями буферов

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

Кроме того, в нашей системе выполняется только код, расположенный в сегментах текста, которые доступны только по чтению. Хотя это не предотвращает возможность переполнений буферов, усложняется возможность злоупотребления, поскольку избыточные данные, находящиеся в стеке или куче, невозможно выполнить как код. Этот защитный механизм является исключительно важным, поскольку он предотвращает заражение вирусами и червями и выполнение их собственного кода. Сценарий наихудшего случая изменяется от взятия непосредственного управления до перезаписи адреса возврата в стеке и выполнения некоторой существующей библиотечной процедуры. Наиболее известный пример такой ситуации часто называют атакой путем «возврата в libc» («return-to-libc»), и этот способ атаки считается гораздо более сложным, чем выполнение кода в стеке или куче.

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

Оконная среда KDE

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

Внешне (рис. 1) KDE имеет нечто общее с Windows 9x или оболочкой OS/2. Хотя спутать ее с обеими - невозможно. Это, с одной стороны, обеспечивает чувство смутного знакомства (и не обескураживает, как экзотика, скажем, Enligtenment'а), с другой - будит здоровое любопытсво, не вызывая скуки, появляющейся при взгляде на, к примеру, fvwm2 (не для того же, в самом деле, мы ставили X-Window, чтобы лицезреть великую кнопку Start).

Рис. 1. Оконная среда KDE, файловый менеджер kfm (на заднем плане) и встроенный в него браузер (на переднем плане)

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

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

Кроме того, в комплекте имеется набор тем рабочего стола; некоторые - весьма симатичны. Разумеется, в качестве обоев можно использовать и свои картинки (в любом из обычных растровых форматов).

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

Операции с маскарадингом:

Для работы с маскарадингом используется команда '-M' (masquerade), которая может сочетаться с '-L' (list) для просмотра текущих установок маскарадинга, и с '-S' (set) для установки параметров.

'-L' может использоваться со своими флагами '-n', '-v', '-x'.

После '-S' должны следовать три параметра, задающие таймауты в секундах, соответственно, для TCP-сеансов, для TCP-сеансов после FIN-пакета, и для UDP-пакетов. Если вы не хотите менять значение какого-то параметра, укажите для него значение 0. Наиболее часто приходится менять первый из этих параметров для нормальной работы FTP.

Операторы управления

Простейшие операторы

exit	завершить выполнение программы;
next	перейти к следующей строке, управление на начало awk-программы;
break	выход из цикла;
continue	переход к следующей итерации;

Ошибки

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

Пользователи то и дело находят все новые и новые ошибки, а Microsoft реагирует на их "открытия" выпуском соответствующих "заплаток". Использование программных "заплаток" - единственный способ защититься от ошибок в программном коде операционной системы и вызванной ими уязвимости системы безопасности. Тем, кто хочет быть в курсе последних новостей в этой области, советую подписаться на бюллетень по адресу: http://www.microsoft.com/security.

Основные достоинства продукта DG/UX B2 Security Option

Предназначен для коммерческого использования в реальных производственных условиях

Для работы с большинством имеющихся в наличии коммерческих приложений не требуется их модификация Совместимость с операционной системой DG/UX на уровне машинных кодов и на уровне носителей Возможность создания защищенных областей (containment areas) для приложений и данных, поддержка жесткого разделения для обслуживания некоторых задач бизнеса Наличие средств и механизмов, позволяющих непосредственно настраивать DG/UX B2 Security Option в соответствии с существующей корпоративной стратегией защиты

Определяемая пользователем стратегия защиты

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

Конфигурирование административных ролей

Практически исчезает риск нанести ущерб при ошибке или неправильном действии администратора Возможность передачи полномочий от предприятия Привилегированные права ограничены определенными ролями Отказ от роли супервизора в UNIX Эффективное (по затратам) управление ресурсами IT

Множество функций на одном сервере

Фильтрация Внутренний web-сервер для поддержки корпоративного Intranet Внешний web-сервер

Модульная контролирующая подсистема

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

Контроль за доступом ориентирован на деловые потребности

Наличие средств дискреционного контроля за доступом (discretionary access controls - DAC) UNIX и POSIX Наличие средств обязательного контроля за доступом (mandatory access controls - MAC), которые позволяют жестко ограничить доступ к конфиденциальной информации (например к файлам, содержащим платежные ведомости) Наличие средства контроля возможности доступа (capability access control - CAC), позволяющего скрыть конфиденциальную информацию от всех любопытных глаз, включая даже работающих по выходным операторов.

Защищенные области

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

Сеансовый Монитор (программный продукт для текущего контроля сеанса)

Текущий контроль осуществляется с помощью сервисных средств (т.е. никоим образом не ограничивает пользователя, не требует дополнительных рутинных действий) Контроль доступа к системе осуществляется с помощью специального механизма идентификации и санкционирования на основе таких факторов, как время и сетевая локализация пользователя Засекреченные пароли (shadowed passwords) Интеграция дополнительных методов идентификации поддерживается без модификации программного продукта

Иерархическая организация блоков информации (Information Hierarchy Regions)

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

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

Защита от проникновения и распространения вирусных имплантантов или других форм повреждения Нет необходимости использовать дорогостоящие методы обнаружения и уничтожения вирусов постфактум, т.к. заражения системы не происходит

Средства надежной и безопасной передачи данных по сети

Контроль за тем, чтобы атрибуты секретности, присвоенные информации, оставались неизменными везде внутри организации Взаимодействие с гетерогенными и распределенными средами IT Поддержка расширений Межсетевого Протокола (Internet Protocol), соответствующих промышленному стандарту

Продукт аттестован Американским Национальным Центром Безопасности Вычислительных Систем (U.S. National Computer Security Center - NCSC)

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

DG/UX B2 Security Option является нераздельной частью комплекта продуктов CYBERSHIELD, обеспечивающего безопасность Internet/Intranet-серверов. Комплект CYBERSHIELD направлен на решение проблем, которые представляют угрозу безопасности организаций, желающих использовать Internet/Intranet-серверы.

Комплект CYBERSHIELD - это комплексное решение, обеспечивающее защиту Internet/Intranet-серверов. Базой для использования CYBERSHIELD являются мощные серверы AViiON, которые могут быть оборудованы подсистемами дисковых массивов CLARION RAID. Это оборудование снабжено продуктом DG/UX Security Option и программным обеспечением для Internet/Intranet компании BDM International, что формирует одну из самых защищенных на сегодняшний день серверных платформ для Internet/Intranet.

Основные опасности и их оценка экспертами

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

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

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

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

Недобросовестные пользователи могут использовать Internet, чтобы легко и быстро распространять самые изощренные вирусы.

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

DG/UX B2 Security Option предоставляет средства управления, необходимые деловым пользователям для организации информационных потоков внутри учреждений таким образом, чтобы передача информация происходила только санкционировано.

Основные понятия Unix

Unix базируется на двух основных понятиях: "процесс" и "файл". Процессы

являют собой динамическую сторону системы, это субьекты; а файлы -

статическую, это обьекты действия процессов. Почти весь интерфейс

взаимодействия процессов с ядром и друг с другом выглядит как запись/чтение

файлов. /* Хотя надо добавить такие вещи, как сигналы, разделяемая память

и семафоры. */

Процессы нельзя путать с программами - одна программа (как правило с различными

данными) может выполняться в разных процессах. Процессы можно весьма условно

разделить на два типа - задачи и демоны. Задача - это процесс, который

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

Демон ждет событий, которые он должен обработать, обрабатывает произошедшие

события и снова ждет; завершается он как правило по приказу другого процесса,

чаще всего его убивает пользователь, дав команду "kill номер_процесса".

/* В этом смысле получается, что интерактивная задача, обрабатывающая

ввод пользователя, скорее похожа на демона, чем на задачу. :-) */

Основы резервного копирования

Лучший способ исправить исковерканный Реестр - заменить файлы system.dat и user.dat их неповрежденными резервными копиями. До того как появилась утилита "Проверка реестра", приходилось вручную сохранять эти файлы - и если вы достаточно разумны, то на отдельном носителе. Конечно, ОС Windows 95 при каждом запуске делала их резервные копии в каталоге Windows под именами system.dao и user.dao. Однако зачастую они оказывались бесполезны: к тому моменту, как вы догадывались о возникновении какой-либо серьезной проблемы, Windows уже хотя бы раз перезапускалась, и исправные резервные копии заменялись испорченными.

Оставьте открытым запасной выход

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

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

Осторожность не помешает

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

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

От переводчика

В ноябрьском номере (1997 г.) журнала ;login, который издается ассоциацией пользователей ОС UNIX Соединенных Штатов Америки была опубликована статья Дэвида Корна относительно впечатлений, которые произвела на него двухлетняя работа по воспроизведению API UNIX с использованием API Win32. Мне кажется, что это должно быть интересно и людям из мира UNIX, и людям, связанным с технологиями Microsoft. - это одна из легендарных фигур в сообществе UNIX в основном благодаря тому, что он является создателем одного из наиболее популярных языков и командных интерпретаторов семейства shell Korn-shell (ksh). Перевод статьи на русский язык и ее публикация сделаны с разрешения Дэвида.

Заметим еще, что любой человек может стать членом Usenix и, в частности, получать журнал ;login. Информация об условиях членства размещена на Web-сервере Usenix.

Поскольку статью переводил я сам, хочу сделать еще одно замечание по поводу терминологии. Известно, что компания Microsoft очень любит вводить свои собственные термины, трудно переводимые на русский язык. Одним из таких терминов является "handle". По смыслу совершенно понятно, что это такое, но соответствующего (и не перегруженного) русского термина я не нашел. Поэтому (хотя мне это самому очень не нравится) я использую транслитерированный термин "хендл". Если кто-нибудь имеет на этот счет собственное мнение, сообщите мне, пожалуйста. А то ведь, не дай Бог, приживется...

С уважением,

Отлавливание плохих указателей

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

PAM c точки зрения пользователя

Как было раньше. Желая войти в систему вы были вынуждены пообшаться с программой-охранником гордо именуемой login. Она спрашивала ваше имя, затем пароль шифровала известным алгоритмом и сличала получивуюся абракадабру с записью в файле /etc/passwd. Если все совпадало, то вам разрешалось войти иначе предлагалось начать все с начала.

Через некоторое время наученные горьким опытом системы перестали хранить зашифрованные пароли в файле /etc/passwd открытом на всеобщее обозрение и переместили эту интимную информацию в файл /etc/shadow, читать который дозводено было только обладателям правами суперпользователя. Программа login была переписана заново: теперь она умела и читать из нового файла и шифровать по более серьезному алгоритму.

Неизвестно сколько еще раз пришлось бы переписывать эту программу, да и не только ее (с паролированием в системе связаны еще и passwd, и su), если бы не пришла кому-то в голову мысль отделить программы от механизма аутентификации. Эта система получила название PAM (Pluggable Authentication Modules), что по-русски означает Подгружаемые Модули Аутентификации (ПМА).

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

Формально PAM выполнен в виде разделяемых библиотек-модулей комфортно расположившихся в каталоге /lib/security/. Каждый модуль по особому пропускает через себя пользователя, реализуя свой особенный механизм аутентификации. То есть, запуская тот или иной набор модулей, мы как из кирпичиков складываем сценарий аутентификации согласно нашим привычкам и желаниям.

Осталось только разобраться каким программам какой сценарий использовать. Оные разместились в каталоге /etc/pam.d .
Имя каждого сценария в этом каталоге совпадает с именем программы для которого он предназначен. Например, сценарий для login находится по адресу /etc/pam.d/login.

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

#%PAM-1.0 auth requisite /lib/security/pam_unix.so nullok #set_secrpc auth required /lib/security/pam_securetty.so auth required /lib/security/pam_env.so auth required /lib/security/pam_mail.so account required /lib/security/pam_unix.so password required /lib/security/pam_unix.so strict=false session required /lib/security/pam_unix.so none # debug or trace session required /lib/security/pam_limits.so

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

Тип-Модуля Флаг-Контроля Путь-К-Модулю Параметры-Модуля

Тип-Модуля должен быть одним из следующих:

auth:Такой модуль проверяет наличие пользователя в системе, спрашивает его имя, разрешает или нет доступ в ту или иную группу (независимо от записей в файле /etc/groups) и вообще способен давать привилегии (конечно специально предназначенные для этого). account: Этот модуль не занимается аутентификацией, а позволяет контролировать распределение ресурсов системы для тех или иных пользовательских бюджетов. session:А этот связан с вещами которые могут происходить перед тем как пользователь получит доступ к той или иной службе. Например ведение записей в системных журналах. password:Модуль, как следует из названия, занимающийся непосредственно проверкой паролей на подлинность, на слабость и т.д.

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



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

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

Помимо файлов-сценариев для некоторых модулей могут использоваться дополнительные файлы конфигурации. Все они расположены в каталоге /etc/security и каждый файл предназначен для конкретной группы настроек.

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

pam_env.conf-А здесь вам под силу ограничить возможности в изменении отдельных переменных среды пользователями. Работает под руководством модуля pam_env.

limits.conf- Если вы злобный администратор или у вас недобросовестные пользователи, то этот файл для вас. Здесь вы можете индивидуально или для группы ограничить:размер core-файла, максимальный допустимый размер файла, максимальное количество открытых файлов, запущенных процессов, сколько раз можно одновременно зайти в систему и т.д. Руководящий модуль pam_limits.

access.conf-Так как PAM имеет средства аутентификации по сети, то подобные настройки являются полезными ибо контролируется не только кто может или не зайти, но и откуда.


Контролируется pam_access.

group.conf- Можно указать какой группе будет принадлежать служба запущенная определенным пользователем, в определенное время с определенного терминала. Хозяева pam_time и pam_group.

console.perms-Несколько выбивается своим названием, но не функциями. Здесь определяются права, получаемые привилегированными пользователями к консоли во время входа в систему и возвращаемые при выходе. Модуль pam_console.

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

pam_cracklib:Тип password. Проверяет ваш пароль на стойкость, не является ли он, например, палиндромом (примечание- это не обязательно при использовании модуля pam_unix). Полезен для программ задающих пароли. Полезные параметры: retry=N -дается N попыток на исправление ошибки,diffok=N-должно быть измененено минимум N символов при смене пароля,minlen=N -минимальный размер пароля,dcredit=N ucredit=N lcredit=N ocredit=N - в пароле должно присутствовать минимум N цифр, строчных, прописных букв и других символов. pam_deny:Тип любой. Всегда перекрывает доступ. pam_env:Тип auth. Контролирует сохранность переменных среды. Полезный параметр conffile=S -задает альтернативное название файла конфигурации. pam_ftp:Тип auth. Предназначен для организации анонимного доступа. То есть получив имя пользователя 'anonymous', ждет в качестве пароля что-то похожее на его почтовый адрес. Полезные параметры: ignore- не обращать внимание похож ли пароль на почтовый адрес, users=XXX,YYY -позволяет анонимный вход для пользователей из этого списка. pam_group:Тип auth. предназначение ясно из описания конфигурационного файла group.conf. pam_lastlog:Тип auth. Сообщает о времени и месте входа в систему. Обновляет /var/log/wtmp файл.Полезные параметры: nodate,noterm,nohost,silent - не выводить в сообщении даты, терминала, машины или вообще ничего, never-если пользователь никогда ранее не появлялся, то его приветствуют. pam_limits:Тип session. Предназначение указано выше при описании файла limits.conf.


Полезный параметр:conf=S -альтернативное имя конфиругационного файла. pam_listfile: Тип auth. Предназначен для организации доступа на основе конфигурационных файлов-списков например /etc/ftpaccess. Для примера смотрите соответствующие файлы сценариев. Возможные параметры: onerr=succeed|fail; sence=allow|deny; file=filename; item=user|tty|rhost|ruser|group|shell apply=user|@group . Первый параметр задает возвращаемое значение в случае неудачного поиска. Второй - в случае удачного поиска. Третий имя файла со списком. Четвертый- тип элемента в списке. Последний вносит дополнительный ограничения если тип объявлен tty, rhost или shell. pam_mail:Тип auth. Сообщается о наличии почты если таковая имеется. Полезные параметры:dir=S -путь к каталогу почтовых очередей, noenv-не устанавливать переменную среды MAIL,close -сообщать если есть почта у пользователей с аннулироваными бюджетами,nopen-не печатать какой либо почтовой информации если пользовательский бюджет только-что заведен. pam_nologin:Тип auth. Стандартная реакция на наличие файла /etc/nologin. Когда он присутствует, в систему может зайти только root, а остальным будет выдано на экран содержимое этого файла. pam_permit:Тип любой. Использование данного модуля ОПАСНО и применимо только в критических ситуациях. Всегда дает допуск. pam_pwdb:Тип любой. Замещает модули серии pam_unix.... . Использует интерфейс библиотеки libpwdb (пользовательские базы данных), что повышает независимость системы аутентификации от способа хранения пользовательских данных(NIS или passwd или shadow). Полезные параметры: nullok -можно использовать пустые пароли,md5,shadow,bigcrypt -различные способы шифрования пароля. pam_radius:Тип session. Позволяет осуществлять аутентификацию через RADIUS сервер. pam_rhosts_auth:Тип auth. Механизм работы этого модуля основывается на анализе содержимого файлов hosts.equiv и .rhosts используемых для аутентификации таких служб как rlogin и rsh. Полезные параметры:no_hosts_equiv -игнорировать содержимое файла hosts.equiv, no_rhosts-игнорировать содержимое файлов .rhosts ,suppress- охраняет системные журналы от потока малозначимых сообщений, в частности когда используется контрольный флаг sufficient. pam_root_ok:Тип auth.


Используется в случае, когда администратору необходимо получать доступ к сервису без введения пароля. Этот модуль допускает пользователя к сервису только если его uid равен 0. pam_securetty: Влючает в проверку файл /etc/securitty. Суперпользователь сможет зайти полько на указанных там терминалах. pam_time:Тип account. Принцип работы думается ясен из описания устройства конфигурационного файла time.conf. pam_warn:Тип auth и password. Просто напросто ведет записи в системных журналах например при смене пароля. pam_weel:Тип auth. Для любителей BSD, где получить права суперпользователя может только пользователь группы wheel (группа root в Linux). Полезные параметры:group=XXX-использовать указанную группу вместо стандартной нулевой,deny- инвертирование действия алгоритма, запрещается получать права суперпользователя пользователям указанной группы, используется вместе с предыдущим параметром, trust -избавляет пользователей группы wheel от необходимости вводить пароль при смене uid на 0.

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

Параллельное мышление

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

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

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

При установке альтернативной NT системы не следует повторять все опции установки первичной системы (например, сетевые службы, роль сервера). Устанавливайте минимальный набор опций для экономии дискового пространства. Лично я сбрасываю все опции в диалоговом окне NT Accessory и обычно не устанавливаю сетевые службы. Но если вам может потребоваться доступ к другим машинам по сети при загрузке альтернативной системы, то установите сетевую компоненту. Кроме того, не обязательно устанавливать последний Service Pack - установите тот, который считаете наиболее подходящим, если только у вас нет крайней потребности в полной эквивалентности двух систем.

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

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

>>>

Параметры просмотра папок в Windows Explorer

Принятые по умолчанию в Windows 2000 параметры настройки Windows Explorer отличаются от установок NT 4.0. Иногда полезно поменять эти настройки, прежде чем начинать что-то делать. Чтобы запустить Windows Explorer, нужно щелкнуть правой кнопкой мыши на значке My Computer или открыть меню Start и выбрать в нем команды Programs, Accessories, Windows Explorer. (Почему Windows Explorer лежит в папке Accessories, тогда как Internet Explorer - в папке Programs, остается загадкой, если принять во внимание, что Windows 2000 Server предназначен для серьезной работы, а не для путешествий по Internet.) В меню Windows Explorer следует выбрать команды Tools, Folder Options, после чего должно открыться диалоговое окно с вкладками. На вкладке General рекомендуется не устанавливать переключатель Web content in folders, поскольку он предусматривает более сложный режим отображения информации и, тем самым, отбирает процессорное время у других задач. Остальные режимы по умолчанию на вкладке General вполне приемлемы. На Экране 5 показана вкладка View с установленным флажком Display compressed files and folders with alternate color, позволяющая визуально отличать по цвету сжатые файлы от несжатых.

экран 5. Настройка режима просмотра файлов.

Кроме того, установлены флажки Display the full path in the address bar и Display the full path in the title bar, что позволяет отображать полный путь к файлам. Кроме того, я всегда устанавливаю флажок Show hidden files and folders и снимаю Hide file extensions for known file types, так как расширения бывают важны при возникновении каких-либо проблем. И, наконец, я обычно снимаю флажок Show My Documents on the Desktop, потому что предпочитаю хранить документы на диске, выделенном специально для размещения файлов данных. После настройки этих параметров нужно нажать кнопку Like Current Folder, чтобы выбранные параметры распространялись на все каталоги.

Переход к использованию динамических дисков

Динамический диск - это новый инструмент, появившийся в Windows 2000 и позволяющий создавать динамические тома. В процессе преобразования дисков NT 4.0 в динамические диски Windows 2000 все существующие разделы трансформируются в тома. Преимущество нового механизма состоит в том, что для изменения конфигурации и управления динамическими томами не требуется перезагружать компьютер. Так, например, можно создать один том, распределенный по нескольким дискам, и это не потребует перезагрузки. Аналогичная операция создания набора томов в NT 4.0 предполагала перезагрузку системы. К сожалению, динамические диски недоступны из NT 4.0 и из любой другой операционной системы. Поэтому не следует выполнять преобразование дисков в системах с несколькими ОС. При этом, однако, с динамическими дисками можно работать удаленно с другого компьютера сети. В данном случае доступ к диску осуществляется не напрямую, а посредством ОС Windows 2000. Она считывает нужные файлы и обеспечивает доступ к ним средствами службы Server.

Чтобы выполнить преобразование диска, следует щелкнуть правой кнопкой мыши на значке My Computer и выбрать в меню команду Manage. Далее нужно раскрыть папку Storage, а затем - узел Disk Management. В правой панели окна будут показаны диски системы (см. Экран 2).

экран 2. Управление дисками.

В верхнем окне следует щелкнуть правой кнопкой на значке нужного диска, затем выбрать в меню Action команду Upgrade to Dynamic Disk, указать диски, которые нужно преобразовать, и нажать OK.

На экране должно появиться окно с просьбой подтвердить необходимость преобразования выбранных дисков. Нужно нажать кнопку Upgrade, после чего система напомнит, что преобразованные диски не будут доступны предыдущим версиям Windows. Нажимаем Yes. Теперь должно появиться еще одно предупреждение: "Эта процедура вызовет размонтирование файловой системы на всех преобразовываемых дисках. Никакие программы не должны выполняться во время преобразования. Рекомендуется проводить преобразование дисков до запуска системы в производственное использование".

Теперь на экране появляется еще

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

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

---

---