Открытые системы

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ федеральное государственное автономное образовательное учреждение высшего образования «САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ АЭРОКОСМИЧЕСКОГО ПРИБОРОСТРОЕНИЯ» КАФЕДРА ВЫЧИСЛИТЕЛЬНЫХ СИСТЕМ И СЕТЕЙ Открытые системы Тексты лекций Гордеев А.В. Санкт-Петербург 2017 1 УДК 004 : 004:051 : 004.057.8 : 681.323 Рецензенты: Кафедра компьютерных технологий и программной инженерии ГУАП, Кандидат физико-математических наук, доцент П.П. Щербаков Утверждено редакционно-издательским советом университета в качестве учебно-методического пособия Гордеев А.В. Открытые системы. Конспект лекций. Настоящий конспект лекций содержит материал, который читается по дисциплине «Открытые системы» и предназначен для студентов, обучающихся по программе подготовки бакалавров по направлению 09.03.01 «Информатика и вычислительная техника». Рассматриваются основные понятия и модели, имеющие отношение к открытым системам и открытым информационным технологиям. Излагаются основы семейства операционных систем, которые чаще всего выступают в качестве фундамента, на котором строятся открытые системы и которые сами удовлетворяют всем принципам открытых систем. Это так называемые POSIXсистемы и, в том числе, системы GNU/Linux. Рассматриваются и другие примеры открытых систем, в том числе и Интернет. Затрагиваются вопросы лицензирования программного обеспечения и открытые коды, которые позволяют сделать системы по-настоящему открытыми. 2 ПРЕДИСЛОВИЕ Предлагаемые тексты лекций соответствуют содержанию курса с одноименным названием (дисциплина называется «Открытые системы»). Эти лекции уже несколько лет читаются студентам, обучающимся на кафедре Вычислительных систем и сетей по программе подготовки бакалавров по направлению «Информатика и вычислительная техника». Дисциплина была введена в учебный план по нескольким причинам. Вопервых, открытые системы и открытые информационные технологии имеют много важнейших преимуществ по сравнению с закрытыми системами и проприетарными технологиями. В последнее время почти все вновь создаваемые системы стараются сделать открытыми, а открытые информационные технологии хоть и затрудняют их монетизацию, но зато существенно облегчают их использование и развитие. В учебном курсе студенты изучают основные понятия открытых систем, условия и требования, выполнение которых позволяет сделать систему открытой, эталонные модель собственно открытой системы и модель взаимодействия открытых систем, основные принципы построения и работы POSIX-систем, к которым прежде всего мы относим открытую систему GNU/Linux, и, наконец, вопросы лицензирования, которые позволяют защищать открытые системы и обеспечивать им большое распространение. В лабораторном практикуме по этой дисциплине студенты знакомятся с открытым пакетом офисных программ LibreOffice.org и с открытой операционной системой GNU/Linux. 3 Лекция 1. Открытые системы: основные понятия 1.1. Понятие открытой системы Поскольку термин открытые системы (Open Systems) появился относительно недавно — в последней четверти ХХ столетия, то он до сих пор не имеет единого толкования. Разные авторы и коллективы по-разному понимают его и единого трактования нет. Возможно, что не нашлось наиболее авторитетного эксперта, который бы «узаконил» этот термин для всех. С одной стороны, в разных источниках можно найти различные трактовки термина, которые могут себя назвать либо как определение «в широком смысле», либо — «в узком смысле». С другой стороны, под эгидой международной организации по стандартизации (International Standard Organization — ISO) было чётко сформулировано определение открытых систем (Open Systems), которое должно было всех привести к согласию. Однако при уже достаточно большом количестве публикаций на тему открытых систем до сих пор так и нет единого толкования. Даже в Википедии по состоянию на осень 2015 имелось четыре (!) разных толкования этого термина. Поэтому мы начнём с того, что кратко перечислим наиболее часто встречающиеся определения, некоторые из которых, кстати, есть и в упомянутой Википедии. 1. Открытые системы — это системы, которые нельзя считать закрытыми по отношению к окружающей среде в каком-либо аспекте — информационном, вещественном, энергетическом и т. д. Открытые системы могут обмениваться веществом, энергией, информацией с окружающей средой. Это наиболее общее определение и оно подходит к общей теории систем, биологии, кибернетике, информатике, экономике и в других областях, поскольку их связи со средой имеют первостепенное значение при их описании и моделировании. 2. Системы являются открытыми, если они построены по модульному принципу и открыты для расширения своей функциональности и для связи с другими системами не путём своей основательной переделки, но за счёт 4 возможности добавления в них новых модулей, реализующих новые функции, или замены одних модулей другими. Это определение позволяет считать очень большое количество систем открытыми, поскольку модульный подход к созданию систем является одним из основных и самых распространённых, и он позволяет изменять и/или расширять возможности систем. Действительно, модульность вытекает из желания упростить создание системы и иметь возможности по замене частей системы (т. е. модулей) аналогичными изделиями других производителей. 3. Под открытостью системы иногда понимают ее соответствие современ- ным промышленным стандартам, которое обеспечивает возможность интеграции с другими открытыми системами. Соответствие стандартам необходимо для обеспечения совместимости модулей и систем. Но это достаточно узкое толкование, оно учитывает далеко не все свойства открытых систем. 4. С точки зрения итологии — науки, изучающей информационные техно- логии — сущность технологии открытых систем состоит в следующем:  в обеспечении унифицированного обмена данными между различными компьютерами и платформами, на которых создаётся система;  в переносимости приложений (прикладных программ) между различными платформами;  в мобильности пользователей, т.е. возможности пользователей переходить с одного компьютера на другой независимо от его архитектуры и установленного программного обеспечения без необходимости переобучения специалистов. 5. Наиболее полное и исчерпывающее определение дал Комитет IEEE POSIX 1003.0. В соответствии с их трактовкой открытая система есть «система, реализующая открытые спецификации на интерфейсы, сервисы и поддерживаемые форматы данных, достаточные для того, чтобы обеспечить должным образом разработанным приложениям возможность переноса с минимальными 5 изменениями на широкий диапазон систем, совместной работы с другими приложениями на локальной и удаленных системах, и взаимодействия с пользователями в стиле, облегчающем тем переход от системы к системе». Ключевой момент в этом определении - использование термина «открытая спецификация», что в свою очередь определяется как «общедоступная спецификация, которая поддерживается открытым, гласным согласительным процессом, направленным на постоянную адаптацию новой технологии, и соответствует стандартам». Что касается обеспечения совместной работы с другими прикладными системами на локальных и удалённых платформах, то это свойство называется интероперабельностью. Открытые системы должны обладать этим свойством. Важным понятием в технологии открытых систем является также профиль – совокупность нескольких базовых стандартов для выполнения определенной функции. Таким образом получается, что наиболее общее толкование термина «Открытая система» сводится к тому, что это система, состоящая из модулей, которые взаимодействуют через открытые стандартные протоколы, которая открыта для расширения и взаимодействия с другими системами, причём обеспечивается максимально простой перенос приложений, созданных должным образом, на широкий диапазон аппаратно-программных платформ и пользователю легко переходить от одной платформы к другой; замена или добавление модулей не должны приводить к переобучению пользователей, но должны позволить получить новые возможности. Отметим, что в первую очередь к свойствам открытости относятся использование открытых стандартов и спецификаций, переносимость и переиспользуемость программного обеспечения, интероперабельность и масштабируемость системы. 6 Переносимостью (portability) информационной системы (или программы) называется свойство, позволяющее ей c возможно меньшими накладными расходами осуществлять перенос её программного обеспечения, информации и пользователей с одной прикладной платформы на другую. Интероперабельностью (interoperability) системы называется возможность совместного использования информации и ресурсов компонентов распределённой системы. Современные информационные системы являются многопользовательскими (мультитерминальными) и свойство интероперабельности является одним из важнейших. Масштабируемостью (scalability) называется свойство информационной системы, которое позволяет ей работать в очень широком диапазоне параметров, определяющих её собственные технические и ресурсные характеристики (количество рабочих станций, число обслуживаемых пользователей, количество обрабатываемых транзакций, число узлов сети, количество серверов и т. д.). Итак, для того чтобы информационную систему можно было отнести к открытым системам, она должна обладать совокупностью вышеназванных свойств. Раскроем их ещё раз, но другими словами и чуть поподробнее: • взаимодействие/интероперабельность – способность к взаимодействию с другими прикладными системами на локальных и (или) удаленных платформах (технические средства, на которых реализована информационная система, объединяются сетью или сетями различного уровня); • стандартизуемость – программные и информационные системы проекти- руются и разрабатываются на основе согласованных международных стандартов и предложений, реализация открытости осуществляется на базе множества согласованных стандартов (профилей) в области информационных технологий; • расширяемость/масштабируемость – возможность добавления новых функций информационной системы или изменения некоторых уже имеющихся 7 при неизменных остальных функциональных частях системы, возможность перемещения прикладных программ и передачи данных в системах и средах, которые обладают различными характеристиками производительности и различными функциональными возможностями; • мобильность/переносимость – обеспечение возможности переноса при- кладных программ и данных при модернизации или замене аппаратных платформ информационных систем (ИС) и возможности работы с ними специалистов без специальной переподготовки при изменениях ИС; • дружественность к пользователю – развитые унифицированные интерфейсы в процессах взаимодействия в системе «пользователь – компьютерное устройство – программное обеспечение», позволяющие работать пользователю, не имеющему специальной системной подготовки. Пользователь должен работать с бизнес-задачами, а не с проблемами компьютера и программного обеспечения. Очень важно, что принципы открытых систем выступают как интеграционная основа для построения информационной инфраструктуры любого уровня. Принципы открытых систем применяются в настоящее время при построении большинства классов систем: вычислительных, информационных, телекоммуникационных, систем управления в реальном масштабе времени, встроенных микропроцессорных систем и многих других. 1.2. Достоинства и недостатки открытых систем Основные достоинства открытых систем проистекают из самого понятия открытых систем. Выгодой от применения открытых систем являются:  пониженные вложения на предпроектные изыскания и проектирование системы – благодаря наличию на рынке большого выбора готовых компонентов открытых систем; 8  простое изменение конфигурации системы для работы с новыми технологическими процессами – вытекает из свойств модульности и расширяемости открытых систем;  упрощение процесса интеграции – открытость подразумевает возможность простой интеграции разнородных систем благодаря использованию открытых стандартов и спецификаций;  экономия финансовых средств – благодаря низкой стоимости компонентов и всего жизненного цикла системы (не только вследствие конкуренции независимых производителей и отсутствия диктата цен монопольным поставщиком, но и возможности многократной модификации);  увеличенное время безотказной работы – благодаря выбору наиболее надежных модулей из имеющихся на рынке;  минимизированное время вынужденного простоя – благодаря большому выбору взаимозаменяемых модулей всегда можно найти поставщика, имеющего нужные модули на складе;  минимальные усилия на ввод в действие как аппаратуры, так и программного обеспечения – благодаря устранению времени на дополнительное обучение как монтажной организации, так и эксплуатирующего персонала;  минимальный объем дополнительного обучения персонала и, как следствие, простота обслуживания;  применение новейших технологий и технических решений – благодаря широкому выбору наилучших решений и специализации производителей;  увеличение времени жизни системы – благодаря взаимозаменяемости отработавшего ресурс и нового оборудования, а также возможности наращивания функциональных возможностей. Недостатки открытых систем видны не сразу. И все же они имеются:  при создании автоматизированной системы на базе открытых решений ответственность за работоспособность системы в целом ложится на систем9 ного интегратора, а не на производителей компонентов системы. Поэтому при появлении в системе невоспроизводимых отказов некому предъявить претензии, поскольку поставщиков много, а системный интегратор отвечает за монтаж, пусконаладку и часто за сопровождение системы;  универсальность всегда находится в противоречии с простотой. Универсальные протоколы, интерфейсы, сети и программное обеспечение, чтобы быть универсальными, должны быть достаточно сложными, следовательно, более дорогими и менее надежными. Хотя снижение надежности, вызванное сложностью, компенсируется повышением надежности благодаря большому тиражу и, следовательно, продолжением отладки после начала продаж;  эффект снижения надежности программного обеспечения (ПО), части которого пишутся разными производителями. Когда ПО пишется сотрудниками одной фирмы, можно предвидеть почти все ситуации, которые могут возникнуть на границе между ПО и пользователем или аппаратурой. Если же в этом участвуют несколько разных команд в разных фирмах, между которыми нет взаимодействия, то становится непонятно, кто отвечает за надежность всего комплекса. Кроме того, с ростом числа программистов, участвующих в создании ПО, по законам статистики увеличивается вероятность того, что появится хотя бы один программист, не умеющий писать надежные программы. А этого достаточно, чтобы сделать всю систему ненадежной. Надежность и безопасность открытых систем остаются темами, требующими решения;  как и любая стандартизация, открытость накладывает ограничения на диапазон возможных технических решений, затрудняя творчество и снижая вероятность появления новых и плодотворных технических решений. 1.3. Ретроспектива открытых систем 10 История концепции открытых информационных систем началась в конце 60-х – начале 70-х годов ХХ века, когда возникла насущная проблема переносимости (мобильности) созданных ранее программ и данных с прежних компьютеров на новые, более мощные. На разработку программ уходило очень много ресурсов (времени и денег) и терять их при переходе на новые компьютеры было непозволительно. Одним из первых шагов в этом направлении, оказавшим существенное влияние на развитие вычислительной техники, явилось создание компьютеров серии IBM-360, обладающих единым набором команд и способных работать с одной и той же операционной системой (ОС). Компания IBM ввела понятие архитектуры и обеспечила возможность выполнения уже готовых двоичных программ на различных компьютерах семейства с одной архитектурой. Если один компьютер заменялся другим, но его архитектура и операционная система при этом не изменялись, то никаких особых проблем при этом не возникало (или не должно было возникать). Существенный вклад в это вносили механизмы обеспечения виртуальной памяти. Однако при смене архитектуры или даже при переходе с одной операционной системы на другую пользователи и программисты сталкивались с существенными трудностями. Частичное решение проблемы мобильности для программ обеспечило введение стандартов на языки высокого уровня; в качестве примера можно назвать ранние стандарты на языки ФОРТРАН и КОБОЛ. Высокоуровневые языки позволяли создавать переносимые программы, хотя часто ограничивали функциональные возможности. Позднее эти возможности были существенно увеличены при появлении новых стандартов (расширений) на эти языки. Мобильность обеспечивалась также за счёт того, что эти стандарты были приняты многими разработчиками различных платформ. Когда языки программирования приобрели статус стандарта де-факто, их разработкой и сопровождением начали 11 заниматься национальные и международные организации по стандартизации. В результате такие языки развивались уже независимо от своих создателей. Достижение мобильности и переносимости уже на этом уровне было первым примером истинных возможностей создаваемых систем, которые содержали в себе основные признаки того, что впоследствии было названо открытостью системы. Следующая фаза в развитии концепции открытости связана с областью интерактивной компьютерной обработки и расширяющимся диапазоном требующих переноса продуктов. В этот период компания Digital Equipment Corp (DEC) разработала свои VAX-системы, работающие под управлением операционной системы VMS (Virtual Memory System). Каждый компьютер этой линии, вне зависимости от размера, мог исполнять один и тот же набор приложений. Машины этой серии имели 32-разрядную архитектуру, что обеспечило значительную эффективность создаваемых программ и сократило издержки на работу с виртуальной памятью. Программисты получили возможность напрямую использовать адресное пространство объёмом до 4 Гбайт, что практически снимало все ограничения на размеры решаемых в то время задач. Вычислительные системы VAX надолго стали стандартной платформой для систем проектирования, сбора и обработки данных, управления экспериментом и т. п.. Именно они стимулировали создание мощных систем автоматизированного проектирования (САПР), систем управления базами данных (СУБД), машинной графики, которые широко используются до настоящего времени. Параллельно с этим происходило развитие сетевых технологий, сначала таких как DECnet и им подобных, а затем и Internet (TCP/IP), объединивших системы и локальные сети академических и военных организаций Соединённых Штатов Америки. Когда сетевые технологии стали реальностью и насущной необходимостью для решения большого числа технических, технологических, научных экономических задач, пользователи и системные интеграторы начали 12 обращать внимание на совместимость и возможность интеграции вычислительных средств как на необходимые атрибуты открытости систем. В 80-е годы ХХ века самыми распространёнными компьютерами становятся персональные. В этом мире персональных компьютеров ОС MS-DOS корпорации Microsoft (с благословения и при поддержке компании IBM) утвердила достоинства стандартной среды, причём не только для пользователей. Низкая цена и широкая распространённость этих компьютеров создали огромный рынок для данной ОС и её приложений. Двоичная совместимость при стандартной архитектуре разрешила массу проблем, хотя она также не свободна от некоторых ограничений. Многие приложения, выполняющиеся в MSDOS, могли выполняться на любой совместимой системе. Но эти системы были ограничены 16-разрядной архитектурой Intel 80x86, графикой низкого разрешения и однопроцессорностью. Для среды MS-DOS был характерен также риск быстрого распространения вирусов, поскольку система никак не защищена (на аппаратном, а значит и на программном уровнях). До появления и распространения MS-DOS для персональных компьютеров в мире мини-ЭВМ быстро стала распространяться ОС UNIX. Важно заметить, что UNIX в процессе работы над ней была разработана так, что она стала относительно легко переносимой, и позднее (с появлением достаточно мощных микропроцессоров) она проявила себя как наиболее перспективное открытое операционное окружение. Исторически ОС UNIX оказалась самым лучшим вариантом для создания общей базы переносимости. Прежде всего, она удовлетворяет ряду требований, предъявляемых к открытым системам. При соответствующем подходе к разработке программного обеспечения приложения для основанных на UNIX`е систем могут быть относительно легко переносимыми как в другие UNIX-системы, так, во многих случаях, и в другие системы, удовлетворяющие стандартам на интерфейсы, подобным тем, которые разработаны X/Open1 и 1 X/Open – это консорциум, который был создан для продвижения открытых стандартов в сфере информационных технологий. Начальной целью было определение единой спецификации операционных си- 13 POSIX2. Было создано большое количество вариантов UNIX-систем и для обеспечения лучшей переносимости приложений эти системы стали придерживаться стандартов POSIX. Соответственно, можно и нужно говорить именно о POSIX-системах как о классе ОС, построенных на принципах UNIX-систем. Одна из причин рассматривать системы POSIX в качестве хороших кандидатов на использование в открытых системах состояла в том, что эти ОС почти целиком написаны на языке высокого уровня и в большинстве случаев имеется доступ к их исходным кодам. Хотя в целом ОС UNIX является машинно-независимой, некоторые сервисы и часть кода зависят от аппаратуры. Приложения, использующие особенности конкретной версии UNIX`а, подобно приложениям MS-DOS реализационно-зависимы. Поэтому наиболее целесообразно опираться на систему, максимально совместимую со стандартами POSIX. Так уж исторически сложилось, что UNIX-системы использовались при создании Интернета. Поэтому стек TCP/IP, который является базисом для этой глобальной сети и наиболее активно используется в современных локальных сетях, стал родным для всех POSIX-систем. Сетевые технологии призваны объединять не только отдельные компьютеры, но и различные информационные системы, а для этого они, в свою очередь, должны быть открытыми. Важнейшим этапом в развитии открытых систем был этап принятия единых стандартов в построении взаимодействующих открытых систем. Упомянутый стек протоколов TCP/IP и стек OSI (Open System Interconnection — взаимодействие открытых систем), которые были разработаны в 80-е годы прошлого века, непосредственно относятся к открытым системам. Сегодня внимание в открытых системах обращено не только к ОС, но и к стандартным интерфейсам объединения существующих систем, приложений и стем, производных от UNIX, для облегчения переносимости программного обеспечения. 2 POSIX - это набор стандартов, который описывает интерфейс между операционной системой и прикладной программой. Фактически, он описывает то, как программа должна вызывать системные функции для того, чтобы свободно запускаться под всеми операционными системами, отвечающими данному стандарту. О стандартах POSIX речь пойдёт дальше. 14 пользователей. Данный подход состоит в концентрации на выработке международно признанных промышленных стандартов и добавления множества компонентов в единое модульное операционное окружение. Предполагается, что реализация стандартов в каждой системе создаст унифицированную структуру, которая уменьшит трудности в соединении разнородных схем. Международно признанные стандарты должны быть реализованы для каждого системного компонента современной сетевой системы, включая каждую операционную систему и приложение. До тех пор, пока компоненты удовлетворяют таким стандартам, они соответствуют целям открытых систем. Однако для некоторых особо специфичных компонентов стандартов может не существовать - в таких случаях реализация стандартов слишком сложна либо слишком накладна. Чтобы исполнить желаемое, открытые системы должны не только обеспечить некое операционное окружение, в котором приложения можно легко перемещать между различными аппаратными и программными платформами, а пользователи могут легко перемещаться между системами; они должны функционировать сообща с уже используемыми продуктами, стоящими миллионы и даже миллиарды долларов. Одна из распространенных точек зрения состоит в признании открытой системы, основанной на стандартной аппаратуре и/или стандартной ОС. К концу ХХ века примером такой системы стали привычные нам персональные IBMсовместимые компьютеры или любая совместимая с ним система. Большинство таких компьютеров используют одну и ту же или совместимую ОС и выполняют (или могут выполнять) практически одни и те же приложения. К началу XXI века большинство персональных компьютеров работало под стандартными ОС Windows компании Microsoft. Эти ОС были почти полностью совместимыми, позволяли разнообразные расширения своей функциональности и относительно легко объединялись посредством сетевых технологий с другими 15 платформами. Однако они не обладали открытостью в смысле возможности их изучения и изменения, а зачастую и исправления ошибок, обнаруживаемых в них во время эксплуатации. Модель распространения этих систем запрещала их декомпилировать, изучать и изменять (исправлять ошибки или модифицировать). Поэтому появление в середине 80-х годов движения за открытость исходных кодов в конечном итоге привело к тому, что на сегодня термин открытая система подразумевает и этот аспект открытости. Практически идеальной ОС для построения открытых систем стали ОС GNU/Linux. Изучение этих ОС во многом определяет содержание настоящей дисциплины, но ни в коем случае не должно этим ограничиваться. В современных условиях построения информационного общества, когда практически все секторы экономики становятся потребителями информационных технологий, а сектор производителей средств и услуг информационных технологий непрерывно растет, проблема развития и применения открытых систем составляет для каждой страны национальную проблему. Так, в США ещё 1993 г. объявили о программе создания Национальной информационной инфраструктуры на принципах открытых систем (National Information Infrastructure Initiative) и они вкладывали в эту программу большие деньги, что содействует инвестициям со стороны частного сектора. Совет Европы в 1994 г. в своих рекомендациях о путях перехода к информационному обществу (Bangemann Report) подчеркнул, что стандарты открытых систем должны играть важнейшую роль при создании информационной инфраструктуры. Ведется работа по созданию глобальной информационной инфраструктуры, также основанной на принципах открытых систем. В нашей стране тоже в начале 90-х годов была разработана соответствующая программа. Однако из-за перестройки государство почти на десятилетие потеряло контроль над развитием этой сферы. Бурный и неуправляемый рост рынка персональных компьютеров, информационных технологий и соответствующих услуг привёл к тому, что мы хоть и приобщились к современным 16 информационным технологиям, но многое потеряли в области открытых систем и технологий. В начале этого века вновь пришло понимание важности открытых систем и соответствующих информационных технологий. Пришло и понимание в необходимости обеспечения информационной безопасности и информационной независимости от зарубежных компаний и/или государств. Таким образом, следует еще раз подчеркнуть, что в условиях перехода к информационному обществу технологии открытых систем становятся основным направлением в развитии и внедрения информационных технологий. Создание информационной инфраструктуры на принципах открытых систем, кроме научно-технических аспектов, имеет социальные, политические и экономические аспекты и, соответственно, должно представлять собой увязанный по ресурсам, исполнителям и срокам осуществления комплекс научноисследовательских, опытно-конструкторских, производственных, социальноэкономических, организационно-хозяйственных и других мероприятий. Это означает, что проблема отвечает уровню федеральной программы, и это зафиксировано в соответствующем постановлении бюро Отделения информатики, вычислительной техники и автоматизации РАН. Успех в реализации этой программы может быть обеспечен только путем создания законодательной, нормативно-методической базы с преимущественным применением международных стандартов в области информационных технологий (с адаптацией к отечественным условиям), способствующих и делающих экономически выгодными практическое применение принципов открытых систем всеми ведомствами, организациями и предприятиями независимо от форм собственности. При этом важнейшим фактором выступает формирование и проведение государственной политики в области обеспечения информационной безопасности. Следует отметить, что принципы открытых систем не противоречат обеспечению информационной безопасности, а предусматривают применение необходимых стандартов по защите информации. 17 Лекция 2. Эталонная модель открытой системы Итак, мы определили, что открытая система — это система, состоящая из элементов, которые взаимодействуют через стандартные интерфейсы и протоколы и открыта для расширения и взаимодействия с другими системами. А существо технологии открытых систем состоит в создании среды, которая, в частности, обеспечивает:  перенос приложений, созданных соответствующим образом, на широкий диапазон программно-аппаратных платформ;  интеграцию и взаимодействие с другими системами;  масштабируемость, дружественность к пользователю и проч. Для того, чтобы можно было построить открытую систему, необходимо иметь её модель, потому что тогда мы будем более полно себе представлять — а что же нужно обеспечить, чтобы система стала открытой. Модель должна быть прежде всего ориентирована на руководителей ИТ-служб и менеджеров, ответственных за приобретение/разработку, внедрение, эксплуатацию и развитие информационных систем, состоящих их неоднородных программно-аппаратных и коммуникационных средств. Модель описывает функциональную среду открытых систем (Open Systems Environment – OSE) и поэтому её называют Open Systems Environment / Reference Model – OSE/RM, т. е. эталонной моделью [ 13 ]. Разработана она была рабочей группой 1003.0 POSIX комитета IEEE и описана на международном уровне в техническом отчете TR 14250 комитета JTC. Строго говоря, эталонная модель — это структурированное множество понятий и их взаимосвязей для некоторой предметной области, осуществляющее концептуальную структуризацию данной области и имеющее до18 статочно обобщенное описание. Эта модель имеет непосредственное отношение к вышеупомянутой итологии — науки, изучающей информационные технологии. По существу, эталонная модель является формой метазнаний 3, определяющих принципиальную декомпозицию или архитектурную спецификацию конкретной предметной области. Такая модель обеспечивает столь необходимую связь между спецификациями требований и разработкой конкретной информационной системы. Эталонная модель вводит набор соглашений и понятий, которые используются как разработчиками и поставщиками информационных технологий, так и пользователями информационных систем. Подобный набор общих соглашений и понятий является ключом для достижения переносимости прикладного программного обеспечения, взаимосвязанности систем и возможного повторного использования программного обеспечения в дальнейшем. Данная модель позволяет создавать более компактные, продуманные и корректные спецификации. В модели OSE/RM информационная система рассматривается как черный ящик, взаимодействие с которым стандартизовано и осуществляется только через его интерфейсы, где под интерфейсами понимаются границы, разделяющие между собой некоторые функциональные сущности. Именно через эти интерфейсы система (платформа) может предоставлять сервисы пользователям и их приложениям и использовать сервисы, связанные с сущностями внешнего окружения. Поэтому центральным понятием данной модели является понятие окружения открытых систем (Open System Environment - OSE), под которым понимается полный набор сервисов, интерфейсов, форматов, а также пользовательских аспектов, обеспечивающих интероперабельность и/или переносимость программ, данных, людей на основе использования базовых стандартов и профилей4 . 3 Метазнания — знания о знании, о том, как оно устроено и структурировано; знания о получении знаний, т.е. приёмы и методы познания и о возможностях работы с ним. 4 Профилем называется набор согласованных и взаимосвязанных между собой стандартов, охватывающих взаимодействие аппаратных и программных компонентов системы, и определяет спецификации протоколов 19 В описании модели используется два типа элементов (см. рис. 1): • логические объекты (сущности), включающие в себя приложения, платформу, на которой эти приложения выполняются, и внешнюю функциональную среду; • интерфейсы, содержащие интерфейс прикладной системы (API) и интерфейс обмена с внешней средой (EEI). и интерфейсов, составляющих структуру открытой системы. 20 Рисунок 1. Упрощённая модель OSE/RM Как видно из этого рисунка, в модели присутствуют три типа логических объектов, а именно: 21  прикладного программного обеспечения (Application Software Entities),  прикладной платформы (Application Platform Entities),  внешнего окружения (External Enviroment Entities). Центральным элементом (объектом) модели служит так называемая прикладная платформа (Application Platform Entity), которая состоит из совокупности программно-аппаратных компонентов, реализующих системные услуги, которые используются приложениями (Application Software Entity). Программистам гораздо легче и удобнее обратиться к системному программному обеспечению, которое устанавливается на платформе (речь идёт об операционной системе), чем создавать самому реализацию всех необходимых функций. Сама платформа находится во внешнем окружении (External Environment), с которым и взаимодействует. В частности, пользователь системы тоже относится к внешнему окружению и может взаимодействовать с приложениями только через прикладную платформу. Понятие прикладной платформы не включает конкретной реализации функциональных возможностей. Например, платформа может представлять собой как однопроцессорный компьютер, на котором параллельно исполняется несколько приложений, так и большую распределенную многопроцессорную или даже многомашинную систему. В простейшем случае в качестве примера платформы можно назвать компьютер с установленной на него операционной системой. Внешняя среда платформы состоит из элементов, внешних по отношению к прикладному программному обеспечению и к прикладной платформе; это рабочие станции, внешние периферийные устройства сбора, обработки и передачи данных, объекты коммуникационной инфраструктуры, услуги других платформ, операционных систем или сетевых устройств. 22 Вышеупомянутые сущности связаны через стандартные интерфейсы. Перечень этих интерфейсов можно увидеть на рис.2 . Рассмотрим их поподробнее. Рисунок 2. Развернутая модель открытой системы 23 Стандарты интерфейсов открытых систем разбиваются на две основные категории в соответствии с двумя типами интерфейсов:  стандарты прикладных программных интерфейсов (Application Program Interface (API) Standards);  стандарты внешнего окружения (External Environment Interface (EEI) Standards). Первая группа стандартов специфицирует взаимодействие прикладного программного обеспечения с компьютерной системой (прикладной платформой). Эти стандарты в основном предназначены для обеспечения переносимости приложений. Вторая группа стандартов определяет взаимодействие платформы (и даже всей информационной системы!) с ее внешним окружением. Эти стандарты позволяют решать проблемы интероперабельности систем, переиспользуемости программного обеспечения и переносимости данных. Следование стандартам обеих групп позволяет решить главную задачу для потребителей информационных технологий, а именно - обеспечить возможность построения информационных систем из компонентов (модулей), поставляемых различными изготовителями, и, как следствие, обеспечить независимость от поставщиков ИТ в целом. Указанные выше две группы сервисов и стандартов, разбиваются на четыре основных категории, а именно:  системные или программные сервисы (System Services),  коммуникационные сервисы (Communication Services),  информационные сервисы (Information Services), 24  сервисы человеко-машинного взаимодействия (Human/Computer Services). Для каждой категории сервисов определяются так называемые межкатегориальные сервисы (Cross-Category Services), элементы которых могут входить в любую группу сервисов. К ним относятся сервисы интернационализации (Internationalization Services), системной безопасности (System Security Services), административного управления (Systems Management Services). Данная модель является достаточно общей в том смысле, что она может быть использована для широкого спектра систем, как общего, так и специального назначения. Дальнейшая структуризация интерфейсов и классов сервисов (разбиение их на категории, подкатегории, конкретные элементы) позволяет построить варианты модели, учитывающие различные особенности применения систем и спектр системных архитектур. Данная эталонная модель не является иерархической. Каждая часть модели взаимодействует с остальными частями через интерфейсы. Все возможности системы могут быть доступны как локально, так и удаленно, если данная система является частью распределенной системы. К вышесказанному можно добавить, что в общем случае сущность "прикладное программное обеспечение" состоит из одного или более компонентов следующих типов:  программ (исходный код, файлы команд или сценариев и т. д.);  данных (данные пользователя, параметры приложения, параметры экрана и т. д.);  документации (online-документация; твердые копии не рассматриваются). Далее, прикладная программа условно может быть разделена на две части: 25  неизменяемую часть исходного кода, не требующую изменений при переносе с одной платформы на другую;  изменяемую часть исходного кода, которая требует изменений при переносе с одной платформы на другую. Для повышения степени переносимости прикладного программного обеспечения необходимо использовать при его создании стандарты на API, а также минимизировать изменяемую часть. Это существенно облегчит перенос компонентов прикладного программного обеспечения между различными (но соответствующими стандартам на интерфейсы) прикладными платформами. На одной и той же прикладной платформе могут одновременно выполняться несколько приложений. Каждое приложение можно рассматривать как независимую прикладную сущность, которая при необходимости взаимодействует и синхронизируется с другими приложениями с помощью различных коммуникационных механизмов. Прикладная платформа определяется как набор ресурсов, предоставляемых сервисам, с помощью которых приложение выполняет свои функции. Для того чтобы обеспечить целостность и согласованность системы, все ресурсы должны быть доступны исключительно через API. Понятие прикладной платформы не включает в себя конкретную реализацию сервисов. Например, платформа может содержать единственный процессор, разделяемый несколькими приложениями, или являться большой распределенной системой. Внешнее окружение содержит внешние сущности, с которыми прикладная платформа обменивается информацией. Эти сущности могут быть разбиты на несколько категорий таких, как, например, конечные пользователи или сущности, обеспечивающие обмен информацией с долговременной памятью, или коммуникационные сущности. 26 Как отмечалось выше, между сущностями общей модели существует два типа интерфейсов: API и EEI. Интерфейс прикладного программирования (API) определяет следующие уже известные нам типы сервисов:  системные сервисы (System Services);  коммуникационные сервисы (Communication Services);  информационные сервисы (Information Services);  сервисы взаимодействия человека с компьютером (Human/Computer Interaction Services). Примером API-интерфейса может служить вызов процедуры создания окна: Open_Window (x1, y1, x2, y2). Интерфейс внешнего окружения (EEI) определяет следующие типы сер- висов и, соответственно, интерфейсов:  коммуникационные сервисы (Communication Services);  информационные сервисы (Information Services);  сервисы взаимодействия человека с компьютером (Human/Computer Interaction Services). Примером EEI-интерфейса может служить понятие окна ('window'), как сущности, связанной с некоторой областью на экране монитора. Сервисы API и EEI не имеют взаимно однозначного соответствия, хотя в большинстве случаев имеют похожие названия. Например, интерфейс сервиса хранения данных может обеспечивать приложению прозрачный доступ к удаленному файлу с помощью сетевых сервисов. В данном случае комплексный 27 сервис хранения данных, предоставляемый API, зависит от коммуникационных сервисов, предоставляемых EEI. В общем случае прикладные программные сущности никогда не имеют доступа к EEI непосредственно, хотя выполнение API сервисов может вызывать выполнение EEI сервисов. В эталонной модели OSE RM рассматриваются следующие три вида спецификаций API:  cпецификации API, полностью представленные средствами некоторого языка программирования (Programming Language API Specifications);  языково-независимые спецификации сервисов (Language-independent service specifications);  спецификации API языкового связывания (Language-binding API specifications), которые представляют собой по существу результат отображения языково-независимых спецификаций в форму доступа к сервису, выраженную средствами конкретного языка программирования. Последние два способа спецификации API считаются наиболее предпочтительными для целей стандартизации. Эталонная модель POSIX OSE разработана таким образом, чтобы с ее помощью можно было адекватно специфицировать функциональности различных распределенных информационных систем. На случай распределённых систем, которые появляются всё чаще, исходную модель открытой системы можно расширить (как это показано на рис. 3). 28 Рисунок 3. Модель OSI/RM для распределённой системы В распределенном окружении различные прикладные платформы могут взаимодействовать с помощью сервисов (коммуникационных механизмов) интерфейса внешнего окружения. Когда для некоторой сущности прикладного программного обеспечения требуется установить связь с некоторой сущностью на другой платформе, делается запрос через API. Конкретная реализация прикладной платформы транслирует API запросы в соответствующие действия на EEI. Связь между прикладными платформами устанавливается с помощью внешних сущностей, поэтому передача данных осуществляется коммуникационными сервисами EEI, обеспечивающими взаимодействие с такими внешними сущностями. В модели OSE/RM также предусмотрены архитектурные решения и для распределенных прикладных платформ, состоящих из нескольких 29 компонентов, взаимодействующих через собственные внутриплатформенные интерфейсы. Более подробно взаимодействие между платформами рассматривается в модели взаимодействия открытых систем (Open System Interconnection), которую рассмотрим дальше. Лекция 3. Модель взаимодействия открытых систем Модель взаимодействия открытых систем (Open System Interconnection Basic Reference Model — OSI/RF) появилась в связи с необходимостью стандартизировать протоколы, с помощью которых компьютеры (платформы) или даже открытые системы, созданные на их основе, можно было бы связать посредством сетевых коммуникаций. OSI/RM предназначена для определения общей основы процесса стандартизации в области взаимосвязи систем, обеспечивающей целостность и взаимную согласованность стандартов. Разработанные на этой основе стандарты позволяют реализовывать унифицированные средства обмена данными между системами, удовлетворяющие требованиям, определенным в модели OSI/RM. Системы, взаимодействующие посредством такого рода стандартных процедур обмена данными, называются «открытыми си- стемами», а реализуемая ими взаимосвязь – «взаимосвязью открытых систем». Модель описывает систему взаимодействия в процессах обмена сообщениями и данными между прикладными программами, которые выполняются на разных компьютерах. Она является наиболее проработанной с функциональной точки зрения, полноты набора стандартов и определения их совместимости друг с другом. При разработке модели использовался известный метод разбиения сложной задачи на подзадачи. Очевидно, что нормальные функциональные коммуникации возможны только при четком согласовании всех функций, необходимых для взаимодей30 ствия и обмена данными между двумя открытыми системами. Идентификация этих важнейших функций и установление порядка их выполнения закладывает основу для открытых систем. Две системы смогут взаимодействовать только в том случае, если они договорятся о том, как будет организовано это взаимодействие. Иначе говоря, они должны следовать общим правилам получения данных от приложения и их упаковки для передачи по сети. Никакие подробности, даже второстепенные, не могут считаться сами собой разумеющимися или зависеть от случайностей. Основная проблема организовать взаимодействие между вычислениями, которые выполняются на разных компьютерах, заключается в том, что платформы могут быть разными. Разным может быть аппаратное обеспечение (архитектура компьютера, состав оборудования), разными могут быть операционные системы, а значит и API. Относительно одинаковыми (точнее, работающими по одному и тому же протоколу передачи и приёму сигналов через среду передачи данных) должны быть только так называемые сетевые адаптеры, они должны работать по одному и тому же протоколу. Иерархически организованный набор протоколов, достаточный для организации взаимодействия между системами, называется стеком коммуникационных протоколов. Как мы уже знаем, приложения работают в операционном окружении и обращаются к платформе на соответствующем API. И поскольку платформы могут быть разными, то для того, чтобы обращение к ОС из приложения (системный вызов), которое работает на одном компьютере, было правильно интерпретировано операционной системой другого компьютера, необходимо осуществить трансляцию запроса. Так как потенциальное множество различных платформ может быть большим, то трансляцию API целесообразно проводить через промежуточное API, которое должно поддерживаться всеми платформами. Таким образом, мы со всей очевидностью переходим к трёхуровневой модели «клиент-сервер», в которой сервер для клиента выступает в роли транслятора и обращается к следующему серверу, сам становясь клиентом. 31 Необходимо отметить, что идея трёхуровневой модели «клиент-сервер» может быть повторена несколько раз, что обеспечивает возможности расширения функциональности и улучшения эффективности. И главное для этого — это соблюдение принятых спецификаций на интерфейсы для взаимодействия между клиентами и серверами. Между уровнем, на котором выполняются приложения, находящиеся на разных платформах, и аппаратурой, посредством которой осуществляется передача данных между компьютерами, может быть расположено несколько модулей, выступающих одновременно в роли клиента и сервера. Эти модули образуют новые, промежуточные уровни. Другими словами, схема взаимодействия получается многоуровневой. При разбиении модели на уровни следует учесть следующие принципы:  Разумное количество уровней;  Прозрачность;  Инкапсуляция данных при передаче их на нижележащие уровни;  Минимальное количество информации, передаваемое интерфейсами между уровнями;  Чётко определённые задачи каждого уровня, причём каждый уровень должен решать (возможно разными способами) только одну задачу;  Новый уровень должен создаваться каждый раз, когда требуется новый уровень абстракции. Модель взаимодействия открытых систем, таким образом, может содержать несколько уровней. В модели взаимодействия, которую назвали стеком протоколов TCP/IP, этих уровней четыре. А в модели, которую приняла в качестве эталонной Международная организация стандартизации (International Standardt Organization - ISO) и получившей название Open System Interconnection (OSI), этих уровней официально семь, а фактически — восемь 5. 5 32 Многоуровневое построение модели взаимодействия открытых систем позволяет максимально эффективно организовать взаимодействие компьютеров в сети. На верхнем уровне оперируют такими понятиями, как файл-сервер, сервер приложений и другими, но совершенно не интересуются технологиями построения сетей. На нижнем уровне, напротив, определяется, как должен сетевой адаптер передать или принять биты и байты сообщения, но в нем нет многих других понятий, необходимых для реализации взаимодействия с разными платформами. Для полного понимания существа модели важно осознать, что можно говорить о двух взаимосвязанных схемах. Есть горизонтальная модель на базе протоколов, обеспечивающая механизм взаимодействия программ и процессов на различных компьютерах. И есть вертикальная модель на основе услуг, обеспечиваемых соседними уровнями друг другу на одной машине. Это можно представить рисунком 4. 7 Application Layer 7 Уровень приложений 6 Presentation Layer 6 Уровень представления 5 Session Layer 5 Уровень сеанса 4 Transport Layer 4 Транспортный уровень 3 Network Layer 3 Сетевой уровень 2 DataLink Layer 2 Канальный уровень Второй уровень модели OSI/RF разбивается на два подуровня. 33 1 Физический уровень 1 Physical Layer Рисунок 4. Схема модели взаимодействия открытых систем В горизонтальной модели двум программам или сервисам, реализующим те или иные запросы, требуется общий протокол для обмена данными. В вертикальной - соседние уровни обмениваются данными с использованием интерфейсов соответствующих API. В результате задача организации взаимодействия между приложениями, выполняющихся на разных компьютерах, последовательно делится на более простые подзадачи, обеспечивается совместимость между продуктами разных производителей и упрощается разработка приложений за счёт создания отдельных уровней и использования уже существующих реализаций. Как общепринятый стандарт (которым, правда, практически никто не пользуется, но, тем не менее все принимают во внимание) модель OSI/RF была принята ISO в 1978 г. К тому времени уже существовало несколько моделей взаимодействия компьютеров (стеков протоколов6). Ныне общеизвестный и наиболее распространённый открытый стек протоколов TCP/IP в то время ещё только развивался и основные участники разработки пытались продвинуть в качестве общего стандарта свой стек. Победил семиуровневый стек протоколов SNA (Systems Network Architecture), за которым стояла компания IBM, и он лёг в основу нового стандарта. Стеку протоколов на базе модели OSI прочили большой успех, поскольку надеялись на силу открытого стандарта. Однако этого не произошло, так как другой открытый стандарт (стек TCP/IP) также мог свободно распространяться; его разрабатывало открытое сообщество профессионалов, его никто никому не навязывал, а успехи в использовании и дальнейшем совершенствовании стека TCP/IP были существенными. 6 Стеком протоколов называют иерархически организованный набор взаимосвязанных сетевых протоколов, необходимых для организации взаимодействия между двумя системами. 34 Чтобы понять правильно модель OSI/RF следует рассмотреть прохождение данных от приложения, выполняющегося на одной платформе к приложению или службе, которые выполняются на другой платформе. В отношениях между двумя вычислительными процессами, которые выполняются на разных компьютерах, мы должны будем увидеть отношение «клиент — сервер». Но приложение на первой платформе не может напрямую обратиться к другой платформе; оно может обратиться только к своей платформе, на которой оно выполняется. Это обращение (системный вызов) к операционной системе упрощённо можно представить в виде связки из заголовка H (Header) и тела вызова Data, см. рис. 5 H Data Рисунок 5. Упрощённый формат системного вызова Главная роль, которую должен выполнять уровень приложений, состоит в том, чтобы заголовок H', сообщающий операционной системе клиентского компьютера на её API1 что конкретно нужно сделать с данными Data на другом компьютере (сервере), был бы заменён на заголовок H 7 , т. е. вместо API1 дальше будет использоваться сетевое API; назовём его NetAPI. Уровень приложений на втором компьютере (условном сервере) должен уметь однозначно интерпретировать заголовок H7 и преобразовать его в заголовок H''. Операционная система второго компьютера поддерживает API2 , поэтому чтобы правильно интерпретировать запрос H' компьютер-сервер после обратной трансляции получит запрос H''. Таким образом, на самом верхнем уровне модели (седьмом) на платформе-клиенте осуществляется замена H' на H 7 , а на компьютере-сервере — H7 на H''. Следующий — шестой — уровень модели отвечает за несколько задач, которые связаны с представлением данных. Главная задача заключается в том, чтобы платформа, выступающая в роли сервера, могла бы правильно интерпре35 тировать поступающие на неё данные. Поскольку данные от платформы-клиента к платформе-серверу передаются по общей среде и могут быть перехвачены, то на шестом уровне модели OSI они могут быть не только перекодированы (например, с целью уменьшения избыточности или, наоборот, внесения необходимой избыточности для контроля их целостности), но и зашифрованы. Информацию о том, что это за данные, как они представлены и закодированы, несёт заголовок H6 , который ставится перед парой H7 Data . Эта процедура группирования (точнее, вложения) заголовков называется инкапсуляцией данных. Вся эта последовательность данных, включая заголовки H 6 и H7, должны быть отправлены серверу. Но поскольку абоненты (клиент и сервер) связаны друг с другом через среду передачи данных наравне с множеством других платформ с их собственными, возможно сложным образом взаимодействующими вычислениями, то необходимо установить сеанс связи, а далее его не только поддерживать, но и завершить по окончании. Эту задачу возлагают на следующий — пятый — уровень модели. Из-за того, что имеющиеся технологии передачи данных не являются абсолютно надёжными, а данные передаются последовательно и, в случае разрыва соединения, потребуется много времени на повторную передачу, данные могут быть разбиты на так называемые сегменты. Очевидно, что потери на повторную передачу некоторого сегмента данных будут меньше, чем на повторную передачу всех данных. За передачу данных (или сегментов данных) от одного абонента к другому, которые уже установили между собой сеанс связи, отвечает следующий — четвёртый — уровень модели; его назвали транспортным. Передача данных осуществляется небольшими порциями данных, которые называют пакетами. Величина пакета выбирается такой, чтобы во время передачи пакета между двумя компьютерами (их часто называют узлами сети), связанными друг с другом непосредственно посредством некоторой разделяемой среды передачи, последняя предоставлялась на относительно небольшой промежуток времени. Тогда в следующий промежуток времени через тот же самый участок соедине36 ний (канал передачи данных) можно будет передавать другой пакет; этот другой пакет может быть связан с прежней парой абонентов или с какой-нибудь иной парой абонентов. Такой метод организации передачи данных между платформами, представляющих собой множество узлов и образующих сеть, называется методом коммутации пакетов. В конце 60-х годов было показано, что для организации обмена данными между компьютерами метод коммутации пакетов имеет преимущество перед методом коммутации каналов, при котором для обмена данными сначала должен быть организован (предоставлен) канал. На этом уровне каждый пакет получает заголовок H 4 , в котором указывается протокол транспортировки данных и номер пакета. Различают протоколы, гарантирующие доставку всех пакетов, из которых состоит сегмент данных, и протоколы, которые не гарантируют передачу всех пакетов. Дело в том, что каждый пакет передается по сети независимо от других пакетов, т. е. они могут передаваться разными путями (маршрутами) и, как следствие, пакеты могут достигать адресата не в той последовательности, в которой они отправлялись. Поэтому если пакеты пришли в узел назначения с нарушением очередности, то их можно будет должным образом упорядочить. А если какие-то пакеты вообще не дойдут до места назначения или будут испорчены, то можно будет попросить отправителя передать их повторно. Очевидно, что такой подход может приводить к появлению порой существенных задержек при передаче сегментов данных. Поэтому при необходимости обеспечить передачу пакетов без задержек (в реальном масштабе времени) могут оказаться полезными протоколы без гарантии доставки всех пакетов. В качестве примера можно назвать IP-телефонию, где важно пусть и с помехами, но передавать в соответствии с реальным временем пакеты, в которых находятся оцифрованные звуки. Пакеты данных передаются между узлами, связующими множество вычислительных сетей в единую сеть. Напомним, что вычислительной сетью называют множество компьютеров, связанных между собой сетевыми соединениями. А сетевые соединения — это соединения между компьютерами с помощью 37 специальных устройств ввода-вывода, которые позволяют передавать информацию (данные) через некую среду передачи данных. Но если две вычислительных сети соединить друг с другом через специальный связующий компьютер, то мы опять же получим сеть. Только она будет состоять из двух подсетей. Другими словами, можно говорить о сетях и о подсетях. Компьютер, входящий в первую и во вторую подсети, т. е. имеющий две сетевые карты, из которых одна соединяет его с первой сетью, а вторая — со второй, называется маршрутизатором. Маршрутизаторы могут иметь и большее количество сетевых карт, которыми они подсоединяются к другим подсетям. Есть маршрутизаторы, соединяющие друг с другом многие десятки подсетей. За передачу пакетов через маршрутизаторы отвечает третий уровень модели OSI. Маршрутизаторы должны иметь информацию о том, какие их сетевые карты связаны с какими подсетями и в какую подсеть нужно передать пакет, чтобы он смог в конечном итоге попасть к нужному компьютеру. Для решения этой задачи вводится двухуровневая адресация узлов: каждая подсеть получает уникальные идентификаторы и в каждой подсети компьютеры (узлы подсети) получают свои уникальные идентификаторы. Таким образом, можно встретить ситуацию, когда в нескольких подсетях можно будет иметь узлы с одинаковыми идентификаторами, но различаться такие узлы будут по идентификаторам подсетей, в которых они расположены. Это даёт возможность администраторам подсетей свободно назначать идентификаторы своих узлов и не зависеть в этом вопросе от других идентификаторов. Для решения задачи маршрутизации каждый пакет получает в качестве заголовка H 3 идентификаторы отправителя и получателя; именно эта информация и анализируется маршрутизаторами для принятия решения о дальнейшем продвижении пакета по сети. Решение задачи передачи пакета между двумя маршрутизаторами, связанными между собой одной и той же подсетью, как и решение задачи передачи пакета от маршрутизатора к конечному узлу-получателю, или от узла отправителя до ближайшего к нему маршрутизатора, или просто между двумя узлами, 38 находящимися в одной и той же подсети, относится ко второму — канальному — уровню модели OSI. Этот уровень ещё иногда называют уровнем доступа к среде передачи данных. На самом деле это уровень решает две разные задачи и поэтому его в общем случае разбивают на два подуровня. Верхний подуровень называют LLC-sublayer (Logical Link Control – управление логическим соединением), а нижний — MAC-sublayer (Media Access Control — управление доступом к среде передачи). Дело в том, что по среде передачи данных сетевыми устройствами (сетевым картами, репликаторами и коммутаторами) передаются за один раз так называемые кадры (фреймы7). Подуровень LLC нужен для того, чтобы пакеты, размеры которых могут быть существенно больше размера кадра, были представлены в виде соответствующей последовательности кадров (подобно тому, как сегмент данных разбивался на пакеты на транспортном уровне). Во-первых, размеры пакетов могут быть разной величины. А во-вторых, разные сетевые технологии имеют различные по размеру кадры данных. Есть технологии, где кадр данных может достигать размера пакета , а есть такие технологии, при использовании которых пакет приходится разбивать на несколько десятков кадров. Каждый кадр передается самостоятельно, но на приёмной стороне из кадров собирается пакет и если какие-то кадры оказались испорченными вследствие ошибок, то их передают повторно. Именно за это и отвечает подуровень управления логическим соединением. Подуровень MAC решает задачу отправки и приёма кадров через среду передачи в соответствии с принятым протоколом. Среда передачи является общей, поэтому нужен чёткий протокол предоставления этой среды конкретному отправителю на всё время передачи кадра. Все активные сетевые устройства, подключённые к среде передачи, имеют свои уникальные идентификаторы, которые принято называть MAC-адресами. Каждый кадр несёт в 7 Frame — кадр (порция) данных, которая передается по среде передачи. 39 заголовке H2 информацию о начале кадра, MAC-адресах получателя и отправителя, типе кадра и его размере; заканчивается кадр контрольной суммой, с помощью которой можно обнаружить ошибку в полученных данных. На самом нижнем уровне модели OSI — физическом — определяются стандарты на среду передачи данных. Другими словами, здесь определяются амплитуды, частоты, полярности передаваемых сигналов, кабели и разъёмы, и многое другое. При соблюдении этих стандартов можно рассчитывать на то, что используемые компоненты будут согласованы между собой и взаимозаменяемы. На этом уровне никаких заголовков к кадрам уже не добавляется. Это сугубо аппаратный уровень в модели взаимодействия открытых систем. Вышеизложенное можно проиллюстрировать рисунком 8, на котором показаны типы, с которыми работают на соответствующем уровне и задачи, которые решаются на этом уровне. Тип данных Уровень (layer) Решаемые задачи Доступ к сетевым службам для передачи запроса от клиента к серверу Представление данных, их кодирование и шифрование Управление сеансом связи Прямая связь между конечными пунктами и надежность Определение маршрута и логическая адресация Физическая адресация Работа со средой передачи, сигналами и двоичными 7. Прикладной (application) Данные 6. Представительский (presentation) 5. Сеансовый (session) Сегменты 4. Транспортный (transport) Пакеты 3. Сетевой (network) Кадры 2. Канальный (data link) Биты 1. Физический (physical) Рисунок 8. Модель взаимодействия открытых систем. Обработка запроса клиентом. На стороне сервера получаемые сигналы, а значит и кадры, обрабатываются в соответствии с моделью OSI, но только теперь следует продвигаться от нижнего уровня к верхнему. Если кадр данных принимается репликатором или коммутатором, то он просто передаётся дальше, т. е. ретранслируется без изме40 нений. А если кадры поступают на подуровень LLC, то из них собирается пакет. Если пакет поступил на конечный узел-получатель, то он поступает на транспортный уровень. В противном случае маршрутизатор пересылает пакет в следующую подсеть. На каждом уровне соответствующее программное обеспечение обрабатывает заголовок своего уровня и выполняет возложенные на него задачи. В конечном итоге из полученных сегментов получаем данные, преобразуем их к необходимым форматам и после трансляции заголовка H 7 в заголовок H'' передаём их для выполнения над ними заказанных клиентом действий. Важно различать модель OSI и стек протоколов OSI, который был через некоторое время создан. В то время как модель OSI является концептуальной схемой взаимодействия открытых систем, стек OSI представляет собой набор спецификаций конкретных протоколов. Для иллюстрации приведём краткую схему стека OSI. В отличие от модели OSI RF стек протоколов OSI разрабаты вался в течение 7 лет. Увы, к 1984 г. он уже не смог занять если не лидирующие, то хотя бы весомые позиции, ибо к тому времени доминирующую роль занял стек TCP/IP; мы рассмотрим его позже. 7.Прикладной X.500 VTP FTAM JTM X.400 6.Представления 5. Сеансовый Протокол уровня представления OSI Сеансовый протокол OSI 4. Транспортный Транспортные протоколы OSI 3. Сетевой 2. Канальный ES-IS, IS-IS, CONP, CLNP X.25 41 ISDN Другие 1. Физический Ethernet (OSI-8802.3, IEEE-802.3) Token Bus (OSI8802.4, IEEE802.4) HDLC LAP-B FDDI (ISO9314) Token Ring (OSI8802.5, IEEE802.5) Рисунок 9. Стек протоколов OSI Лекция 4. Интернет как пример открытой системы 4.1. Краткая история возникновения Интернета Как это ни странно, но в Советском Союзе прорабатывались идеи объединения компьютеров в единую вычислительную систему посредством использования телекоммуникаций и построения мощной централизованной системы управления народным хозяйством. Истоком первых советских проектов по использованию ЭВМ для управления экономикой послужили проводившиеся в то время работы по развитию компьютерных систем военного назначения. В середине 1950-х годов советские военные эксперты обратили самое серьезное внимание на создаваемую в США систему противовоздушной обороны SAGE (Semi-Automatic Ground Environment). В ее основе лежало создание централизованной общенациональной сети компьютеризированных пунктов контроля и управления для координации адекватного ответа на возможное массированное воздушное нападение противника. В ответ Советский Союз принял решение создать три системы аналогичного назначения: систему противовоздушной оборо42 ны, систему ракетной защиты и систему контроля космического пространства — каждую с собственной централизованной компьютерной сетью. Инициатива применения вычислительных машин в экономике исходила от тех же специалистов, кто проектировал, внедрял и использовал военные системы. Однако этим проектам не суждено было сбыться в полной мере, а нашей стране — занять заметное место в мире информатики и первой создать глобальную компьютерную сеть, поскольку партийные чиновники вследствие своей неграмотности испугались потенциальных возможностей, которые несли вычислительная техника и информационные технологии. В результате в конечном итоге лидерство в этом направлении науки и техники так и осталось за США. После запуска Советским Союзом искусственного спутника Земли в 1957 году Министерство обороны США посчитало, что на случай войны Америке нужна надёжная система передачи информации, а не просто система компьютеров, связанных телекоммуникациями. Агентство передовых оборонных исследовательских проектов США (Defence Advanced Research Projects Agensy DARPA) в 1961 году предложило разработать для этого соответствующую компьютерную сеть. Разработка такой сети была поручена Калифорнийскому университету в Лос-Анджелесе (University of California), Стэнфордскому исследовательскому центру (Stanford Research Institute), Университету штата Юта (University of Utah) и Университету штата Калифорния в Санта-Барбаре (University of California) . Все работы финансировались Министерством обороны США. В 1966 году в DARPA пришел Ларри Робертс с идеей распределенной сети, не имеющей центрального компьютера. В 1968 начали работать совместно четыре станции, в 1969 принят первый RFC-документ. Компьютерная сеть была названа ARPANet (англ. Advanced Research Projects Agency Network) и в 1969 году в рамках проекта сеть объединила четыре указанных выше научных учреждения. Эта сеть предназначалась первоначально для изучения методов обеспечения надежной связи между компьютерами различных типов. Многие методы передачи данных через модемы были 43 разработаны в ARPANet. Тогда же были разработаны и протоколы передачи данных в сети - TCP/IP. Стек TCP/IP - это множество коммуникационных протоколов, которые определяют, как компьютеры различных типов могут общаться между собой. Затем сеть ARPANet начала активно расти и развиваться, её начали использовать учёные из разных областей науки. В 1972 была проведена международная конференция с демонстрацией сети из 40 машин и эти технологии стали быстро распространяться. В 1971-72 годах вышел первый стандарт для протоколов TCP/IP (разработчик - Internet Working Group), вошедший в Military Standarts (MIL STD), т.е. в военные стандарты, и все, кто работал в сети, обязаны были перейти к этим новым протоколам. Для облегчения этого перехода DARPA обратилась с предложением к руководителям фирмы Berkley Software Design - внедрить протоколы TCP/IP в Berkeley Software Distribution (BSD UNIX). С этого и начался союз UNIX и TCP/IP. В настоящее время стек TCP/IP является родным для всех UNIX-подобных систем, в том числе и для GNU/Linux. Эксперимент с ARPANet был настолько успешен, что многие организации захотели войти в нее, с целью использования для ежедневной передачи данных. И в 1975 году ARPANet превратилась из экспериментальной сети в рабочую сеть. Ответственность за администрирование сети взяло на себя Defence Communication Agency (DCA), в настоящее время называемое Defence Information Systems Agency (DISA). Но развитие ARPANet на этом не остановилось; протоколы TCP/IP продолжали развиваться и совершенствоваться. В 1983 году из ARPANet выделилась MILNET, которая стала относиться к Defence Data Network (DDN) министерства обороны США. Термин Internet стал использоваться для обозначения единой сети: MILNET плюс ARPANET. И хотя в 1991 году ARPANet прекратила свое существование, сеть Internet не просто существует, а ее нынешние размеры на несколько порядков превышают первоначальные, так как она объединила множество сетей во всем мире. 44 Всемирная паутина - World Wide Web (WWW) появилась много позже, в 1992 году. Точно известен автор - Тим Бернерс-Ли из Европейского центра ядерных исследований (CERN), расположенного в Женеве (Швейцария). Мало кому известная, появившаяся за счет энтузиазма, технология обеспечила лавинообразный рост Интернета, и тот бескрайний океан информации, который мы имеем сейчас. Своеобразным рубежом многие считают 1993 год, когда количество подключенных серверов перевалило за миллион. После этого пропали последние сомнения в перспективах сети сетей. Историю Интернета в России (а ранее – в Советском Союзе) принято отсчитывать с 1982 года, когда Курчатовский институт атомной энергетики (КИАЭ) начал разрабатывать UNIX-подобную операционную систему. К 1986 году появилась сеть из трех узлов Демос - КИАЭ - СП Диалог. Там же в начале 1990 года состоялся первый сеанс связи с зарубежными сетями Интернет (Хельсинки). И уже к осени 1990 года сложилось ядро сети СССР. Узлы общались друг с другом по dial-up (скорость 1200/2400), то есть выделенных линий не было. Но это не помешало уже в сентябре зарегистрировать домен .su. В феврале 1991 был запущен первый в нашей стране междугородний канал связи на протоколе TCP/IP. Работал он по модему между Москвой и Барнаулом. А к середине того же года в Советском Союзе уже существовала коммерческая сеть «РЕЛКОМ», первоначально организованная компанией Демос. Вообще говоря, история достаточно запутанная, и имеется несколько вариантов развития событий. Почитать об этом лучше всего в Интернете :) . Постепенно новая технология вошла в моду, а движение от сетей "академического" назначения к коммерческой передаче данных стало массовым. Назвать его быстрым и согласованным нельзя, сильно повлияла на этот процесс перестройка. Известны и громкие скандалы, и успехи. Но общим было то, что развитие шло скорее за счет энтузиазма и веры в будущее, чем реальных доходов. 45 Некоторое изменение ситуации стало заметно в 1994 году. Быстро начало расти количество пользователей, был зарегистрирован домен .ru. , начавший официально существование Интернета в России. А в ноябре 1994 года начал выходить первый в Рунете гипертекстовый журнал, т.е. заработал протокол HTTP. 4.2. Организационная структура Интернета С технической точки зрения Интернет — это прежде всего объединение транснациональных компьютерных сетей, работающих по самым разнообразным технологиям сетевых коммуникаций и связывающих всевозможные типы компьютеров, физически передающих данные как по различным кабелям, начиная от телефонных проводов и кончая оптоволоконными кабелями, а также используя бескабельные коммуникации через радиомодемы и спутники. Структура сети Интернет напоминает ответвления различных сетей от дерева, которое является опорной сетью. При этом трафик сети Интернет со временем во многом стал коммерческим, и поэтому встал вопрос разграничения сетей коммерческого и научно-исследовательского пользования. Такое положение дел привело к тому, что единой организации, контролирующей и ответственной за состояние всей сети Интернет, не существует, как не существует и централизованного руководства всей Сетью. Каждая организация управляет своим участком Сети и устанавливает свои правила для пользователей, работающих с её ресурсами. Таким образом, Интернет представляет собой объединение различных региональных и организационных сетей, каждая из которых управляется своей организацией по своим внутренним правилам. Существует, однако, ряд организаций, в основном общественных, которые выполняют конкретные функции, позволяющие поддерживать порядок в Сети. Эти организации вырабатывают рекомендации, поддерживают форумы активных пользователей Интернет, способствуют распространению новых технологий, ведут базу данных адресов, а также выполняют другие функции. 46 Наиболее известной и глобальной из них является организация «Сообщество Интернета» (Internet Society — ISOC), которая проводит обсуждения по различным техническим и организационным вопросам использования ресурсов Интернет и издает журнал Internet Society News, где представлена информация обо всей сети Интернет. Это сообщество предоставляет организационную основу для множества других консультативных и исследовательских групп, занимающихся развитием Интернета. Выработкой стандартов на протоколы Интернета занимается общественная организация «Инженерный совет Интернета» (Internet Ingineering Task Force — IETF). Проведением исследований, связанных с развитием Сети и ее будущим, занимается организация «Исследовательские силы Интернета» (Internet Research Task Force — IRTF). Подобными вопросами в Европе занимается Европейская ассоциация сетей и пользователей. Кроме того, существуют несколько Центров сетевой информации (Internet Network Information Center — InterNIC), которые распространяют информационные материалы по работе организаций в Интернете, в том числе и перечисленных выше. Эти же организации поддерживают базу данных по доменам и адресам Интернета и полный комплект RFC-документов, которые содержат всю документацию по организации протоколов Интернета и самой сети: описание протоколов, используемых при организации сети, протоколов ресурсов, кодовых таблиц и другую информацию, претендующую на статус стандарта. Главным регулирующим органом является международная некоммерческая организация «Корпорация по управлению доменными именами и IP-адресами» (Internet Corporation for Assigned Names and Numbers — ICANN), созданная в 1998 году при участии правительства США для регулирования вопросов, связанных с доменными именами, IP-адресами и прочими аспектами функционирования Интернета. ICANN состоит из международных представителей и принимает решения в совещательном порядке. В ряде стран полагают, что функции ICANN, главным образом сводящиеся к управлению системой доменных имен и распределению блоков IP-адресов, должны быть переданы какой47 либо организации под эгидой ООН (например, Международному союзу электросвязи ITU), чтобы обеспечить более активное участие развивающихся стран в управляющей деятельности. Однако власти США объявили, что не намерены передавать кому-либо базовые контролирующие полномочия, которые де-факто находятся в ведении министерства торговли США, которое унаследовало их у Пентагона, где Интернет был создан. В 1998 году министерство торговли делегировало полномочия ICANN, но оставило за собой право вето. США считают Интернет важнейшим механизмом международного информационного взаимодействия, в первую очередь, коммерческого, и полагают, что контроль за корневыми DNS-серверами должен оставаться в руках тех, кто их создал и поддерживает, так как стабильность существующей структуры уже подтверждена, а подвергать базовые механизмы сети опасности дестабилизации недопустимо, поэтому проекты комиссии ООН не могут инициировать смену главного управляющего субъекта. 4.3. Документы Интернета Основные протоколы, спецификации и стандарты на Интернет представлены в виде RFC-документов. Отвечает за них инженерный совет Интернета — специальная группа IETF (Internet Engineering Task Force). Как мы уже знаем, это открытое международное сообщество проектировщиков, учёных, сетевых операторов и провайдеров, созданное группой технических советников, которая занимается развитием и обеспечением доступности сети Интернет. Именно оно обладает правами на все стандарты Интренета. В основные задачи, возложенные на неё входят:  надзор за архитектурой Интернета, включая его протоколы и связанные с ними процедуры;  надзор за созданием новых стандартов Интернета; 48  редактирование и публикацию серии RFC-документов;  консультации руководства сообщества Интернета по техническим, архитектурным и процедурным вопросам, связанным с Интернетом и его технологиями. Собственно RFC (Request for Comments — запрос на комментарии) представляет собой и документ, и способ распространения информации, хранящейся на общедоступном сервере. Документы RFC имеют последовательную нумерацию, поэтому при появлении нового документа он просто получает новый порядковый номер. Причём в каждом документе в его начале перечисляются все те основные RFC-документы, на основании которых появился новый. Важно отметить, что эти документы по своей сути представляют собой стандарты Интернета. Причём они имеют разный статус, что должно быть очевидным. Согласно RFC 2026, жизненный цикл стандарта выглядит следующим образом:  Выносится на всеобщее рассмотрение Интернетовский черновик (Internet Draft). Черновики не имеют официального статуса, и удаляются из базы через шесть месяцев после последнего изменения.  Если черновик стандарта оказывается достаточно удачным и непротиворечивым, он получает статус Предложенного стандарта (Proposed Standard), и свой номер RFC. Наличие программной реализации стандарта желательно, но не обязательно.  Следующая стадия — Черновой стандарт (Draft Standard) означает, что предложенный стандарт принят сообществом, в частности, существуют две независимые по коду совместимые реализации разных команд разработчиков. В черновые стандарты ещё могут вноситься мелкие 49 правки, но они считаются достаточно стабильными и рекомендуются для реализации.  Высший уровень — Стандарт Интернета (Internet Standard). Это спецификации с большим успешным опытом применения и зрелой формулировкой. Параллельно с нумерацией RFC они имеют свою собственную нумерацию STD. Список стандартов имеется в документе STD 1 (сейчас это RFC 5000, но нумерация может измениться). Из более чем трёх тысяч RFC-документов этого уровня достигли только несколько десятков.  Многие старые RFC замещены более новыми версиями под новыми номерами, или вышли из употребления. Такие документы получают статус Исторических (Historic). Практически все стандарты Интернета существуют в виде опубликованных заявок RFC. Но в виде документов RFC выходят не только стандарты, но также концепции, введения в новые направления в исследованиях, исторические справки, результаты экспериментов, руководства по внедрению технологий, предложения и рекомендации по развитию существующих Стандартов и другие новые идеи в информационных технологиях:  Экспериментальные (Experimental) спецификации содержат информацию об экспериментальных исследованиях, интересных для интернет- сообщества. Это могут быть, например, прототипы, реализующие новые концепции.  Информационные (Informational) RFC-документы предназначены для ознакомления общественности, не являются стандартами и не являются результатом консенсуса или рекомендациями. Некоторые черновики, не 50 получившие статуса Предложенного стандарта, но представляющие интерес, могут быть опубликованы как Информационные RFC.  Лучший современный опыт (Best Current Practice). Эта серия RFCдокументов содержит рекомендации по реализации стандартов, в том числе от сторонних организаций, а также внутренние документы о структуре и процедурах стандартизации. Почти все стандарты разрабатываются под эгидой каких-либо научных или интернет-организаций (например W3C, IETF, консорциум Юникода, Интернет2). Напоследок приведём URL8 на сервер, где расположены RFC-документы — http://www.rfc-editor.org/retrieve/. Имеется и русскоязычные ресурсы — http://rfc2.ru/. 4.4. Архитектура стека TCP/IP Стек протоколов TCP/IP был создан до появления модели взаимодействия открытых систем и, тем более, намного раньше собственно стека протоколов OSI. Поэтому его архитектура получилась существенно проще и вместо семи уровней он имеет только четыре. Причём самый нижний уровень в стеке TCP/IP вообще не специфицирован, т. е. фактически имеются свои протоколы только для трёх уровней. Рассмотрим рисунок 10, на котором отражена эталонная модель стека TCP/IP и её соответствие уровням эталонной модели взаимодействия открытых систем (OSI OSI). Модель OSI Стек TCP/IP 8 URL — Uniform Resource Locator — указатель на информационный ресурс в Интернете, записанный универсальным (стандартизированным) образом. Описан в RFC 1748. 51 7 Уровень приложения 1 6 Уровень представления данных 5 Уровень Сеанса 4 Транспортный уровень Уровень транспорта 2 3 Уровень сети Межсетевой уровень 3 2 Канальный уровень Уровень сетевого интерфейса 4 1 Физический уровень Уровень приложения Рисунок 10. Уровни стека TCP/IP К уровню приложений относится достаточно большое количество протоколов, включая те службы, без которых использование стека стало бы неудобным. Дело в том, что этот уровень напрямую взаимодействует с выполняющимися приложениями, более того, имеются изначально сетевые приложения, поэтому разнообразие их запросов приводит к появлению большого числа протоколов. Прежде всего, это протоколы для работы с файлами; к ним относятся протоколы FTP (File Transfer Protocol — протокол передачи файлов), TFTP (Trivial File Transfer Protocol — простой протокол передачи файлов), NFS (Network File System — сетевая файловая система). Для целей удалённого управления вычислениями через интерфейс командной строки есть протоколы Telnet и SSH (Security Shell). Они имитируют работу в терминальном режиме на удалённом компьютере, обеспечивая передачу команд на него и приём ответов системы. Первый из них не безопасен и лучше его не использовать. А второй протокол позволяет безопасно установить соединение с удалённым компьютером, передавая регистрационные данные пользователя (его логин и пароль) по технологии открытого ключа, и в дальнейшем 52 осуществлять обмен зашифрованными данными, но уже по технологии закрытого ключа. Если необходимо обеспечить работу пользователя в графическом интерфейсе, то это можно сделать как через систему X Window, так и Virtual Network Computing (VNC), которые используют простой клиент-серверный сетевой протокол прикладного уровня для удалённого доступа к графическому рабочему столу компьютера RFB (Remote Frame Buffer). Для работы с электронной почтой имеются такие протоколы как SMTP (Simple Mail Transfer Protocol — простой протокол отправки почтового сообщения), POP3 (Post Office Protocol) и IMAP (Internet Message Access Protocol). Последние два протокола используются для получения почтовых сообщений, приходящих на почтовый сервер. Для работы с гипертекстом используются протоколы HTTP (Hyper Text Transfer Protocol) и HTTPS (HTTP Security — безопасный протокол HTTP); они используются как основа для построения Всемирной Паутины — World Wide Web (WWW) — распределенных информационных систем гипермедиа. Для поисковых систем первое время использовался протокол Gopher, но вскоре он был вытеснен системами на основе полностью открытого протокола HTTP, поскольку за использование протокола Gopher стали взимать лицензионные отчисления. Для управления сетевыми устройствами есть протокол SNMP (Simple Network Management Protocol). Для размещения, распространения, запроса и получения групп новостей при взаимодействии между сервером групп новостей и клиентом имеется протокол NNTP (Network News Transfer Protocol). Что касается сетевых служб, то это прежде всего система доменного именования —DNS (Domain Name System) и служба конфигурирования узлов, с 53 помощью которой можно автоматизировать назначение IP-адресов; это протокол DHCP (Dynamic Host Configuration Protocol). К уровню транспорта прежде всего следует отнести протоколы TCP и UDP, однако к нему относятся и другие более новые протоколы — SCTP, DCCP. Протокол управления передачей (Transmiccion Control Protocol — TCP) является тем самым протоколом, который гарантирует передачу данных между узлами, поэтому он и вошёл в название стека. Он нумерует все пакеты, благодарю чему есть возможность не только проконтролировать их получение, но при необходимости и переупорядочить, если они будут получены в другом порядке. Поскольку этот протокол вносит задержки, то для передачи данных в масштабе реального времени предназначен протокол UDP — User Datagram Protocol. Согласно этому протоколу они отправляются и получаются в естественном порядке. И если какой-то пакет задерживается, то он просто игнорируется протоколом. Протокол передачи с управлением потоком ( Stream Control Transmission Protocol — SCTP) по сравнению с TCP имеет несколько нововведений, таких как многопоточность, защита от dDos атак, синхронное соединение между двумя хостами по двум и более независимым физическим каналам. Протокол дейтаграмм управление перегрузкой (Datagram Congestion Control Protocol DCCP) предоставляет механизмы для отслеживания перегрузок в сети, избегая необходимости создавать их на прикладном уровне. Этот протокол не гарантирует доставку информации в нужном порядке. Подобно UDP протокол DCCP эффективен для приложений, в которых данные, пришедшие не вовремя, становятся бесполезными. Например, интернет-телефония, потоковое медиа-вещание, онлайн-игры. Главная особенность этих приложений состоит в том, что старые сообщения очень быстро становятся бесполезными, поэтому лучше получить новое сообщение, чем пытаться переслать старое. К межсетевому уровню прежде всего относится протокол IP (Internet Protocol — межсетевой протокол), который как один из самых важнейших даже вошёл в название всего стека. Заметим, что неотъемлемой частью этого прото54 кола является двухуровневая адресация. IP-адрес содержит в себе сразу два идентификатора — идентификатор сети, в которой находится узел, и идентификатор собственно узла. Пакеты (IP-пакеты) свободно передаются между узлами одной сети. Но для перехода в другую сеть нужно иметь специальный узел с как минимум двумя сетевыми интерфейсами, среди которых один принадлежит первой сети, а остальные — другим сетям. Такие узлы с двумя или более сетевыми интерфейсами при наличии механизма передачи пакетов с одного интерфейса на другой называют маршрутизаторами. Посредством маршрутизаторов множество сетей может быть соединено в единую сеть следующего уровня иерархии — общую интегрированную сеть. Для большей ясности может использоваться термин подсеть (subnet) по отношению к простым сетям, в то время как интегрированную сеть можно тогда называть сетью (network). Internet по-существу и является множеством подсетей. Помимо адресации протокол IP определяет структуру пакета и правила маршрутизации. Протокол IP не гарантирует надёжной доставки пакета до адресата — в частности, пакеты могут прийти не в том порядке, в котором были отправлены, продублироваться (приходят две копии одного пакета), оказаться повреждёнными (обычно повреждённые пакеты уничтожаются) или не прийти вовсе. Гарантию безошибочной доставки пакетов дают некоторые протоколы более высокого уровня — транспортного. Помимо IP к этому же уровню относятся протоколы ICMP (Internet Control Message Protocol), SLIP (Serial Link Internet Protocol), PPP (Point to Point Protocol). Для связи с уровнем сетевых интерфейсов есть протоколы ARP (Address Resolution Protocol) и RARP (Reverse ARP). А для автоматизации решения задач маршрутизации и возможности находить оптимальные маршруты имеются протоколы, хоть и относящиеся к третьему (межсетевому) уровню, но использующие вышеперечисленные протоколы этого уровня. Это RIP (Routing Information Protocol), OSPF (Open Shortest Path First) и другие. 55 Как уже говорили, на четвёртом уровне — уровне сетевого интерфейса — стек TCP/IP не имеет своих протоколов. Допускается использование самых разных сетевых технологий. И на этом уровне работают драйверы сетевых карт и остального активного сетевого оборудования, которые и реализуют работу. Детальное изучение протоколов TCP/IP выходит за рамки нашего курса. Лекция 5. Общие спецификации на устройства внешней памяти с прямым доступом Основным способом обеспечить возможность программам работать на разных компьютерах (но с одной архитектурой) является виртуализация. При создании приложения программист работает с виртуальной памятью, виртуальными файлами, виртуальными устройствами. Благодаря тому, что механизмы виртуализации осуществляют трансляцию виртуальных объектов в реальные физические, об особенностях которых программисты могут не задумываться, их программы перестают зависеть от реальных устройств. Желательно виртуализировать как можно большее количество типов объектов, с которыми работают приложения. Тогда можно не только не зависеть от конфигурации компьютера, на котором сможет выполняться приложение, но и существенно проще будет обеспечить мобильность приложений и интероперабельность. Если для виртуализации памяти помимо операционной системы, которая создаёт и поддерживает специальные таблицы трансляции виртуальных адресов в реальные, обязательно нужна аппаратная поддержка, то для виртуализации файлов и устройств достаточно системных соглашений и спецификаций, и специального системного кода, обеспечивающего работу с виртуальными объектами. Другими словами, вместо двухуровневой модели клиент-сервер следует использовать трёхуровневые модели и даже их иерархические конструкции. В этом случае те программные модули, которые непосредственно работают на самом нижнем уровне или на нижних уровнях, могут быть заменены (без необходимости внесения изменений в модули верхних уровней). При56 чём все эти уровни поддерживаются платформой и собственно приложения от этих уровней не будут зависеть. Абсолютное большинство компьютеров использует различные устройства внешней памяти с прямым доступом. Самыми известными и на сегодня самым распространёнными такими устройствами являются накопители на жестких магнитных дисках (НЖМД). Эти устройства могут иметь разную ёмкость (объём), разные интерфейсы, через которые они подключаются к центральной части компьютера, на них могут быть использованы разные файловые системы, на них можно устанавливать даже по несколько операционных систем сразу. Очень часто эти устройства называют дисками, хотя понятно, что тот же твердотельный накопитель (SSD — Solid-State Drive) всего лишь представляет собой устройство внешней памяти, доступ к данным в котором осуществляется по тем же принципам, что и в классических НЖМД. А именно: данные хранятся в виде блоков, размеры которых уже давно принято делать равными 512 байтам. И при обращении к такому устройству указывается порядковый номер блока. За одну операцию можно либо записать 512 байтов, либо прочитать 512 байтов. А если нам нужно получить некую последовательность битов или байтов, то мы должны обратиться к тому блоку (или к тем тем блокам), в которых эта последовательность нужных нам данных расположена. Поскольку адресация блоков может быть относительной, а абсолютные адреса на устройстве могут быть вычислены, то появляется возможность виртуализировать подобные устройства. А для того, чтобы было легче реализовать механизмы трансляции адресов и полностью изолировать высокоуровневое системное программное обеспечение платформы, вводятся два важных понятия: логический диск (Logical Disk) и том (Volume). Логический диск — это множество блоков, расположенных по соседству, т. е. неразрывное множество. А том — это просто множество блоков, которое может быть не только неразрывным, но и разрывным. Другими словами, том представляет собой виртуализацию блочного устройства с прямым доступом, у которого блоки могут быть физически распо57 ложены даже на разных физических устройствах. Получается, что логический диск является всего лишь частным случаем того виртуального устройства, которое мы называем томом. Следует, однако, заметить, что не во всех операционных системах используется понятие логического диска. Так, UNIX-системы не имеют логических дисков, а говорят о разделах или томах. Кстати, широко известные RAID9-массивы создают тома и при этом реализуют такие способы виртуализации, которые предоставляют нам в общем случае более производительные и/или надёжные устройства, чем исходные диски, из которых делается массив. Очень важно отметить, что именно на томе может быть организована работа с файлами, т. е. форматируем мы тома (или логические диски). Благодаря тому, что тома на RAID-массивах можно организовывать на аппаратном уровне с помощью специальных контроллеров, операционная система может ничего не знать о реальных физических устройствах. Но при этом она сама в последующем может представить из этих томов логические диски или более сложные тома. Преимущество аппаратной реализации виртуальной внешней памяти заключается в том, что сама операционная система может быть расположена на RAID-массиве со всеми его преимуществами, в то время как в случае создания RAID-массива средствами операционной системы её собственные файлы должны находиться на обычных логических дисках. Поскольку желательно обеспечить возможность получения доступа к данным, расположенным на любом логическом диске или томе, подключая физическое устройство к разным компьютерам, то нужно чтобы любой компьютер однозначно мог распознать - каким образом устройство поделено на логические диски. Даже если весь накопитель представляется как единственный логиче9 RAID — Redundant Array of Inexpensive Disks — массив недорогих дисков с избыточностью. Технология, позволяющая представлять множество обычных жёстких дисков в виде высокопроизводительного и надёжного устройства с прямым доступом. 58 ский диск, то и в этом случае нужно сообщить системе об этом, ибо в общем случае может быть иначе. Другими словами, нужные общие для всех спецификации, позволяющие понять: где расположены логические диски и какого они размера? Спецификации, которые бы соблюдались всеми разработчиками операционных систем. Первым таким стандартом для персональных компьютеров была спецификация MBR, разработанная в компании IBM, но впервые реализованная в операционной системе MS-DOS 2.0 для IBM PC AT. Спецификации на IBM PC были открытыми, поэтому способ записи таблицы разделов (Partition Table), который был описан в спецификации на главную загрузочную запись (Master Boot Record - MBR), стал таким стандартом на несколько десятков лет. Главная загрузочная запись была введена для того, чтобы в этом блоке данных (а это первый блок на диске) находилась таблица разбиения НЖМД на разделы и можно было понять — какие логические диски есть на диске. Помимо таблицы разделов в этом блоке находится программа Non-System Bootstrap — внесистемный загрузчик. Эта программа анализирует таблицу разделов и получает адрес того блока, в котором (или начиная с которого) должна располагаться программа загрузки операционной системы. Таблица разделов небольшая — всего на четыре записи, причем каждая запись может описывать только один раздел (логический диск). После включения компьютера (или после нажатия на клавишу Reset) начинает выполняться программное обеспечение BIOS (Base Input-Output System), расположенное в постоянной памяти. Это, прежде всего, программа самотестирования POST (Power-On-Self-Test). Если всё работает правильно, то в случае, когда загрузка операционной системы должна осуществляться с НЖМД, упрощённый драйвер работы с такими дисками находит первый блок данных (т. е. MBR), загружает его в память и передаёт управление внесистемному загрузчику. 59 Детали блока данных, называемого MBR, включая описание формата записи таблицы разделов, достаточно подробно описаны в учебнике по операционным системам [ 2 ]. Здесь мы всего лишь скажем, что в одних операционных системах (прежде всего, это ОС от компании Microsoft) используется последовательная нумерация логических дисков, начиная от простых разделов (так называемые Primary partition), а затем нумеруются логические диски из расширенного раздела Extended logical (они являются подразделами более сложного раздела — Extended partition). А в других ОС (это прежде всего UNIX-подобные ОС) первые четыре номера зарезервированы за Primary partition, a Extended logical диски нумеруются, начиная с числа 5. Этот нюанс необходимо не забывать, если на одном НЖМД мы имеем (или хотим иметь) разные ОС. Отметим, что данный стандарт на описание таблицы разделов устарел. Главным образом потому, что для адресации блока данных отводится мало двоичных разрядов. Так, по спецификациям, которых придерживалась компания Microsoft, это всего лишь три байта, т. е. 24 бита. Это означает, что нельзя этим стандартом пользоваться, если размер устройства превышает 8 ГБ. С другой стороны, для UNIX-систем в каждой записи раздела для нумерации блоков отведено по 32 бита, а это позволяет адресовать до 2 ТБ. В любом случае этого уже давно стало мало. Поэтому в настоящее время для блочных устройств внешней памяти большого объема преимущественно используется новая спецификация, получившая название GPT. GPT — это GUID Partition Table, т.е. стандарт размещения данных о таблице разделов на физическом носителе данных блочного типа. В свою очередь, GUID - Globally Unique Identifier - это уникальный 128-битовый идентификатор, который присваивается разделу. Очевидно, что поскольку можно создать 2128 идентификаторов, вероятность коллизии получить два одинаковых идентификатора ничтожно мала, а уж тем более на одном компьютере. В тексте GUID записывается в виде строки из 32 шестнадцатеричных цифр, разбитой на группы дефисами и заключённой в фигурные скобки, например: {6D9619AF-8B86-D01E-B42D-00CF4FC964FC}. 60 Подобно тому, как блок MBR связан с BIOS, структура данных GPT непосредственно связана с программным обеспечением, которые ныне называется UEFI (ранее EFI). Главным недостатком BIOS было то, что это программное обеспечение ограничено в размере: обычно это 32КБ, причём вследствие 16разрядного режима работы процессора, в котором выполняется код BIOS, его размер не может быть больше 64КБ. Со временем это стало существенным препятствием и компания Intel пошла на создание расширяемого микропрограммного интерфейса (Extensible Firmware Interface — EFI). К проекту EFI присоединились другие производители и ведущие IT-компании, и EFI стал UEFI - Unified Extensible Firmware Interface. Важно, что UEFI добавляет полную аппаратную независимость и разделение интерфейса на загрузочные службы и runtime-службы. Целью этого шага было получение высокой степени стандартизации, а вместе с тем и предоставление достаточной гибкости для производителей. Итак, UEFI - это программный интерфейс, который работает между операционной системой и прошивкой платформы, что позволяет заменить BIOS. Тем более, что BIOS содержал 16-битный код, а UEFI может содержать и 32-битный, и 64-битный. Код UEFI достаточно сложный. Он не только предлагает поддержку драйверов, интерфейсов и служб, но также имеет оболочку, в которой пользователи могут выполнять приложения посредством интерфейса командной строки. UEFI содержит системную информацию, организованную в виде таблиц, здесь есть загрузочные и runtime-службы внутренней операционной системы. Загрузочные службы включают инициализацию, файловые службы и другие подобные, а также текстовые и графические консоли пользователя. Runtimeслужбы включают сервисы даты, времени и работы с NVRAM. Для поддержки связи между устройствами все драйверы и компоненты UEFI поддерживают связь через специальные протоколы. Драйверы тоже очень важны, поскольку 61 окружение устройств UEFI является независимым от процессора, обеспечивающим как инициализацию, так и работу устройств. Ещё раз отметим, что UEFI реализует собственный загрузчик, отвечающий за эту задачу. Поэтому прежняя схема загрузки ОС перестала быть актуальной. Схематично структура данных GPT представлена на рисунке 11. LBA 0 MBR для защиты структуры диска Запись GPT раздела 4LBA 2Главный заголовок таблицы GPT Запись GPT раздела 1 LBA 1 LBA 3Запись GPT раздела 2Запись GPT раздела 3 Записи GPT для остальных разделов ... ... LBA 34 ... ... ... Остальные разделы (всего до 128) Ma[ LBA - 33раздела 3Запись GPT Запись GPT раздела 4 Записи GPT остальных 62 разделов диска ... Max LBA - 2 Max LBA - 1 Рисунок 11. Схема структуры данных GPT К преимуществам GPT относятся:  Избыточность данных. Введено дублирование заголовка и таблиц разделов в начале и конце диска. Подобное нововведение позволило создать отказоустойчивость на уровне разделов, чего был лишен классический MBR. При повреждении одной из копий заголовка/таблиц разделов GPT, возможно их восстановление из резервной копии.  Огромный максимальный размер разделов, равный 9.4 зеттабайт (ЗБ) или 8 zebibyte (ZiB, ZB) или 264 блоков (блок имеет размер 512 байтов) или 9.4 x 1021 (9444732965739290427392) байтов. Чтобы было проще осознать такой объем — это примерно 9 миллиардов терабайт. MBR имел параметр «смещение первого сектора» в записи о разделе разрядностью всего 4 байта (32 бита, LBA-32), что позволяло адресовать лишь 4ГБ * размер сектора (512 байт) =~ 2 ТБ. В GPT размерность параметров, описывающих смещения разделов, увеличилась до 64 бит (LBA-64).  Отсутствие ограничения разметки MBR в четыре основные раздела (партиции). GPT может иметь до 128 разделов на одном физическом диске, что вполне достаточно даже для самых требовательных задач. 63  Отказ от такого архаизма, как логические диски в расширенном разделе, который присутствует в традиционной разметке MBR [ 2 ].  Отсутствие необходимости писать цепочку загрузчиков вида MBR-PBRbootmgr и самому работать с аппаратным обеспечением компьютера посредством использования портов и прерываний реального режима, нет необходимости заботиться о переходе в защищенный режим и прочих нюансах. В UEFI загрузчике все проще — структуры данных уже подготовлены, есть возможность использовать функции UEFI для более простого взаимодействия с оборудованием.  16-байтовый идентификатор (GUID) типа раздела. В классическом MBR тип раздела определялся комбинацией всего из 8 битов, что вводило ограничение на использование множества ОС и файловых систем. Напомним, что тип будущей файловой системы связывался с типом раздела (его сигнатурой).  Использование контрольной суммы в формате CRC32 заголовка и таблицы разделов GPT, что упрощает обнаружение ошибок по причине сбоев носителя информации.  Используются поля номера версии (ревизии) и размеров заголовка и записи раздела, что позволяет безболезненно модифицировать структуру GPT в будущих версиях. Первый физический сектор диска (LBA 0) может по-прежнему содержать хорошо известный сектор MBR. В спецификации GPT он именуется как «Protective MBR», т. е. он используется для защиты структуры диска. Protective MBR — это типовой сектор MBR выбранной ОС. Соответственно, под Windows 7 он полностью повторяет стандартный MBR Windows 7, который используется при традиционной разметке, за исключением следующих отличий: 64  Поле «NT Disk Signature» равно 00000000;  Вне зависимости от реальной разметки диска, в таблице разделов MBR указано наличие всего одного раздела, охватывающего весь диск. В официальной документации он называется GPT Protective partiton. Очевидно, что таблица разделов, размещенная в защитном MBR, имеет всего одну запись, описывающую раздел, имеющий размер, равный размеру физического носителя. Поле начала раздела равно LBA 1 и поле конца раздела равно LBA (N), где N — последний блок (сектор) диска. Если же объем диска более предельного значения, то поле конца выставляется в значение 0FFFFFFFFh;  Тип (Partition Type) этого раздела имеет значение 0EEh, которое указывает на использование GPT, наличие единственного псевдо-раздела, покрывающего весь диск; Зашита обеспечивается совместимостью с устаревшим ПО (например, старые версии утилиты fdisk), которое просто-напросто не в курсе, что же такое GPT, а умеет работать исключительно с MBR. Очевидно, что подобная логика работы, при отсутствии знакомых старым программам структур способна повредить GPT-диск, а наличие защитного MBR способно значительно упростить ситуацию. Старые 32-битные ОС могут распознавать раздел и присваивать ему статус недоступного GPT диска. Более старые ОС обычно представляют диск, как содержащий единственный раздел неизвестного типа и без свободного места; как правило, они отказываются модифицировать такой диск, пока пользователь явно не потребует и не подтвердит удаление неопознанного раздела. Таким образом вероятность случайного затирания содержимого GPT диска резко уменьшается. Вышеизложенные сведения желательно знать при установке новой ОС на компьютер или при необходимости осуществить переразбиение накопителя. 65 При установке операционной системы её инсталлятор либо автоматически разбивает накопитель на логические диски, либо предоставляет пользователю выполнить эту операцию самостоятельно. Если ОС уже установлена, то в ней как правило имеются специальные утилиты, с помощью которых можно посмотреть на разбиение дискового пространства и, при необходимости, перераспределить его. Само собой, что это небезопасная операция, поскольку могут быть потеряны данные, которые находятся на существующих разделах. Поскольку в рамках дисциплины «Открытые системы» студенты должны изучить основы GNU/Linux и, в том числе, начать её изучение с установки операционной системы как минимум на виртуальный компьютер, то полезным будет знать сигнатуры разделов, на которые будет осуществляться установка. Если виртуальный диск виртуального компьютера относительно небольшого размера (несколько десятков ГБ), то можно воспользоваться спецификацией MBR. В этом случае для Linux обязательно нужен раздел типа 83h. Желательно ещё создать раздел типа 82h для организации на нём виртуальной памяти (так называемый Linux swap; на нём сохраняются те страницы виртуального пространства выполняющихся приложений, которые не удаётся сохранить в физической памяти). А если ставить систему GNU/Linux на реальном компьютере, то лучше создать не 2, а минимум три раздела — для собственно системы, для виртуальной памяти и для каталога /home (в котором будут размещаться файлы пользователей). Но в этом случае скорее всего на современном компьютере будет вместо BIOS располагаться UEFI, а значит и диск будет разбиваться по спецификации GPT. Тогда будет необходимо иметь раздел ef00h с файловой системой EFI File system для размещения в нём загрузчика, пару разделов типа 8300h — для системы и каталога /home, и раздел типа 8200h для Linux swap. Лекция 6. Особенности операционных систем UNIX, POSIX-системы Создателями системы UNIX считаются Кен Томпсон и Деннис Ритчи. В своей операционной системе они учли опыт работы над проектом создания 66 сложной мультизадачной операционной системы с разделением времени, в котором Томпсон и Ритчи, будучи молодыми специалистами, принимали участие. Эта ОС имела название MULTICS (MULTiplexed Information and Computing System). Название новой системы UNIX произошло от аббревиатуры UNICS (Uniplexed Information and Computing System), которое подчеркивало, что система не была изначально предназначена для работы в ней многих пользователей. Но в новой системе они смогли реализовать те основные понятия и механизмы, которые закладывались в так и не реализованный проект MULTICS. А со временем они добавили в систему и все необходимые механизмы для обеспечения эффективной и безопасной многопользовательской работы. UNIX относится к примеру исключительно удачной реализации простой мультипрограммной и многопользовательской операционной системы. Своей простотой, уникальностью, эффективностью, открытостью система UNIX обязана во многом тому обстоятельству, что она была, по сути, создана очень небольшим числом разработчиков. Причем люди, создававшие ее, делали эту систему для себя и первое время ее использовали на мини-ЭВМ с очень скромными вычислительными ресурсами. Первая версия этой системы занимала всего около 12 Кбайт и могла работать на компьютерах с очень небольшим объемом оперативной памяти. Поскольку при создании второй версии этой операционной системы отказались от языка ассемблера и специально разработали язык высокого уровня, на котором можно было бы писать не только системные, но и прикладные программы (речь идет о языке Си), то и сама система UNIX, и приложения, выполняющиеся в ней, стали легко переносимыми (мобильными). Компилятор с языка Си для всех оттранслированных программ дает реентерабельный и разделяемый код, что позволяет эффективно использовать имеющиеся в системе ресурсы. Важно, что эту первую версию системы взяли в качестве отправной точки при проектировании следующей системы, которую уже создавали как инструментальную систему для разработки программного обеспечения. Первой целью при разработке этой системы было стремление со67 хранить простоту и обойтись минимальным количеством функций. Все реальные сложности оставлялись пользовательским программам. Второй целью была общность. Одни и те же методы и механизмы должны были использоваться во многих случаях. Поэтому общность в UNIX-системах проявляется во многих аспектах, и в частности:  обращение к файлам, устройствам ввода/вывода и буферам межпроцессных сообщений выполняются с помощью одних и тех же примитивов;  одни и те же механизмы именования, присвоения альтернативных имен и защиты от несанкционированного доступа применяются и к файлам с данными и каталогами (директориями), и к устройствам;  одни и те же механизмы работают в отношении программно и аппаратно инициируемых прерываний. Третья цель заключалась в создании операционной среды, в которой большие задачи можно было бы решать, комбинируя существующие небольшие программы, а не разрабатывая программы заново. Наконец, четвертая цель состояла в создании мультитерминальной операционной системы с эффективными механизмами разделения не только процессорного времени, но и всех остальных ресурсов; т.е. разработчики решили реализовать наконец те идеи, которые были задуманы, но так и не реализованы в системе MULTICS. В мультитерминальной операционной системе на одно из первых мест по значимости выходят вопросы защиты вычислительных процессов от невмешательства друг к другу. Причем для реализации третьей цели необходимо было создать механизмы полноценного обмена данными между программными модулями, из которых предполагалось составлять конечные программы. 68 ОС UNIX была составлена из основных компонентов, включающих ядро, инструментальные утилиты и интерпретатор команд (так называемая оболочка ядра). Ядро, образующее стержень UNIX`а, состоит из относительно маленького набора предоставляющих системные ресурсы программ, непосредственно взаимодействующих с аппаратурой. Утилиты выполняют основные действия по обработке данных, обращаясь в определенной последовательности к процедурам ядра. Отдельные утилиты, решающие простые задачи, могут объединяться с другими утилитами для выполнения более сложных действий. Оболочка (Shell) предоставляет пользовательский интерфейс и действует в точности так же, как любая другая программа. Поскольку она не интегрирована в ядро, ее можно разработать заново (что и было неоднократно проделано) при изменении требований, или заменить на другую. Операционная система UNIX обладает простым, но очень мощным командным языком и независимой от устройств файловой системой. Важным, хоть и простым с позиций реализации такой возможности, является тот факт, что система UNIX предоставляет пользователям возможность направить выход одной программы непосредственно на вход другой. В результате большие программные системы можно создавать путем композиции имеющихся небольших программ, а не путем написания новых, что в большинстве случаев упрощает задачу. UNIX-cистемы насчитывают уже 45 лет своего существования, и к настоящему времени имеется чрезвычайно большой набор легко переносимых из системы в систему отлично отлаженных и проверенных временем приложений. Как правило, UNIX-системы поставляются с большим набором системных и прикладных программ, включающим редакторы текстов, программируемые интерпретаторы командного языка, компиляторы с нескольких популярных языков программирования, включая Си, Cи++, ассемблер, PERL, FORTRAN, JAVA и многие другие, компоновщики (редакторы межпрограммных связей), отладчики, многочисленные библиотеки системных и пользовательских программ, 69 средства сортировки и ведения баз данных, многочисленные административные и обслуживающие программы. Для абсолютного большинства всех этих программ имеется документация, включающая в себя, прежде всего, такие важные документы как исходные (как правило, хорошо комментированные) тексты программ. Кроме этого, описание и документация в большей части доступны пользователю непосредственно за экраном в интерактивном режиме. Используется иерархическая файловая система с полной защитой, работа со съемными томами, обеспечивается независимость от устройств. Центральной частью системы UNIX является ядро (kernel). Оно состоит из большого количества модулей и с точки зрения архитектуры считается монолитным. Однако в ядре всегда можно выделить три основные подсистемы: управления процессами, управления файлами, управления операциями ввода/вывода между центральной частью и периферийными устройствами. Подсистема управления процессами организует выполнение и диспетчеризацию процессов, их синхронизацию и разнообразное межпроцессное взаимодействие. Важнейшая функция подсистемы управления процессами - это распределение оперативной памяти и (для современных систем) организация виртуальной памяти. Подсистема управления файлами тесно связана и с подсистемой управления процессами, и с драйверами. Ядро может быть перекомпилировано с учетом конкретного состава устройств, входящих в состав компьютера, и задач, решаемых на нем. Не все драйверы могут быть включены в состав ядра, часть из них может вызываться из ядра. Более того, очень большое количество функций, выполняемых системой, выполняется системными программными модулями, не входящими непосредственно в состав ядра, но вызываемых из ядра. Основные системные функции, которые должно выполнять ядро совместно с остальными системными модулями, строго стандартизированы. За счет этого во многом достигается переносимость кода между разными версиями UNIX и абсолютно различным аппаратным обеспечением. 70 Еще один привлекательный аспект ОС UNIX состоял в том, что компания AT&T (которая владела на эту систему авторскими правами) стала передавать исходные тексты системы в университеты. Получив исходные коды системы, системные программисты часто вносили в неё необходимые им изменения. Главным мотивом для таких шагов была адаптация системы под те аппаратные особенности, которые были наиболее характерны для нового или иного компьютера. Ведь UNIX относительно легко мог быть перенесён на новое аппаратное обеспечение. Один из результатов такой свободы и гибкости - множество различных и несовместимых реализаций. Соответственно, разработчики и пользователи пришли к очевидной и разумной идее — стандартизации операционного окружения приложений. Деятельность ряда групп, таких как UniForum, POSIX и X/Open, была направлена на поиск общего функционального ядра, которое позволило бы достичь переносимости между различными системами. Как результат, в итоге этих работ появилось несколько стандартов POSIX. POSIX – это аббревиатура: Portable Operating System Interface for Computer Environments based on UNIX , т. е. платформенно-независимый системный интерфейс для компьютерного окружения, основанный на UNIX. Стандарт был принят международной ассоциацией Институт инженеров по электротехнике и электронике (IEEE); он описывает системные интерфейсы открытых ОС, в том числе оболочки, утилиты, инструментарии. Так же, стандартизированными являются задачи обеспечения безопасности, задачи реального времени, процессы администрирования, сетевые функции и обработка транзакций. Стандарт базируется на UNIX-системах, но допускает реализацию и в других ОС. POSIX начинался как попытка международной организации IEEE пропагандировать переносимость приложений в UNIX средах путем разработки абстрактного, платформенно-независимого стандарта. Однако, POSIX не ограничивается только UNIX системами. Существуют различные реализации этого стандарта в системах, которые соответствуют требованиям, предъявляемым стандартом IEEE Standard 1003.1-1990 (POSIX.1). Стандарты POSIX существу71 ют в виде серии регулярно обновляемых документов (общим числом под два десятка), в которых описываются спецификации отдельных компонентов систем. Стандарт подробно описывает систему виртуальной памяти (Virtual Memory System - VMS), многозадачность (MPE), и технологию переноса операционных систем (CTOS). Таким образом, на самом деле, POSIX представляет собой множество стандартов, именуемых POSIX.1 – POSIX.12. В следующей таблице (см. табл. ??) приведены основные направления, описываемые данными стандартами. Следует так же особо отметить, что POSIX.1 предполагает язык C как основной язык описания системных функций API. Таблица Семейство стандартов POSIX Стандарт ISO Стандарт Краткое описание POSIX.0 Нет Введение в стандарт открытых систем. Данный документ не является стандартом в чистом виде, а представляет собой рекомендации и краткий обзор технологий. POSIX.1 Да Системное API (язык С) POSIX.2 Нет Оболочки и утилиты (одобренные IEEE) POSIX.3 Нет Тестирование и верификация POSIX.4 Нет Задачи реального времени и нити (потоки выполнения) POSIX.5 Да Использование языка ADA, применительно к стандарту POSIX.1 POSIX.6 Нет Системная безопасность POSIX.7 Нет Администрирование системы 72 POSIX.8 Нет Сети «Прозрачный» доступ к файлам Абстрактные сетевые интерфейсы, не зависящие от физических протоколов. RPC (Remote Procedure Calls) Связь системы с протокол- зависимыми приложениями POSIX.9 Да Использование языка Fortran, применительно к стандарту POSIX.1 POSIX.10 Нет Super-computing Application Environment Profile (AEP) POSIX.11 Нет Обработка транзакций AEP POSIX.12 Нет Графический интерфейс пользователя (GUI) Таким образом, программы, написанные с соблюдением данных стандартов, должны одинаково выполняться на всех POSIX совместимых системах. Однако, стандарт частично носит рекомендательный характер. Часть стандартов описана очень строго, тогда как другая часть только поверхностно раскрывает основные требования. Важно понимать, что стандарты POSIX жестко определяют базовую функциональность систем и приложений, которые не должны изменяться. В то же время расширению функциональности они отнюдь не препятствуют. Так, любая из предусмотренных для POSIX-систем команда должна иметь определенный набор опций, предназначенных для выполнения базового набора действий. Однако никто не препятствует введению для данной команды дополнительных возможностей, реализуемых через опции, стандартом не предусмотренные. Важно только, чтобы первозданная функциональность команды оставалась неприкосновенной. 73 Многие полагают, что именно операционная система определяет, является ли система открытой, и что предоставляемые ОС сервисы играют существенную роль в том, как компьютерная система функционирует и как она вписывается в объемлющее окружение. Такая трактовка открытости основана на теории, что архитектуры, работающие под управлением одной и той же ОС, будут автоматически исполнять одни и те же приложения, решая проблему переносимости; что они будут взаимодействовать друг с другом, решая проблему возможности совместной работы; что пользовательский интерфейс (монитор, клавиатура, мышь) будет оставаться единым, решая проблему "переносимости" пользователей. Однако для достижения целей открытых систем требуется стандартизация в значительно более широком диапазоне областей и на уровне более высоком, чем уровень реализации. Как один из результатов создания серии стандартов POSIX является тот факт, что все UNIX-подобные системы стали называть POSIX-системами. Тем более, что собственно товарный знак на UNIX в настоящее время принадлежит компании SCO Group. Большинство POSIX-систем разработаны по модульному принципу и они относительно гибкие благодаря заложенным изначально возможностям расширения. В дальнейшем мы будем в основном излагать те идеи и принципы, которые характерны для POSIX-систем, хотя на практике мы чаще всего имеем дело с операционными системами, которые принято называть GNU/Linux. Лекция 7. Основные понятия и сущности POSIX-систем Одним из достоинств ОС UNIX и всех POSIX-систем, включая тот же GNU/Linux, является то, что все они базируются на небольшом числе основных понятий. Рассмотрим их вкратце за неимением достаточного места в настоящем пособии. Главное — это уяснить сущности этих понятий. Сложность их изложения продиктована тем, что они достаточно сильно переплетены, взаимосвязаны между собой. Вместо линейного, последовательного изложения, которое 74 является естественным для книги, гораздо лучше описывать их «по спирали». Поэтому настоятельно рекомендуется после чтения настоящего учебного пособия вернуться к этим понятиям через практические занятия на компьютере. Для тех, кто желает более детально изучить POSIX-системы, можно рекомендовать такие великолепные книги, как [ 1, 3 - 6 ]. 7.1. Понятие образа и виртуализация компьютера POSIX-cистемы – многопользовательские, мультитерминальные. Каждый пользователь работает за своим терминалом. Поэтому после входа в систему (регистрации) каждому пользователю предоставляется своеобразный виртуальный персональный компьютер, в котором есть все необходимые ресурсы: процессор (процессорное время выделяется на основе круговой диспетчеризации и с использованием динамических приоритетов с тем, чтобы обеспечить равенство в обслуживании), оперативная память, устройства, файлы. Текущее состояние такого виртуального компьютера, предоставляемого пользователю, называется образом. Можно сказать, что вычислительный процесс – это выполнение образа. Образ состоит из образа памяти, значений регистров процессора, состояния открытых файлов, текущего каталога файлов, и другой информации. Образ процесса во время его выполнения размещается в основной памяти и в рабочих регистрах. В старых версиях системы UNIX образ мог быть выгружен (откачан) на диск, если какому-либо более приоритетному процессу потребуется место в основной памяти. Напомним, что такое замещение процессов называется свопингом (swapping). В современных реализациях, под- держивающих, как правило, страничный механизм виртуальной памяти, прежде всего выгружаются неиспользуемые страницы. В частности, в системах GNU/Linux свопинг образов не применяется, но создается специальный раздел на диске для размещения там тех виртуальных страниц выполняющихся процессов, для которых не хватает места в оперативной памяти. Таким образом, замещаются не процессы, а отдельные их страницы. 75 Образ памяти делится на три логических сегмента:  сегмент реентерабельных процедур (начинается с нулевого адреса в виртуальном адресном пространстве процесса);  сегмент данных (располагается следом за сегментом процедур и может расти в сторону больших адресов);  сегмент стека (начинается со старшего адреса и растет в сторону младших адресов по мере занесения в него информации при вызовах подпрограмм и при прерываниях). 7.2. Понятие пользователя и суперпользователя Мы уже отмечали, что с самого начала ОС UNIX замышлялась как интерактивная многопользовательская система. Чтобы начать работать, пользователь должен "войти" в систему, введя со свободного терминала свое учетное имя (account name или login — логин) и пароль (password). Человек, зарегистрированный в учетных файлах системы, и, следовательно, имеющий учетное имя, называется зарегистрированным пользователем системы. Создание учётных записей для новых пользователей выполняет администратор системы — так называемый суперпользователь. Пользователь не может изменить свой логин, но может установить и/или изменить свой пароль. Пароли хранятся в отдельном файле в закодированном виде. Ядро POSIX-системы идентифицирует каждого пользователя по его идентификатору (UID - User Identifier), уникальному целому значению, присваиваемому пользователю при регистрации в системе. Идентификатор пользователя — это одно из главных полей в учётной записи. Кроме того, каждый пользователь относится к некоторой группе пользователей, которая также идентифицируется некоторым целым значением (GID - Group IDentifier). Значения UID и GID для каждого зарегистрированного пользователя сохраняются в учетных 76 файлах системы и приписываются всякому процессу. Прежде всего они приписываются процессу, порождаемому при регистрации пользователя, а затем эти значения наследуются каждым новым процессом, запущенным от имени данного пользователя, и используются ядром системы для контроля правомочности доступа к файлам, выполнения программ и т.д. Очевидно, что администратор системы, который тоже является зарегистрированным пользователем, должен обладать существенно большими привилегиями, чем обычные пользователи, т.к. он должен обладать возможностями по управлению всей системой. В POSIX-системах эта задача решается путем выделения нулевого значения UID. Пользователь с таким UID называется суперпользователем (superuser) или root. Он имеет неограниченные права на доступ к любому файлу и на выполнение любой программы. Кроме того, такой пользователь имеет возможность полного контроля над системой. Он может остановить ее и даже разрушить. По этой причине не рекомендуется работать под этой учетной записью. Более того, в современных версиях таких систем невозможно зарегистрироваться под учётной записью root. Администратор должен создать себе обычную учетную запись простого пользователя, а для выполнения действий, связанных с административными полномочиями рекомендуется использовать команду su или даже sudo. Команда su (Switch User или Set Uid) позволяет сменить UID, поработать от имени другого пользователя. По умолчанию (если команду вызвать без параметров) она запрашивает у пользователя пароль суперпользователя, и если он указан правильно, операционная система переводит сеанс пользователя в режим работы суперпользователя. После выполнения необходимых действий, требующих привилегий суперпользователя, следует выполнить команду exit, которая и вернет администратору статус простого пользователя. Для ещё большей безопасности ввели команду sudo, которая позволяет выполнить команду, следующую за словом sudo в качестве параметра. После выполнения этой команды пользователю и его текущему актуальному процессу возвращается его UID. В настоящее время рекомендуется использо77 вать только такой способ выполнять команды, связанные с управлением системы. Еще одним важным отличием суперпользователя от обычного пользователя POSIX-систем является то, что на суперпользователя не распространяются ограничения на используемые ресурсы. Для обычных пользователей устанавливаются такие ограничения как максимальный размер файла, максимальное число сегментов разделяемой памяти, максимально допустимое пространство на диске и т.д. Суперпользователь может изменять эти ограничения для других пользователей, но на него они не действуют. 7.3. Понятие процесса Процесс в POSIX-системах - это вычисления по программе, выполняемые в собственном виртуальном адресном пространстве, т.е. понятие процесса в POSIX-системах почти ничем не отличается от такового в других ОС. Главное отличие — это механизм порождения нового процесса и получения необходимых ресурсов. Если в большинстве ОС процессы запрашивают ресурсы у операционной системы, то в POSIX-системах процессы наследуют ресурсы у своих процессов-родителей, т. е. тех процессов, которые их породили (создали и запустили). Когда пользователь входит в систему, автоматически создается процесс, в котором выполняется программа командного интерпретатора. Командный интерпретатор — это программа, которая реализует интерфейс командной строки. Для всех POSIX-систем это главный интерфейс с системой. Обычно интерпретатор команд называют shell (оболочка системы), но в GNU/Linux в роли интерпретатора команд чаще всего выступает программа bash. Если командному интерпретатору встречается команда, запускающая некий выполняемый файл, то он создает новый процесс и запускает в нем соответствующую программу, кото78 рая начинается с функции main. Эта запущенная программа, в свою очередь, может создать процесс и запустить в нем другую программу (она тоже должна содержать функцию main) и т.д. Для образования нового процесса и запуска в нем программы используются два системных вызова POSIX API — это fork() и exec(имя_выполняемого_файла). Системный вызов fork приводит к созданию нового образа, состояние которого абсолютно идентично состоянию адресного пространства основного процесса (то есть в нем содержатся те же программы и данные). Для дочернего процесса заводятся копии всех сегментов данных. Другими словами, сразу после выполнения системного вызова fork основной (родительский) и порожденный процессы являются абсолютными близнецами; управление и в том, и в другом находится в точке, непосредственно следующей за вызовом fork. Чтобы программа могла разобраться, в каком процессе она теперь работает - в основном или порожденном, функция fork возвращает разные значения: 0 в порожденном процессе и целое положительное число (идентификатор порожденного процесса – так называемый PID — Process Identifier) в основном процессе. Любой процесс, независимо от того — системный ли он, пользовательский, интерактивный или неинтерактивный, имеет несколько атрибутов, основными являются следующие:  идентификатор процесса (PID — Process IDentifier);  идентификатор родительского процесса (PPID — Parent PID);  имя пользователя - владельца процесса;  идентификатор владельца процесса (UID); 79  идентификатор группы владельца (GUID);  приоритет;  номер терминала, к которому привязан процесс. Идентификатор процесса - это целочисленный идентификатор, который соответствует номеру его в порядке запуска, от единицы до максимального значения, возможного в данной системе (количество одновременно запущенных процессов - величина конечная). Первый номер обычно получает процесс init первопредок всех остальных процессов в системе. Идентификатор родительского процесса - это номер процесса, от которого произошел данный процесс (посредством системного вызова fork). Если мы запустим новую программу в порожденном процессе, то это происходит за счёт обращения к системному вызову exec, указав в качестве аргументов вызова имя файла, содержащего новую выполняемую программу, и, возможно, одну или несколько текстовых строк, которые будут переданы в качестве аргументов функции main новой программы. Выполнение системного вызова exec приводит к тому, что в адресное пространство порожденного процесса загружается новая выполняемая программа и запускается с адреса, соответствующего входу в функцию main. Другими словами, это приводит к замене текущего программного сегмента и текущего сегмента данных, которые были унаследованы при выполнении вызова fork, на новые соответствующие сегменты, заданные в файле. Прежние сегменты теряются. Другими словами, сначала с образа снимается копия, а затем содержимое в копии образа меняется на новое. Это эффективный метод смены выполняемой процессом программы, но не самого процесса. Файлы, уже открытые до выполнения примитива exec, остаются открытыми после его выполнения. 80 В следующем примере пользовательская программа, вызываемая как команда интерпретатора shell, выполняет в отдельном процессе стандартную команду ls, которая выдает на экран содержимое текущего каталога файлов. main() {if(fork()==0) wait(0); /* родительский процесс */ else exec("ls", "ls", 0); /* порожденный процесс */ } Таким образом, процесс в POSIX-системах является объектом, создаваемым в результате выполнения функции fork(). Каждый процесс, за исключением начального (нулевого) порождается в результате запуска другим процессом операции fork(). Каждый процесс имеет одного родителя, но может породить много процессов. Начальный (нулевой) процесс является особенным процессом, который создается в результате загрузки системы. После порождения нового процесса с идентификатором 1 нулевой процесс становится процессом подкачки и реализует механизм виртуальной памяти. Процесс с идентификатором 1, известный под именем init, является предком любого другого процесса в системе и связан с каждым процессом особым образом. 7.4. Понятие файла Понятие файла в POSIX-системах является одним из самых главных. Почти все объекты в этих системах связаны с файлами самым тесным образом, либо хранятся в файлах, либо даже являются файлами. В отличие от общепринятого и привычного понятия файла как именованного набора данных (именно так определяется файл в учебниках по информатике и в операционных системах компании Microsoft), в POSIX-системах файл — это набор данных, который имеет некий числовой идентификатор. Принципиальное различие здесь в том, что идентификатор это не имя. Идентификатор нужен системе управления фай81 лами, а пользователи используют имена, которые привязываются к идентификаторам, а значит и к файлам. Другими словами, раз первичным является некий числовой идентификатор, то с ним можно связать не одно единственное имя, а файл может иметь много различных имён. В качестве идентификатора файла используется номер специальной информационной структуры — i-node (читается как айнод). По существу i-node — это дескриптор, в котором указаны размер файла, перечень кластеров (отведённых для хранения файла, с их помощью можно вычислить блоки данных на устройстве памяти, в которых расположены данные этого файла), идентификатор владельца файла, права на доступ к файлу у владельца, у членов группы владельца файла и у всех остальных пользователей, а также счётчик ссылок на файл и параметры времени (дата и время создания файла и его последней модификации). При форматировании тома создаются эти самые дескрипторы, а при создании файлов в свободные дескрипторы (i-node) заносятся соответствующие сведения. Одним из полей дескриптора является счётчик ссылок на i-node. Если у файла одно единственное имя, то значение этого счётчика будет равно единице, а если у файла несколько имён, то значение счётчика покажет количество имён файла. Имена файлов содержатся в специальных файлах-каталогах. Каждый каталог - это отдельный файл особого типа (он обозначается символом "d", от англ. "directory"), отличающийся от обычного файла с данными. Другими словами, помимо обычных файлов с данными (их называют регулярными файлами) есть файлы-каталоги. Запись в таком файле привязывает имя файла к его дескриптору — айноду. Есть главный каталог, его называют корневым; он обозначается символом косой черты - /. За счёт того, что в файле-каталоге могут быть указаны другие файлы-каталоги, файловая система получается иерархической. Итак, каталог - это, по существу, список ссылок на айноды, а значит — на файлы или другие файлы-каталоги. Принято говорить, что каталог содержит в себе файлы или другие каталоги, хотя в действительности он только ссылается 82 на них, физическое размещение данных на диске обычно никак не связано с размещением каталога. Тем более, что один и тот же файл может иметь множество имён, которые могут располагаться в разных каталогах. Каталог, на который есть ссылка в данном каталоге, называется подкаталогом или вложенным каталогом. Каталог в файловой системе более всего напоминает библиотечный каталог, содержащий ссылки на объединённые по каким-то признакам книги и другие разделы каталога (файлы и подкаталоги). А поскольку ссылки на один и тот же файл могут содержаться в нескольких каталогах одновременно, это может сделать доступ к файлу более удобным. При удалении файла на самом деле удаляется его имя, но если это было единственное имя или оно оказалось последним, то удалятся и собственно данные этого файла. Когда файл получает второе имя, то это называется жесткой ссылкой. Для создания такой ссылки имеется специальная команда, которая позволяет привязать к новому имени уже существующий файл. Помимо жестких ссылок имеются так называемые символьные или мягкие ссылки, в которых к имени файла привязывают не айнод уже существующего файла, а имя существующего файла. Другими словами, символьные ссылки представляют собой своеобразную косвенную адресацию, поскольку по имени файла мы можем найти его другое имя (в таких файлах хранятся в качестве значений содержатся пути к файлам или каталогам). Часто символьные ссылки называют симлинками. Может быть это и нехорошо говорить так с точки зрения правил русского языка, но зато сразу понятно о чём идёт речь. Жесткая ссылка на файл может существовать только в той же файловой системе, в которой размещен его i-node. Кроме требования нахождения в одной и той же файловой системе, на жесткие ссылки накладывается еще одно ограничение: они могут быть созданы только на обычные или специальные файлы (например, файлы устройств), но не на каталоги. В отличие от жесткой ссылки, представляющей собой просто еще одно имя для одного и того же набора данных и соответствующий им дескриптор, символьная ссылка - это именно само83 стоятельный файл, со своим идентификатором и прочими атрибутами, записанными в его дескрипторе, и со своими данными. Другое дело, что в качестве данных выступает просто указание пути к собственно файлу или каталогу, на который эта ссылка указывает. Причем файл этот может лежать не только на иной файловой системе (на другом томе), но даже находиться на иной машине в локальной или даже глобальной сети. Не возбраняются и символические ссылки на каталоги - в этом случае содержимое каталога-ссылки будет точно воспроизводить внутреннюю иерархию исходного каталога. Помимо упомянутых регулярных файлов, файлов-каталогов и ссылок на файлы в POSIX-системах имеются специальные файлы устройств, именованные каналы и сокеты. Это позволяет организовать единообразный способ доступа к данным, поскольку практически всё сводится к понятию файла. Файлы можно создавать, открывать, читать, изменять, закрывать и удалять. И программист не должен задумываться над тем, где расположен файл — на локальном диске, в сети, в оперативной памяти. Является ли этот файл устройством или это данные, которые другой процесс передаёт текущему процессу (или наоборот — принимает отправляемые ему данные). Файлы устройств соответствуют различным присутствующим в системе устройствам, которые могут быть реальными (жесткие диски, флешки, принтеры, клавиатура и т. д.), а могут — так называемым псевдоустройствами. В качестве примера псевдоустройства можно назвать файл /dev/null, в котором ничего не содержится, или файл /dev/zero, содержимое которого - это сплошные нули. 7.5. Интерфейс пользователя Традиционный способ взаимодействия пользователя с системами типа UNIX основывается на использовании командных языков. После входа пользо84 вателя в систему для него запускается один из командных интерпретаторов (в зависимости от параметров, сохраняемых в файле /etc/passwd). В наше время обычно в системе поддерживается несколько командных интерпретаторов с похожими, но различающимися своими возможностями командными языками. Общее название для любого командного интерпретатора ОС UNIX— shell (оболочка), поскольку любой интерпретатор представляет внешнее окружение ядра системы. По умолчанию в системах GNU/Linux командным интерпретатором является bash. В принципе, он может быть заменен на другой интерпретатор команд, но практически мало кто это делает. Вызванный командный интерпретатор выдает приглашение на ввод пользователем командной строки, которая может содержать простую команду, конвейер команд или последовательность команд. После выполнения очередной командной строки и выдачи на экран терминала или в файл соответствующих результатов, shell снова выдает приглашение на ввод командной строки, и так до тех пор, пока пользователь не завершит свой сеанс работы и не выйдет из системы Командные языки, используемые в POSIX-системах, достаточно просты, чтобы новые пользователи могли быстро начать работать, и достаточно мощны, чтобы можно было использовать их для написания сложных программ. Последняя возможность опирается на механизм командных файлов (shell scripts), которые могут содержать произвольные последовательности командных строк. При указании имени командного файла вместо очередной команды интерпретатор читает файл строка за строкой и последовательно интерпретирует команды. Правда, поскольку в настоящее время все большее распространение получают графические интерфейсы, то и в POSIX-системах, особенно если их используют как десктопные, стали все чаще работать в графическом режиме. Общеизвестный X-Window – это графический интерфейс, позволяющий пользователям взаимодействовать со своими вычислениями и с системой в графиче85 ском режиме. В отличие от систем Windows компании Microsoft, графический интерфейс для систем GNU/Linux не является основным, в системе можно работать и без него. Прежде всего графический режим разрабатывался для возможности иметь приложения, требующие работы с графикой. В последние годы его стали использовать гораздо чаще, особенно в системах Linux, которые начинают использовать и как десктопные системы, а не только как серверные. Графический интерфейс в POSIX-системах основан на модели «клиентсервер». Серверная часть X Window — это аппаратно-зависимая система ввода/вывода, которая непосредственно взаимодействует с приложением и видеоподсистемой, клавиатурой и мышью. При этом серверная часть должна работать на компьютере, производящем вычисления. Взаимодействие с пользователем осуществляется через клиентскую часть, которая обеспечивает вывод данных на дисплей и прием их с устройств ввода. Клиентская часть должна быть на том компьютере, за которым работает пользователь. Таким образом, можно работать в графическом режиме, сидя за одним компьютером, в то время как собственно вычисления могут происходить и на другом компьютере. Один из Х-клиентов°— это оконный менеджер (также называемый диспетчером окон). Он управляет размещением окон на экране, определяет их вид и характер управляющих элементов. То есть именно он и представляет собой GUI (Grafical User Interface) в собственном смысле слова, тогда как XWindow – это его основа. В системах GNU/Linux наиболее популярными менеджерами графического интерфейса являются KDE и GNOME. Последние дистрибутивы Ubuntu Linux от компании Canonical используют Unity. Есть и другие менеджеры. Например, популярная нынче система Linux Mint использует менеджер Cinnamon. 86 Лекция 8. Интерфейс командной строки и файловая система Если Вы работаете в системе GNU/Linux и после регистрации в системе получили графический интерфейс, который сейчас в большинстве десктопных систем установлен по умолчанию, то для перехода в режим консоли (в котором мы получаем доступ к интерфейсу командной строки) достаточно нажать комбинацию клавиш {Сtrl+Alt+F#}, где # означает номер терминала. Linux по умолчанию поддерживает 6 терминалов (консолей) с текстовым интерфейсом и один терминал с графическим режимом. То есть если мы нажали {Сtrl+Alt+F2}, то перейдем в терминал tty2, а если нажмем {Сtrl+Alt+F7}, то вернёмся в графический режим и увидим десктоп (desktop - рабочий стол) системы. Кроме основных 6 текстовых консолей (tty1, tty2, tty3, tty4, tty5, tty6) и одного графического терминала, Linux поддерживает виртуальные консоли, позволяя запускать интерпретатор команд непосредственно в графическом режиме и наблюдать в окне его работу. При этом средствами графического интерфейса можно менять размеры окна такой консоли, шрифт, цвет и некоторые другие параметры. В консольном режиме система (интерпретатор команд) принимает команды и, если они составлены корректно и для их выполнения имеются все условия, включая права на их запуск, то они исполняются. Команды бывают внутренними и внешними. Внутренними являются те команды, которые исполняются самим интерпретатором. А к внешним командам относятся те, для исполнения которых в системе должны быть соответствующие исполняемые файлы. Обобщенный синтаксис простой команды выглядит следующим образом: <имя команды> [<опции>] [<аргументы>] В этой записи квадратные скобки означают необязательность присутствия соответствующей части команды, т. е. в квадратных скобках обычно указывают87 ся аргументы команды, которые можно опустить. В командной строке (терминале) процесс взаимодействия с пользователем выполняется в терминах записи и чтения в файл. Вывод на экран представляется как запись в файл, а ввод — как чтение файла. Файл, из которого осуществляется чтение, называется потоком ввода, а в который осуществляется запись — потоком вывода. Все консольные команды читают информацию со стандартного потока ввода и выводят ее в стандартный поток вывода. По умолчанию стандартным потоком вывода является текущая консоль, а стандартным потоком ввода - клавиатура. Стандартный поток может быть перенаправлен в любой другой файл, в том числе и в файл любого устройства из каталога устройств /dev. Символом перенаправления выходного потока служит значок > , а входного - < . Например, команда ls > files создает новый или заменяет старый файл с именем files в текущем каталоге и записывает в него результат выполнения команды ls ; этим результатом будет список файлов, расположенных в текущем каталоге. Для того, чтобы выходной поток добавлялся к старому содержимому файла, используется символ перенаправления >> . Так, если после предыдущей команды выполнить команду cat /var/log/dmesg >> files , то в файл files к перечню файлов будет добавлен протокол загрузки ядра, который был занесён в файл dmesg , находящийся в каталоге /var/log . Команды могут объединяться в цепочки с помощью символа | . При объединении выходной поток предыдущей команды поступает во входной поток следующей. Например, цепочка команд cat /var/log/dmesg | head -10 | less -S 88 интерпретируется следующим образом: получить протокол загрузки ядра, выделить в нем первые 10 строк и послать их в программу просмотра в интерактивном режиме. Для получения справочной информации о командах рекомендуется использовать специальную команду man (от слова manual — руководство, справочник). Справку о самой команде man можно получить по команде man man. У вышеупомянутой команды ls в качестве основных опций чаще всего используют опции a (all) и l (long). Первая опция позволяет увидеть все файлы, в том числе и скрытые (если имя файла начинается с точки, то такой файл по умолчанию не показывается). А вторая опция выводит информацию о файлах в так называемом длинном формате: выводится не только имя файла, но и его тип, права доступа на файл, количество жестких ссылок на файл, имя владельца, имя группы, размер файла, дату и время создания. Для того чтобы увидеть номер айнодов файлов имеется опция i. Перед опцией ставится знак минус (дефис). В качестве примера, команда ls при использовании всех трёх опций может выглядеть следующим образом: ls -ali . Параметром для команды ls является имя каталога, т. е. по команде ls -li / мы получим информацию о каталогах (и файлах, если они там есть), расположенных в корне файловой системы. В POSIX-системах (в том числе и в GNU/Linux) имена файлов и каталогов могут быть длиной не более 256 символов, и могут содержать любые символы, кроме "/". Причина этого ограничения очевидна: этот символ используется как разделитель имён в составе пути, поэтому не должен встречаться в самих именах. Причём система всегда различает прописные и строчные буквы в именах файлов и каталогов, поэтому "opensystem", "OpenSystem" и "OPENSYSTEM" будут тремя разными именами. Есть несколько символов, допустимых в именах файлов и каталогов, которые, при этом, нужно использовать с осторожностью. Это - так называемые спецсимволы "*", "\", "&", "<", ">", ";", "(", ")", "|", а также пробелы и табуляции. Дело в том, что эти символы имеют особое значение для 89 любого интерпретатора команд (командной оболочки (как её часто называют), поэтому нужно будет специально позаботиться о том, чтобы командная оболочка воспринимала эти символы как часть имени файла или каталога. Поэтому лучше всего во избежание проблем использовать для именования файлов только маленькие и заглавные буквы, цифры, символ подчеркивания, точку, плюс и минус и не начинать имя с плюса или минуса. Файловая система ОС Linux имеет иерархическую (древовидную) структуру, которая может быть изменена с помощью специальных файловых объектов — ссылок — и перестать быть деревом. В вершинах дерева находятся каталоги , содержащие списки файлов. Эти файлы, в свою очередь, могут быть либо снова каталогами, либо обычными файлами, либо специальными файлами, представляющими различные устройства. Kорневой каталог обозначается как "/" и содержит следующие основные подкаталоги: /boot- для хранения файлов ядра и загрузчика системы; /dev – для файлов устройств, поддерживаемых системой; /usr – для программного обеспечения пользователя; /bin – для утилит (программ обслуживания ОС); /usr/bin – для программ пользователя; /sbin – для программ системного администратора; /usr/sbin – для программ системного администратора; /usr/X11R6 – для графического интерфейса; /usr/X11R6/bin – для программ графического интерфейса; /lib – для системных библиотек и модулей ядра; /tmp – для временных файлов; 90 /var – для изменяемой во время работы системной информации; /var/log – для протоколов работы системы; /var/log/dmesg – файл протокола загрузки ядра; /media -каталог для съемных носителей; /mnt – для монтируемых файловых систем; /home/ - домашние каталоги пользователей; /etc – конфигурационные файлы системы. Можно указать два независимых критерия разбиения множества файлов на независимые типы (а точнее — на два непересекающихся подмножества): разделяемые файлы в противоположность неразделяемым, и неизменяемые (статические) файлы как противоположность изменяемым файлам. Разделяемые файлы — это те, к которым может быть разрешен доступ с различных компьютеров; неразделяемые — те, которые являются специфическими для данного компьютера. Например, домашние каталоги пользователей содержат разделяемые данные, а файлы блокирования устройств (device lock files) являются неразделяемыми. Неизменяемые (или статические) файлы — это исполняемые файлы, файлы библиотек, документация, и все, что не должно изменяться без вмешательства системного администратора; изменяемые данные — это все, что может изменяться без участия системного администратора. Должно существовать простое и понятное соответствие между каталогами и типом данных, которые в этом каталоге размещаются: каталоги могут являться точками монтирования для других файловых систем, характеристики которых отличаются от характеристик той файловой системы, в которую они монти- 91 руются. Эти очевидные принципы легли в основу стандарта FHS (File Hierarchy Standard) [ 10 ]. Различать разделяемые и неразделяемые файлы необходимо по следующим причинам:  При работе компьютера в сети (т.е. в тех случаях, когда несколько компьютеров взаимосвязаны), всегда имеется достаточно значительная доля таких файлов, которые могут использоваться совместно всеми, что позволяет экономить дисковое пространство и облегчает выполнение задач поддержки и обслуживания (task of maintenance).  С другой стороны, при работе в сети некоторые файлы содержат информацию, которая относится только к данному компьютеру. Следовательно, эти данные не могут использоваться другими компьютерами и не могут быть разделяемыми (если не принять специальных мер). Старые реализации файловых систем для UNIX допускали размещение разделяемых и неразделяемых файлов в одних и тех же каталогах, ограничивая тем самым возможность делать разделяемыми по сети большие части файловой системы. Выделение "разделяемых" данных может использоваться, например, для:  монтирования (в режиме "только для чтения") раздела /usr (или части /usr ) по сети (используя сетевую файловую систему NFS).  монтирования раздела /usr (или части раздела /usr ) с носителя, допускающего только чтение. В качестве примера можно назвать CD-ROM и/или DVD-диски. Различие между "статическими" и "изменяемыми" данными оказывает влияние на структуру файловой системы по двум основным направлениям:  Поскольку корневой каталог / содержит как изменяемые, так и статические данные, он должен всегда монтироваться в режиме чтения-записи. 92  Поскольку традиционно каталог /usr содержал как статические, так и изменяемые данные, и поскольку мы хотим монтировать его в режиме "только для чтения" (смотри выше), необходимо найти способ монтировать /usr только для чтения. Этого можно достичь, если создать каталоговую структуру /var, которая монтируется в режиме "чтениезапись" (либо размещается в другом разделе, где разрешены как чтение, так и запись, таком, как / ), а в оставшейся части структуры /usr разрешить только чтение. Приведем еще один пример того, как должны распределяться данные для того, чтобы файловая система могла считаться совместимой со стандартом FHS (еще раз повторим, что это только пример, можно привести и другие примеры того, как размещать данные для обеспечения FHS-совместимости). Статические Изменяемые Разделяемые Неразделяемые /usr /etc /opt /boot /var/mail /var/run /var/spool/news /var/lock Противопоставление разделяемых и неразделяемых каталогов обусловлено изначально сетевой природой Unix. То есть данные, относящиеся к локальной машине (например, файлы конфигурирования ее устройств) должны лежать в каталогах, отдельных от тех, содержимое которых доступны с других машин в сети, локальной или глобальной (примером чему являются не только пользовательские данные, но и программы). 93 Большинству студентов знакомо понятие расширения в имени файла — это часть имени файла после точки, обычно ограничивающаяся несколькими символами и указывающая на тип содержащихся в файле данных. В файловой системе Linux нет никаких предписаний по поводу расширения: в имени файла может быть любое количество точек (в том числе и ни одной), а после последней точки может быть любое количество символов. Хотя расширения не обязательны и не навязываются технологией в Linux, они, тем не менее, используются: расширение позволяет человеку или программе, не открывая файл, только по его имени определить, какого типа данные в нём содержатся. Однако нужно учитывать, что расширение - это только набор соглашений по наименованию файлов разных типов. Строго говоря, данные в файле могут не соответствовать заявленному расширению по той или иной причине, поэтому всецело полагаться на расширение просто нельзя. Определить тип содержимого файла можно и на основании самих данных. Многие форматы предусматривают указание в начале файла, как следует интерпретировать дальнейшую информацию: как программу, исходные данные для текстового редактора, страницу HTML, звуковой файл, изображение или что-то другое. В распоряжении пользователя Linux есть утилита file, которая предназначена именно для определения типа данных, содержащихся в файле. Практически в любой ОС, а значит и в POSIX-системах существует понятие текущего каталога. Это тот каталог, в котором мы сейчас находимся; его имя записывается перед именем файла в текущем каталоге и в результате мы получаем полное имя файла. Для того, чтобы узнать имя текущего каталога существует команда pwd. А чтобы не записывать полное имя файла, перечисляя все каталоги, которые относятся к имени файла, можно использовать символ «тильда» - ~ . Для разграничения доступа к файлам в POSIX-системах используются атрибуты прав доступа. Эти атрибуты прав доступа можно представить в виде 94 двенадцати битов двоичного числа, равных 1, если атрибут установлен, и 0, если нет. Порядок битов в числе следующий: sU|sG|t|rU|wU|xU|rG|wG||xG|rO|wO|xO где sU — это SetUID, sG — это SetGID, t — это t-атрибут (sticky–бит), после чего следуют три тройки атрибутов доступа: rU | wU | xU - права чтения (Read), записи (Write) и выполнения (eXecute) для владельца файла (User); rG | wG | xG - права чтения (Read), записи (Write) и выполнения (eXecute) для членов группы владельца файла (Group); rO | wO | xO - права чтения (Read), записи (Write) и выполнения (eXecute) для всех остальных (Other). Исполняемые файлы с установленным битом sU выполняются как процессы с правами владельца. А с установленным битом sG – с правами группы владельца, а не с правами пользователя, запустившего эти процессы. В каталоге с установленным sticky–битом удалять файлы может только владелец или root. При том устанавливать этот бит может только суперпользователь root, а сбрасывать может владелец и root. Для изменения прав доступа к файлу можно использовать команду chmod. Полную справку об этой команде можно получить по команде man chmod, а сокращённую — по команде chmod —-help. Если опустить буквенные обозначения прав, а оставить только значения битов, то можно достаточно наглядно и компактно описывать права на файлы. Приведём несколько примеров, используя не только двоичную запись, но и восьмеричную систему. 95 110 110 110 все могут читать и изменять этот файл 111 100 000 владелец имеет все права, члены его группы - чтение, остальные не имеют никаких прав установлен t-атрибут, владелец имеет все права, его группа Примеры записи 001 111 100 000 чтение, остальные не имеют прав доступа в двоичникаких прав ной форме установлен атрибут SetGID, владелец имеет все права, 010 111 100 000 группа - чтение, остальные не имеют никаких прав установлен атрибут SetUID, владелец имеет все права, его 100 111 100 000 группа - чтение, остальные не имеют никаких прав Примеры записи прав доступа в восьмеричной форме 666 все могут читать и изменять 740 владелец имеет все права, группа - чтение, остальные не имеют никаких прав 1740 установлен t-атрибут, владелец имеет все права, его группа чтение, остальные не имеют никаких прав 96 2740 установлен атрибут SetGID, владелец имеет все права, группа - чтение, остальные не имеют никаких прав 4740 установлен атрибут SetUID, владелец имеет все права, группа - чтение, остальные не имеют никаких прав Мы уже говорили, что каталог — это особый тип файла. Его содержание — это список других файлов. Файлы-каталоги имеют те же атрибуты прав, что и регулярные файлы. Однако то, что эти права означают для каталогов, может быть не таким простым для понимания. Если каталог можно читать (r), то это означает, что разрешено только узнать список файлов, содержащихся в этом каталоге. Только список файлов, но не их свойства (размер, права доступа и др.). Если каталог можно исполнять (x), то это означает, что в него можно заходить и просматривать содержимое файлов (доступ к которым разрешен для данной категории), узнавать свойства (атрибуты) файлов. Можно изменить содержимое файла (если его разрешено менять), но не имя файла. Если каталог можно изменять (w), то это означает, что в нем можно изменять файлы, их имена, удалять их. По умолчанию при создании нового файла он не имеет атрибута на исполнение и об этом не стоит забывать. Сделать файл исполняемым можно только изменив значение атрибута x . Иногда приходится иметь дело со скриптовыми файлами, которые обрабатываются командным интерпретатором. Интерпрета97 тор_команд - это программа, которая запускается первой после прохождения процедуры регистрации в системе. Обычно это так называемый login shell . Чаще всего в качестве интерпретатора команд выступает bash , поэтому, как правило, скрипт должен начинаться со следующей строки #!/bin/bash Эта строка однозначно указывает на интерпретатор bash, который должен будет исполнять скрипт. Для обозначения переменных в shell-скриптах используются последовательность из букв, цифр и символа подчёркивания, причём переменные не могут начинаться с цифры. Присваивание значений переменным осуществляется с использованием знака = , например, Var1='<'; Var2=10 . Для обращения к значению переменной перед именем ставится знак $ . Переменные можно разделить на следующие группы:  - простые переменные, значения которых может задавать пользователь или они могут устанавливаться интерпретатором;  - позиционные переменные вида $n, где n — целое число;  - специальные переменные # , ? , - , ! , $ устанавливаются интерпретатором позиционных и позволяют переменных, коде получить информацию завершения последней о числе команды, идентификационном номере текущего и фонового процессов, о текущих флагах интерпретатора shell. Простые переменные. Интерпретатор команд присваивает значения переменным: z=250 98 x=$z echo $x 250 В приведённом примере переменной x было присвоено значение, которое получила переменная z. Команда echo вывела на экран значение переменной x Позиционные переменные. Переменные вида $n используются для идентификации позиций элементов в командной строке с помощью номеров, начиная с нуля. Например, в командной строке cat text_1 text_2 … text_9 аргументы идентифицируются параметрами $1 , $2 , … , $9. Для имени собственно команды всегда используется $0. В данном случае $0 — это cat , $1 — text_1 , $2 — text_2 и т. д. Для присваивания значений позиционным пе- ременным используется команда set , например: set arg_1 arg_2 … arg_9 здесь переменной $1 присваивается значение аргумента arg_1 , $2 — arg_2 и т. д. Для получения информации обо всех аргументах (включая последний) используют метасимвол * . Например: echo $* arg_2 arg_3 … arg_10 arg_11 arg_12 С помощью позиционных переменных интерпретатор команд может сохранить имя команды и её аргументы. При выполнении команды интерпретатор (например bash) должен передать ей аргументы, порядок которых может регулироваться также с помощью позиционных переменных. Специальные переменные. Переменные - ? # $ ! устанавливаются только интерпретатором команд. Они позволяют с помощью команды echo получить следующую информацию: 99  - - текущие флаги интерпретатора (установка флагов может быть изменена командой set);  # - число аргументов, которое было сохранено интерпретатором при выполнении какой-либо команды;  ? - код возврата последней выполняемой команды;  $ - числовой идентификатор текущего процесса PID;  ! - PID последнего фонового процесса. Группы команд или сложные команды могут формироваться с помощью специальных символов (метасимволов):  & - процесс выполняется в фоновом режиме, не дожидаясь окончания предыдущих процессов;  ? - шаблон, распространяется только на один символ;  * - шаблон, распространяется на все оставшиеся символы;  | - программный канал - стандартный вывод одного процесса является стандартным вводом другого;  > - переадресация вывода в файл;  < - переадресация ввода из файла;  ; - если в списке команд команды отделяются друг от друга точкой с запятой, то они выполняются друг за другом; 100  && - эта конструкция между командами означает, что последующая команда выполняется только при нормальном завершении предыдущей команды ( код возврата 0 );  | - последующая команда выполняется только, если не выполнилась предыдущая команда ( код возврата 1 );  ( ) - группирование команд в скобки;  { } - группирование команд с объединенным выводом;  [ ] - указание диапазона или явное перечисление ( без запятых);  >> - добавление содержимого файла в конец другого файла. При составлении скриптов часто возникает необходимость использовать операторы присваивания, арифметические и логические операции, операторы циклов и условные операторы. Все они существуют в языке интерпретатора bash. Команда expr вычисляет выражение (expression) и записывает результат в файл стандартного вывода. Элементы выражения разделяются пробелами; символы, имеющие специальный смысл в командном языке, нужно экранировать. Строки, содержащие специальные символы, заключают в апострофы. Используя команду expr, можно выполнять сложение, вычитание, умножение, деление, взятие остатка, сопоставление символов и т. д. Рассмотрим несколько простейших примеров b=386 а=`ехрr 400 - $b` ; где ` - обратная кавычка. d= `expr $а + 125 "*" 10` c= `expr $d % 13` 101 Здесь символ * означает умножение, / - деление , % - вычисление остатка. Обратите внимание, что знак умножения заключается в двойные кавычки, чтобы интерпретатор не воспринимал его как метасимвол. В последней строке переменной с присваивается значение остатка от деления переменной d на число 13. Напомню, что для того, чтобы скрипт file_script.sh мог быть выполнен, он должен иметь соответствующие права. Для вновь созданного скрипта ему необходимо изменить значение атрибута на исполнение. Например, чтобы его смог запустить любой пользователь, можно выполнить например такую команду: chmod +x file_script.sh Лекция 9. Ещё раз о пользователях, файлах и процессах В POSIX-системах, в отличие от систем семейства Windows NT, к которым относятся и все современные (включая Windows 10 и Windows Server 2012), учетные записи пользователей и групп хранятся не в одном единственном файле, а распределены по нескольким. Так, учётные записи пользователей перечисляются и частично описываются в файле /etc/passwd , их пароли (точнее, значения хэш-функции паролей) — в файле /etc/shadow , а группы пользователей описаны в файле /etc/group . Заметим, что каталог /etc описан в уже упомянутом стандарте FHS (Filesystem Hierarchy Standard), он содержит в себе основные конфигурационные файлы системы. Файл /etc/passwd описывает всех пользователей системы. Каждая строка в этом файле описывает одного пользователя. Формат строки описания пользователя следующий: Имя_входа_пользователя : Зашифрованный_пароль : UID : GID : Реальное_имя : Домашний_ каталог : Интерпретатор_команд 102 Поля в файле разделяются двоеточием. Как мы уже знаем, UID – это уникальный числовой идентификатор пользователя, поскольку система распознает пользователей по их идентификаторам. Процессы, запущенные пользователем, наследуют его UID и GID, но в случае запуска программ, которые могут временно изменить его идентификатор на иной, главную роль получают EUID — Effective UID и EGID — Effective GID; Напомним, что GID — Group Identifier или Login Group — это основная группа пользователя. Все файлы, создаваемые пользователем, будут иметь в качестве группы-владельца основную группу для пользователя. При входе пользователя в систему для него будет запущена указанная программа. По завершении работы программы пользователь покидает систему. Вышеупомянутый EGID может отличаться своим значением от GID в случае запуска программ, имеющих соответствующий бит SetGID. В своем домашнем каталоге пользователь хранит свои файлы. Также домашний каталог автоматически становится текущим каталогом при входе пользователя в систему. Для того, чтобы указать свой домашний каталог, можно воспользоваться символом тильда - ~. При использовании скрытых паролей (а это делают все современные POSIX-системы, в том числе и GNU/Linux) пароли пользователей хранятся не в файле /etc/passwd, а в отдельном файле /etc/shadow. Файл /etc/shadow в отличие от /etc/passwd не имеет прав на чтение для всех пользователей, что повышает безопасность системы. При использовании скрытых паролей вместо зашифрованного пароля в файле /etc/passwd указывается символ х. Кстати, для смены пароля имеется команда passwd , которая имеет единичное значение для бита SetUID и владельцем которой является суперпользователь root , благодаря чему пользователь на время исполнения этой команды получает доступ к файлу /etc/shadow . 103 Информация об основной группе пользователя хранится в файле /etc/passwd . Информация о дополнительных группах для пользователей хра- нится в файле /etc/group ; этот файл содержит информацию о всех группах в системе. Формат данного файла следующий: Имя_группы : Групповой_пароль : GID : Список_пользователей Групповой пароль в настоящее время не используется и обычно имеет значение х или *. Как мы уже знаем, GID представляет собой уникальный числовой идентификатор группы. Список пользователей представляет собой перечисленные через запятую имена пользователей (точнее, их логины), для которых эта группа является дополнительной. Для работы с учётными записями — их создания и редактирования — имеются специальные команды. При работе в графическом интерфейсе часто используют соответствующие утилиты. Описывать их не будем, т. к. гораздо продуктивнее это изучить на практике. Однако заметим, что для работы с учётными записями нужно обладать правами суперпользователя. Вернёмся к файловой системе. Тот же GNU/Linux сейчас поддерживает несколько файловых систем и приложения прежде всего работают с виртуальной файловой системой, которая в дальнейшем обеспечивает полноценный доступ к файлам, расположенным на реальных файловых системах (например XFS, ExtFS, Ext2FS, Ext3FS, Ext4FS, ReiserFS и другие). Как система управления файлами она представляет собой структуру данных, размещенную на диске и содержащую управляющий супер-блок, в котором специфицирована файловая система в целом. Далее, это множество айнодов, в котором определены все файлы в этой файловой системе и подмножество свободных айнодов. В области хранения данных расположены блоки с файлами и свободные блоки. Выделение пространства под данные осуществляется блоками фиксированного размера. Обычно множество айнодов имеет фиксированный размер, который задаётся 104 при создании (форматировании) раздела. Но встречаются файловые системы, в которых реализован механизм расширения множества айнодов. Каждый файл однозначно идентифицируется старшим номером устройства, младшим номером устройства и i-номером (индексом i-node данного файла в массиве айнодов). Когда вызывается драйвер устройства, по старшему номеру индексируется массив входных точек в драйверы. По младшему номеру драйвер выбирает одно устройство из группы идентичных физических устройств. С каждым поддерживаемым системой устройством ассоциируется один или большее число специальных файлов. Операции ввода/вывода для специальных файлов осуществляются так же, как и для обычных дисковых файлов, с той лишь разницей, что эти операции активизируют соответствующие устройства. Специальные файлы обычно находятся в каталоге /dev. На специальные файлы могут указывать связи точно так же, как на обычные файлы. От файловой системы не требуется, чтобы она вся целиком размещалась на том устройстве, где находится корень. Запрос от пользователей или от системы на установку носителей и т. п. (команда mount ) позволяет встраивать в иерархию файлов файлы на других, в том числе и на сменных томах. Команда mount имеет несколько опций, но обязательных аргументов у стандартного ва- рианта ее использования два: это имя файла блочного устройства и имя каталога. В результате выполнения этой команды файловая система, расположенная на указанном устройстве, подключается к системе таким образом, что ее содержимое заменяет собой содержимое заданного в команде каталога. Поэтому для монтирования соответствующего тома обычно используют пустой каталог. Команда umount выполняет обратную операцию – «отсоединяет» файловую систему, после чего диск с данными можно физически извлечь из системы. Например, для записи данных на дискету необходимо ее «подмонтировать», а после работы – «размонтировать». Согласно стандарту FHS каталогом для монтирова105 ния несъемных устройств является /mnt , а сменные устройства типа Plag&Play монтируются в каталог /media . К такого рода устройствам прежде всего следует отнести накопители с интерфейсом USB. Монтирование файловых систем позволяет иметь единое логическое файловое пространство, в то время как реально отдельные каталоги с файлами могут находиться и в различных разделах одного жесткого диска, и даже на разных жестких дисках. Причем, что очень важно, сами файловые системы для монтируемых разделов могут быть отличными друг от друга. Например, при работе в Linux мы можем иметь часть разделов с файловой системой Ext3FS, а часть разделов – c системой Ext4FS. Важно, чтобы ядро Linux поддерживало эти файловые системы. Как мы уже знаем, файл-каталог, в котором перечислены имена файлов, позволяет установить соответствие между именами и самими файлами. Каталоги образуют древовидную структуру. При этом все стараются придерживаться уже упомянутого стандарта FHS. Большое число системных каталогов POSIX-системы используют для своих собственных нужд. В них содержатся программы и команды, предоставляемые пользователям, и файлы устройств. В каталоге /etc располагаются конфигурационные файлы. Имена файлов задаются последовательностью имен каталогов, разделенных косой чертой (« / ») и приводящих к концевому узлу (листу) некоторого дерева. Если имя файла начинается с косой черты, то поиск по дереву начинается в корневом каталоге. Если же имя файла не имеет в начале косой черты, то поиск начинается с текущего каталога. Если выполнить команду ls -a , то среди имен файлов мы увидим два необычных имени — это точка и две точки. Точка обозначает текущий каталог, а две точки — родительский каталог. Поэтому имена файлов, начинающиеся с « ../ », подразумевают начало поиска в 106 каталоге, родительском по отношению к текущему. Имя файла work1 указывает на элемент work1 в текущем каталоге. Имя файла /home/student/work1 приводит к поиску в каталоге home в корневом каталоге. Затем к поиску каталога student в каталоге home и, наконец, к поиску элемента work1 в каталоге student. Сама по себе первая косая черта / в этом длинном имени обозначает как корневой каталог, так и разделитель в длинном перечне имён вложенных каталогов. Напомню, что файл, не являющийся каталогом, может встречаться в различных каталогах, возможно под разными именами. Это называется связыванием. Элемент в каталоге, относящийся к некоторому файлу, у которого уже есть имя, называется связью или жёсткой ссылкой. В POSIX-системах все такие связи имеют равный статус. Важно понимать, что файлы не принадлежат каталогам, они там всего лишь упоминаются. Сами файлы существуют независимо от каталогов, а ссылки (жёсткие) указывают на реальные физические файлы. Файл «исчезает», когда удаляется последняя связь, указывающая на него. Биты защиты (права доступа к файлам), заданные в ссылках, могут отличаться от битов защиты в исходном файле. Таким образом можно решать проблему избирательного ограничения доступа к файлам. Программа, выполняющаяся в системе, всегда запускается от имени какого-то пользователя и какой-то группы (обычно - основной группы этого пользователя), но связь процессов с пользователями и группами организована сложнее: здесь различаются идентификатор для доступа к файловой системе (FSUID - File System access User ID, FSGID — File System access Group ID) и ранее упомянутые эффективные идентификаторы (EUID — Effective User ID, EGID — Effective Group ID), а при доступе к файлам учитываются еще и полномочия (capabilities), присвоенные самому процессу. При создании файл получает UID, совпадающий с FSUID процесса, который его создает, и, как правило, GID, совпадающий с FSGID этого процесса. Ат107 рибуты доступа определяют, что разрешено делать с данным файлом данной категории пользователей. Как мы помним, имеется всего три операции: чтение, запись и выполнение. При создании файла (или еще одного имени для уже существующего файла) модифицируется не сам файл, а каталог, в котором появляются новые ссылки на айноды. Удаление файла заключается в удалении ссылки. Таким образом, право на создание или удаление файла — это право на запись в каталог. Право на выполнение каталога интерпретируется как право на поиск в нем (прохождение через него). Оно позволяет обратиться к файлу по пути, содержащему данный каталог, даже тогда, когда каталог не разрешено читать и список всех его файлов поэтому недоступен. Помимо трех названных основных атрибутов доступа существуют дополнительные, используемые в следующих случаях. Атрибуты SetUID и SetGID существенны при запуске программы на выполнение: они требуют, чтобы программа выполнялась не от имени запустившего ее пользователя (группы), а от имени владельца (группы) того файла, в котором она находится. Если файл программы имеет атрибут SetUID (SetGID), то FSUID и EUID (FSGID и EGID) соответствующего процесса не наследуются от процесса, запустившего его, а совпадают с UID (GID) файла. Благодаря этому пользователи получают возможность запустить системную программу, которая создает свои рабочие файлы в закрытых для них каталогах. Кроме того, если процесс создает файл в каталоге, имеющем атрибут SetGID, то файл получает GID не по FSGID процесса, а по GID каталога. Это удобно для коллективной работы: все файлы и подкаталоги в каталоге автоматически оказываются принадлежащими одной и той же группе, хотя создавать их могут разные пользователи. Есть еще один атрибут – CVTX, который нынче относится к каталогам. Этот атрибут часто называют стики-битом (sticky bit). Он 108 показывает, что из каталога, имеющего этот атрибут, ссылку на файл может удалить только владелец файла. Установка SetUID для файла позволяет запускать его на исполнение не от своего имени, а от имени владельца файла. Установка SetUID для каталога указывает, что владельцем всех вновь создаваемых в каталоге файлов будет владелец каталога, а не текущий пользователь. Аналогично действует бит SetGID, но для группы владельцев. Из предыдущей лекции мы уже знаем, что существуют две стандартных формы записи прав доступа — символьная и восьмеричная. Символьная используется при выводе информации о правах доступа и в случае использования команды ls с опцией -l получаемая нами информация представляет собой цепочку из десяти символов. Первый из них не относится собственно к правам, а всего лишь обозначает тип файла. Используются следующие обозначения:  ' - ' — обычный файл;  ' d ' — каталог (директорий);  ' с ' — символьное устройство;  ' b ' — блочное устройство,  ' р ' — именованный канал ( named pipe);  ' s ' — сокет (socket),  ' l ' — символьная ссылка. Бит SetUID можно установить командой chmod u+s <имя_файла или имя_каталога>. 109 Бит SetGID можно установить командой chmod g+s <имя_файла или имя_каталога>. Отметим, что команду chmod могут использовать только владелец файла (каталога) или суперпользователь. Восьмеричная запись — это шестизначное число, первые два знака которого обозначают тип файла и довольно часто опускаются, третья цифра — атрибуты SetUID (4), SetGID (2) и SVTX (1), а оставшиеся три — соответственно права владельца, группы и всех остальных. Очевидно, что право на чтение можно представить числом '4', право на запись - числом '2', а право на выполнение кодируется как '1'. Например, стандартный набор прав доступа для каталога /tmp в символьной форме выглядит как drwxrwxrwt, а в восьмеричной - как 041777 (это каталог; чтение, запись и поиск разрешены всем; установлен атрибут SVTX). A набор прав -r-S-x-w-, или в числовом виде — 102412, будет означать, что это обычный файл, владельцу разрешается читать его, но не выполнять и не изменять, пользователям из группы файла (за исключением владельца) — выполнять (причем во время работы программа получит права владельца файла), но не читать и не изменять, а всем остальным — изменять, но не читать и не выполнять. Большинство программ создают файлы с разрешением на чтение и запись для всех пользователей, а каталоги — с разрешением на чтение, запись и поиск для всех пользователей. Этот исходный набор атрибутов логически складывается с «пользовательской маской» — User File-Creation Mask, сокращенно umask , которая обычно ограничивает доступ. Например,следующие значения для umask u=rwx,g=rwx,o=r-x следует понимать так: у владельца и группы остает- ся полный набор прав, а всем остальным запрещается запись. В восьмеричном виде оно запишется как 002. Первая цифра здесь — это ограничения для владельца, вторая — для группы, третья — для остальных, запрещение чтения — 110 4, записи — 2, выполнения — 1 . Владелец файла может изменить права доступа к нему командой chmod. Для смены владельца файла существует команда chown. Формат команды простой — chown [ опции ] <новый_владелец> <перечень_файлов> Изменить владельца файла может только сам владелец файла (т. е. можно передать файл другому пользователю) или суперпользователь. И, наконец, вернёмся ещё раз к процессам. Процесс может выполняться в одном из двух состояний, а именно: пользовательском и системном. В пользовательском состоянии процесс выполняет пользовательскую программу и имеет доступ к пользовательскому сегменту данных. Более того, в этом состоянии процессор не может выполнять все команды, которые потенциально мог бы выполнить. Часть команд (это, прежде всего, команды ввода-вывода, команды обработки прерываний и команды с обращением к защищённым областям памяти). В системном состоянии процесс выполняет программные модули ядра и имеет доступ к системному сегменту данных. При этом процессор может исполнять любые команды. Когда пользовательскому процессу требуется выполнить системную функцию, он создает системный вызов. Фактически происходит вызов ядра системы как подпрограммы. С момента появления системного вызова процесс считается системным. Таким образом, пользовательский и системный процессы являются двумя фазами одного и того же процесса, но они никогда не пересекаются между собой. Каждая фаза пользуется своим собственным стеком. Стек задачи содержит аргументы, локальные переменные и другую информацию относительно функций, выполняемых в режиме задачи. Диспетчерский процесс не имеет пользовательской фазы. 111 В большинстве POSIX-систем используется разделение времени (Time Sharing), то есть каждому процессу выделяется квант времени. Либо процесс завершается сам до истечения отведенного ему кванта времени, либо он откладывается по истечении кванта. Механизм диспетчеризации характеризуется достаточно справедливым распределением процессорного времени между всеми процессами. Пользовательским процессам приписываются приоритеты в зависимости от количества получаемого ими процессорного времени. Процессам, которые получили большое количество процессорного времени, назначают более низкие приоритеты, в то время как процессам, которые получили лишь небольшое количество процессорного времени – наоборот, повышают приоритет. Кроме этого, различают интерактивные процессы и фоновые процессы — так называемые демоны (от англ. Daemon — Disk And Execution MONitor — т. е. запущенная с диска программа, выполняющая функции некоторого монитора. Другими словами, демоны представляют собой программы, выполняющие функции какой-нибудь службы). У процессов-демонов нет управляющего терминала и нет, соответственно, пользовательского интерфейса. Для управления демонами приходится использовать другие программы. Посмотреть информацию о выполняющихся сейчас процессах можно например с помощью команды top . По умолчанию она выведет отсортированный перечень наиболее активных процессов, предварив это информацией о работе самой операционной системы. Существуют и другие команды, но лучше всего их изучать на практических занятиях. Лекция 10. Открытые системы и открытые коды Помимо термина «открытые системы» в последние годы мы достаточно часто встречаемся с понятием «открытые коды». Открытые системы используют открытые коды. Термин «открытые коды» означает, что у нас имеется сво112 бодный доступ к исходным текстам программ. Исходный код таких программ доступен для просмотра, изучения и изменения, что позволяет любому пользователю либо принять участие в доработке самой открытой программы, либо использовать код для исправления в них ошибок или создания новых программ. Последнее возможно через заимствование исходного кода, если это позволяет лицензия на программу, или через изучение использованных алгоритмов, структур данных, технологий, методик и интерфейсов (поскольку исходный код может существенно дополнять документацию, а при отсутствии таковой сам служит документацией). В противовес открытым кодам большинство используемых программ и программных комплексов недоступны для того, чтобы их можно было изучать и уж тем более — изменять. Однако если понятие открытых систем дополняется понятием открытых кодов, то обратное неверно. Действительно, наличие исходных кодов на систему, доступных для изучения и изменения, не является гарантией того, что система является открытой. Но если мы говорим о том, что некая система является по-настоящему открытой, то это подразумевает, что у нас есть исходные коды. Собственно термин Open Source Software (открытое программное обеспечение) ввёл Эрик Раймонд, когда он попробовал дистанцироваться от понятия «свободное программное обеспечение» (Free Software), которое ввёл Ричард Столлман. Собственно Open Source является даже торговой маркой организации Open Source Initiative. Существует специальный комитет, решающий, может ли лицензия носить имя Open Source. Определение, которым он при этом руководствуется, приведено в The Open Source Definition. Отличие между открытым ПО и свободным ПО заключается в основном в приоритетах. Сторонники термина Open Source делают упор на эффективность открытых исходников как метода разработки, модернизации и сопровождения программ. Не следует путать два разных понятия — Open Source и Free Ware. Это разные понятия. Открытый исходный код — это не всегда бесплатный код и наоборот — бесплатная программа не обязательно распространяется вместе с ис113 ходниками. Сторонники термина Free Software считают, что именно права человека на свободное распространение, модификацию и изучение используемых им программ являются главным достоинством свободного открытого ПО. Открытые системы — это прежде всего системное, а не прикладное программное обеспечение, хотя функциональность системы обеспечивают именно прикладные программы. И наличие открытых кодов для системного программного обеспечения — это скорее исключение, а не правило. Вносить какие-либо исправления или дополнения может только держатель исходных кодов. Если нет доступа к исходным кодам, то система всегда будет восприниматься как чёрный ящик. В результате для разработчиков приложений и пользователей становится важным только изучение интерфейсов, которые предоставляет система. Изменять эти интерфейсы уже не представляется возможным. Если же есть доступ к исходным кодам, то при необходимости можно внести изменения, если это не запрещено. Открытое программное обеспечение может быть и системным, и прикладным. Например, офисный пакет OpenOffice.org — это прикладное программное обеспечение. До сих пор многие компании не решаются использовать программное обеспечение с открытым исходным кодом. Главной причиной этому служат как старания отделов маркетинга некоторых крупных разработчиков программ, заинтересованные в продаже лицензий, так и распространённые убеждения со стороны потребителей (пользователей), что «Вы получаете ровно столько, за сколько заплатили». До сих пор некоторые фирмы опасаются, что лицензионные соглашения вроде GNU Public License могут оказаться ловушкой, то есть если вы при создании своих проектов используете бесплатное программное обеспечение, то вам придется сделать их исходный код открытым. К счастью, большинство этих опасений оказываются напрасными. Многие крупные компании бесплатно пользуются идеями программного обеспечения с открытым исходным кодом в своих проектах и продвигают их. Некоторые из них полностью основывают свои продукты на этой идее. А часть компаний пришла к решению 114 сделать исходные коды своих продуктов открытыми. В качестве примера можно назвать компанию QNX Software Systems, которая хорошо известна своей операционной системой реального времени QNX. Для большинства рядовых пользователей ПО с открытым исходным кодом означает доступ к большому количеству разнообразных приложений, за пользование которыми не нужно платить. Например, такая популярная программа как Adobe Photoshop стоит от 29000 руб, в то время как открытая программа GIMP, которая умеет делать не меньше и может быть установлена на разные операционные системы, абсолютно бесплатна. Или офисный пакет программ Microsoft Office стоит от 11500 руб, в то время как открытый пакет офисных программ LibreOffice может быть использован любым пользователем абсолютно бесплатно. Но гораздо важнее для многих не бесплатность программы, а доступность её исходных кодов, возможность внести в программу те или иные изменения и/или добавления. Среди рядовых пользователей таких не много, но для организаций доступ к исходным кодам может стать чрезвычайно важным. Модель открытого кода (Open Source) - это не только соглашения о формах использования программ или других результатов творческой деятельности людей и целых организаций. Наиболее важной стороной Open Source является свободный, индивидуальный выбор участия в создании и использовании таких проектов. В мире Open Source никому не придет в голову заставить кого бы то ни было что-то создать или что-то использовать вопреки желаниям субъекта. Такое партнерство сильно отличается от отношений, где главными действующими лицами являются заказчик и исполнитель. Модель открытого кода не следует трактовать слишком узко и ограничивать ее пригодность только сферой разработки программных систем. По этой модели организуются проекты из различных областей творческой деятельности - составление словарей и энциклопедий (например, сетевая энциклопедия Wikipedia), изготовление и распространение карт, и многое-многое другое. Политика открытого кода (Open Source Policy) — это принцип "распределенной" разработки, использующийся в техно115 логии, искусстве, политике общественных организаций и сетей и, прежде всего, — в создании свободного и/или открытого программного обеспечения. Кстати, важно понимать различия между открытым и свободным ПО. Открытое ПО не всегда является свободным. В качестве примера можно привести продукт 1С Бухгалтерия, который является открытым, но не свободным. Особенность проектов по созданию открытого кода заключается в том, что эти проекты выполняются открытым сообществом. Наиболее ярким примером проекта, созданного по модели открытых кодов и при этом являющегося понастоящему открытой системой, является GNU/Linux. Начинал свою операционную систему Линус Торвальдс один. Но после того, как он опубликовал исходные коды своей системы, которая в тот момент представляла собой всего лишь действующий макет, к работе над его проектом стали подключаться другие заинтересовавшиеся программисты. Проект стал коллективным, поскольку образовалось открытое сообщество; руководителем проекта был и остаётся Линус Торвальдс [ 7 ]. Другим ярким и очень полезным проектом является пакет прикладных программ OpenOffice, который нынче наиболее полно представлен новым вариантом — LibreOffice. После того, как сообщество OpenOffice.org, которое разрабатывало свой пакет программ под покровительством компании Sun Microsystems, попало под юрисдикцию компании Oracle, основные разработчики основали новое сообщество — LibreOffice.org. При этом они вновь провозгласили, что прежде всего придерживаются идей свободного и открытого программного обеспечения, основателем которых общепризнанно считается Ричард Столлман, американский программист из Массачусетского технологического института. Для продвижения своего проекта разработчики организовали фонд The Open Document Foundation, который является некоммерческой организацией, созданной для разработки и поддержки независимого офисного пакета программ LibreOffice с открытым исходным кодом и открытыми стандартами на электронные документы. Этот фонд ставит перед собой цель — создать в пол116 ной мере свободный офисный пакет как для пользователей, так и для разработчиков, не принуждая их передавать авторские права какой-либо организации, в том числе самому фонду. Во многих странах, в том числе и в нашей стране, наиболее распространённым и популярным офисным пакетом является Microsoft Office. Он, увы, не является ни открытым, ни бесплатным. На самом деле это достаточно дорогой продукт и для компании Microsoft он принёс очень большой доход. Но несмотря на то, что официально Microsoft Office и электронные документы (файлы), изготовленные или отредактированные с его помощью, не должны выступать в роли стандарта, по факту именно этот пакет используется у нас повсеместно. Это яркий пример того, что стандарт де факто может иметь приоритет перед стандартом де юре. LibreOffice — это мощный офисный пакет, который может работать на большинстве современных операционных систем, включая GNU/Linux, Microsoft Windows и Mac OS X. Он имеет открытый исходный код и бесплатен, причём не только для частного, но и для коммерческого использования. Пакет переведён (адаптирован) на большинство языков мира. Форматы электронных документов, которые в нём используются, были приняты как стандарты для большинства стран. Даже компания Microsoft перешла на эти стандарты. Правда, ради справедливости следует заметить, что в эти стандарты Microsoft внесла небольшие изменения, в результате чего документы перестали быть полностью совместимыми. В состав пакета LibreOffice входят текстовый процессор Writer, табличный процессор Calc, программа для подготовки и просмотра презентаций Impress, векторный графический редактор Draw, система управления базами данных Base и редактор формул Math. Основным форматом файлов, использующимся в приложении, является открытый международный формат OpenDocument (ODF, ISO/IEC 26300), но поддерживается работа и с другими популярными форма117 тами, в том числе форматы DOC, DOCX, XLS, XLSX, PPT, PPTX, CDR. Поскольку в нашей стране в качестве стандарта принят формат ODF, то все студенты в обязательном порядке должны освоить работу в пакете программ LibreOffice.org [ 8 ]. Что же такое открытое сообщество? Открытое сообщество создаётся вокруг какого-нибудь проекта с открытым исходным кодом или вокруг некоторого информационного ресурса. Это может быть сервер с исходными кодами некоторой программной системы, виртуальная энциклопедия или база стандартов или ещё каких-нибудь открытых документов. Люди объединяются в сообщество с целью развивать информационный ресурс — разрабатывать программу, писать и редактировать статьи в энциклопедии или разрабатывать или уточнять спецификации некоторого стандарта. Обычно сообщество называют открытым, если оно удовлетворяет следующим требованиям:  У всех членов сообщества есть доступ к информационному ресурсу, над которым ведётся работа.  Сообщество осуществляет свои коммуникации через доступные извне каналы общения — дискуссионные листы, форумы.  Известны правила, которые регулируют отношения людей в сообществе, причём для того, чтобы узнать эти правила, не требуется вступать в сообщество.  Для вступления и участия в работе сообщества не требуется выплачивать какие-либо лицензионные отчисления.  Участие в сообществе не ограничивает социальных свобод (в частности, не требуется подписка о неразглашении коммерческой или иной тайны). 118 Само собой, что участие в открытом сообществе налагает на человека определённые обязательства. Открытое сообщество представляет собой принципиально новую социальную формацию по сравнению с корпоративными или исследовательскими коллективами разработчиков. Прежде всего, это высокая личная ответственность каждого за качество и объём работы. Кроме того, проекты ведутся совместно несколькими независимыми разработчиками, и результат их работы является совместной интеллектуальной собственностью. Открытые сообщества прежде всего складываются из добровольцев, которые зачастую не имеют материальной заинтересованности в результатах проекта. В силу этой особенности открытых сообществ приказные механизмы управления, как правило, не эффективны — несогласные просто уйдут и приложат свои силы в других проектах. Поэтому в открытых сообществах обязательно возникают элементы самоорганизации, которые позволяют вырабатывать организационные формы, приемлемые для всех участников. В частности, распространены коллегиальные механизмы принятия решений, выборный характер руководства проекта. Структура такого сообщества и распределение обязанностей в нём могут меняться динамически. При этом проект создаётся не отдельной личностью или группой, а глубоко взаимосвязанным коллективом заинтересованных в этой проблеме участников. В соответствии с историей возникновения открытые сообщества можно разделить на две группы — те, что "возникли сами", и те, что "были созданы". К первой группе следует отнести сообщества, возникшие вокруг небольшой инициативной группы или даже одного человека для создания или развития информационного ресурса. Примером может служить сообщество разработчиков ядра ОС Linux, которое выросло из инициативной группы, поддержавшей в начале 1990-х Линуса Торвальдса в его работе над новой операционной системой для персональных компьютеров. В таких проектах выделяется группа наиболее активных и уважаемых разработчиков, которые зарекомендовали себя в ходе проекта. Они наделяются полномочиями управлять проектом — при119 нимать или отклонять изменения, вносимые в информационный ресурс, планировать разработку и т.д. Важной чертой этих проектов является то, что такая руководящая группа образуется как бы "сама по себе", зачастую с использованием демократических механизмов, таких как выдвижение кандидатов и голосование сообщества. Ко второй группе относят сообщества, которые развиваются по принципам открытых сообществ, но изначально были созданы общественными или коммерческими организациями. Сюда для примера следует отнести уже упомянутое сообщество Internet Society и многие другие. Поскольку открытые системы имеют очень большое значение, то многие компании софинансируют наиболее значимые проекты. Так, компании IBM и Microsoft уже в течение многих лет вносят по несколько миллиардов долларов в разработку и продвижение GNU/Linux и считают это выгодным. Дело в том, что эта ОС оказалась не только открытой, но и успешной, поэтому имеет смысл не изолироваться, а сотрудничать. При первом знакомстве с понятием Open Source у многих возникает впечатление, что с такими проектами можно делать всё, что заблагорассудится — использовать, тиражировать, изменять и даже продавать. Однако такая возможность есть только в том случае, если результаты работы передаются в общественное достояние (Public Domain). Однако гораздо чаще авторы стараются защитить свою работу хотя бы от кражи. Вышеупомянутый Ричард Столлман (Richard Stallman) в 1984 году основал Фонд Свободного Программного Обеспечения (Free Software Foundation). Целью этого фонда было устранение всех запретов и ограничений на распространение, копирование, модификацию и изучение программного обеспечения. До этого коммерческие компании тщательно оберегали разработанное ими программное обеспечение, ограждали его патентами и знаками защиты ав120 торских прав, держали в секрете исходные коды программ. Столлман считал (и сейчас так считает), что это наносит огромный вред развитию программного обеспечения (ПО), приводит к снижению качества программ и наличию в них огромного количества невыявленных ошибок. И, что хуже всего, это приводит к замедлению процесса обмена идеями в области программирования, тормозит создание нового ПО в силу того, что каждому программисту приходится полностью заново писать каждую программу, вместо того, чтобы заимствовать уже готовые куски исходного кода из готовых программ. Кстати, идея создания программ из уже написанных программных модулей является одной из главных принципов, которые послужили ОС UNIX для того, чтобы она и все её клоны со временем стали открытыми системами. Фонд Столлмана организовал разработку открытого и свободного ПО и одним из самых главных проектов был проект создания UNIX-подобной операционной системы, но не подпадающий под ограничения, которые были наложены на UNIX. Поэтому свой проект он назвал GNU, что является оригинальным рекурсивным акронимом — Gnu Not Unix, т. е. UNIX, но не UNIX. В рамках этого проекта было разработано большое количество системного ПО, необходимого для полноценной ОС. Но собственно ядро этой ОС так и не успели создать, поскольку в этой роли удачно выступил проект Линуса Торвальдса. В последующем Linux стали называть GNU/Linux, поскольку в состав этой ОС входит очень большой объём кода из проекта GNU. Лучшие проекты с открытыми исходниками основаны на так называемой "базарной модели" ("bazaar model"). Этот термин и понятие ввёл Эрик Рэймонд в совей статье "Собор и базар" [ 9 ]. Его очень удивил стиль разработки Линуса Торвальдса — частый выпуск релизов, доступность всех исходных текстов и терпимость к разнородным программам. «Это было совсем непохоже на размеренное строительство собора, сообщество Linux скорее напоминает шумный базар, с множеством различных подходов и направлений. То, что на этом базаре рождается согласованная стабильная операционная система, кажется чудом из 121 чудес. Меня потрясло, что этот базарный стиль работает и работает хорошо. Я не только участвовал в разработке индивидуальных проектов, но также пытался понять, почему в мире Linux'a не только не возникает беспорядка, но напротив он движется вперед со скоростью, которой строители собора могут только позавидовать» [ 9 ]. Как показала практика многих проектов, децентрализованная модель разработки сложных проектов с открытым исходным кодом действительно во многом превосходит методы, используемые разработчиками коммерческих (проприетарных) программ. Согласно этой модели собственно разработкой кода занимается относительно небольшое количество программистов, один из которых осуществляет документирование проекта и поддерживает базу данных с исходными кодами. Вокруг этой группы объединяется уже существенно большего размера группа программистов, которая занимается тестированием, она теснейшим образом взаимодействует с первой группой. По этому поводу Эрик Раймонд пишет: «Если пользователи будут вашими сотрудниками, то вам обеспечены улучшение кода и эффективная отладка» [ 9 ]. Третья группа, которая обычно имеет ещё больший размер, уже не проявляет активности, характерной для первой и второй группы, но это одни из первых активных пользователей разрабатываемого и/или развиваемого проекта и они, безусловно, вносят большой вклад в доведение проекта до нужного качества в отличие от тех пользователей, которые потребляют продукт без обратной связи. «Иногда использовать идеи пользователей лучше, чем использовать свои идеи». А благодаря тому, что активные пользователи-программисты имеют доступ к исходным кодам и к группе разработчиков, удаётся намного быстрее протестировать программное обеспечение и исправить максимально большое число ошибок. В результате, как показывает практика, такие проекты оказываются более эффективными и продукты получаются более качественными, нежели проекты, создаваемые какой-нибудь компанией, которая всё держит в секрете и выпускает в продажу уже готовый продукт. 122 Открытые коды очень близки к другим открытым документам, имеющим непосредственное отношение к открытым системам; речь идёт об открытых спецификациях и стандартах. Разработка и продвижение стандартов обладают рядом особенностей, обусловленных природой стандартов. Стандарты разрабатываются иначе, чем программное обеспечение. К ним предъявляются жёсткие требования (полнота, непротиворечивость, понятность, однозначность), поэтому изменения в стандарты вносятся, как правило, сразу большими частями, чтобы обеспечить более высокое качество стандарта. Стандарты могут содержать отдельные части или главы, поясняющие их назначение и основные идеи, что аналогично проектной документации для программного обеспечения. Тестирование стандарта заключается в разработке реализаций-прототипов, что само по себе может быть гораздо сложнее, чем тестирование программ в проектах Open Source. Стандартизацией занимаются не столько отдельные люди, сколько целые организации, поскольку реализация стандарта — это задача, требующая больших ресурсов и, как правило, непосильная для одного человека. В стандартизации часто бывают заинтересованы индустриальные компании. В таком случае в состав группы, разрабатывающей стандарт, делегируются представители компаний. Они получают зарплату за участие в работе над стандартом и отстаивают в стандарте интересы компании-работодателя. Стандарты могут затрагивать национальные интересы отдельных государств, поэтому многие международные органы стандартизации, в том числе и те, что ведут открытые проекты стандартизации, поддерживают сеть базовых организаций или региональных представительств в различных странах. Посредством базовых организаций решаются вопросы коммуникации с правительствами и адаптации стандарта и методов его продвижения к особенностям соответствующих стран. В этом проекты по стандартизации отличаются от большинства проектов с открытыми кодами, которые являются в чистом виде интернациональными проектами без привязок к национальным структурам. 123 Отметим наиболее характерные особенности открытых стандартов.  Открытость проекта для включения новых участников. Создание и продвижение открытых стандартов осуществляется некоммерческими консорциумами или публичными форумами, которые не взимают плату за участие в работе сообщества. Участие в консорциуме или форуме происходит на добровольной основе.  Открытость результатов для ознакомления. Разработанные стандарты, тестовые наборы, демонстрационные и агитационные материалы выкладываются в открытый доступ в сети Интернет, за скачивание и использование результатов проектов не взимается плата.  Открытость результатов для использования. Разработанные открытые стандарты можно реализовать без выплаты лицензионных платежей. Можно самостоятельно проводить акции и кампании по продвижению стандарта, для этого не требуется получать специальные разрешения и платить лицензионные отчисления. Разработка стандартов также имеет ряд отличий от типичных проектов, направленных на создание программ. Программы разрабатываются инкрементально, небольшими кусками с частыми обновлениями исходных текстов. Проектная документация создаётся редко, даже пользовательская документация на программы, разработанные в проектах Open Source, редко существует в полном объёме. Не всегда серьёзное внимание уделяется тестам, которые проверяют функциональную корректность программ. Немаловажной частью продвижения стандарта является задача создания тестовых наборов для проверки соответствия стандарту. Эта задача лежит на стыке областей стандартизации и разработки программных средств. От обычных проектов по созданию ПО разработка тестовых наборов отличается, прежде всего, более глубокой прора- 124 боткой требований, тщательной реализацией тестового набора, использованием специализированных средств разработки. Лекция 11. Лицензирование программного обеспечения В большинстве развитых стран программное обеспечение подобно другим объектам интеллектуальной собственности, таким как изобретения, литературные и/или музыкальные произведения, защищено от несанкционированного использования и копирования законами об авторских правах. Наверное все знают, что авторское право ― это часть гражданского права, регулирующая правоотношения, связанные с созданием и использованием (изданием, исполнением, показом и т. д.) произведений науки, литературы или искусства, то есть объективных результатов творческой деятельности людей в этих областях. Законы об авторских правах в Российской Федерации описаны в четвертой части Гражданского Кодекса [ 11 ]; они предусматривают сохранение за автором (а точнее — за правообладателем) нескольких исключительных прав, одно из которых право на производство копий (CopyRight). Авторские права — совокупность прав автора - правообладателя, закрепленных действующим законодательством и направленных на использование произведения, а также на осуществление и защиту личных неимущественных и имущественных авторских прав. Возникновение авторских прав непосредственно связано с фактом создания произведения. При этом не требуется специального оформления или регистрации, но для обеспечения доказательства авторства и дополнительной защиты правообладателями авторских прав осуществляется регистрация прав. Авторское произведение считается существующим с момента его фактического создания. Произведением признается результат творческой деятельности автора. Для того, чтобы произведение могло получить охрану, оно должно 125 не только возникнуть в сознании автора, но также получить объективную форму выражения, то есть стать доступным для восприятия других людей. Автором произведения признается только физическое лицо, своим творческим трудом создавшее произведение. Для передачи авторских прав составляется и заключается лицензионный договор. Очень часто автор не имеет прав на свою программу, эти права переходят к собственнику. Чаще всего таким собственником оказывается работодатель или заказчик программы. Другими словами, права на служебные произведения — произведения, созданные в порядке выполнения служебных обязанностей или служебного задания, регулируются отдельно. Исключительное право на использование служебного авторского произведения принадлежит работодателю. Однако договором между автором (работником) и работодателем может быть предусмотрено иное. Правом работодателя, не подлежащим изменению, является возможность указывать свое наименование (использовать знак охраны авторских прав) либо требовать такого указания при любом использовании служебного произведения. Итак, программный продукт и его исходный код охраняется авторским правом, которое даёт авторам или правообладателю (как мы выяснили, чаще всего правообладателем является организация-наниматель автора служебных произведений) власть над изменением, распространением, способом использования и поведением программы, включая случаи, когда исходный код опубликован. Сила власти авторских прав в современном обществе настолько велика, что даже изучение или попытки исправления ошибок программ путём дизассемблирования могут преследоваться уголовным правом. Для использования произведений, программ, баз данных и каких-нибудь иных объектов, охраняемых авторским правом, следует приобрести (или получить бесплатно) лицензию на те или иные права по отношению к таким объектам. 126 Лицензия (лат. Litentia) ― это документ (соглашение), дающий право на выполнение некоторых действий. Соответственно лицензионные условия ― это условия, при соблюдении которых лицензия действительна. Лицензии бывают различными. По желанию автора (или издателя) программы лицензии могут быть платными или бесплатными. Прежде всего их подразделяют на проприетарные (собственнические) и на свободные (открытые) [ 12 ]. Приобретая программное обеспечение мы в действительности приобретаем лицензию, которая дает нам право на использование этого ПО. Условия использования программного обеспечения (например, возможность переноса на другой компьютер, право использования предыдущих версий) фиксируются в соглашении, сопровождающим поставку продукта. Самый распространенный вариант такого соглашения — это лицензионное соглашение конечного пользователя (EULA - End User License Agreement). Такая лицензия сопровождает продукты, поставляемые вместе с новыми компьютерами (OEM-лицензия) или отдельно в розничной продаже (коробочная версия). OEM-лицензия (Original Equipment Мanufacturer) - лицензия на программное обеспечение для продажи вместе с новым компьютерным оборудованием. Установить такое ПО может только сборщик систем, но не конечный пользователь. В настоящее время EULA чаще всего распространяется в электронном виде и отображается при первом запуске продукта. Пользователь должен согласиться с его условиями перед установкой программного обеспечения. Ознакомиться с правилами использования OEM или коробочных версий ПО желательно до его покупки. Для организаций наиболее выгодный способ приобретения лицензий - это специальные программы корпоративного лицензирования. Не все компании поддерживают этот вариант продажи лицензий, но наиболее успешные компании — практикуют. Корпоративные схемы предусматривают значительные скидки и позволяют учесть размер компании и другие особенности бизнеса. Кроме этого бывают лицензии для учащихся; как для личного использования, так и для учебных заведений. Скидки для подобных лицензий себя оправды127 вают, поскольку после обучения для работы придётся приобретать уже полноценную лицензию. Традиционно в лицензиях на коммерческие продукты (проприетарные лицензии) содержатся ограничения на использование программы (число инсталляций/ процессоров/пользователей и т. д.), на распространение и на доступ к "внутренностям" программы (её декомпилирование) и на ее изменения. Так, например, лицензия Microsoft на её ОС Windows 10 дословно запрещает «изучать технологию, декомпилировать, деассемблировать программное обеспечение или предпринимать попытки совершения таких действий». То есть первоначальное назначение лицензии заключается в защите коммерческих прав и интеллектуальной собственности разработчика программы или его издателя (владельца). При этом владелец лицензии получает право использовать продукт (программу), ибо без лицензии этого делать, как правило, нельзя. Права на использование программного обеспечения, полученные благодаря лицензии, могут быть однократно переданы другому лицу на постоянной основе при условии, что передается продукт целиком (включая все предыдущие версии продукта, если новые версии приобретались как обновления). При этом новый пользователь продукта должен принять условия соглашения EULA, в противном случае передача лицензии не может быть произведена. При передаче прав бывший пользователь продукта должен удалить продукт со своего компьютера. Все продукты, приобретенные в виде OEM-версий, а также операционные системы, приобретенные по программам корпоративного лицензирования, могут быть переданы только вместе с оборудованием, на которое они были установлены. Большинство лицензий имеет определённую структуру. Прежде всего оговаривается объём прав, передаваемых лицензией. Он может включать в себя 128 разрешение на установку и использование (как локальное, так и через сеть), условия на обновления, возможности по передаче лицензии другим лицам. Далее, лицензия может перечислять ограничения на декомпиляцию и/или внесение исправлений. Абсолютное большинство лицензий имеет раздел по отказу от предоставления каких-либо гарантий и от компенсаций ущерба в случае возникновения каких-то непредвиденных аварийных случаев. Итак, проприетарные лицензии дают пользователям всего лишь право на использование программы. В большинстве таких лицензий в явном виде запрещается производить дизасблирование кода с целью его изучения и/или модификации (даже с целью исправления ошибок!) поскольку владелец лицензии не имеет доступа к исходному коду. Вместе с проприетарной лицензией мы получаем всего лишь готовые двоичные коды. Причём даже документацию на использование программы в большинстве случаев нужно приобретать отдельно; например компания Microsoft продает документацию на свои операционные системы в виде книг с названием типа «Ресурсы Microsoft Windows … ». Для программ с открытым исходным кодом имеются свободные лицензии. Свободные лицензии — это особый вид лицензий, предназначенных для обеспечения юридической защиты прав («свобод») пользователя (общественности) на неограниченные воспроизведение, изучение, распространение и изменение (модификацию или совершенствование) различных продуктов интеллектуальной деятельности. Т.е. эти лицензии, в отличие от проприетарных лицензий, защищают прежде всего права пользователей, а не права автора. В них автор добровольно передает большое количество прав пользователям своих программ и при этом защищает программу от того, чтобы кто-нибудь не смог присвоить себе права на его программу. Авторство остаётся за автором. Свободных лицензий существует большое множество, в которых поддерживаются основные принципы, но несколько отличаются методы и характер защиты прав пользователя, а также различны виды продуктов интеллектуальной 129 деятельности. Но наиболее известными являются лицензии, созданные по инициативе Ричарда Столмана. Прежде всего это GNU General Public License, разработанная в FSF (Free Software Foundation) — Фонде свободного программного обеспечения. Это название переводят, как Универсальная общественная лицензия GNU, Универсальная общедоступная лицензия GNU или Открытое лицензионное соглашение GNU ― лицензия на свободное (открытое) программное обеспечение, созданная в рамках проекта GNU в 1988 г. Её также сокращённо называют GNU GPL или даже просто GPL, если из контекста понятно, что речь идёт именно о данной лицензии (существует довольно много других лицензий, содержащих слова «general public license» в названии). Вторая версия этой лицензии была выпущена в 1991 году; третья версия GPL 3 , после многолетней работы и длительной дискуссии ― в 2007 году. GNU General Public License предоставляет пользователю права копировать, модифицировать и распространять (в том числе на коммерческой основе) программы (что по умолчанию запрещено законом об авторских правах!), а также гарантировать, что и пользователи всех производных программ получат вышеперечисленные права. (Например, запрещается создавать на основе свободной программы под GNU GPL другой проект, не предоставляя его исходники пользователям. Таким образом, данная лицензия вовсе не позволяет делать с программами всё что угодно, как могут ошибочно трактовать данную лицензию плохо знакомые с ней.) Что важно, лицензируя свою работу на условиях GNU GPL, автор не отказывается от права считаться её автором. GNU GPL предоставляет всем пользователям компьютерной программы следующие права, или «свободы»:  свободу запуска программы, с любой целью; 130  свободу изучения того, как программа работает, и её последующей модификации (очевидным условием для этого является доступ к исходному коду);  свободу распространения копий;  свободу улучшения программы, и выпуска улучшений в публичный доступ (предварительным условием для этого является наличие открытого исходного кода). Наиболее важным моментом в такого рода лицензиях является принцип наследования прав. Этот принцип называется «копилефт» (транслитерация английского «copyleft») и он был придуман Ричардом Столманом. Термин "CopyLeft" в данном случае применяется как противоположность слову CopyRight (авторское право, ограничивающее свободу использования и копирования произведений ). Copyleft позволяет человеку, получившему произведение или программу вместе с лицензией GPL, изменять и распространять как само произведение, так и произведения, базирующиеся на нём. Именно этот принцип и гарантирует, что открытая программа останется достоянием общества и что даже после внесения в неё каких-либо изменений её нельзя будет сделать проприетарной и воспользоваться правом CopyRight. GNU GPL имела чётко поставленную задачу — не допустить "закрытия" программ, которые первоначально были выпущены как свободные. Вторая версия такой лицензии (GPL2) предоставляет право свободно использовать, модифицировать и распространять программу, при обязательном условии, что вместе с ней будут распространяться и её исходные коды, включая все сделанные изменения, и по той же самой лицензии. Допускается не включать исходные коды в дистрибутив при условии, что их можно будет свободно получить в дальнейшем (например, скачав с ftp-сервера). Формально эта лицензия не требует от разработчика или дистрибьютора распространять программу бес131 платно, но в свете обязательности предоставления исходных кодов взимание платы за "сборку" в какой-то степени теряет смысл. В GPL2 не предусмотрена возможность распространять программный продукт посредством Интернета (имеется в виду не скачивание дистрибутивов, а использование ПО как интернет-сервиса). В ней ничего не говорится о патентах, так что уже нельзя сказать, что она надёжно защищает право программы оставаться свободной. Поэтому в GPL3 вводится явное разделение понятий "распространение" и "личное использование". На последнее не налагается практически никаких ограничений. Это достаточно сильное послабление, позволяющее вносить нужные вам модификации и ни с кем ими не делиться. Кроме этого в ней регламентируется использование патентов. Все права на сопутствующие патенты на программу должны передаваться вместе с программой для свободного использования. В GPL3 добавлен пункт, запрещающий использовать управление цифровыми правами (DRM — Digital Restriction Management). DRM — это законодательно защищаемые ограничения на доступ к информации (например, требование специального ключа). В сообществе Free Software Foundation считают, что подобные ограничения противоречат духу Open Source, где любой пользователь вправе отключить любую функцию (в том числе и ту, которая отвечает за ограничение доступа). Кроме вышеупомянутых есть и другие свободные лицензии. Например GNU LGPL (Lesser GPL); иногда её называют Library GPL. Эта "ограниченная" GPL, регламентирует права на программные библиотеки. Она содержит ряд пунктов, допускающих компоновку данной библиотеки с программами, распространяемыми по другим лицензиям. Разработчик библиотеки (или её модификации) вправе перевести её на лицензию GPL, однако обратная процедура уже будет невозможна. По этой лицензии OpenOffice.org. 132 разрабатывается пакет программ Широко известна Лицензия BSD. BSD (англ. Berkeley Software Distribution) — это система распространения программного обеспечения в исходных кодах, созданная для обмена опытом между учебными заведениями. Особенностью пакетов программного обеспечения BSD была специальная лицензия BSD, которую кратко можно охарактеризовать так: весь исходный код — собственность BSD, все правки — собственность их авторов. В данный момент термин BSD чаще всего употребляется как синоним BSD-UNIX общего названия вариантов UNIX, восходящих к дистрибутивам университета Беркли. Пожалуй, это самая простая и демократичная открытая лицензия, занимающая всего несколько строк. Её смысл сводится к тому, что "делайте с программой всё, что хотите, только не говорите, будто это вы её написали". То есть единственное предъявляемое ею требование — сохранение уведомлений об авторских правах. Таким образом, лицензия BSD не подпадает под понятие Copyleft, поскольку не запрещает ограничивать свободу этого или производных продуктов. Сторонники GPL часто критикуют BSD за то, что она позволяет любому "украсть" разработку. Действительно, если хорошая программа распространяется под BSD-лицензией, то существует ненулевая вероятность, что какая-нибудь крупная корпорация возьмёт этот код и будет распространять программу как закрытую под коммерческой лицензией. Очевидно, что у такой компании будет гораздо больше маркетинговых возможностей по продвижению и продаже программы — большинство пользователей могут даже и не догадываться, что существует почти такая же программа, но абсолютно бесплатная. К тому же лицензия BSD не обязывает делиться с сообществом модифицированным кодом. Именно этим и воспользовалась компания Apple. Она взяла исходные коды FreeBSD, код микроядра Mach и сделала уже проприетарную систему Mac OS. Ещё стоит упомянуть лицензию CDDL (Common Development and Distribution License). Это лицензия, разработанная в Sun Microsystems. Она требует распространения программы вместе с правами на все сопутствующие патенты и только в исходных кодах, с обязательным уведомлением обо всех сде133 ланных изменениях. В двоичном виде допускается распространение по другой лицензии, при условии, что это не ограничивает свободу доступа к исходному коду. Предусмотрен отзыв всех переданных прав на ПО и патенты в случае судебных претензий к разработчику или распространителю. В недавнем прошлом под этой лицензией распространялись, в частности, операционная система OpenSolaris и процессор Niagara. Если взять и внимательно изучить текст вышеупомянутой лицензии GNU GPL3, то прежде всего стоит обратить внимание на то обстоятельство, что «каждый имеет право распространять точные копии этой лицензии, но без внесения изменений». Лицензия написана на английском языке, поэтому её русскоязычный перевод уже не имеет юридической силы. В то же время, согласно нашему законодательству, лицензия обязательно должна быть написана на русском языке. Второе важное обстоятельство из нашего законодательства, о котором нельзя забывать, заключается в том, что лицензия на программное обеспечение должна иметь ненулевую стоимость, т. е. лицензия не может быть бесплатной! Чтобы обойти этот невероятный казус, нужно купить лицензию за некую небольшую (условную) цену. В этом случае приобретатель получает комплект официальных документов, подтверждающих факт приобретения и легальность использования ПО (договор поставки, счет-фактуру, акт приемапередачи ПО). Продать такую лицензию может любая компания, которая возьмётся за её изготовление, но при этом она должна будет изготовить дистрибутив из тех исходников, которые доступны благодаря наличию GNU GPL. В нашей стране есть такие компании, которые занимаются распространением открытого ПО; попутно они зарабатывают на сопровождении и разработке такого программного обеспечения, и на обучении пользователей. Сама GNU GPL это не запрещает. Наиболее успешной компанией, которая делает бизнес на этой ниве — это американская Red Hat. Её серверные дистрибутивы на базе GNU/Linux используют очень многие компании и организации, включая министерство обороны США. 134 Напоследок полезно знать советы о том, что и как нужно сделать, если Вы разрабатываете программу и хотите, чтобы она была открытой. Для этого укомплектуйте программу нижеследующими уведомлениями. Безопаснее всего присоединить их к началу каждого файла исходных текстов для наиболее эффективного указания отсутствия гарантий; каждый файл должен, по крайней мере, иметь строчку с авторскими правами и указатель на нахождение полного списка уведомлений. <название программы и краткое описание того, что она делает> Copyright (C) <год> <имя автора> Эта программа является свободным программным обеспечением. Вы можете распространять и/или модифицировать её согласно условиям Стандартной Общественной Лицензии GNU, опубликованной Фондом Свободного Программного Обеспечения, версии 3 (или, по Вашему желанию, любой более поздней версии). Эта программа распространяется в надежде, что она будет полезной, но БЕЗ ВСЯКИХ ГАРАНТИЙ, в том числе подразумеваемых гарантий ТОВАРНОГО СОСТОЯНИЯ ПРИ ПРОДАЖЕ и ГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОГО ПРИМЕНЕНИЯ. Смотрите Стандартную Общественную Лицензию GNU для получения дополнительной информации. Вы должны были получить копию Стандартной Общественной Лицензии GNU вместе с программой. В случае её отсутствия, посмотрите . Так же добавьте информацию о том, как можно связаться с вами по электронной и обычной почте. 135 Если программа взаимодействует с пользователем при помощи терминала, сделайте так, чтобы она выводила краткое сообщение наподобие нижеследующего при запуске в интерактивном режиме: <название программы> Copyright (C) <год> <имя автора> Эта программа распространяется БЕЗ ВСЯКИХ ГАРАНТИЙ; для получения дополнительной информации наберите show w. Это свободное программное обеспечение, и Вы можете распространять её в соответствии с конкретными условиями; для получения дополнительной информации наберите show c. 136 Литература 1. Операционная система UNIX : Учебное пособие / А. М. Робачевский, С. А. Немнюгин , О. Л. Стесик. - 2-е изд., перераб. и доп. - СПб. : БХВ - Петербург, 2015. - 636 с. 2. Гордеев А. В. Операционные системы: Учебник для вузов. 2-е изд. СПб.: Питер, 2009. — 416 с: ил. 3. Таненбаум Э. Современные операционные системы. 4-е изд. СПб.: Питер, 2015, - 1120 с. 4. Федорчук А.В. Доступный UNIX: Linux, FreeBSD, DragonFlyBSD, NetBSD, OpenBSD СПб.: БХВ-Петербург, 2006. - 672 с. 5. Федорчук А.В. За свободный POSIX'ивизм. http://posix.ru/index.shtml (дата обращения 27.02.2016) 6. Федорчук А.В. Введение в POSIX'ивизм. http://citforum.ru/operating_systems/posixbook/ (дата обращения 27.02.2016) 7. Линус Торвальдс, Дэвид Даймонд. Just for Fun. Рассказ нечаянного революционера. Эксмо-Экспресс. 2002. - 288 с. 8. Краткое руководство по libreOffice. http://libreoffice.readthedocs.org/ru/latest/ (дата обращения 28.03.2016) 9. Эрик С. Рэймонд. Собор и базар. http://www.lib.ru/LINUXGUIDE/bazar.txt_with-big-pictures.html (дата обращения 28.03.2016) 10. Стандарт на структуру каталогов файловой системы (File Hierarche Standard) http://rus-linux.net/MyLDP/file-sys/fhs-2.2-rus/index.html#TOC (дата обращения 17.04.2016) 137 11. Гражданский кодекс Российской Федерации. Часть IV. http://www.internet-law.ru/law/kodeks/gk_4.htm (дата обращения 26.04.2016) 12. Лицензии. http://www.gnu.org/licenses/licenses.ru.html (дата обращения 26.04.2016) 13. Барабанова М.И., Кияев В.И. Информационные технологии: открытые системы, сети, безопасность в системах и сетях: Учебное пособие.– СПб.: Издво СпбГУЭФ, 2010.– 267 с. 138 СОДЕРЖАНИЕ Предисловие 3 Лекция 1. Открытые системы: основные понятия 4 Лекция 2. Эталонная модель открытой системы 18 Лекция 3. Модель взаимодействия открытых систем 30 Лекция 4. Интернет как пример открытой системы 42 Лекция 5. Общие спецификации на устройства внешней памяти с прямым доступом 56 Лекция 6. Особенности операционных систем UNIX, POSIX-системы 66 Лекция 7. Основные понятия и сущности POSIX-систем 74 Лекция 8. Интерфейс командной строки и файловая система 86 Лекция 9. Ещё раз о пользователях, файлах и процессах 102 Лекция 10. Открытые системы и открытые коды 112 Лекция 11.Лицензирование программного обеспечения 124 Литература 136 139