Стандартна база Linux

1. Дистрибутивів ОС Linux створено досить багато, і створюється відчуття, що вони вже є окремі, не сумісні...
2. Linux Standard Base
3. підтримка LSB
4. бібліотеки LSB
5. Сильні сторони і обмеження LSB
6. імена LSB

Дистрибутивів ОС Linux створено досить багато, і створюється відчуття, що вони вже є окремі, не сумісні один з одним операційні системи. Часом програми, скомпільовані під конкретний дистрибутив, не працюють на іншому дистрибутиві, навіть якщо процесорна архітектура це дозволяє. В результаті виробникам програмного забезпечення доводиться тестувати і сертифікувати свої продукти під різні варіанти Linux.

В даний час в світі Linux виділяються три центри інновацій - Red Hat, Novel / SuSE і Debian, в складі яких є великі команди розробників для доведення, що розвиваються в ініціативному порядку програмних систем до стану цілісних комерційного продукту. Компанія Red Hat здобула популярність завдяки своїй програмі пакетування RPM, ім'я Novell пов'язують з утилітою установки і конфігурації YaST, яка довгий час зберігала статус закритого продукту, а Debian - з системою багатоплатформного розробки та розповсюдження програм. Ці команди внесли істотний внесок у розвиток важливих для комерційних Linux-продуктів технологічних компонентів: багатоплатформного розробки, пакетування і установки програм, а також комплексної настройки всієї системи.

Проблема несумісності дистрибутивів

Досить згадати про складнощі розгортання проекту Linux Standard Base (LSB), що почався в 2002 році за підтримки громадської організації Free Standards Group. Перша версія LSB містила тільки рекомендації, що визначають, в яких каталогах повинні знаходитися компоненти операційної системи - бібліотеки, вихідні тексти, документація і т.п. Згодом з'ясувалося, що цього недостатньо для забезпечення сумісності, і з'явилися такі версії. Зараз прийнята специфікація LSB 2.1, яка послужила основою для документа, спрямованого на утвердження в ISO (правда, в дистрибутивах Linux поки реалізована тільки версія 2.0).

Як відомо, ядро ​​Linux контролюється Лінус Торвальдс; всі ключові зміни ядра узгоджуються з ним або з іншими координаторами. Склад і базова функціональність ядра завжди однакові в одній версії, але щоб у виробників не виникало проблем з перенесенням їх продуктів з однієї версії ядра на іншу, для системних викликів ядра необхідний стандарт. Мінімальною вимогою є дотримання специфікації ISO POSIX, на яку спочатку спиралися розробники Linux. У LSB увійшла розширена специфікація POSIX, прийнята ISO в 2003 році, але в ній не визначено пристрій ядра - описані лише інтерфейси, за допомогою яких додатки з ним взаємодіють. Втім, до складу ядра входять не тільки базові алгоритми управління пам'яттю, розподілу процесорного часу і організації взаємодії процесів ОС, але і драйвери периферійних пристроїв, за які зазвичай відповідають самі виробники. А крім загальних для всіх платформ алгоритмів в ядрі є апаратно залежні частини, які також розвиваються окремо.

Деякі розробники дистрибутивів додають в ядро ​​власні коди або коди сторонніх груп, оформлені як виправлення до ядра. Так, у вигляді виправлень можуть бути реалізовані засоби захисту. Крім того, деякі комерційні компанії додають в дистрибутиви Linux свої розробки, такі як файлові системи, засоби підтримки багатопроцесорних архітектур і розподілених обчислень, інші технологічні новації. Зрозуміло, що додатки, розраховані на підтримку цих технологій з боку ядра, не зможуть працювати з дистрибутивом, в якому такої підтримки немає. Вони не будуть LSB-сумісними, оскільки використовують додаткові інтерфейси, які не завжди є в інших LSB-середовищах. У деяких випадках ситуацію рятує механізм модулів, що дозволяє інтегрувати в ядро ​​додатковий код, але це можливо, тільки якщо в ядрі є інтерфейс для даної функціональності.

