Символьные и блочные устройства

Файлы символьных и блочных устройств создаются с помощью программы mknod и соответствуют внешним устройствам, а также псевдоустройствам, таким как знаменитое пустое устройство /dev/null (такое, при попытке чтения из которого сразу же сообщается о достижении конца файла и при записи в которое никогда не происходит переполнения - точный аналог NUL в DOS/Windows).

Устройства нумеруются двумя целыми числами - старшим (major number) и младшим (minor number). Первое из них соответствует типу устройства (например, для устройств, подключенных к первому IDE-контроллеру, оно равно 3, для подключенных ко второму - 22 и т. д.), а второе - конкретному устройству (например, для мастер-диска, подключенного к первому IDE-контроллеру, оно равно 0, для первого раздела на этом диске - 1 и т. д.). При этом символьные и блочные устройства нумеруются независимо.

Число 30Ah в поле "положение" информации о файлах /usr/bin/unzip и /usr/bin/zipinfo на рис. 1 и 2 обозначает как раз номер устройства: 3 - это первый IDE-диск, а 0A - его десятый раздел.

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

Многие устройства имеют дополнительные характеристики: скажем, на консоли (виртуальной) IBM PC есть три лампочки - Num Lock, Caps Lock и Scroll Lock, - а последовательный порт может передавать данные с различной скоростью. Как правило, программы в Linux работают просто с файлами, никак или почти никак не учитывая особенности того или иного конкретного устройства. Если же программа должна их учитывать, она осуществляет управление соответствующими параметрами через системный вызов ioctl, позволяющий, например, зажечь Num Lock или изменить громкость звука. В основном использование ioctl сводится к управлению конфигурацией (отсюда и название - I/O ConTroL, т. е. управление вводом-выводом).

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

Эта проблема была осознана достаточно давно, и уже предложено несколько вариантов ее решения. Однако самым распространенным остается пока стандартный подход, когда все файлы устройств создаются вручную программой mknod. Мне представляется наиболее удачным вариант с использованием специальной файловой системы devfs, монтируемой в каталог /dev, в которой специальные файлы устройств создаются и уничтожаются автоматически по мере надобности (именно так настроен компьютер, где сейчас пишутся эти строки).

Система безопасности WMI

WMI осуществляет защиту на уровне пространства имен. Если приложение управления успешно соединяется с пространством имен, то оно имеет право просматривать свойства всех объектов и обращаться к ним в этом пространстве. Администратор может использовать приложение управления WMI для контроля доступа пользователей к пространству имен. Чтобы запустить приложение управления WMI, следует выбрать Start/Administrative Tools/Computer Management. Затем нужно открыть Services and Applications, щелкнуть правой кнопкой мыши на WMI Control и выбрать Properties, чтобы открыть диалоговое окно WMI Control (Local) Properties, показанное на Экране 5. Чтобы настроить защиту для пространства имен, на закладке Security следует выбрать нужное пространство имен и нажать Security. Другие закладки в диалоговом окне позволяют изменять функции и резервировать параметры настройки, хранимые в системном реестре.

ЭКРАН 5. Настройка системы безопасности пространства имен.

Системы с минимальным ядром

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

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

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

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


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

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

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

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



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

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

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


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

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

Сколько имен у файла?

Описанная схема позволяет связать с одним файлом несколько равноправных имен, что в ряде случаев бывает полезно. Сравните, например, характеристики файлов unzip и zipinfo на рис. 1 и 2

Рис. 1. Характеристики файла unzip

(для получения информации использована программа Midnight Commander).

Рис. 2. Характеристики файла zipinfo

Как видим, они совпадают: у обоих файлов одно и то же "положение" (кстати, шестнадцатеричное число 1A328h является номером узла), одинаковая длина и т. д., причем на каждый из файлов имеется по две ссылки - это в действительности и есть два имени. Но, будучи физически одним и тем же файлом, unzip и zipinfo являются различными программами: каждая из них выполняет свои действия и имеет собственный набор опций. Никакой мистики здесь нет - просто в программу в качестве нулевого параметра передается ее имя, по которому она и определяет, что делать дальше.

Далее, в Unix-системах (включая Linux) нет операции удаления файла в смысле DOS/Windows: есть только удаление ссылки на узел - unlink - и ссылки на пустой каталог - rmdir (в некоторых Unix-системах unlink позволяет удалить ссылку на пустой каталог, но в Linux это не так). Сам же файл удаляется автоматически тогда, когда делается недоступным для системы. Это означает, что не должно остаться, во-первых, ни одной ссылки на него, а во-вторых, ни одной работающей с ним активной программы.

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

Службы

Существует еще один способ защиты административных учетных записей. Он потребует особого внимания к службам, доступным обычным пользователям. Многие системные службы, например планировщик задач или сервер баз данных, предоставляют в распоряжение пользователей механизмы запуска команд, исполнять которые будет сама служба. Некоторые планировщики достаточно "умны" и умеют выполнять команды от имени учетной записи пользователя. Другие этого делать не умеют, и команда выполняется с привилегиями учетной записи самой службы. Например, в состав Microsoft SQL Server входит собственный планировщик задач и SQL-команд, что дает пользователям SQL Server возможность выполнять команды операционной системы. В этом случае существует два способа защиты администраторских полномочий. Во-первых, можно ограничить права пользователей на выполнение команд настройкой самой службы. Большинство служб, таких, как SQL Server и Microsoft Exchange Server, снабжены механизмами аутентификации и контроля доступа. Необходимо убедиться, что такие механизмы корректно сконфигурированы, и следить за их настройкой. Во-вторых, зачастую подобные службы запускаются от имени системной учетной записи Local System Account, которая даже мощнее, чем учетная запись администратора системы. Чтобы этого избежать, нужно создать отдельную учетную запись для службы и предоставить ей только те права и разрешения, которые необходимы для работы. В результате если кто-то и получит возможность работать с данной службой, то у него будут лишь те права доступа к системе, которые предоставлены учетной записи службы.

Такой подход особенно важен применительно к системной службе планировщика NT Scheduler. По умолчанию эта служба работает от имени системной учетной записи. Если это не имеет значения, ее можно запускать от имени непривилегированного пользователя. В любом случае следует иметь в виду, что члены группы Server Operators могут выполнять команды с помощью NT Scheduler, лишь когда значение реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Control\LSA\SubmitControl равно 1.
Запуск NT Scheduler от имени системной учетной записи или пользователя с административными привилегиями фактически означает, что члены группы Server Operators могут повысить собственные привилегии до уровня администратора системы. Здесь важно убедиться, что значение ключа реестра SubmitControl равно 0.

И последнее замечание относительно конфигурации системных служб: следует помнить о том, что NT уязвима с точки зрения физического доступа. Если злоумышленник сможет загрузить компьютер под управлением DOS или другой операционной системы, он получит неограниченный доступ к системе. Использование пароля на уровне BIOS ограничит возможность локальной загрузки и модификации параметров CMOS. Однако не нужно полностью полагаться только на такую защиту. Взломщик может обойти все подобные уловки, сбросив BIOS, удалив батарейки или просто изъяв из компьютера жесткий диск. Известно, что в Internet можно найти заводские пароли для многих моделей BIOS. Лучшая защита - держать сервер, ленты с резервными копиями данных и диски аварийного восстановления под замком.

Смерть процесса

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

Обратимся еще раз к примеру, рассмотренному выше. Когда мы нажатием <Ctrl>+C принудительно завершили выполнение программ dd и wc, соответствующие процессы были уничтожены, и на экране появилось приглашение командного интерпретатора. Пока программы работали, приглашения не было: интерпретатор находился в состоянии ожидания, в которое перешел, послав специальный системный вызов (в действительности таких вызовов существует несколько: wait, waitpid, wait3, wait4). После окончания работы программ вызов вернул управление интерпретатору, и тот выдал на терминал приглашение.

Если родительский процесс по какой-то причине завершится раньше дочернего, последний становится "сиротой" (orphaned process). "Сироты" автоматически "усыновляются" программой init, выполняющейся в процессе с номером 1, которая и принимает сигнал об их завершении.

Если же потомок уже завершил работу, а предок не готов принять от системы сигнал об этом событии, то потомок не исчезает полностью, а превращается в "зомби" (zombie); в поле Stat такие процессы помечаются буквой Z. Зомби не занимает процессорного времени, но строка в таблице процессов остается, и соответствующие структуры ядра не освобождаются. После завершения родительского процесса "осиротевший" зомби на короткое время также становится потомком init, после чего уже "окончательно умирает".

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

Смесь бульдога с носорогом

В настоящее время происходит активный процесс слияния универсальных OC и ОС реального времени. На программном рынке появляются различные инструменты поддержки режима реального времени, встраиваемые в привычные операционные системы. Этот класс продуктов обладает значительными преимуществами со стороны пользователей и программистов, сочетая в себе привычный пользовательский интерфейс, средства разработки программ и API-интерфейс реального времени. Правда, пока еще нет оснований утверждать, что подобные решения полностью заменят собой обычные системы реального времени. У традиционных ОС реального времени есть пока большое преимущество - встраиваемость и компактность. Однако и на этом рынке происходят изменения: корпорация Microsoft выпустила Windows NT Embedded (NTE), использование которой позволяет "ужать" NT до 8-10 Мбайт. Уже появились и продукты реального времени, рассчитанные на эту операционную систему, например, RTX.

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

Бурный рост популярности Linux побуждает разработчиков внимательнее присмотреться к этой операционной системе. У Linux много достоинств: открытость кода; большое количество сопутствующего программного обеспечения, пока в основном ориентированного на серверные применения; наличие неплохой документации на API-интерфейс и ядро операционной системы; работа на процессорах различных классов. В данный момент эта ОС готова к стабильной работе, а открытость ее исходных текстов и архитектуры наряду с растущей популярностью заставляет программистов переносить свои наработки на многие аппаратные платформы: SGI, IBM, Intel, Motorola и т.д. В частности, Motorola активно работает в своей традиционной сфере встраиваемых систем и продвигает на рынок продукт LinuxEmbedded. Вообще говоря, Linux прекрасно подходит для компактных встроенных применений; на рынке уже появились поставщики, предлагающие усеченные варианты этой операционной системы, которые занимают 1-2 Мбайт на жестком диске. В качестве примера можно привести проект Linux Router Project.

Для задач реального времени сообщество разработчиков Linux активно применяет специальные расширения - RTLinux, KURT и UTIME, позволяющие получить устойчивую среду реального времени. RTLinux представляет собой систему "жесткого" реального времени, а KURT (KU Real Time Linux) относится к системам "мягкого" реального времени. Linux-расширение UTIME, входящее в состав KURT, позволяет добиться увеличения частоты системных часов, что приводит к более быстрому переключению контекста задач.

Снижение потенциального влияния ошибок

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

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

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

Сноски

