Журнал LinuxFormat - перейти на главную

LXF131:Тема номера

Материал из Linuxformat
Версия от 08:20, 17 мая 2011; Crazy Rebel (обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск
Доступно о Linux

Содержание

Вскроем Linux

Вы когда-нибудь задумывались о том, что такое DCOP, или где прячутся ваши драйверы? Погрузитесь с Грэмом Моррисоном в недра Linux в поисках ответов.

Основная проблема попыток забраться под капот Linux и понять, как он работает, состоит в неосведомленности, с чего начать. Перед вами — огромный пласт сложного ПО, разрабатывавшийся тысячами программистов. Разумно было бы рассмотреть последовательность загрузки и разобраться, что же такое делает Grub, а уж потом приниматься за инициализацию RAM-диска и загрузку ядра.

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

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

Уровень 1 Пространство пользователя

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

Перед погружением в недра Linux важно понять главную идею. Это – концепция, которая связывает пользовательское пространство [userspace], привилегии [privileges] и группы [groups] и управляет работой и поведением всей Linux-системы в целом, а также взаимодействием с ней пользователей. Концепция эта предполагает, что обычный пользователь не может внести в систему серьезных изменений, не доказав, что он обладает правами администратора, которые это позволяют. Потому-то вам и предлагают ввести пароль, когда вы пытаетесь установить новые пакеты или открываете панели управления конфигурацией вашего дистрибутива, и потому-то обычный пользователь не может видеть содержимого каталога /root или модифицировать некие файлы.

В любом дистрибутиве для доступа к настройкам в масштабах всей системы потребуется либо команда sudo, либо учетная запись с правами администратора. Sudo обычно работает в пределах одного сеанса или команды, и применяется в качестве ситуативного [ad-hoc] решения для повседневного использования, аналогично подходу других ОС, например, Windows 7 и Mac OS X. Правда, войдя в полноценную учетную запись администратора, легко нечаянно там засидеться и забыться так, что допустить роковую ошибку. Но цель у обоих методов одна – безопасность.

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

Linux – вариация на тему Unix, который многие десятилетия являлся одной из самых распространенных многопользовательских ОС в мире. А значит, многопользовательских функций в Linux избежать трудно; но это и одна из причин его популярности – ведь многопользовательские ОС просто обязаны быть защищены, и Linux унаследовал многие преимущества этих ранних решений. Например, в Linux учетная запись пользователя автономна. Все ваши персональные файлы хранятся в вашем домашнем каталоге; то же справедливо и для остальных пользователей системы. Имена пользователей, имеющих право доступа к данной системе, можно найти, просмотрев содержимое папки /home из менеджера файлов. В зависимости от прав доступа, иногда даже можно заглянуть в домашние папки других пользователей. Но только сам владелец файлов определяет, кому дается к ним доступ, а кто его лишен.

Полномочия

В файловой системе Linux у каждого файла и папки есть девять атрибутов, используемых для задания прав доступа к нему. Эти атрибуты указывают, может ли пользователь, группа или кто угодно читать файл, писать в него или запускать его на выполнение. Пусть вы хотите поделиться своими фото с прочими пользователями системы. Тогда создайте группу ‘photos’, добавьте в нее пользователей, по вашему мнению, достойных лицезрения, и выдайте этой группе права на доступ к папке – больше никто ваших снимков не увидит. Такая задача решаема в любом современном файловом менеджере: обычно достаточно будет выбрать папку и отредактировать ее свойства [Properties].

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

Шаг за шагом: Присоединимся к группе

Шаг 1

  • 1 Создадим группы
От имени администратора, откройте утилиту User Manager, переключитесь на страницу Groups и добавьте новую группу.

Шаг 2

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

Шаг 3

  • 3 Отредактируем файл
Теперь задайте через свой файловый менеджер свойства папки, которую вы хотите предоставить новой группе.

Уровень 2 Рабочие столы

Если Linux глубок, как Байкал, то рабочий стол – его сверкающая гладь.


Тем, кто попал в Linux не из серверного зала, а из мира Windows или Mac OS X, попытка объяснять, что такое рабочий стол, покажется диковатой. Все равно что объяснять «чайнику», что Microsoft Windows – операционная система; а он-то думал, что это компьютер! Видимо автор спутал термин "Рабочий стол", который безусловно знаком пользователям всех ОС, с термином "Оконный менеджер". Причем замену надо делать начиная от заголовка и до конца раздела.

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

Первый из них – так называемый программный интерфейс приложения (Application Programming Interface, API). Когда программист разрабатывает приложение, используя API рабочего стола, он получает все преимущества, предлагаемые рабочим столом: например, проверку орфографии или создание списка контактов для передачи другому приложению, основанному на том же API. Когда множество приложений использует один и тот же API, создается намного более однородная и непротиворечивая среда, чего мы и ожидаем от рабочих столов вроде Gnome и KDE. Скажем, K3b (http://www.k3b.org/) так хорошо работает с вашими музыкальными файлами, поскольку использует тот же API KDE, что и ваш музыкальный проигрыватель; то же относится и к приложениям Gnome.

Инструментарии

Приложения, предназначенные для конкретной среды рабочего стола, не обязаны использовать исключительно какой-то единственный API. Различных API, пожалуй, даже больше, чем дистрибутивов Linux, и они умеют делать все – от сложных математических выкладок до общения с аппаратурой. Здесь-то и звучат термины наподобие Clutter или Cairo: это дополнительные инструментарии, позволяющие программистам разрабатывать более унифицированные приложения. Например, при создании красивых интерфейсов пользователя с аппаратным ускорением графики для устройств с низким энергопотреблением в Ubuntu Netbook Remix и Moblin используется Clutter. Именно он обеспечивает прокрутку верхней панели в Moblin и эффекты «проявления» стартового меню в UNR. Cairo облегчает программистам создание векторных графических изображений, и по умолчанию используется как движок визуализации в GTK, базовом инструментарии рабочего стола Gnome, для большинства его значков. Векторная графика не привязывает изображение к конкретному разрешению экрана и допускает бесконечное масштабирование, благодаря чему идеальна для изображений, предназначенных для широкого диапазона устройств.

Межпроцессная коммуникация

Второй способ, которым нам содействует рабочий стол – межпроцессная коммуникация. Из названия этой технологии следует, что она помогает процессам «общаться» друг с другом; в среде рабочего стола это обычно взаимодействие между приложениями. Благодаря ему рабочий стол представляет собой единое целое. Например, ваш программный медиа-проигрыватель может узнать о подключении MP3‑плейера; или, скажем, ваше ПО для работы с беспроводной сетью пользуется системой уведомлений об обнаружении новой сети. В общем, межпроцессная коммуникация – причина того, что приложения GTK лучше работают в среде Gnome, а приложения KDE лучше работают в KDE. Но главное – то, что оба рабочих стола используют для межпроцессной коммуникации один и тот же совместимый метод: систему под названием D-BUS.

Так почему же тогда Gnome и KDE так непохожи? Отчасти потому, что используют разные оконные менеджеры. Идея оконного менеджера берет начало еще с тех лет, когда Unix-подобные системы только зародились из «первичного бульона» командных строк и начали отображать сеансы терминала в окнах. Можно было перетаскивать эти окна курсором по заштрихованному фону, открывать другие терминальные сеансы и так же манипулировать ими с помощью штуки, известной как TWM (Tom’s Window Manager). Умел он немногое, но все же освобождал пользователей от текстовых страниц. Окна можно было свободно перемещать по экрану, менять их размеры, распахивать на весь экран и размещать друг поверх друга.

То же делают и современные оконные менеджеры из Gnome и KDE. Оконный менеджер KDE, называемый KWin, дополнил возможности TWM рядом продвинутых функций: например, встраиванием любого окна в рамку, снабженную вкладками, привязкой приложений к заданной области экрана и еще более специфической привязкой конкретных приложений к собственным виртуальным рабочим столам. Кроме того, KWin создает массу сложных эффектов: дрожание окон, отбрасывание теней и отражений и т. д. – идея, впервые воплощенная в Compiz, еще одном оконном менеджере, который добавил не функции, а красоты динамического интерфейса в ранее статический мир оконных менеджеров. Compiz до сих пор является заменой по умолчанию для оконного менеджера Gnome (Metacity), и вы получите его на машине Gnome, активировав расширенные эффекты на панели Visual Effects. Вы увидите, что он плавно замещает стандартные процедуры отрисовки изображений аппаратно-ускоренными.

Обновления

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

Исключением из этого правила является ситуация, когда вы берете неофициальные пакеты. Ваш дистрибутив может должным образом поддерживать только пакеты, протестированные и выпущенные его кураторами [maintainers]. Часто это оплачиваемые специалисты, и задача проверки, подходит ли тот или иной пакет для включения в официальный дистрибутив, воспринимается разработчиками систем вроде Fedora очень серьезно. Если вы используете свой Linux-компьютер для критически важных задач, необходимо ограничиться только официально поддерживаемыми пакетами. Менеджер пакетов вашего дистрибутива установит их по умолчанию, и вы можете быть уверены, что при наличии проблем они будут исправлены. Именно это происходит, когда менеджер обновлений выскакивает с извещением о том, что один или несколько пакетов следует обновить. Обязательно дайте ему выполнить эту операцию.

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

Зависимости

Одно из серьезнейших затруднений для людей, перешедших на Linux – то, что нельзя просто загрузить исполняемый файл из Интернета, чтобы он сразу заработал. С другой стороны это безусловно благо, если вспомнить что половина заражений компьютеров пользователей Windows вирусами происходит именно так. Например, при выходе новой версии Firefox не получится просто скачать файл с http://www.mozilla.org, сохранить его на рабочем столе, дважды щелкнуть мышью и установить новую версию. Некоторые дистрибутивы близки к этому идеалу, но проблема остается. Она зависит от конкретного дистрибутива, и мы сейчас не ближе к решению, чем были 10 лет тому назад. Проблема коренится в зависимостях и в разнице способов, которыми дистрибутивы пытаются ее преодолеть.

Зависимость [dependency] – просто пакет, необходимый приложению для корректной работы. Обычно это API, примененные разработчиками при создании приложения, и они необходимы, потому что приложение использует часть реализуемых ими функций. Когда они упакованы таким образом, их называют библиотеками; приложение заимствует из библиотеки пару-тройку компонентов и добавляет их в состав своей функциональности. Скажем, Clutter является зависимостью и для Moblin, и для UNR, и его надо установить, чтобы оба этих рабочих стола могли работать. И хотя, например, Firefox выглядит самодостаточным приложением, на самом деле он имеет внушительный список зависимостей, в число которых входят Cairo, набор шрифтов TrueType и даже аудиодвижок.

Решая эту проблему, другие ОС связывают приложения с требуемыми ресурсами статически, то есть упаковывают в один файл все, что может потребоваться программе. Все зависимости скрыты в файле setup.msi (Windows) или DMG-файле (Mac OS X), дающем приложению или утилите все, что им надо для работы, безо всяких дополнений. Основной недостаток этого подхода в том, что в итоге в вашей системе появляется несколько версий одной и той же библиотеки. Во-первых, это отнимает дисковое пространство, а во-вторых, при обнаружении бреши в системе безопасности придется обновлять все приложения, а не одну библиотеку.

Шаг за шагом: Межпроцессная коммуникация в деле

Шаг 1

  • 1 Исследуем Kopete
Если вы запускаете Kopete в KDE, введите команду qdbus org.kde.kopete, чтобы просмотреть все данные, которые каждый из процессов может найти о Kopete.

Шаг 2

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

Шаг 3

  • 3 Сделаем нечто полезное
Попробуйте ввод следующей строки: qdbus org.kde.kopete /Kopete org.kde.Kopete.setOnlineStatus Away. D-BUS изменит ваш статус на «Отсутствует».

Уровень 3 Под поверхностью

Покинем безопасную графическую среду, чтобы понять, как работает Linux.


X – не самое умное название для системы, отвечающей за отрисовку окон на вашем экране и управление клавиатурой и мышью, но мы к нему привыкли. Как и серия имен языков программирования: B, C, C++ и C#, оконная система X получила такое имя потому, что ее предшественница называлась W (в чем все же имелась логика). Буквально с рождения Linux, оконная система X стала одним из важнейших компонентов операционной системы. Ее часто критикуют за сложность и размеры, но на свете очень мало программ, которые продержались бы почти 20 лет, особенно с учетом того, как сильно изменились за это время графика и GUI.

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

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

Здравому смыслу в данном случае противоречит то, что сервером является как раз терминал, устройство с экраном и клавиатурой, а клиентом – большая машина, где вся работа возлагается на CPU. Опять автор путает, сервером называют приложение выводящее изображение на экран, а клиентом - приложение которое чтото хочет вывести, и логика здесь совершенно четкая. В обычной среде клиент–сервер дела обстоят с точностью «до наоборот» – там сервером считается более мощная машина. И еще одно неверное утверждение, см хотя бы рукводство по сборке медиа-сервера из компьютера на выброс, опубликованного в LXF105 В системе X все перевернуто с ног на голову потому, что именно терминал доставляет ресурсы пользователю, а приложения потребляют их как клиенты.

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

Служба, управляющая аутентификацией при вашем входе в систему, называется PAM (Pluggable Authentication Modules, Подключаемые модули аутентификации). Как намекает ее название, PAM реализует множество типов схем безопасности за счет применения разных модулей. Аутентификация в этом смысле предоставляет способ защиты ваших регистрационных данных, гарантирующий их сравнение с информацией, хранящейся в файлах настройки, так, чтобы при этом процессе данные не подсмотрели и не скопировали. Если модуль PAM не может завершить процесс аутентификации, значит, реквизитам доверять нельзя. В большинстве дистрибутивов установленные модули располагаются в каталоге /etc/pam.d. Если вы работаете в Gnome, то существует как минимум один модуль для аутентификации вашего имени пользователя на экране Gdm, а также для выполнения автоматического входа в систему.

Имеются общие модули для управления стандартным приглашением к регистрации в командной строке, а также для таких популярных команд, как passwd, cvs и sudo. Все они используют PAM для удостоверения, что вы – тот, за кого себя выдаете, и поскольку модули PAM подключаемые, процедура аутентификации не всегда основана на паролях. Есть модули, настраиваемые на использование биометрических данных, например, отпечатка пальца, или аппаратного ключа шифрования (на базе USB-брелка). Подробнее об этом можно почитать на страницах LXF83 Самое замечательное в модулях PAM то, что их методы не связаны с тем, откуда вы аутентифицируетесь, а это значит, что можно свободно конфигурировать систему по своему вкусу.

Шаг за шагом: Туннелирование X через SSH

Шаг 1

  • 1 Изменим конфигурацию
Убедитесь в том, что в файлах настройки SSH на обоих ваших компьютерах активизированы AllowX11Forwarding и ForwardX11.

Шаг 2

  • 2 Установим соединение
Чтобы установить соединение с удаленным компьютером, введите команду ssh -X имя_пользователя@ip-адрес. В идеале, на этом компьютере не должнобыть запущено сеансов X.

Шаг 3

  • 3 Запустим графический сеанс
Для запуска графического сеанса через сеанс SSH, введите команду startx --:1 или попробуйте команду xclock &, если такой сеанс уже имеется.

Оболочки командной строки

Внутренними механизмами работы вашего компьютера управляют так называемые оболочки [shell]; они могут иметь как графический, так и текстовый интерфейс. До появления графических дисплеев, предоставляющих пользователям интерактивную среду для работы через сеть, нормой были текстовые дисплеи, и этот слой до сих пор остается жизненно важной частью Linux. Текстовые оболочки прячутся под GUI, и часто «выходят на поверхность», когда вам нужно выполнить специфическую задачу, не обеспечиваемую графическим интерфейсом.

Существует масса графических приложений, позволяющих открыть окно в мир командной строки. Приложения Terminal (Gnome) и Konsole (KDE) – только два из них, самые известные. Однако лучше всего в оболочках командной строки то, что для их использования вообще не нужен графический интерфейс. Возможно, вы уже знакомы с виртуальными консолями. Это приглашения к регистрации в системе, которые появляются, если нажать клавишу Alt и, удерживая ее в этом состоянии, нажать одну из функциональных клавиш (F1–F6). Если вы запустите виртуальную консоль и зарегистрируетесь, указав свое имя пользователя и пароль, в вашем распоряжении окажется полнофункциональный терминал, что особенно удобно, если ваш X-сеанс завершится аварийно и потребуется перезапустить его.

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

По умолчанию, если вы не установите систему X Window, большинство дистрибутивов перейдет к оболочке, известной как Bourne Again Shell или просто Bash. Bash – это интерфейс командной строки, который использует большинство из нас. Он позволяет выполнять скрипты и приложения из командной строки, находясь где угодно, в любой точке файловой системы. Если вы не боитесь лаконизма текстового интерфейса командной строки, то с его помощью вы выполните практически любую задачу.

Оболочек очень много, и каждая из них ориентирована на конкретный тип пользователей. Например, можно выбрать интерфейс в стиле программирования на C (C-Shell) или сверхмощную оболочку, позволяющую делать что угодно (Z-Shell). Однако базовые возможности у них одинаковы, и чтобы извлечь из них максимум, необходимо разобраться в файловой системе Linux.

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

Файловая система Linux – штука необычная. Она может представлять собой смесь локальных и удаленных файлов, работающих процессов и аппаратных устройств, и способна ошеломить новичка. Например, там нет папки ‘Program Files’, а все ваши личные файлы хранятся в соответствующем каталоге в /home. Приложения и библиотеки размещаются в разных директориях, обычно в дереве /usr или в /lib, но даже эти стандарты могут меняться в зависимости от дистрибутива. Самую серьезную проблему представляют файлы настройки. Они обычно находятся в каталоге /etc, но их названия и содержимое зависят от дистрибутива и меняются от версии к версии.

Еще больше путаницы вызывают виртуальные файлы и каталоги. Один из таких каталогов – /proc. С виду это обычный каталог, такой же, как любой другой. Но, взглянув на его содержимое, вы обнаружите экзотическую смесь из чисел, директорий и символических ссылок. При попытке определить, кто является владельцем файлов, через графический файловый менеджер или по команде ls -l /proc, вы увидите множество имен, в том числе системного администратора (root), ваше собственное и кучу других, включая демонов и фоновые задачи.

Причина тут в том, что каталог /proc – виртуальная файловая система. Все его файлы и папки на самом деле не хранятся на вашем жестком диске. Они созданы ядром, чтобы пользователи и приложения могли получать сведения обо всем изобилии процессов, аналогично доступу к файлам. Например, введя команду cat /proc/meminfo, вы увидите разнообразную информацию о конфигурации вашей памяти, включая объем памяти, свободной на данный момент. Команда cat /proc/cpuinfo покажет тип процессора, установленного на вашем компьютере. Числа, которые вы видите в этом каталоге – это идентификаторы всех работающих процессов для каждой из запущенных вами задач. Те же номера вы увидите при просмотре списка задач с помощью графического монитора системы или по команде top.

Мало того…

В каталоге /proc найдется любая информация о любой задаче. Например по команде cat /proc/1/cmdline вы увидите команду, запустившую первый процесс, /sbin/init.

Если вам нужна более общая информация, займитесь еще одной виртуальной файловой системой: /sys. Как и его эквивалент, относящийся к процессам, этот каталог полон виртуальных файлов и папок с данными о вашей системе. В него вложены директории block, bus, class, dev, devices, firmware, fs, kernel, module и power; каждая из них соответствует одному из компонентов системы, играющих принципиальную роль. block содержит информацию об устройствах-накопителях (также называемых «блочными»), а kernel позволяет увидеть, что именно происходит на самом низком уровне системы. devices же обеспечивает доступ к драйверам ядра, управляющих работой всех аппаратных компонентов, подключенных к компьютеру, что подводит к глубинам знаний о том, как управляются устройства и само ядро.

Уровень 4 Ядро и его друзья

Именно здесь живет Большой Босс Linux.


Мы спускаемся на нижние уровни операционной системы Linux, оставляя позади царство относительной простоты – взаимодействия с пользователем, графических интерфейсов, командных строк… Лучший способ объяснить все происходящее на нижнем уровне – пошагово рассмотреть процесс загрузки, от начала до момента выбора: запустить графический сеанс или начать работать с командной строкой. И в первую очередь (ну, после загрузчика и ядра) вы увидите init.

Процесс init, используемый большинством дистрибутивов, включая Debian и Fedora, для запуска всех остальных компонентов ОС, должен начать работу в тот момент, когда ядро Linux выполнит инициализацию своих внутренних структур и будет готово создавать пользовательские процессы. Он имеет долгую историю, и версия, используемая большинством дистрибутивов Linux – это sysvinit, являющаяся наследием Unix System V.

Запуска требует все – от Samba до SSH; процесс init выполняет запуски, «прочесывая» каталог со стартовыми скриптами и вызывая их в особом порядке, определяемом номером, с которого начинается имя скрипта. Состав исполняемых скриптов зависит от так называемого уровня работы (runlevel) вашей системы. Их различие определяется используемым дистрибутивом и особенно заметно между потомками Fedora и Debian.

Изучить их в действии можно, используя команду init для переключения уровней runlevel вручную. В системах на базе Debian, команда init 1 переводит систему в однопользовательский режим, а команда init 5 – в полномасштабный графический режим. А старые версии Fedora предлагают консоль без сетевых возможностей (runlevel 2), консоль с сетевыми возможностями (runlevel 3) и полномасштабный графический режим (runlevel 5), причем каждый процесс будет запущен в свою очередь, по мере загрузки системы. Это может создать узкое место, особенно когда один процесс ждет активизации сетевых сервисов. Каждый скрипт дожидается завершения предыдущего, и только после этого может начать работу, независимо от того, какие объемы системных ресурсов остаются в простое.

Если вы думаете, что система init здорово устарела, вы не одиноки. Так считают многие, и разработчики ряда дистрибутивов уже рассматривают переход с init на альтернативный вариант, upstart. Что следует упомянуть особо, дистрибутив, который в настоящее время спонсирует разработку upstart, Ubuntu, уже использует его по умолчанию в качестве загрузочного демона. То же самое делает Fedora, а разработчики Debian тоже объявили о намерении использовать upstart в следующем релизе своего дистрибутива.

Серьезным преимуществом upstart является асинхронный запуск скриптов. Это означает, что пока один из них ожидает появления сетевого соединения, другой в это время может настраивать аппаратную часть или инициировать X. Upstart будет использовать те же скрипты, что и init, но сделает процесс загрузки более быстрым и эффективным. Это – одна из основных причин, по которым последние версии Ubuntu и Fedora по сравнению со своими предшественницами загружаются намного быстрее.

Ядро

Итак, мы рассмотрели почти все, с одним, но очень крупным, исключением – самим ядром. Как уже говорилось, ядро отвечает за поддержку всех системных ресурсов и управление ими. Это «сердце» работающей системы Linux; именно оно делает Linux тем, что он есть. Ядро управляет файловыми системами и процессами, загружает драйверы, реализует сетевые средства, пользовательские пространства, управляет памятью и дисками. И, как ни странно, обычному пользователю здесь практически не на что смотреть. Кроме элементов, отображаемых при просмотре виртуальных файловых систем /proc и /sys, а также ряда процессов, работающих в фоновом режиме, большинство управляющих систем абсолютно прозрачны.

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

Чтобы увидеть, какие модули подгружены к ядру в данный момент, введите команду lsmod от имени системного администратора. Рядом с именем каждого модуля помещается список зависимостей – это другие программные компоненты, необходимые длякорректной работы модуля.

Модули зависят от ядра, и именно из-за этого ваш драйвер Nvidia может внезапно отказать, если ваш дистрибутив автоматически обновит ядро. Сборка модуля Nvidia GLX выполняется для текущей версии ядра, что и происходит при запуске инсталлятора. К счастью, можно установить несколько версий модуля, и каждая из них при выборе нового ядра из загрузочного меню Grub будет обнаруживаться автоматически – потому что все различные модули спрятаны в каталоге /lib/modules, который, в свою очередь, содержит дальнейшие каталоги, названные в соответствии с версиями ядра. Чтобы определить, какую версию ядра используете вы, скомандуйте uname -a.

В зависимости от вашего дистрибутива, вы можете найти множество модулей драйверов ядра в каталоге /lib/modules/версия_ядра/kernel/drivers. Просмотр этого каталога бывает полезен, если ваше оборудование распознается неправильно. Точно зная, какой модуль должно использовать аппаратное устройство, вы можете попробовать загрузить его командой modprobe с именем нужного модуля. Тогда может оказаться, что ваше устройство работает и не нуждается в дальнейшей настройке. Тем не менее, благоразумно будет просмотреть системные журналы и убедиться, что ваши аппаратные средства работают как полагается. Удалять модули из памяти можно с помощью команды rmmod; это пригодится в случаях, когда установщик драйвера Nvidia сообщает, что драйвер уже работает.

Iptables

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

Но, если вы привыкли к другим системам и хотите конфигурировать Iptables вручную, рекомендуем воспользоваться приложениями с графическим пользовательским интерфейсом, например, Firestarter или входящей в состав Ubuntu программой ufw. Они созданы специально для того, чтобы упростить настройку Iptables. Установив ufw, вы можете быстро активизировать брандмауэр, войдя в систему как root и введя команду ufw enable. Можно разрешать или блокировать конкретные порты с помощью команд ufw allow и ufw deny, или заменить порт именем сервиса, который вы хотите блокировать. Список сервисов, работающих в системе, находится в файле /etc/services, и при полной решимости вы можете использовать еще более дружелюбное клиентское приложение для настройки Iptables, установив пакет gufw.

Это еще не все…

Мы рассмотрели важнейшие аспекты операционной системы Linux, и надеемся, что теперь вы гораздо лучше понимаете, как взаимодействуют все эти компоненты. Одной из лучших черт Linux является свобода эксперимента: менять можно все. И это лучший способ изучить операционную систему и ее возможности – конечно, если вы не делаете этого в производственной обстановке. Тогда попробуйте запустить любимый дистрибутив в виртуальной среде, а если вам нужны помощь и пояснения, загляните на форумы LXF по адресу: http://www.linuxformat.ru/forum.

Grub

Grub появляется первым, еще до того, как начинает загружаться Linux. Обычно он запускается из главной загрузочной записи (MBR) вашего первого жесткого диска при старте компьютера. Кроме Linux, Grub может загружать Windows и Mac OS X, и обычно позволяет выбирать операционную систему из загрузочного меню. Как правило, конфигурация для каждой операционной системы хранится в загрузочном каталоге на разделе Linux. Именно оттуда вы можете изменять загрузочные параметры, доступные через меню, хотя большинство дистрибутивов предлагают и графический инструмент для упрощения этой процедуры.

Запись для Linux, например, указывает на двоичный образ ядра, а также на диск, где он находится. Это одно из отличий Grub от его предшественника, Lilo: Grub может читать разделы Linux на диске и загружать любой из найденных образов ядра. Благодаря этой возможности, загрузочное меню Grub интерактивно. Здесь можно менять различные загрузочные параметры, выбирать ядро для загрузки и раздел жесткого диска, с которого требуется выполнить старт системы. Для этого выделите в загрузочном меню нужную строку, нажмите клавишу E и отредактируйте текст с помощью встроенного редактора. В мультизагрузочной системе, не толь ко с Linux, но и с другими ОС, возможность настройки параметров может оказаться настоящим спасением.

После выбора Linux из меню загружается ядро Linux, которое берет на себя управление дальнейшим процессом. Именно на этой стадии на экране начинают появляться различные сообщения о ходе загрузки (если в вашем дистрибутиве они не скрыты). RAM-диск (initrd) копируется загрузчиком Grub в определенную область памяти и затем используется ядром как временная файловая система Linux, содержащая, например, драйверы жесткого диска и файловой системы для монтирования реального корневого раздела. После этого управление передается расположенному в нем «настоящему» процессу init.

Шаг за шагом: Создаем диаграмму загрузки

Шаг 1

  • 1 Установим пакет
Воспользуйтесь своим менеджером пакетов для установки bootchart. Это модифицирует файл настройки загрузчика Grub.

Шаг 2

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

Шаг 3

  • 3 Просмотрим диаграмму
Перейдите в каталог /var/log/bootchart и поищите там PNG-файл. В нем отображается точная информацию о том, что именно загружается и когда.
Персональные инструменты
купить
подписаться
Яндекс.Метрика