Основні відмінності дистрибутивів полягають в наборах програм, які їх складають. Для кожної програми потрібен свій набір бібліотек, які задіє додаток. У разі застосування відкритих вихідних кодів бібліотеки, розроблені одним програмістом або групою розробників, використовуються багатьма. А якщо вже додаток спирається на якусь бібліотеку, вона також повинна бути поміщена в дистрибутив. В результаті набір додатків визначає і вибір бібліотек.

При цьому в Linux прийнято використовувати динамічне зв'язування бібліотек: під час запуску програми ядро ​​ОС збирає її виконуваний образ з актуальними версіями бібліотек. Якщо ж інтерфейс бібліотеки не збігається з застосовуваної програмою, виникає помилка. Те ж саме відбувається, коли програма динамічного зв'язування не може знайти затребувану додатком бібліотеку, розташовану, наприклад, в нестандартному каталозі. Таким чином, для забезпечення сумісності дистрибутивів потрібно розміщувати стандартизовані бібліотеки в заздалегідь встановлених місцях, і якщо перша версія специфікації LSB визначала тільки стандартний набір каталогів, то друга зачіпає вже і набір функцій, об'єднаних в стандартній бібліотеці.

Вирішити проблему несумісності конкретної версії програми з бібліотекою дозволяє статичну зв'язування додатків: в їх склад включаються необхідні бібліотечні функції. Саме в такому вигляді поставляються більшість комерційних додатків, розробники яких не хочуть, щоб у клієнтів виникали проблеми з їх установкою. Однак при використанні статично пов'язаних бібліотек розмір самого додатка і обсяг займаного їм місця на диску збільшуються, тому розробники пропонують різні варіанти поставки своїх рішень - з динамічними або зі статичними бібліотеками. Стандарт LSB дозволяє вирішити ситуацію, якщо для розробника програми досить його базової функціональності. Втім, коректна робота додатків визначається доступністю не тільки кодів і бібліотек, а й інших ресурсів, таких як картинки, конфігураційні файли, підказки та документація. Вони також повинні розташовуватися в заздалегідь відомих і закріплених стандартом каталогах.

Несумісність може виникати при запуску додатків заздалегідь визначеними користувачами і їх групами (mail, shutdown, lp і ін.). А тому стандарт повинен закріплювати ще і розміщення ресурсів додатків: конфігураційні файли, системні сценарії запуску, графічні файли і документація, а також найменування стандартних користувачів і груп (в сенсі ОС), від імені яких може знадобитися виконати установку програми.

Linux Standard Base

Базовий набір специфікацій LSB називається LSB Base і включає в себе LSB-Core, LSB-C ++ і LSB-Graphics, що відповідають за стандартизацію відповідних елементів операційної системи. LSB-Core описує стандартне розташування файлів, LSB-C ++ - інтерфейс ядра на мові С ++, а LSB-Graphic - роботу додатків з X Window. Передбачається, що розробники будуть задіяти ту чи іншу специфікацію, якщо їх додаток використовує відповідну функціональність, і не вдаватися до допомоги функцій, які не описаних в специфікації. Тільки в цьому випадку гарантується коректна робота додатків у всіх LSB-сумісних дистрибутивах.

У специфікаціях є частини, які залежать від платформи (скажімо, LSB-IA-32 - специфікація LSB для 32-розрядних процесорів Intel-архітектури). Ці документи визначають особливості процесорної архітектури, які можуть вплинути на сумісність додатків. Фактично, специфікація стандарту для конкретної архітектури є комбінацією загального документа LSB-generic і архітектурно залежної частини LSB-arch; обидві є обов'язковими до виконання.