1)Некоторые слова здесь были употреблены небрежно. Намерение состояло в том, чтобы никто не должен был платить за разрешение пользоваться системой GNU. Но эти слова не проясняют это, и люди часто интерпретируют их, как будто они говорят, что копии GNU всегда должны распространяться бесплатно или за малую плату. Это никогда не было целью; далее манифест упоминает о возможности компаний предоставлять услуги по распространению за плату. Впоследствии я понял, что нужно точно различать "free" в смысле свободы и "free" в смысле цены. Свободное программное обеспечение --- это программное обеспечение, которое пользователи вольны распространять и изменять. Некоторые пользователи могут получить копии бесплатно, тогда как другие платят за получение копий, и если эти деньги помогают улучшать эти программы, то чем больше, тем лучше. Важно то, что каждый, кто имеет копию, имеет свободу сотрудничать с другими при ее использовании. 2)Это еще одно место, где я не выявил тщательно разницу между двумя различными значениями слова "free". Само по себе это предложение не является неправдой --- вы можете получить копии программ GNU бесплатно от ваших друзей или по сети. Но оно предполагает ложную идею. 3)Сейчас существуют несколько таких компаний. 4)Фонд Свободного Программного Обеспечения получает большую часть средств за услуги по распространению, хотя он является организацией, существующей на пожертвования, а не коммерческой компанией. Если никто не выберет в качестве способа получить копии заказ от Фонда, он будет неспособен выполнять свои работу. Но это не означает, что собственнические ограничения оправданы, чтобы заставить каждого пользователя платить. Если малая часть всех пользователей заказывает копии в Фонде, этого достаточно, чтобы Фонд остался на плаву. Поэтому мы просим пользователей поддержать нас таким образом. Сделали ли вы свою часть? 5)Группа компьютерных компаний недавно выдала средства на поддержку сопровождения компилятора GNU C Compiler.

Сокращение числа ошибок в ядре

Нашей первой линией защиты является очень небольшое ядро. Хорошо известно, что в большем по объему коде содержится большее число ошибок, и поэтому чем меньше ядро, тем меньше в нем ошибок. Если в качестве нижней оценки использовать 6 ошибок на 1000 строк исполняемого кода [27], то при наличии 3800 строк исполняемого кода в ядре будет присутствовать, как минимум, 22 ошибки. Кроме того, 3800 строк кода (менее 100 страниц листинга, включая заголовки и комментарии) – это достаточно мало, чтобы весь этот код мог понять один человек; это существенно повышает шансы на то, что со временем все ошибки удастся найти.

В отличие от этого, в ядре монолитной системы, такой как Linux, размером в 2.5 миллиона строк исполняемого кода, вероятно, должно содержаться не менее 6 * 2500 = 15,000 ошибок. Кроме того, при наличии системы из нескольких миллионов строк ни один человек не может прочитать весь исходный код и полностью понять, как он работает, что уменьшает шансы на нахождение всех ошибок.

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

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

Стандарт POSIX.1 содержит несколько сотен (если не тысяч) требований; считается самоочевидным, что если не выполнено хотя бы одно из них, то система (или прикладная программа) не удовлетворяет стандарту. Вместе с тем, к настоящему времени написано такое количество операционных систем класса UNIX и прикладных программ для них, что вряд ли разумно требовать полного соответствия в указанном смысле. Трудности разработки международного стандарта такого рода усугубляются существованием разных национальных языков. Даже если забыть о прикладных программах, предназначенных для обработки текстов на национальных языках, практически любая прикладная программа должна выдавать какие-то диагностические сообщения и/или воспринимать тексты, вводимые оператором.

Осознавая такого рода трудности, авторы POSIX предлагают уточненную семантику слова "соответствует". Во-первых, вводится несколько видов соответствия (прикладной программы стандарту):

строгое соответствие стандарту POSIX.1;

соответствие международной версии POSIX.1;

соответствие национальной версии POSIX.1;

соответствие POSIX.1 с расширениями.