Базовим для Unix стандартом є формат уявлення здійсненних програм і бібліотек у вигляді файлів. Цей стандарт входить до складу специфікації System V ABI і називається Executable and Linking Format (ELF). Він важливий і для Linux: перехід версії ядра з 1.x на 2.x пов'язаний з підтримкою формату ELF і відмовою від застарілого a.out. Після появи другої версії ядра ELF є суттєвою частиною Linux, а його специфікація перекочувала в LSB.

Ще одним інститутом стандартизації, на документи якого спиралися творці LSB, є IETF. Так, в LSB використовуються стандартний алгоритм хеш-функції MD5 (RFC 1 321), протокол віддаленого виклику процедур RPC (RFC 1833), стандарти стиснення інформації ZLIB (RFC 1950), DEFLATE (RFC 1951), GZIP (RFC 1952), а також стандарт на електронний підпис OpenPGP (RFC 2440). Є і ще кілька специфікацій, на які спиралися розробники LSB, зокрема специфікації пакетування програм і перевірки цілісності пакету, що встановлюється в операційному середовищі.

Документ LSB-Core складається з трьох частин: специфікація формату ELF, набір вимог LSB і специфікація Linux Packaging Specification. В саму специфікацію LSB входять визначення базових та додаткових бібліотек, набір стандартних команд і утиліт Linux, вимоги до середовища виконання (ієрархія каталогів, локалізація, права доступу та ін.) І до стандартної процедури ініціалізації Linux, а також список стандартних рольових користувачів. Природно, специфікація фіксує лише базові можливості, яких проте досить для більшості утиліт і додатків. Якщо розробник застосовує в своїх продуктах тільки ці набори бібліотек, його застосування безболісно переносяться в будь-який LSB-сумісний дистрибутив.

Як стандарт пакетування програм служить RPM, що ускладнює забезпечення відповідності LSB для дистрибутивів, які не мають його підтримки, наприклад Debian. Втім, в стандарті є приписка, що при необхідності розробники дистрибутивів можуть використовувати і інші програми пакетування. Незмінним залишається лише вимога того, щоб після установки на клієнтську машину все компоненти додатків розташовувалися і іменувалися відповідно до LSB. Таким чином, частина Linux Packaging Specification фактично є необов'язковою: вона лише визначає стандартний формат представлення програм у файлах RPM.

Специфікація LSB-C ++ встановлює інтерфейс з ядром Linux для програм на мові програмування С ++. Цей інтерфейс зібраний в бібліотеку libstdcxx і визначається стандартом на С ++, який специфікований документом ISO / IEC 14882: 2003, а також специфікацією бінарного інтерфейсу Itanium C ++ ABI (Revision: 1.75). А специфікація LSB-Graphics містить опис інтерфейсу для графічних бібліотек, які пов'язані зі стандартами на X Window і OpenGL.

підтримка LSB

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

Природно, і самі програми для дистрибутива повинні відповідати специфікації LSB, що обмежує їх вибір. Втім, зараз з'явилося досить багато додатків, які відповідають специфікації LSB і гарантовано працюють в середовищі дистрибутива, сумісного з LSB.

бібліотеки LSB

Стандарт LSB передбачає наявність на клієнтській машині ряду загальних бібліотек:

• libdl - функції динамічного зв'язування додатків;
• libcrypt - набір функцій шифрування;
• libz - пакет утиліт архівування;
• libncurses - утиліти управління курсором і псевдографікою в термінальному режимі;
• libutil - різні утиліти;
• libpthread - бібліотека потоків, які відповідають специфікації POSIX;
• libpam - функції аутентифікації користувачів;
• libgcc_s - набір визначень бібліотеки Unwind.

Стандарт також передбачає наявність бібліотек libm і libc, визначення яких залежать від використовуваної процесорної архітектури. Функції цих бібліотек такі:

• libc - інтерфейси RPC, IPC, системних викликів, стандартного введення / виведення, сигналів, локалізації, мережевих сокетів, роботи з рядками і регулярними виразами, маніпуляцій з часом і інші інтерфейси, пов'язані з платформою;
• libm - математичні функції.