Во-вторых, многие интерфейсные средства объявлены факультативными (optional); стандарт требует, чтобы факультативные интерфейсные функции либо отрабатывались так, как предписано стандартом, либо всегда возвращали особый код ошибки, ENOSYS (означающий, что функция не реализована). Факультативные средства разбиты на несколько групп, каждой из которых соответствует некоторая конфигурационная константа, которая декларируется (оператором #define) в соответствующем заголовочном файле; тем самым обеспечивается возможность выяснения, реализована ли функция, на фазе компиляции.

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

Создание дисковых разделов

Всякий, кто хоть раз устанавливал эту ОС Linux знает, что ATA-диски (SCSI-накопители - тема особая и для большинства пользователей все менее актуальная) в Linux маркируются в соответствии с порядком подключения к IDE-контроллеру: первый диск на первом канале - /dev/hda, второй - /dev/hdb, третий - /dev/hdc, четвертый - /dev/hdd. Эти имена дисков (собственно, не дисков, а файлов соответствующих им устройств) всегда неизменны.

Разделы на дисках маркируются дополнительными цифрами: с hd?1 по hd?4 для первичных разделов и начиная с hd?5 - для логических томов расширенного раздела. Поскольку в Linux принята таблица разделов в стиле MS DOS, последний может присутствовать только в единственном экземпляре, отнимая одно поле в таблице у разделов первичных. На физическом диске теоретически могут сосуществовать три первичных раздела и некоторое количество логических томов, например, hda1-hda3 и hda5-hda8. Ныне это нуждается в коррективах - большинство современных дистрибутивов Linux на базе ядра 2.4.xx задействуют файловую систему devfs, которая предоставляет массу дополнительных возможностей, в частности, избавляет от резервирования имен для отсутствующих в системе устройств, проблем со старшими номерами устройств и многого другого. Однако в ней по умолчанию применяется совершенно иная номенклатура и предусмотрены совершенно иные места для размещения файлов устройств. Так, для файлов любых ATA-накопителей предназначен каталог /dev/ide (в некоторых дистрибутивах файловая система устройств монтируется в каталог /devices, а каталог /dev сохраняется для совместимости). Файлы накопителей на встроенном IDE-контроллере локализуются в подкаталоге /dev/ide/host0. А внутри него есть два подкаталога, соответствующие IDE-каналам - /dev/ide/host/bus0(bus1), каждый из которых опять же может делиться надвое: на каталоги target0 и target1, по количеству подключенных устройств. Внутри каталога target0(1) имеется минимум еще один подкаталог lun0. А уж в нем размещаются непосредственно файлы устройств: disc для всего накопителя, part1, ...
part# для разделов. Таким образом, полное обозначение дискового раздела будет выглядеть как:

/dev/ide/host0/bus0 /target0/lun0/part1

для первого первичного раздела на первом диске первого IDE-канала. Предусмотрен и более краткий способ обращения к файлам устройств - через жесткие ссылки (иные имена для тех же наборов данных). Для файлов дисковых накопителей они собраны в каталоге /dev/discs (для файлов CD-приводов, например, в каталоге /dev/cdrom) с подкаталогами disc0, ... , disc#. И потому к приведенному в качестве примера разделу можно обратиться и так:

/dev/discs/disc0/part1

Наконец, для совместимости со старыми соглашениями в большинстве дистрибутивов поддерживается номенклатура, принятая до внедрения devfs - все то же из примера можно обозвать просто как /dev/hda1.

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

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

Создание и монтирование файловых систем

Создание файловых систем на дисковых разделах (или, в терминах DOS/Windows, форматирование последних) и их монтирование (т. е. обеспечение доступа к ним со стороны ОС и пользователя) - второй этап подготовки диска к инсталляции Linux. Сами по себе эти действия не сложны, однако осознанное их выполнение требует некоторой подготовки.

Устройство файловой системы

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

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

Возникает вопрос, почему такой, казалось бы неотъемлемый, атрибут файла, как его имя, не обнаруживается ни в его метаданных, ни, тем более, среди его данных? В Unix имя являет собой атрибут не файла, но файловой системы. И для хранения имен файлов предназначены файлы особого типа - каталоги, которые представляют собой просто списки файловых дескрипторов идентификаторов и соответствующих им имен файлов.
Поэтому идущая от MacOS и активно используемая в Windows метафора каталога как папки с документами в Unix только затемняет суть - здесь это никакое не "вместилище документов", а скорее каталожный ящик в библиотеке.

Несмотря на столь простое устройство, роль каталогов в файловой системе Unix трудно переоценить. Имена файлов, через которые они включаются в файловую систему фигурируют только в составе каталога, к которому файл приписан. Удаление имени файла (или подкаталога) из списка, представляющего собой данные его родительского каталога равносильно тому, что метаданные файла становится недоступными, а приписанные к его inode блоки данных помечаются как свободные. Чтобы сделать файловую систему доступной она со всем ее содержимым (суперблоком, списком inode, блоками данных) должна быть включена в состав какого-либо из существующих каталогов, называемого точкой монтирования. Именно это и составляет суть процесса монтирования. Результат же для монтируемой файловой системы в том, что ее корневой каталог (до сих пор безымянный) получает имя каталога - точки монтирования (mount point), содержимое которого отныне составляет список имен ее файлов и подкаталогов. Обратный процесс - размонтирование, отсоединение от точки монтирования дерева смонтированной файловой системы. Кроме того, в inode ее корневого каталога устанавливается бит чистого размонтирования (clean bit).

Выбор файловой системы

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


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

Файловая система ReiserFS оказалась для Linux исторически первой - она поддерживается каноническим ядром (), начиная с первых версий ветви 2.4.x и была единственной, разработанной "с нуля" специально для этой ОС Хансом Райзером. Как и в большинстве таких систем здесь осуществляется журналирование только операций над метаданными файлов. Кроме этого, ReiserFS обладает уникальной возможностью оптимизации дискового пространства, занимаемого мелкими файлами - они целиком хранятся в своих inode, без выделения блоков в области данных и вместе с экономией места это способствует и росту производительности, так как данные и метаданные хранятся в непосредственной близости и могут быть считаны одной операцией ввода/вывода. Другая особенность ReiserFS - та, что хвосты файлов меньше чем один блок могут быть подвергнуты упаковке (режим тайлинга). Это обеспечивает около 5% экономии дискового пространства.

ReiserFS не совместима с ext2fs на уровне утилит обслуживания файловой системы, однако соответствующий инструментарий, объединенный в пакет reiserfsprogs, уже давно включается в штатный комплект современных дистрибутивов. Более серьезная проблема - загрузчики Linux (Lilo и GRUB) часто не способны загрузить ядро Linux с раздела ReiserFS, оптимизированного в режиме тайлинга. А поскольку, будучи отключенным, этот режим обладает свойством самовосстановления, пользователь может столкнуться с тем, что после пересборки ядра система откажется загружаться. Именно поэтому может быть необходимым создание раздела под каталог /boot.

В отличие от ReiserFS, ext3fs - не более чем журналируемая надстройка над классической ext2fs, разработанная в компании Red Hat и поддерживаемая ядром Linux, начиная с 2.4.16.


Как следствие такого происхождения, она сохраняет со своей прародительницей полную совместимость, в том числе и на уровне утилит обслуживания (начиная с версии 1.21 объединяющего их пакета e2fsprogs). Другое преимущество - чуть ли не максимальная надежность: ext3fs является единственной системой из рассматриваемых, в которой возможно журналирование операций не только с метаданными, но и с данными.

В ext3fs предусмотрено три режима работы: полное журналирование (full data journaling), журналирование с обратной записью (writeback), а также задействуемое по умолчанию последовательное (ordered). В первом случае все новые данные сначала пишутся в файл журнала и только после этого фиксируются на диске. В случае аварийного отказа можно повторно перечитать журнал, приведя данные и метаданные в непротиворечивое состояние. Этот механизм практически гарантирует от потерь данных, однако является наиболее медленным. В режиме с обратной записью в файл журнала записываются только изменения метаданных и никакой гарантии сохранности данных он не предоставляет, однако обеспечивает наибольшее (в рамках ext3fs) быстродействие. В последовательном режиме также физически журналируются только метаданные файлов, однако, связанные с ними блоки данных логически группируются в единый модуль, называемый транзакцией. И эти блоки сохраняются перед записью на диск новых метаданных, что, хотя и не гарантирует полной сохранности но весьма способствует ей.

Файловая система XFS, в отличие от молодых ReiserFS и ext3fs, развивается на протяжении почти десяти лет - впервые она появилась для версии Irix 5.3 в 1994 г. XFS - единственная из рассмотренных 64-разрядная файловая система. Особенностями XFS являются:

механизм allocation group - деление единого дискового раздела на несколько равных областей, имеющих собственные списки inodes и свободных блоков, для распараллеливания дисковых операций; логическое журналирование только изменений метаданных, но с частым сбросом их на диск для минимизации возможных потерь при сбоях; механизм delayed allocation - ассигнование дискового пространства при записи файлов не во время журналирования, а при фактическом сбросе их на диск, что, вместе с повышением производительности, предотвращает фрагментацию дискового раздела; списки контроля доступа (ACL, Access Control List) и расширенные атрибуты файлов (extended attributes), рассмотрение которых далеко выходит за рамки нынешней темы.



XFS очень сбалансированная файловая система - она почти столь же надежна, как ext3fs, и не уступает ReiserFS в быстродействии на большинстве файловых операций. А при манипуляциях с очень большими файлами XFS вне конкуренции. Не отмечалось для нее и проблем с совместимостью. Однако следует учесть, что в отличие от ReiserFS и ext2fs, поддержка которых является штатными опциями ядра Linux, XFS по сию пору (текущая версия - 2.4.19) не поддерживается каноническим ядром Линуса Торвальдса. Хотя недавнее включение такой поддержки в разрабатываемую ветвь ядра (версии 2.5.X) позволяют надеяться, что скоро эта функция станет штатной. Утилиты поддержки для XFS объединены в несколько пакетов, из которых абсолютно необходимым является xfsprogs. Хотя многие дистрибутивы Linux штатно комплектуются средствами поддержки XFS (из SB-дистрибутивов в настоящий момент это Gentoo и SMGL), обо всем этом следует помнить при предварительной разметке диска.

Практические следствия

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

Если нет желания заниматься сравнительным анализом разных файловых систем нормальным выбором для всех разделов остается ext2fs. Она может быть создана любой из следующих команд - /sbin/mke2fs, /sbin/mkfs, /sbin/mkfs.ext2 с указанием файла устройства в качестве аргумента, например:

$ /sbin/mke2fs /dev/hd?#

Для создания файловой системы ext3fs можно применить ту же команду mke2fs с опцией -j, при этом она получит некоторые характеристики по умолчанию, определить которые вручную позволяет следующая форма этой команды:

$ /sbin/mke2fs -J опции_журналирования /dev/hd?#

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


Можно использовать и специальную команду /sbin/mkfs.ext3 - возможности ее идентичны /sbin/mke2fs. Но самое интересное - преобразование существующей ext2fs в ext3fs простым добавлением журнала, не только без потери данных, но и без перезапуска системы (и даже без размонтирования). Делается это командой "$ tune2fs -j /dev/hd?#", которая просто добавляет файл журнала /.journal в корневом каталоге модифицируемой файловой системы (если последняя не была размонтирована), или задействует для журнала скрытый inode (если перед модификацией файловая система была размонтирована). Обратное преобразование еще проще и осуществляется командой монтирования.

Файловая система ReiserFS создается командой /sbin/mkreiserfs из пакета reiserfsprogs. Для нее доступны многочисленные опции (-s для задания размера журнала, -f для принудительного переформатирования ранее существовавшей файловой системы иного типа, и т.д.). Во избежание неожиданностей напомню: если корневой раздел форматируется как ReiserFS, не лишним будет предусмотреть небольшой раздел под каталог /boot для размещения на нем файловой системы ext2fs.

Для создания XFS также существует собственная команда mkfs.xfs (из пакета xfsprogs). Важнейшие опции: b - задание размера блока данных; d - определение параметров области данных файловой системы; l - описание параметров журнального файла. При использовании mkfs.xfs для достижения максимальной производительности рекомендуется в явном виде задать количество allocation groups иначе оно будет определяться автоматически, что приведет к непроизводительным расходам ресурсов (лучше определить его из расчета одна allocation group на 4 Гбайт дискового пространства). Далее, по тем же причинам можно установить размер файла журнала (здесь рекомендованное значение составляет 32 Мбайт). Для дискового раздела объемом в 20 Гбайт команда приобретет вид

$ mkfs.xfs -d agcount=5 -l size=32m /dev/hda1

Команда mkfs.xfs имеет опцию -f - принудительное создание файловой системы XFS поверх любой существующей.


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

$ dd if=/dev/zero of=/dev/hd?#

Ждать заполнения нулями всего устройства не обязательно - достаточно дать этой команде поработать секунд 10-20, после чего прервать ее комбинацией клавиш Control+D и перейти к созданию новых файловых систем.

И последнее, о чем следует сказать об области подкачки, созданной на этапе разбиения диска. Хотя файловой системы как таковой он не несет, но нуждается в определении, что достигается командой "$ mkswap имя_устройства", к которой следует подходить со вниманием - ее применение к обычному разделу уничтожит на нем все данные.

Создание стандарта конфигурации

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

Средства безопасности, основанные на языках

В предыдущей работе один из авторов также затрагивал проблему безопасного выполнения внешнего кода внутри ядра. В проекте Open Kernel Environment (OKE) обеспечивается безопасная, контролирующая ресурсы среда, позволяющая загрузить в ядро операционной системы Linux полностью оптимизированный собственный код [4]. Код компилируется с использованием специального компилятора Cyclone, который добавляет к объектному коду инструментарий в соответствии с политикой, определяемой привилегиями пользователя. Cyclone, подобно Java, является языком с типовой безопасностью, в котором большая часть ошибок, связанных с указателями, предотвращается языковыми средствами. Явное доверительное управление (trust management) и контроль авторизации обеспечивают администраторам возможность осуществлять строгий контроль над предоставлением внешним модулям привилегий, и этот контроль автоматически приводится в исполнение в коде этих модулей. Кроме обеспечения авторизации, компилятор играет центральную роль в проверке того, что код соответствует установленной политике. Для этого используются как статические проверки, так и динамический инструментарий.

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

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

Средства конфигурации

Гордостью Corel LINUX можно считать единую панель конфигурирования системы под названием Control Center. Почти все параметры операционной системы настраиваются здесь - от размера шрифтов в меню до IP-адреса компьютера (рис. 2).

Рис. 2

Здесь вы найдете параметры дисплея, несколько популярных экранных тем, среди которых я сразу же отыскал и установил приятную для глаз голубоватую палитру Sun CDE. Отдельные элементы среды могут быть настроены индивидуально. Вообще дисплейные настройки работают очень хорошо, что необычно для Linux. Возьмите-ка RedHat и попробуйте настроить нужные параметры видео одним махом. С высокой долей вероятности вас ждет разочарование - без опыта это сделать не удастся. В Corel LINUX нужно произвести типовые действия, к которым вы привыкли в Windows: выбрать тип дисплея, цветовую глубину, разрешение экрана и частоту развертки монитора. Сплошное удовольствие, а не работа. То же самое касается и сетевых настроек, и сервера Samba. IP- и DNS-адреса выставляются за одну минуту, и перезагрузка всей системы не нужна. Примечательно то, что в Control Center настраиваемых параметров, требующих перезапуска Corel LINUX, вообще очень мало. В основном новые значения вступают в силу немедленно после нажатия кнопки Apply.

Средства работы с текстами

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

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

Для меня процессоры - в первую очередь инструмент верстки. Так уж сложилось исторически. То, с чем я имею дело - многостраничные, довольно сложно структурированные документы (научного, так сказать, содержания). Ни PageMaker, ни QuarkPress для этих целей категорически не подходят, что бы не говорили их адепты. А в специально предназначенный для такого FrameMaker поддержку русского языка так никто и не удосужился вставить (баловство это - наука по русски). Не верстать же, право, в старой DOS'овской Ventura с ее GEM'ом...

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

Достаточно посмотреть, во что превратился AmiPro (уже в версии 3.0 он содержал практически все, что нужно), сменив свое милое сердцу имя друга профессионала на безликий - WordPro. А уж чего стоит такое достижение микрософтовской творческой мысли, как невозможность (в 97-м Word'е) создать пустой фрейм? Все никак не удосужусь проверить, исправлено это в двухтысячном Word'е, или возведено в ранг пренепременной фичи.

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

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

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

Их - два, kedit и kwrite. Они ориентированы на разные задачи и, соответственно, отличаются функционально.

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

Рис. 2. Kedit - простой текстовый редактор

Kwrite функционально ближе к редакторам типа Aditor'а или TextViewer'а (рис. 3). Он предназначен скорее для писания исходных текстов программ. Помимо обычных настроек, позволяет цветом выделять языковые конструкции (тэги html, синтексис C, Java и прочих). В общем, типичный редактор для программиста.



Рис. 3. Kwrite - развитый текстовый редактор для программистов.

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

Разумеется, мало-мальски сложный сайт в kwrite не сделать, так как остутствуют средства проверки ссылок, целостности проекта и тому подобные атрибуты развитых html-редакторов.Однако - уж получше Notepad'а, который многие профессиональные web-мастера считают лучшим web-редактором всех времен и народов. Правда, думаю, все же лукавят.

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

Средства управления файлами

Здесь таковое именуется kfm (K Files Manager). Организована она в стиле Windows'кого Explorer'а. Мне то больше нравятся системы типа Nortona, FAR'а при прочих Windows Commander'ов. Но эта - довольно удобна.

Kfm функционирует в двух режимах - обычном пользовательском и суперюзерском (в последнем случае при запуске в терминале запрашивается пароль root'а). Функционально они аналогичны, различаясь только правами доступа.

Управление kfm - браузероподобное (см. рис. 1, задний план). Имеются кнопки - Вверх, Вперед, Назад, Домой. Щелчок (одинарный) на текстовом файле автоматически вызывает редактор kedit (о котором - дальше), на графическом - вьювер kview.

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

Так, чтобы скопировать некий каталог (хоть диск целиком, ведь разница между каталогом и устройством - нет), выбираем пункт "Скопировать" в исходной точке, переходим в целевую и выбираем - "Вставить". Правда, команды "Переместить" нет, для этого надо вернуться обратно и удалить исходный каталог. Для удаления есть два режима - безвозвратное (как известно, в UNIX'е нет аналогов unerase, undelite etc.) или путем помещения в корзину (аналогичную таковой Windows; правда, как настроить или хотя бы определить ее размер - так и осталось для меня загадкой).

Кстати, что раздражает человека, непривычного к UNUX'у - это всякого рода права доступа. Часто хоть тресни, а скопировать или перезаписать файл не удается. Пока не вспомнишь, что создал его (а то и целый каталог) в роли root'а. Конечно, kfm в режиме суперпользователя позволяет изменить принадлежность файла пользователю и группе, а также изменить для них права доступа. Однако, в отличие от копирования, это приходится делать по одному, что - скучно.
Проще сделать это в командной строке посредством команд chgrp, chown, chmode с параметром -R (рекурсивно, то есть включая все вложенные подкаталоги и их файлы).

Сетевая ориентированность kfm (в нем, как и в последних Explorer'ах, нет разницы - работаете Вы с файлами на локальном диске или на сколь угодно удаленной машине; но реализовано это не столь навязчиво, как в Windows) подчеркивается тем, что в него встроен собственный браузер.

Это - не бог весть что по сравнению с современными Explorer'ами и Communicator'ами, но все минимально необходимые функции в нем есть (см. рис. 1, передний план). Правда, не поддерживается JavaScript и Java, а также фреймы. Зато работает чрезвычайно быстро. Кроме навигационных целей, его удобно использовать для просмотра простых страничек, создаваемых в kedit'е или kwrite, но об этом позднее

Раз уж здесь зашла речь о браузерах (ведь это тоже в какой-то мере средство работы с файлами) - скажу еще пару слов , что бы потом не возвращаться к этой теме. Вместе с KDE (и встраиваясь в него) в комплекте идет Netscape Communicator версии 4.6. Что про него скажешь - Netscape как Netscape, полный аналог соответствующей по номеру версии для Windows, с Composer'ом и Messager'ом (но, хвала аллаху, без AOL'а, избавиться от которого в Windows - задача не из самых простых). Автоматически устанавливается plug'in для просмотра Shockwave, хотя, скажем, проигрывателя Real'овских файлов или VRML-вьювера - нет. Хотя, возможно, их можно каким-то образом доустановить: попытка запустить RealVideo вызвала предложение это сделать. За отсутствием Сети - проверить не смог.

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

Ну вот, с файлами в первом приближении разобрались. Теперь посмотрим, чем же они (файлы) делаются. Здесь важнейшими для меня являются

StarCalc

Это почти точная копия MS Excel 97, дополненная инструментарием StarOffice (рис. 3). Соответственно, все возможности величайшего таб-процессора здесь имеются, хотя иногда они реализованы несколько по другому. Имеется большое количество всяких функций - математических, финансовых, логических, статистических, управления базами данных и прочие. Я не считал их количество, но на первый взгляд оно более достаточное.

Рис. 3. StarCalc

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

Разумеется, можно вставлять в рабочий лист разнообразные графики, в том числе и трехмерные (рис. 4). Для последних доступно редактирование 3D-эффектов (о чем - ниже).

Рис. 4. StarCalc - трехмерная диаграмма

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

В целом должен сказать, что StarCalc мне очень понравился. Я всегда испытывал теплые чувства к электронным таблицам. Ведь это были первые пакеты общего назначения, которые в давно прошедшие времена мне удалось приспособить для решения своих, весьма специфических, задач. И в этом отношении StarCalc не разочаровывает. С его помощью можно сделать абсолютно все, что удавалось сделать посредством Excel 95/97 или (в более отдаленном прошлом) Lotus 1-2-3 для Windows и Quattro Pro для DOS. Единственно, о чем сожалею - что традиция истинной трехмерности таблиц (как в Lotus 1-2-3 v. 3.0 для DOS и v. 4.0 для Windows - единственных табличных процессорах, где работа с блоками "вглубину" ничем не отличалась от таковой с блоками плоскими) так и не получила развития.

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

StarDraw

Это - весьма приличная векторная рисовалка, тесно интегрированная с презентационной программой (StarImpress). По принципам работы она несколько напоминает CorelDraw. Инструментальная панель слева позволяет создавать прямоугольники и квадраты, в том числе с закругленными углами, овалы и круги, в том числе усеченные, с вырезанными секторами и прочими излишествами, кривые Безье и ограниченные ими полигоны, линии и стрелки. Все замкнутые объекты могут быть залитыми или пустыми. Здесь же, в инструментарии - различные трансформации (вращение, зеркальное отражение и т.д.), горизонтальное и вертикальное выравнивание, перемещение на фронт и в тыл, вставка объектов (диаграмм, формул, растровых картинок, таблиц StarCalc, апплетов и т.д.) и форм (разнообразных кнопок, текстовых полей, чек-боксов, меток и тому подобного). Задержка на каждом виде инструментов при нажатой левой клавише дает доступ ко всем возможным его модификациям. В общем, джентельменский набор обычного уважающего себя векторного редактора и даже несколько больше.

А вот что представляется чуть ли не уникальным - это возможность вставки 3D объектов и их редактирования (рис. 5). Причем не псевдотрехмерных, как в CorelDraw, а истинных, по стандарту OpenGL. И при этом двух видов, названных просто 3D-объектами, и 3D-объектами вращаемыми. Первые - все равно могут вращаться не только в плоскости экрана, но и в перпендикулярной, но их тыльная сторона как бы отсутствует. Тогда как вторые - истинно трехмерные тела.

Рис. 5. StarDraw

Созданные трехмерные объекты могут редактироваться путем применения к ним набора готовых 3D-эффектов - изменения цвета, градиентных заливок, положения, интенсивности и цветовой гаммы источника освещенности, даже наложения текстур. Набор этот неизбежно ограничен, но для любительских целей вполне достаточен, во всяком случае, не намного меньше, чем, скажем в Asymetrix 3Dfx или подобном простом 3D пакете для Windows. Как уже говорилось, те же эффекты могут быть применены и для трехмерных диаграмм из StarCalc.

Изменение атрибутов рисованных объектов осуществляется из меню, доступного по щелчку правой клавишей мыши. Здесь изменение и атрибутов линий и стрелок, и размера и положения объектов, и редактирование точек на кривых Безье, и, главное, конвертация объектов: преобразование правильных фигур в полигоны или кривые, прямых линий - в кривые Безье, плоских фигур - в простые или вращаемые 3D-объекты (обратное преобразование, как будто, невозможно). Интересно, что в трехмерные объекты как бы могут трансформироваться и линии - путем добавления еще одного измерения они становятся фигурами.

В общем, изобразительным средствам StarDraw могут позавидовать не только убогие векторные рисовалки под Linux, но и почтенные графические редакторы для Windows. Однако они портятся одной маленькой особенностью: полной невозможностью работать с русскими текстами. Не потому, что текстовые средства недостаточны. Напротив, помимо аналогов Artistic Text и Paragraph Text из CorelDraw, имеется такая опция, как Callouts, то есть нечто вроде создания подписей с указателями на объекты; последние могут редактироваться точно так же, как линии и стрелки. И не потому, что русские буквы не поддерживаются: из StarDraw доступны все кириллические шрифты Type 1, установленные в системе.

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

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

Рисовалка SratDraw плавно перетекает, если так можно выразиться, в презенташку -

StarImpress

Она имеет точно такой же инструментарий для рисования и всякого рода эффектов. Но, кроме всего, набор шаблонов как презентаций в целом (сгруппированных по назначению - научные, финансовые отчеты, бизнес-проекты), так и отдельных страниц. В общем, как в Lotus Freelance или MS PowerPoint. В состав слайдов презентации могут быть вставлены: текст, в том числе в несколько колонок, рисунки векторные и растровые, диаграммы, электронные таблицы и просто объекты (вроде бы по OLE-технологии). Ну и конечно, доступны всяческие эффекты переходов между слайдами и различные режимы воспроизведения слайд-шоу.

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

StarWriter

Это весьма монументальное сооружение, видом весьма напоминающее Word и такое же нравом ("С отличием окончившие школу профессора Игнатия Лойолы, любимые его ученики" - Ю.Визбор). Даже состав и вид инструментальных панелей (настраиваемых) вызывают воспоминания о лучшем процессоре всех времен и народов (рис. 2). Впрочем, кое в чем ученик, как и положено у хорошего учителя, последнего превзошел. Так, слева от рабочего поля наличествует дополнительная инструментальная панель (с которой доступны операции вставки таблиц, объектов (аналог пресловутого OLE), рисунков и прочего, а также проверка правописания и многое другое, также настраиваемое.

Рис. 2. StaWriter.

Кроме того, здесь же можно включить/выключить дополнительное окно (или, скорее, фрейм), представляющее собой внешне аналог Layont Manager из CorelDraw последних (начиная с 8-й) версий. Через эту конструкцию возможен доступ к адресной книге, закладкам, каталогам рисунков и прочего (т.н. Gallery), шаблонам, рабочему каталогу и т.д.

А в целом StaWriter поддерживает все характерные для современного текстового процессора функции: разнообразное форматирование, стилевые таблицы, в том числе и в применении к отдельным символам, вставку как вновь созданных, так и существующих рисунков (разных форматов), редактор формул, весьма приличный табличный процессор и многое другое. Я бы сказал, что по широте возможностей StarWriter превосходит MS Word (в том числе и 2000-й), приближаясь к WordPerfect (для Windows) предпоследних версий.

Однако эти возможности далеко не всегда реализованы адекватным образом. Это нелегко выразить словами, но чувствуется сразу при любой неэлементарной операции: работа с StarWriter не оставляет ощущения комфортности (даже в не очень критические дни). Разумеется, и MS Wodr, особенно последних версий, в этом отношении не близок к идеалу (ИМХО, последний комфортный текстовый процессор в современной истории - AmiPro 3.1 под Windows 3.1 же), но его заморочки, по крайней мере, привычны. А здесь: создаешь фрейм (или бокс, или как он там называется) под будущий рисунок - и не очень понятно, что же с ним делать дальше.

Однако это так, придирки. Что более существенно - трудности при работе с великим и могучим, добрым и ласковым Русским Словом (часто, кстати говоря, поминаемым).

В принципе StarWriter (и StarOffice в целом) русификации поддается. Для этого достаточно установить набор русских шрифтов Type 1 в кодировках KOI8 и (для совместимости с MS Office) Windows-1251. Каковые, вместе с детальной инструкцией по установке, можно взять во многих местах (см. , а также ). Можно изготовить шрифты и самому - путем конвертации из TrueType. Однако есть несколько осложняющих обстоятельств.

Во первых, ввод русских букв в StarOffice возможен только при раскладке клавиатуры, именуемой "хакерской" (отличной от принятой по умолчанию в, скажем, локализованных вариантах KDE). Само по себе это принципиальным препятствием не является (см. руководство А.Новодворского к Linux Mandrake 6.0/RE), но иногда доставляет некоторые неудобства.

Во вторых (возможно, это исключительно моя заморочка), установленные в каталоге /usr/X11R6/lib/X11/fonts/Type1, шрифты эти прекрасно видны во всех компонентах StarOffice. Кроме, разумеется, StarWriter. Где, чтобы получить какие-никакие русские буквы, требуется прибегнуть к Font Substitution из раздела меню Options - General. Что интересно - в списке заменяющих шрифтов можно видеть все доступное KDE хозяйство, тогда как шрифты заменяемые - только фиксированный набор из поставки (русских среди них, разумеется, нет).

Впрочем, и это неудобство, разумеется, обходимо: достаточно приписать подстановку какого-либо шрифта в KOI8 вместо, скажем, Times (принятого по умолчанию) и Windows-1251 шрифта (для той же совместимости с MS Office) - вместо чего-нибудь другого штатного, - и все в порядке. Приходится только все время помнить, что говоря Paltino - подразумеваем Times ET, а подразумевая Arial KOI8 - говорим Helvetica. Но к этому - нам не привыкать стать.

Более неприятно, что шрифты русские в StarWriter (и прочих компонентах StarOffice) ведут себя весьма странным образом.


Кернинг их принимает совершенно немыслимые формы (вне зависимости от того, включен ли он как таковой или нет). Иные буквы разбегаются на всю строку, а иные - наползают друг на друга, как танки на окопы. Причем для шрифтов Serife (обычно применяемых в длинных документах) это выражено много сильнее, чем для шрифтов Sans Serife. Сначала я грешил на шрифты Type1 собственного производства (изготовленные из шрифтов TrueType подручными средствами), но потом то же самое (и в не меньшей степени) обнаружил и на шрифтах из упоминаемого выше пакета русификации StarOffice. И ведь в других приложениях все эти шрифты, включая и мои самодельные, ведут себя вполне пристойно! Справедливости ради надо заметить, что при импорте текстовых документов этот эффект не проявляется.

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

Дело, однако, на этом не кончается. Тот же StarWriter выступает и в ипостаси html-редактора. С чем на первый взгляд справляется неплохо, поскольку степень его интеграции с WWW выше, чем у MS Office 97 (хорошо это или нет - не знаю, все же сапоги должен тачать сапожник). Однако: генерируемый StarWriter html-код вполне сопоставим с Word'овским по своей неудобочитаемости и изобилию отсебятины вплоть до тэгов <font></font> посреди слова. А русские буквы он просто превращает в esc-последовательности. То есть возможности редактирования html-исходника - нет. Правда, это исправимо посредством программы, которую можно взять .


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

И еще. Одно из декларируемых достоинств StarOffice - полная совместимость с офисом микрософтовским. И это действительно почти так: StarWriter позволяет считывать форматы Word 6, 95 и 97. Запись, правда, возможна только в текстовых форматах DOS, Windows и Mac. Но вообще-то обмен файлами с MS Word возможен через html-формат, хотя это и не самый удобный способ.

К сожалению, все это относится только к файлам, написанным латиницей. Кириллические тексты Word 7/95 считываются и выглядят (при наличии шрифтов Type 1 в кодировке Wondows-1251) более-менее нормально, но тексты из Word 97 - просто теряют русские буквы вообще. Что понятно, поскольку кириллические шрифты в кодировке Unicode - отсутствуют. Конечно, опять-таки возможен обмен через html-файлы и, возможно, в будущем этот способ и может стать основным (после тотальной web-изации всех офисных приложений), но пока - это не предел удобства.

Почти все, сказанное о текстовом процессоре, применимо и к процессору табличному -

Структура awk-программы

Программа состоит из операторов (правил), имеющих

вид:

шаблон {действие}

шаблон {действие}

. . .

Частные случаи:

{действие} - когда действие выполняется для всех

строк.

шаблон - когда выводятся строки с данным шаблоном.

Действие может состоять из последовательности операторов,

разделяемой ";" или переводом строки или закрывающей

скобкой.

Возможны комментарии (как в shell "#.........").

Пример:

Для дальнейших примеров возьмем входной файл "f-awk"

( фамилия инициалы год-приема-на-работу возраст ):

Иванов И.И.	1980		50
Петров А.В.	1979	40
Сидоров С.К.	1979	40
Хведоров И.Х.	1970	60

awk '{print}' f-awk # выдает весь текст;

echo

awk '/до/ {print}' f-awk # выдает строки, где есть "до".

echo

awk '/до/ {}' f-awk # выдает строки, где есть "до"

echo

awk '/до/ {print("Привет!")}' f-awk

Результат:

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

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

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

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

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

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

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

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

Привет!

Привет!

Существует два оператора специального вида ("BEGIN"-начальные

установки и "END" - "последействия"):

BEGIN {действие}

шаблон {действие}

шаблон {действие}

. . .

END {действие}

Структурные операторы

if (условие) {операторы} [else {операторы}]

while (условие) {операторы}

for (выражение; условие; выражение) {операторы}

for (индекс in имя_массива) {операторы}

Структурные операторы в значительной степени аналогичны

соответствующим операторам Си. В последнем случае для каждого

индекса выполняется блок. Текстовые индексы рассматриваются в

лексикографическом порядке.

Примеры

1) awk ' $4~/40/ {if($3<=1980) {print("Фамилия: " $1 )

M["40"]++}}

$4~/50/ {M["50"]++}

END {for(i in M)

{print(" i =" i " M[" i "]=" M[i])}} ' f-awk

Результат:

Фамилия: Петров

Фамилия: Сидоров

i =40 M[40]=2

i =50 M[50]=1

2) awk ' BEGIN {ORS = " "}

{ for(k=NF; k>0; --k) {print $k}

{print RS}

} ' f-awk |

sed 's/^ //'

Результат:

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

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

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

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

Здесь, кроме изменения очередности полей в строке

на противоположное (что делает цикл "for"), предварительно

устанавливается выходной разделитель - пробел и весь результат

предварительно выдается в одну строку, поэтому после обработки

каждой строки выдается команда "print RS" для перевода

выходной строки. Редактор "sed" подключен через конвейер,

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

Если запустить лишь базовую структуру

awk '{ for(k=NF; k>0; --k) {print $k}}' f-awk

то все поля исходной таблицы с изменениями порядка

внутри прежних строк получим вытянутыми в один столбец переводом

строки:

50

1980

И.И.

Иванов

40

1979

А.В.

Петров

40

1979

С.К.

Сидоров

60

1970

И.Х.

Хведоров

Однако, если поставим ";" сразу после условия,

т.е. сделаем пустое тело цикла, за пределы которого вынесен "print

$k"

awk '{ for(k=NF; k>0; --k); {print $k}}' f-awk

то получим исходную таблицу

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

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

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

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

поскольку "$k" после выхода из цикла будет

иметь значение "0", а "$0" - соответсвует

всей строке в качестве значения(!), то "print $k" будет

после каждого цикла печатать полные строки.

Сверьтесь со списком совместимых устройств и программ

Следующим шагом нанесите визит на специально посвященную вопросам совместимости Windows 2000 Web-страницу Windows 2000 Product Compatibility (). Там вы найдете информацию о совместимости ОС с аппаратным и программным обеспечением, а также список конкретных моделей ПК, о которых известно, что они работают с Windows 2000; сейчас он занимает 276 страниц. Если компьютер числится в этом списке, шансы столкнуться с проблемами сравнительно невелики. Если же нет, это еще не повод для паники - установка Windows 2000 все равно может пройти абсолютно гладко.

Предположим, в Microsoft считают ваш компьютер совместимым с Windows 2000. А что можно сказать о подключенных к нему внутренних (дисководы для CD, CD-RW и сменных накопителей, модемы, звуковые платы и т. д.) и внешних (принтеры, сканеры, внешние дисководы и т. д.) периферийных устройствах? Windows 2000 поддерживает намного более широкий спектр аппаратуры, чем NT 4.0, но все-таки отстает по этому параметру от Windows 9x. Из всех протестированных нами устройств особенно много хлопот нам доставили сканеры и некоторые цифровые фотоаппараты с интерфейсом USB (см. раздел "Последствия модернизации"). Чтобы избежать неприятных сюрпризов после установки Windows 2000, проведите инвентаризацию своих периферийных устройств и проверьте их по списку совместимой аппаратуры на Web-узле Microsoft (). Можно также поискать информацию на упомянутой выше странице Windows 2000 Product Compatibility. Несколько более старая версия того же списка имеется на инсталляционном диске Windows 2000.

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

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

Свободному ПО двадцать лет: что дальше?

Ричард Столлман, ZDNET Россия

Источник: Richard Stallman. Twenty years of free software: What now?

6 января 2004 г.

Сегодня ровно 20 лет, как я оставил свою работу в МТИ, чтобы начать разрабатывать свободную операционную систему GNU. Хотя мы так и не выпустили функционально полную систему GNU, годную для промышленного использования, одним из вариантов системы GNU сейчас пользуются десятки миллионов людей, которые, по большей части, об этом не знают. Свободное ПО не значит "бесплатное"; оно означает, что пользователь свободен запускать программу на исполнение, изучать исходный код, изменять его, и распространять с изменениями или без таковых, даром или за плату.

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

Несвободное ПО несёт с собой антиобщественную систему, запрещающую сотрудничество и объединение. Вы, обычно, не можете увидеть исходный код; вы не можете сказать, какие грязные трюки или какие дурацкие ошибки оно может содержать. Если оно вам не нравится, вы не в силах его изменить. Что хуже всего, вам запрещено разделять его с кем бы то ни было. Запретить делиться программными продуктами, значить разрубить связующие звенья общества.

Сегодня у нас есть большое сообщество пользователей, которые пользуются GNU, Линукс и другим свободным ПО. Тысячи людей хотели бы расширить его и поставили себе цель убедить большее число пользователей компьютеров "использовать свободное ПО". Но что это значит, "использовать свободное ПО"? Значит ли это уход от собственнического ПО, или просто установку свободных программ вместе с ним? Намерены ли мы вести людей к свободе или мы всего лишь знакомим их с нашей работой? Иными словами, работаем ли мы ради свободы или же мы подменили эту цель пустой целью завоевать популярность?

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

Например, что мы должны сказать, когда несвободный видео драйвер Invidious, несвободная база данных Prophecy или несвободный переводчик с Индонезийского языка с библиотеками выпускаются в версии, которая запускается под GNU/Линукс? Должны ли мы благодарить разработчиков за такую "поддержку" или следует рассматривать подобную несвободную программу как любую другую - как привлекающую внимание помеху, искушение попасть в зависимость, задачу, требующую решения?

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

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

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


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

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

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

Copyright © 2004 Richard Stallman
Verbatim copying and distribution of this entire article are

permitted world wide without royalty provided this notice is preserved.

Авторские Права на Перевод © 2004 Сергей А. Середа, © 2004 Движение ПОтребитель. Все права защищены. За дополнительной информацией обращайтесь на consumer.cjb.net

*Здесь Столлмен использует игру слов: Invidious - Враждебный, Prophecy - Пророчество.

Свойства надежности

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

Сокращается объем ущерба, который может быть причинен любой ошибкой.

Имеется возможность восстановления после распространенных сбоев.

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

Объекты и счетчики.

Объект: Счетчик Объект контроля Порядок использования

Process: Working Set (Процесс: Рабочее пространство)	Количество потребляемой процессом физической оперативной памяти.	Непрерывный контроль использования приложением памяти и выявление утечки памяти.
Process: Pagefile Bytes (Процесс: Байт файла подкачки)	Количество памяти, которое процесс использует в файле подкачки.	Непрерывный контроль использования приложением всей доступной памяти.
Memory: Committed Bytes (Память: Байт выделенной виртуальной памяти)	Общий размер выделенной виртуальной памяти, которую в данный момент занимают все пользовательские процессы.	Позволяет установить момент начала роста файла подкачки (путем сравнения с Commit Limit).
Memory: Commit Limit (Память: Предел выделенной виртуальной памяти)	Расчетная величина, которая определяет, какое количество виртуальной памяти система может выделить, не увеличивая размера файла подкачки.	Помогает выяснить, насколько размер файла подкачки соответствует системным требованиям. Используется для расчета значений счетчика %Commited Bytes In Use.
Memory: % Committed Bytes In Use (Память: %использования выделенной памяти)	Соотношение величин счетчиков Commited Bytes и Commit Limit.	Позволяет установить момент начала роста файла подкачки.
Process: % Processor Time (Процесс: %загруженности процессора)	Степень использования процессора заданным процессом.	Позволяет выявить наиболее загружающие процессор приложения.

Каталоги и символические ссылки на каталоги, содержащиеся в /usr.

bin	Основное место для размещения исполняемых файлов системы. /usr/bin/X11 должен быть символической ссылкой на /usr/X11R6/bin, если последний существует. Интерпретаторы языков Perl, Python и Tcl должны вызываться из /usr/bin (можно оставить только символические ссылки на действительное местоположение интерпретаторов).
include	Место, где должны быть размещены все системные подключаемые файлы общего пользования для языка Cи, в частности файлы заголовков. Символическая ссылка /usr/include/X11 должна указывать на /usr/X11R6/include/X11, если последний существует.
lib	Содержит объектные файлы, библиотеки и внутренние исполняемые файлы, которые не могут вызываться непосредственно пользователями из командной строки или скриптов оболочки. Приложения могут использовать отдельные подкаталоги в /usr/lib. Если приложение использует подкаталог, все архитектурно-зависимые данные, используемые только этим приложением, должны размещаться внутри этого подкаталога. (Например: подкаталог perl5 для модулей и библиотек Perl 5.)
local	Каталоговая структура для локально устанавливаемых программ.
sbin	Системные команды, используемые исключительно системным администратором, не являющиеся жизненно-важными для системы и поэтому не попавшие в /sbin. Локально устанавливаемые программы для системного администрирования должны размещаться в /usr/local/sbin.
share	Архитектурно-независимые данные.
X11R6	Структура для X Window. Для некоторого упрощения и сохранения совместимости XFree86 с системой X Window для других типов операционных систем должны быть созданы следующие символические ссылки, если только каталог /usr/X11R6 существует: /usr/bin/X11 -> /usr/X11R6/bin /usr/lib/X11 -> /usr/X11R6/lib/X11 /usr/include/X11 -> /usr/X11R6/include/X11 Приложения, которым необходима информация о текущей конфигурации хоста, должны искать ее в каталоге /etc/X11, куда могут быть сделаны ссылки из каталога /usr/X11R6/lib.
games	Игры и обучающие программы.
lib<qual>	Библиотеки для альтернативных форматов.
src	Исходные тексты программ.

Такие разные файлы

Осталось выяснить, что такое файл блочного устройства. Для этого следует рассказать о том, какие вообще "звери" встречаются в файловой системе. Очевидно, там есть обычные файлы и каталоги, но это далеко не все. Файлами с точки зрения Linux являются также:

символьные устройства;

блочные устройства;

именованные каналы (named pipes);

гнезда (sockets);

символьные ссылки (symlinks).

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

Task Manager

Просмотр текущих запущенных задач обязан быть удобным. Если использовать стандартную утилиту UNIX под названием ps, то вы узнаете все, что хотите, но, конечно, основательно повозитесь, отыскивая и сравнивая идентификаторы процессов. Обычный пользователь должен быть огражден от подобной канители. Удобный менеджер задач Task Manager значительно облегчает просмотр процессов в памяти, показа их отношений типа "родительский - порожденный" между ними в виде иерархического дерева. Фильтр позволяет определить, какие задачи нужно отображать: только пользовательские или только системные. Кроме того, "по совместительству" Task Manager работает как измеритель использования системных ресурсов.

Типичные неприятности

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

ЭКРАН 1: Содержимое "голубого экрана смерти" - blue screen of death в Windows NT

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

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

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

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

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

Три совета

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

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

Установив кириллические шрифты из русифицированных дистрибутивов Linux, сразу же уменьшите все размеры знаков на две точки, поскольку кириллица размером знаков в 10 точек будет равна по высоте буквам английского шрифта в 12 точек.

"Уборка мусора"

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

Порой возникает необходимость удаления файлов и параметров реестра, относящихся к конкретному пользователю. Так, если мастер обновления пакетов запущен в сеансе работы пользователя jsmith, не исключено, что он запишет изменения реестра в раздел HKEY_USERS\jsmith или включит установленные файлы в профиль jsmith.

Если при развертывании установочного пакета пользователь предусматривает возможность его удаления, установщик добавит в реестр раздел Uninstall, который используется значком Add/Remove Programs панели управления. Если пакет предназначен для приложения, которое уже поддерживает режим удаления, следует убрать из меню Start значок программы Uninstall, чтобы исключить возможность доступа к двум разным методам удаления.

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

Удаленное управление

Сложность удаленного администрирования сервера Windows NT всегда тяготила меня. Хотя опытные администраторы и освоили такие трюки, как использование RCMD (Remote Command Service, RCMD.EXE) в сочетании с программами regini или regedit, все равно удаленное администрирование Windows NT сильно отличается от своего локального аналога. В любом случае требуется освоение специального инструментария. Это связано с тем, что операционные системы персональных компьютеров всегда были тесно привязаны к локальным клавиатуре и дисплею. В самом деле, до недавнего времени большинство "персоналок" не подключались к сети и, следовательно, не нуждались во взаимодействии с другими клавиатурами или мониторами.

Что касается Linux, то она изначально приспособлена к дистанционному управлению, поскольку произошла от UNIX. Первыми UNIX-машинами были дорогие мини-компьютеры, к которым через последовательные порты подключалось множество терминалов. Единственным различием между локальным и удаленным соединением была более высокая скорость локальной связи (от 4800 бит/с до 19 200 бит/с) по сравнению со скоростью коммутируемого доступа (110, 300 или 1200 бит/с). При этом в обоих случаях применялось одно и то же коммуникационное программное обеспечение, независимо от того, подключен терминал напрямую или через пару модемов и телефонную линию. Даже сегодня, когда UNIX обзавелась графическим интерфейсом, установка сеанса связи остается одинаково простой на удаленной и локальной машине (при условии, что пользователь имеет право на запуск сеанса с удаленного хоста). Таким образом, если для управления расположенным в другой стране компьютером с Linux мне нужно лишь подключиться к нему с помощью программы telnet, то для решения той же задачи с сервером NT придется в эту страну съездить.

Уязвимость реестр

Злоумышленник может попытаться получить администраторские полномочия различными окольными путями, которые можно перекрыть простым изменением конфигурации и разрешений. Во-первых, в реестре есть несколько ключей, содержащих текст, интерпретируемый системой как команда, которую нужно запустить при регистрации пользователя. По умолчанию списки контроля доступа (Access Control List, ACL) для этих ключей слишком широки. Например, когда пользователь регистрируется в системе, NT проверяет раздел HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Windows\CurrentVersion\Run, после чего исполняет каждое текстовое значение, содержащееся в ключе, как команду с привилегиями зарегистрировавшегося пользователя. Непривилегированный пользователь может добавить в этот раздел свои команды и дождаться, когда администратор зарегистрируется в системе. Когда это произойдет, команды, указанные злоумышленником, будут исполнены уже от имени администратора. Команды при этом могут делать все что угодно - от добавления взломщика в группу Administrators до изменения прав доступа к жизненно важным каталогам системы. По умолчанию группа Everyone имеет право Set Value в данном разделе. Очевидно, это право необходимо отменить. Имеются и другие разделы реестра, подвергающие риску систему защиты, хотя способ "взлома" в каждом конкретном случае может оказаться достаточно сложным. Полный список подобных разделов и рекомендации по их защите можно найти в работе признанного эксперта по вопросам безопасности NT Стива Саттона "Windows NT Security Guidelines" (http://www.trustedsystems.com).

Как и в случае с другими мерами по укреплению защиты, выполнение рекомендаций, связанных с повышением безопасности доступа к разделам реестра, может вызвать проблемы совместимости с плохо написанными приложениями, работа которых была рассчитана на незащищенную конфигурацию системы. Такие ситуации особенно часто возникают на рабочих станциях. Я бы рекомендовал в целях повышения безопасности уделить внимание прежде всего серверам и контроллерам доменов, которые должны по определению соответствовать более строгим требованиям в этом отношении, чем рабочие станции, в частности, и потому, что интерактивный запуск приложений на серверах и контроллерах доменов случается значительно реже.
Файлы операционной системы в каталоге \%systemroot% (чаще всего C:\Winnt) с назначенными по умолчанию разрешениями также уязвимы для несанкционированных изменений. Непривилегированные пользователи могут заменить критически важные файлы операционной системы своими версиями, которые система будет исполнять в привилегированном режиме. Список каталогов, которые содержат подобные файлы, и рекомендованные изменения списков контроля доступа приведены в многочисленных публикациях (например, в упоминавшейся выше книге Стива Саттона "Windows NT Security Guidelines").

Защита реестра и каталогов операционной системы начинается с ограничения удаленного доступа к ним. С помощью одного-единственного раздела реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Control\SecurePipeServer\winreg можно указать, кто имеет право удаленного доступа к реестру (независимо от разрешений для конкретных разделов). Дополнительную информацию об ограничении удаленного доступа к реестру можно найти в статье "How to Restrict Access to NT Registry from a Remote Computer" (http://support.microsoft.com/support/kb/ articles/q153/1/83.asp). Важно убедиться, что пользователи не могут получить удаленный доступ к каталогам операционной системы благодаря неосторожно созданным общим ресурсам. Следуя приведенным выше простым рекомендациям, можно ограничить круг лиц, способных внести изменения в реестр и файловую систему.

Уязвимость встроенной учетной записи администратора

В одной из своих статей я уже отмечал, что сама природа встроенной учетной записи Administrator делает NT уязвимой в отношении атак, направленных на "взлом" административной учетной записи. Нельзя просто взять и удалить эту всемогущую запись, так что злоумышленник знает наверняка, чей пароль нужно взламывать. К тому же по умолчанию NT не выполняет блокировку учетной записи Administrator после нескольких неудачных попыток регистрации, даже если установлен режим блокировки учетной записи после определенного числа таких попыток с помощью утилиты User Manager (команда Policy, Account). К счастью, положение можно исправить. Во-первых, нужно запустить утилиту Passprop с параметром /ADMINLOCKOUT (эта утилита из состава Microsoft Windows NT 4.0 Resource Kit впервые появилась в Service Pack 3). В результате на учетную запись Administrator будут распространяться те же ограничения установленной учетной политики, что и на остальные учетные записи.

Следующий шаг - переименовать учетную запись Administrator, чтобы лишить злоумышленника очевидной цели. Вместе с тем, если ограничиться простым переименованием, безопасность окажется мнимой. Например, известная программа RedButton использует анонимные соединения для перебора всех учетных записей и может найти переименованную учетную запись по ее идентификатору системы защиты SID, который никогда не меняется. Для защиты от подобного рода атак следует установить сервисный пакет SP3 и активизировать параметр реестра RestrictAnonymous. Нужно иметь в виду, что это действие может привести к некоторым проблемам в работе службы Computer Browser. После переименования встроенной учетной записи Administrator следует изменить поля Description и Full name, поскольку их значения по умолчанию раскроют истинную роль переименованной учетной записи. Многие системные администраторы идут еще дальше по пути маскировки встроенной административной учетной записи и создают учетную запись - "приманку". Эта запись не имеет никаких полномочий, но обладает всеми внешними атрибутами встроенной административной записи - в частности значениями по умолчанию в полях Description и Full name. Постоянный мониторинг процесса регистрации по данной учетной записи поможет выявить скрытые попытки проникновения в систему.

Укрощение бесконечных циклов

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

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

Унификация прерываний и сообщений

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

УНИВЕРСАЛЬНАЯ ОБЩЕСТВЕННАЯ ЛИЦЕНЗИЯ GNU

Версия 2, июнь 1991 г.

Copyright (C) 1989, 1991 Free Software Foundation, Inc.

59 Temple Place, Suite 330, Boston, MA 02111--1307, USA

Copyright (C) перевод на русский язык,

1993 Кузина О.В., Юфа В.М.

1998 Тихонов О.С.

Всем разрешается копировать и распространять дословные копии этого

лицензионного документа, но изменять его нельзя.

UNIX, Usenix, Монтерей: Техническая конференция Usenix в 1999 г.

Сергей Кузнецов

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

Во-первых, для чего я ездил на эту конференцию. Если вы помните, в конце весны этого года издательство "Открытые системы" организовало первую конференцию OpenForum. Форма проведения конференции без потребности уплаты регистрационных взносов при наличии достаточно насыщенной технической программы и интересных семинаров-презентаций компаний-спонсоров позволила привлечь к участию в конференции более 400 человек. Было особенно приятно, что практически все участники были действительно заинтересованы тематикой конференции. Мы приняли решение провести следующую конференцию в конце февраля 2000 г. и, чтобы сделать ее еще более интересной и привлекательной, привлечь приглашенных докладчиков из Usenix. Основная цель моей поездки, которая финансировалась "Открытыми системами" и Usenix, состояла в том, чтобы договориться с руководством Usenix и с потенциальными докладчиками. Похоже, что все удалось сделать.

Usenix имеет долговременное соглашение с компанией Marriot, поэтому все технические конференции (а на них в среднем собирается около 1000 участников) проходят в разных городах Соединенных Штатов, но всегда в гостиницах Marriot. В этом году местом проведения конференции был выбран небольшой городок Монтерей, расположенный на берегу Тихого Океана (вернее, на берегу залива Monterey Bay). Я не слишком большой знаток тихоокеанского побережья США, но более чистого и живописного места в Калифорнии я не видел.

Как я уже говорил, Монтерей - это небольшой городок. Он прижат к океану и поэтому вытянут миль на тридцать в длину.
Если вы из любопытства посмотрите на схемы города на сайтах www.monterey.org или www.monterey.com, то убедитесь, что по этим схемам абсолютно невозможно оценить расстояние между интересующими пунктами. Это меня и подвело. В этот раз мне пришлось самому заказывать гостиницу, и, конечно, я решил делать это через Internet. Поскольку мне нужна была гостиница подешевле, а в очевидном центре Монтерея в таких гостиницах уже не было мест, я соблазнился районом Pacific Grove, который, как казалось по схеме, находится не так уж далеко от центра.

Добравшись до аэропорта Монтерей (а это заняло более 20 часов с посадкой в Сиетле и со сменой самолета в Лос-Анжелесе), я взял такси и попросил доставить меня по нужному адресу (бульвар Асиломар, 1500). Первые подозрения возникли, когда вместо обещанных в Internet 12 долларов шофер попросил у меня 21 бакс. Потом, когда машина уже уехала я долго осматривался вокруг и спрашивал прохожих, а где же здесь все-таки отель Sunset Inn. В результате удалось выяснить, что нахожусь-то я в том самом конференц-центе Асиломар, где в прошлом году проходило известное собрание специалистов по базам данных (см. Асиломарский отчет). Мне стало ясно, что я несколько ошибся в своих оценках размеров города Монтерей, я сунулся в reception ближайшей гостиницы и попросил вызвать еще одно такси, шофер которого был бы в состоянии довести меня до Sunset Inn. Слава Богу, такой шофер нашелся. (Кстати, во время моих поисков я первый раз увидел на пригорках Монтерей ланей, которые совершенно свободно и безбоязненно гуляют и кормятся травкой. А может быть, это и не лани, а мелкие олени. Позднее я их часто встречал. Глупые до ужаса. Машин не боятся совершенно. Прославленная в России глупость кур - это ничто по сравнению с глупостью монтерейских ланей. Но лани гораздо красивее.)

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


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

У меня был свободный день перед началом конференции. Утром имелись две проблемы. Во-первых, я забыл взять с собой сигарет, а как выяснилось, в Pacific Grove их не продают в принципе. Во-вторых, мне очень хотелось знать, можно ли вообще добраться пешком до Марриота. Поэтому где-то в 6 часов утра я облачился в подобающую (по моему мнению) Калифорнии одежду (шорты, майка, тапочки на босу ногу) и двинулся в путь. Благо, что виднелась только одна хотя бы теоретически подходящая дорога (Lighthouse). Как выяснилось потом, это самая длинная улица в Монтерее. Когда я вышел на улицу, мне показалось, что несколько прохладно, но я отнес это на слишком раннее время и отправился в путь.

Сначала был длинный подъем на горку, потом длинный-длинный спуск. Я думал, что после спуска уже попаду в настоящий Монтерей, но увидел надпись, что это всего-навсего центр City of Pacific Grove. Потом я долго шел, пока не решил повернуть к самому берегу залива. И как оказалось, повернул очень вовремя, потому что вышел на велосипедно-прогулочную дорожку, с которой было видно солидное здание, напоминающее по моим понятием отель Марриот. (Так оно и оказалось.) По дороге к Марриоту проходишь мимо одной из пристаней для яхт (американцы называют такие места marina). Около берега там небольшая бухточка с каменистыми островками. И на этих островках постоянно лежат тюлени (а может быть, морские львы, я не большой специалист). Наверное, там проживает одно стадо (гарем), поскольку только один, самый большой, тюлень все время очень громко кричит. Почти на весь Монтерей.

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


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

Моим родственникам и друзьям известно, что я не могу долго сидеть на месте. Поэтому вскоре после прихода я надел длинные брюки, рубашку, ботинки с носками и пиджак и снова пошел в Монтерей. Я уже не мерз, шел не спеша, разглядывал окрестности, сидел на лавочках, курил и наслаждался жизнью. Кстати, времени было все еще меньше 11-ти утра. (Интересно, что во всех Штатах, похоже, запретили курить в любом общественном помещении. Только на улице или в специально отведенных комнатах. При этом пачка Marlboro теперь стоит 4 бакса.)

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

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

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


Он называется Old Fishmen Walf. Сто лет тому назад это был главный рыболовный причал в Монтерее. (Рыбы-то там и сейчас ловят изрядно. Мне показалось, что насчет рыбы Монтерей находится полностью на самообеспечении.) Теперь это туристический причал. На нем расположено множество мелких и не очень мелких магазинчиков, ресторанчиков, баров и т.д. В силу своих личных гастрономических предпочтений я сразу обратил внимание на несколько устричных баров, работающих прямо на улице. В этот и следующие дни в Монтерее я хорошо познакомился с их работниками (и с их устрицами тоже). Кроме того, к этому же причалу пристают туристические суденышки, на которых можно прогуляться по заливу или даже отправиться ловить рыбу. И снова я был совершенно удивлен, когда рядом с одним из корабликов увидел не только того самого орущего тюленя, но и составлявших ему компанию пеликанов. Никогда не знал, что пеликаны живут и в Калифорнии. У нас принято считать, что для них больше подходит Флорида. Так вот, живут! И плавают совершенно наравне с чайками и утками, и дерутся с ними, если кто-нибудь бросит рыбку.

Это был хороший день. К вечеру я так умотался, что опять лег спать часов в 8 вечера. А назавтра, 9-го июня начиналась конференция Usenix. Имея уже некоторый опыт перемещения по Монтерею и узнав о наличии одного автобуса, останавливающегося недалеко от моей гостиницы (так называемый Visitor Shuttle), я решил, что на конференцию я отправлюсь на этом автобусе. Как было написано на табличке, автобусы ходят с интервалом в 30 минут, начиная с 9 утра. Этот маршрут не доходит до Марриота, только до Аквариума, но все-таки оттуда гораздо ближе.

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


До Аквариума автобус идет минут 10, оттуда до Марриота 20 минут хода. Итого (фууу…) в половине одиннадцатого я добрался до конференции (это было 9 июня 1999 г.). Там как раз закончился первый доклад (Keynote Address) Джона Ойтерхута из Scriptics Corporation и народ вывалил в фойе и на улицу пить кофе и есть всякие выпечки. (Кстати, как мне потом говорили, этот доклад был не очень интересным.) Дальше конференция проходила в виде трех параллельных треков: отобранные (резенцированные) доклады, приглашенные доклады и трек под названием Freenix. Этот последний трек был целиком посвящен свободно распространяемому программному обеспечению и доклады отбирались отдельным программным комитетом.

Поскольку ассоциация Usenix обеспечила мне свободную (бесплатную) регистрацию, я просто подошел к офису оргкомитета, представился и получил стандартный набор участника конференции: два тома трудов конференции (отобранных докладов и Freenix), три CD-ROM (среди них только что выпущенный диск с текстами и бинарными кодами FreeBSD) и всякой мелочью. Став, наконец, полноценным участником конференции, я стал соображать, на какой трек сначала идти. На первой рабочей сессии на треке отобранных докладов обсуждалась тема управления ресурсами, на треке приглашенных докладов был представлен доклад про IP-телефонию, а темой трека Freenix были файловые системы.

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

После перерыва я решил отправиться на трек приглашенных докладов, где должен был состояться доклад Аллисон Манкин из USC/ISI о перспективах перехода к использованию IPv6.


Это очень интересная тема, и докладчица была весьма эрудированной (она с самого начала участвовала в разработке IPv6), но говорит она очень плохо. Тихо, невнятно и т.п. Поэтому неудивительно, что минут через 20 после начала доклада (а каждый приглашенный доклад длился полтора часа) публика начала потихоньку расходиться. Я честно выдержал 40 минут.

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

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

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

Между прочим, года три тому назад я был на конференции Usenix в Новом Орлеане. Там тоже был прием в местном аквариуме.


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

Замечу, что в этот день я встретил довольно много старых знакомых: Питер Салус, Дэвид Тилбрук, ребята из Англии и Чехии и т.д. Немного встревожило отсутствие исполнительного директора Usenix Элли Янг, которая мне была нужна больше всех.

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

Естественно, со своим пешим хождением я никак не мог попасть на первую сессию конференции, которая начиналась в 9 часов утра. 10-го июня я решил сначала пойти на трек Freenix, где обсуждались проблемы бизнеса в связи с Free Software. Мне понравились два доклада. Вилфредо Санчес (Apple Computers) рассказывал про опыт использования BSD в коммерческих операционных системах своей компании. В очень интересном докладе Дональда Розенберга речь шла про различные варианты лицензирования свободного программного обеспечения.

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

В завершение дня я снова пошел на трек Freenix на доклады по тематике ядра. Честно говоря, там мне ничего особенно не понравилось, разве что доклад Крейга Метса про опыт переноса сетевых подсистем в среду четырех вариантов BSD и Linux. Но даже это не слишком впечатлило.

В четыре часа дня 10-го июня выставка закрылась. Она была не очень большая (около 30 стендов), и известные в России компьютерные компании представлены не были.


Было несколько стендов компаний-производителей свободного программного обеспечения - Free Software Foundation, Red Hat Software и т.д. и очень широко были представлены компьютерные издательства: Прентис Холл, О'Рейли, Морган Кауфманн, Эддисон Весли и т.д. На всех стендах издательств продавались книги, причем для Usenix дается хорошая скидка. В общем, это была веселая многолюдная тусовка.

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

В последний день (11 июня) я был на двух сессиях. Сначала пошел на трек приглашенных докладов, где выступал Джеффри Могул (Compaq Western Research Corp.). Он является активным участником IETF и был одним из основных разработчиков HTTP/1.1. В докладе была представлена личная точка зрения автора относительно слабых сторон HTTP и полученных уроках. Очень интересная тема, но снова качество презентации было не на высоте. И, наконец, последний приглашенный доклад делал Питер Салус. Он является одним из наиболее авторитетных историографов UNIX (конечно, этим не исчерпывается круг его интересов). В докладе Питер подчеркнул, что в этом (1999-м) году мы отмечаем двойной юбилей - 30 лет UNIX и Internet. В совершенно замечательном стиле он представил параллельные очерки истории этих двух явлений. На мой взгляд, доклад Салуса был самым интересным на конференции. Питер так завел публику, что последние 30 минут ему просто не давали говорить. Непрерывно поступали вопросы, дополнения, замечания. Думаю, что в России это длилось бы несколько часов. Но дисциплинированные американцы закончили ровно через полтора часа.

Я встретился с Элли Янг. Мы договорились об участии приглашенных докладчиков Usenix в следующей нашей конференции Open Forum. Мне особенно приятно, что согласился приехать Питер Салус. Думаю, что он понравится нашей аудитории. Кроме того, обещал приехать Дэн Клейн, наш старый друг и отличный докладчик. Мы имеем все шансы иметь хорошую конференции в феврале 2000 г.

Последние два дня (суббота и воскресенье) были у меня свободными и слились в один день.


Я обошел весь Монтерей, нашел стадо диких гусей в центре города у пруда. Они тоже никого не боятся, подходят к самым ногам. Добрался до пляжа. Там громадный пляж шириной метров в 100. Но холодно в Монтерее, никто, естественно, не купается.

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

Вечером в воскресенье я решил пойти домой в обход вдоль берега. Шел долго, часа три. И понял, что полюбил Монтерей. Это прекрасное, дивное, скучное место.

А утром в понедельник я уехал в аэропорт и улетел в Вашингтон. Но это, как говорили классики, уже совсем другая история.

Управление электропитанием

В состав Windows 2000 включена утилита Power Options. Она запускается из папки Control Panel и позволяет устанавливать параметры управления электропитанием, знакомые владельцам портативных компьютеров. Используемый по умолчанию режим Always On (никогда не отключать питание) является вполне оправданным для серверов: хотя отключение монитора после 20 (или менее) минут бездействия пользователя и не представляет особой опасности, но сам компьютер и диски должны функционировать постоянно. Для рабочих станций можно порекомендовать более жесткие установки. Например, в целях экономии электроэнергии и предотвращения излишнего повышения температуры воздуха в помещении можно отключать системные диски и видеосистему, если пользователь не проявлял активности в течение продолжительного времени.

Условия проверки пакетов, которые можно задавать в правилах:

Адреса отправителя и получателя могут быть заданы, соответственно, после параметров '-s' и '-d', в следующих формах:

в виде символического адреса (localhost, www.kernel.org и т.п.)

в виде IP-адреса (127.0.0.1)

в виде IP-адреса с маской в виде четырех десятичных чисел (1.2.3.0/255.255.255.0 - означает все адреса от 1.2.3.0 до 1.2.3.255)

в виде IP-адреса с битовой маской (1.2.3.0/24 эквивалентно 1.2.3.4/255.255.255.0, а 1.2.3.4/32 эквивалентно 1.2.3.4/255.255.255.255). Если маска после адреса не указана, то подразумевается /32, то есть правило распространяется только на сам указанный адрес. Чтобы указать любой адрес, можно использовать маску 0, сам адрес при этом может быть любым, хотя обычно тоже используется 0:

ipchains -A input -s 0/0 -j DENY

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

Инверсия условия: многие условия (в частности, -s и -d) допускают инвертирование путем указания '!' перед параметром. Например, чтобы указать все пакеты, кроме пришедших с localhost, надо использовать параметр '-s ! localhost'

Протокол ('-p') может указываться в виде названия (большими или маленькими буквами) - TCP, UDP, ICMP, или в виде номера (см. /etc/protocols). К протоколам также может применяться инверсия: '-p ! TCP'

означает любой протокол, кроме TCP.

Для протоколов TCP и UDP в параметрах '-s' и '-d' после адреса могут указываться номера портов. Порты могут указываться в виде символического имени, например, www (см. /etc/services), в виде десятичного номера (например, 80) и в виде диапазона (80:82 включает порты 80, 81, 82). Если в диапазоне пропущена нижняя граница, то подразумевается 0 (например, :19 означает все порты с 0 по 19 включительно), если верхняя, то подразумевается 65535. Если порт не указан вовсе, то подразумеваются все.
К портам также может применяться инверсия: '-p TCP -d 0.0.0.0/0 ! www'

означает все пакеты протокола TCP, кроме адресованных на 80 порт.

Внимание! Условие '-p TCP -d ! 192.168.1.1 www'

сильно отличается от '-p TCP -d 192.168.1.1 ! www'

Первое означает любой TCP-пакет на www-порт любой машины, кроме как на 192.168.1.1. Второе означает любой TCP-пакет на любой порт машины 192.168.1.1, кроме порта www.

А запись '-p TCP -d ! 192.168.1.1 ! www'

означает любой TCP-пакет, кроме адресованных на любой порт машины 192.168.1.1 и кроме адресованных на www-порт любой машины.

Для протокола ICMP могут указываться тип (type) и код (code) ICMP-пакетов. Тип может указываться после адреса в параметре '-s', а код - в параметре '-d'. Они могут указываться в виде чисел, а тип - и в виде символического имени. Чтобы получить список символических имен типов, наберите команду ipchains -h icmp

Вот небольшая таблица наиболее распространенных типов ICMP-пакетов: Номер типа: Название: Кем используется: 0 echo-reply ping 3 destination-unreachable любой TCP/UDP-трафик 5 redirect маршрутизация в отсутствие демона маршрутизации 8 echo-request ping 11 time-exceeded traceroute

В текущей версии ipchains имена типов не могут инвертироваться с помощью '!'.

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

Интерфейсом называется физическое или логическое устройство, через которое могут приниматься или передаваться пакеты. Чтобы узнать, какие интерфейсы присутствуют в вашей машине и активны (up), воспользуйтесь командой ifconfig. Параметр '-i' позволяет задать проверку интерфейса в правиле.

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


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

Вполне допустимо при задании правил указывать неактивный (down) или вообще отсутствующий в данный момент интерфейс. Такое правило просто не будет соответствовать ни одному пакету, пока интерфейс не активизируется.

Можно указать сразу некоторую группу интерфейсов, написав '+' после имени. Так, '-i ppp+' означает все интерфейсы, имена которых начинаются с 'ppp' (в том числе, и не существующие на момент задания правила).

К интерфейсам также применима инверсия: '-i ! eth0' означает все интерфейсы, кроме eth0.

Иногда бывает полезно разрешить создание TCP-соединений только в одну сторону (например, из локальной сети в остальной интернет, но не наоборот). Фильтрация пакетов только по адресам здесь не поможет, потому что TCP-соединение требует передачи пакетов в обе стороны. Решение состоит в том, чтобы уничтожать пакеты с запросом на установку соединения, идущие в нежелательную сторону.

Пакеты с запросом на установку TCP-соединения отличаются тем, что у них установлен флаг SYN, а флаги FIN и ACK сброшены, и по традиции называются SYN-пакетами. Проверка этого условия включается флагом '-y'. Он допустим только в правилах с указанным протоколом TCP, например: -p TCP -s 192.168.1.1 -y

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

Иногда случается так, что пакет превышает максимально возможный размер для передачи по некоторому каналу (MTU - maximum transfer unit). В этом случае он разбивается на несколько пакетов (фрагментов), которые посылаются по отдельности. Это называется фрагментацией (fragmentation). На принимающей стороне фрагменты собираются обратно (дефрагментация - defragmentation).

Проблема состоит в том, что некоторые данные, необходимые для проверки условий фильтрации, содержатся только в первом фрагменте (в частности, порт отправителя, порт получателя, тип ICMP, код ICMP, TCP флаг SYN).


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

Если ваша машине не дефрагментирует транзитные пакеты, то фильтрация будет работать так: если правило содержит проверки информации, которая отсутствует во фрагменте, то условие считается не выполненным, и правило не срабатывает. Таким образом, первый фрагмент обработается как любой нефрагментированный пакет, а все остальные фрагменты - нет. Например, условие '-p TCP -s 192.168.1.1 www'

не сработает на втором и последующих фрагментах пакета. Но также не сработает и обратное условие: '-p TCP -s 192.168.1.1 ! www'

поскольку во втором и последующих фрагментах вообще нет информации о номере порта.

Вы можете указывать правила для второго и последующих фрагментов с помощью флага '-f'. Очевидно, его нельзя применять вместе с номерами портов TCP/UDP, типом и кодом ICMP, и TCP SYN флагом, поскольку эта информация во втором и последующих фрагментах отсутствует. Можно также указать, что правило не применяется ко второму и последующим фрагментам, указав '!' перед '-f'.

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

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

Следующий пример уничтожает фрагменты, адресованные на 192.168.1.1: ipchains -A input -f -d 192.168.1.1 -j DENY

Условные операторы

Каждый, кто когда-либо занимался программированием, понимает, насколько важна конструкция if...then. Не удивительно, что операторы условного перехода оказались востребованными большинством пользователей SMS Installer. Они могут пригодиться для решения, например, такой задачи, как настройка пакета в зависимости от типа операционной системы. Кроме того, эти средства помогут завершить процесс установки в случае отсутствия в системе некоторого приложения или выполнить различные действия в зависимости от учетной записи пользователя.

ЭКРАН 4. Использование специальных операторов.

В конструкциях If/While можно применять специальные операторы (например, Equals, Contains), позволяющие сравнивать переменную с заданным значением (см. Экран 4). Сценарий будет использовать результат сравнения для запуска блока If или цикла While, внутри которого описаны операции, подлежащие выполнению при удовлетворении условия. Условная конструкция завершается командой End Block.

К числу условных операторов можно отнести и ряд других команд. Например, команда проверки конфигурации Check Configuration изменяет ход исполнения сценария в зависимости от того, какая именно система используется. По сути, она играет роль блока If, который реализует, например, такой алгоритм: "Если на компьютере установлена операционная система Windows 95, прекратить установку пакета". Те администраторы, которые планируют применять SMS для дистрибуции своих пакетов, должны помнить о том, что SMS способен проверять соответствие большинству условий, предъявляемых к конфигурации, например не разрешать запуск пакетов на компьютерах, где установлена не Windows NT или Windows 9x, а какая-либо иная система. Для формирования альтернативных ветвей выполнения следует добавить к блоку If условный оператор Else, и следующие за ним команды будут выполняться в случае, когда условие оператора If не соблюдается. Например:

If <условие> <команда1> Else <команда2> End Block

Усложненная процедура установки

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

Думаю, эта точка зрения ошибочна. Я не откажусь от использования Windows 98 до тех пор, пока большинство производителей аппаратуры и программного обеспечения не реализуют поддержку Windows 2000. И, судя по всему, я не одинок. Хочется надеяться, что в будущем специалисты Microsoft придут к единой стандартной версии Windows на основе ядра Windows 2000, и тогда двойная загрузка никому не потребуется. Однако этой мечте пока не суждено сбыться - в проекте Windows Millennium (следующая версия Windows 98) использовать ядро Windows 2000 не предполагается.

ДЖОН Д. РУЛЕЙ

Независимый технический писатель. Он готовит еженедельные выпуски Windows 2000 Pro UPDATE (). Также ведет online-колонку в BYTE.com и готовит обзоры по программному обеспечению в Plane&Pilot Magazine. Его адрес: .

Установка аудита системы безопасности

Войдите в систему с административными правами.

Запустите программу User Manager. Выберите в меню: Policies, Audit и отметьте Audit These Events.

Выделите для аудита (по минимуму) события с успешным (Success) и неудачным (Failure) результатом выполнения; включите аудит попыток входа в систему и выхода из нее (Logon, Logoff). Закройте диалоговое окно, чтобы активизировать аудит системы.

Откройте программу Services в Панели Управления (Control Panel), установите для службы Планировщика NT (NT Scheduler) режим запуска от имени системы (System account). Запустите (или перезапустите) службу Планировщика.

Откройте командное окно DOS и проверьте текущее системное время.

Прибавьте к текущему времени 1-2 минуты (так, если время 11:30, используйте 11:32) и введите следующую команду: at 11:32 /interactive "regedt32.exe"

Эта команда вставляет в список Планировщика событие, по которому в 11:32 на консоли будет запущена утилита regedt32 с правами SYSTEM.

Дождитесь 11:32, когда Планировщик NT запустит редактор реестра. При этом вы получите доступ ко всему реестру, включая базу данных SAM. Будьте внимательны при редактировании реестра - ошибка может вывести из строя систему.

Выберите HKEY_LOCAL_MACHINE, найдите дерево SAM и выделите его в левой панели экрана.

Выберите в меню: Security, Auditing.

В диалоговом окне Auditing выберите Add, Show Users.

Добавьте учетную запись SYSTEM, группу Domain Admins, все учетные записи пользователей, имеющих административные права, а также все остальные учетные записи, которым присвоены следующие права (User Rights):

Take ownership of files or other objects (Овладение файлами или иными объектами)

Back up files and directories (Архивирование файлов и каталогов)

Manage auditing and security log (Управление аудитом и журналом безопасности)

Restore files and directories (Восстановление файлов и каталогов)

Add workstations to domain (Добавление рабочих станций к домену)

Replace a process-level token (Замена маркера уровня процесса)

Отметьте: Audit Permission on Existing Subkeys

Отметьте Success и Failure для следующих полей:

Query Value

Set Value

Write DAC

Read Control

Нажмите кнопки OK, Yes.

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

Выйдите из редактора реестра.

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

---

---