Нарешті, стандартом передбачені наступні графічні бібліотеки:

• libX11 - функції роботи з системою X Window;
• libXt - набір утиліт для роботи з X Window (X toolkit);
• libGL - набір функцій для роботи з OpenGL;
• libXext - функції, що розширюють базову функціональність X Window;
• libICE - функції, що забезпечують взаємодію різних клієнтів одного X-сервера (Inter-Client Exchange);
• libSM - утиліти управління сеансами протоколу X Window.

Сильні сторони і обмеження LSB

У число розробників LSB входять провідні гравці ІТ-ринку, такі як IBM, HP, Intel, Sun Microsystems, AMD, а також виробники найбільш популярних дистрибутивів Mandriva, RedHat і некомерційна організація Software for Public Interest, що представляє інтереси Debian. Брати участь в розробці LSB може будь-хто, хто підписався на відповідні списки розсилки, тому прийняття рішень навряд чи зможе монополізувати будь-яка група компаній.

LSB відповідають мінімальним бібліотек, що входять в основну частину дистрибутива. Регламентовані версії бібліотек, які повинні входити в кожен дистрибутив, і описані їх інтерфейси. Цей забезпечує зворотну сумісність програм з дистрибутивом: користувач повинен бути впевнений, що і через десять років новий дистрибутив, який підтримує набір стандартів LSB, дозволить запускати додатки, сумісні з конкретною версією LSB.

Крім того, LSB визначає порядок роботи стандартних утиліт, що входять в будь-який дистрибутив Linux. Це робить LSB схожим на Single Unix Specification Version 3, на якому засновані ядро ​​Linux і додатки: вони часто використовують shell-сценарії для установки, видалення, ініціалізації або припинення роботи програмного забезпечення. У таких сценаріях найчастіше застосовуються стандартні утиліти, а LSB описує, які параметри вони повинні мати. Крім того, LSB включає в себе стандарт ієрархії файлової системи (Filesystem Hierarchy Standard, FHS), який регламентує розміщення файлів і бібліотек ( www.pathname.com/fhs ).

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

Формат бінарних файлів ELF ( www.linuxbase.org/spec/refspecs/elf.pdf ) Є фактичним стандартом для всіх дистрибутивів, заснованих на GNU / Linux. LSB підтримує його використання і включає в себе набір тестів для перевірки на сумісність.

Стандарт LSB розбитий на кілька частин відповідно до платформами, на яких працює ядро ​​Linux, а також з рівнями сумісності. Так, поточна версія LSB 2.9 опублікована для апаратних платформ IA-32, IA-64, PowerPC32, PowerPC64, S390 і S390X і ділиться на частини Core, Embedded, Desktop, Java, C ++, Packaging і Graphics. Кожна з частин відповідає за відповідну область застосування LSB-сумісного програмного продукту.

Примітно, що значна частина можливостей GNU / Linux не покривається стандартами LSB. Виробникам дистрибутивів Linux, інтеграторам і розробникам вигідно не тільки те, що LSB стандартизує основні програми, але і те, що LSB не описує вимоги до операційної системи «до останнього файлу». LSB визначає певний рівень порушення сумісності з додатками, нижче якого «опускатися» неприпустимо. Ядро Linux, яке знаходиться вище цього рівня, може розвиватися без обмежень.

Завдяки цьому розробник дистрибутива є вільним у виборі методів і стратегій адміністрування системи. Наприклад, LSB не вимагає виконання чіткої політики безпеки щодо створення та адміністрування користувальницьких і групових облікових записів, а також прав на файли. LSB-сумісні програми будуть працювати і в тому випадку, якщо адміністратор змінить налаштування безпеки, встановлені за замовчуванням (звичайно, в розумних межах: невмілий адміністратор може зламати всю систему, і LSB не дозволяє запобігти такому розвитку подій). Вплив LSB не поширюється і на засоби настройки програмного забезпечення; так, SuSE і Red Hat містять принципово різні програми настройки. Користувач часто вибирає той чи інший дистрибутив Linux, орієнтуючись саме на зручність настройки, а тому Red Hat і SuSE можуть конкурувати в цій галузі, зберігаючи сумісність з існуючими додатками.

В рамках проекту LSB створені спеціальні засоби, що допомагають розробляти сумісні програмні продукти. Це середовище для складання додатків і пакет Application Battery, який містить стандартний набір бібліотек і скомпільованих спеціальним чином програм. Application Battery використовується для тестування програм на сумісність з LSB, а також дає приклади того, як треба збирати LSB-сумісні програми. Програма, яка претендує на сумісність з LSB, може використовувати тільки програми з Application Battery. Сьогодні в цей пакет входять Apache, celestia, expect, groff, lynx, python, rsync, samba, tcl, xpaint і xpdf.

Для розробніків дістрібутівів є свой набор тестів и приклад реализации LSB-сумісного дистрибутива; він не є повнофункціональним і розробляється паралельно з LSB як «випробувального майданчика» для нових стандартів. Зрештою, LSB розроблявся як набір стандартів для широко поширених дистрибутивів, а не для їх адаптації (скажімо, з метою забезпечення роботи з вбудованими пристроями). Правда, в деяких випадках була б корисна сумісність з LSB спеціальних рішень, заснованих на GNU / Linux, оскільки в LSB є аспекти, які недоречні для таких випадків.

Як середовище спілкування і координації LSB використовує стандартні засоби, прийняті в проектах Free Software, - списки розсилки, IRC і CVS. Кожен, хто зацікавлений у розвитку бази стандартів для Linux, може взяти участь у проекті. Завдяки проведенню відкритих дискусій після прийняття чергової версії стандарту незгодних з тим чи іншим пунктом вимог майже не залишається. Крім того, незважаючи на чималий обсяг стандартів, колективна розробка сприяє тому, що вони не містять внутрішніх протиріч.

У LSB чимало переваг, які є значущими для розробників програмних продуктів для платформи Linux, таких як надійні рекомендації для створення гарного коду. На жаль, ще не всі поширені дистрибутиви сертифіковані на відповідність з LSB; з найбільш поширених слід назвати SuSE 9, Red Hat Enterprise Linux 3 і Mandrake Corporate Server 3.0. Серед постачальників спеціалізованих рішень відповідний сертифікат отримав заснований на Debian продукт Progeny Componentized Linux Core. У разі загального прийняття LSB додатки зможуть працювати на базі будь-якого дистрибутива Linux, а не розроблятися для певних поєднань апаратної платформи і дистрибутива. Акуратно визначаючи рамки сумісності додатків, LSB не загрожує основним ідеям Open Source і дає кожному розробнику свободу внесення нововведень в додатки при збереженні їх сумісності.

Петро Новодворский ( [email protected] ) - технічний фахівець центру компетенції Linux компанії IBM (Москва).

імена LSB

Стандарт LSB визначає рольові імена користувачів, які можуть застосовуватися в операційній системі. Обов'язкових користувачів всього три: root (адміністратор всієї системи) і два успадкованих користувача - bin і deamon. Необов'язкові користувачі і групи такі:

• adm - альтернативний адміністратор;
• lp - демон принтера;
• sync - облікове ім'я для синхронізації системи;
• shutdown - ім'я для виключення системи;
• halt - ім'я для припинення системи;
• mail - ім'я демона електронної пошти;
• news - ім'я демона системи поширення новин;
• uucp - ім'я демона пересилання електронної пошти по протоколу UUCP;
• operator (група root) - ім'я для позначення привілеїв оператора;
• man - ім'я демона форматування підказки;
• nobody - ім'я, яке використовується демоном NFS.

Всі ці імена дозволяють правильно налаштувати права доступу для різних підсистем Linux.