Zenbook. Это должен знать каждый

Алексей Федорчук

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

Содержание

Введение

Принято считать, что для установки Windows знать ничего не нужно, тогда как Linux предъявляет очень высокие требования к начальной подготовке пользователя. Оба эти мнения, мягко говоря, спорные. Пользователю современных Windows’ов (XP и Vista), впервые устанавливающему эту систему, не худо бы иметь представление, по крайней мере, о трёх вещах — дисковых разделах, файловых системах и пользовательских аккаунтах.

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

Для потенциальных пользователей Zenwalk’а первоначальный минимум имеет свою специфику. С одной стороны, его инсталлятор не уступает по «дружелюбию» ни одному другому, самому любвеобильному. И потому устанавливает для входящего ничуть не более высокую планку, чем Mandriva или Ubuntu.

С другой же стороны, Zenwalk — это всё-таки трамплин для погружения в глубины Linux’а, и потому чем больше изначально будет знать его потенциальный пользователь, тем лучше. Может быть, его «лишние» знания не будут востребованы в ходе установки, но наверняка пригодятся в дальнейшем.

Исходя из этого «диалектического противоречия», я решил собрать такой оптимум начальных сведений, может быть, не жизненно необходимых начинающему пользователю Zenwalk’а сразу, но более чем желательных для него в последующем. Они включают в себя всё те же представления о:

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

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

Но прежде чем переходить к очерченному выше кругу вопросов, необходимо рассказать о краеугольном понятии не только Linux’а, но и всех Unix-подобных операционных систем —

О файлах

Ответить на вопрос, что такое файл в Unix-подобной системе, очень легко: это всё, что в ней существует: собственно файлы в понимании DOS/Windows, объединяющие их каталоги, устройства и многое другое. Даже протекающие в системе процессы и каналы обмена данными между ними тоже предстают перед пользователем в виде файлов. То есть образ файла есть универсальное понятие, обеспечивающее доступ к устройству Unix-подобной системы.

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

И так, среди файлов в Linux выделяются:

  • каталоги (directory) — списки имен файлов любого типа (в том числе и каталогов более глубокого уровня вложенности);
  • символические ссылки (symlinks) — указатели на файлы любого иного типа; содержание символической ссылки представляет просто описание пути к некоторому другому файлу; нечто подобное в Windows именуется ярлыками; на один и тот же файл может существовать сколько угодно символических ссылок:
  • файлы устройств — имена, присваиваемые действительно существующим в системе физическим устройствам (или могущим существовать в ней), от дисков до принтеров и сканеров; выделяются файлы символьных устройств, обмен данными с которыми происходит побайтно (например, последовательные и параллельные порты), и файлы устройств блочных, которые взаимодействуют с окружающим миром наборами байтов — блоками (жесткие диски и прочие накопители);
  • именованные каналы (pipes) и сокеты (sockets) — через них осуществляется взаимодействие между протекающими в системе процессами);
  • обычные (regular) файлы — всё, что не вошло в перечисленные выше группы; среди обычных файлов можно выделить текстовые, образованные наборами символов, и бинарные, представляющие собой наборы последовательностей нулей и единиц.

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

Основы командного интерфейса

Далее в этой интермедии (и во всей остальной книжке тоже) нам время от времени придется иметь дело с командами. И потому именно сейчас уместно рассмотреть основы командного интерфейса, так называемого CLI (Command Line Interface).

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

Командная директива (или просто команда) — основная единица, посредством которой пользователь взаимодействует с шеллом. Она образуется по определенным правилам, именуемым синтаксисом. Синтаксис командной директивы определяется конкретным шеллом; ниже речь будет идти только о sh-совместимом синтаксисе, свойственном, в частности, командной оболочке bash принятой по умолчанию во всех дистрибутивах Linux, в том числе и в Zenwalk.

Командная директива образуется:

  • именем команды, однозначно определяющим ее назначение,
  • опциями, определяющими условия выполнения команды, и
  • аргументами — объектами, над которым осуществляются действия.

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

Еще один непременный компонент командной директивы — это специальный невидимый символ конца строки: именно его ввод отправляет команду на исполнение. В обыденной жизни этот символ вводится нажатием и отпусканием клавиши Enter. Почему обычно и говорят: для исполнения команды нажмите клавишу Enter. Тот же эффект, как правило, достигается комбинацией клавиш Control+M. Конца командной строки, знаменующего исполнения команды, мы на экране не видим. Однако важно, что это — такой же символ, как и любой другой (хотя и имеющий специальное значение).

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

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

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

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

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

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

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

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

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

Большинство команд допускает указание не одного, а нескольких (и даже очень многих) аргументов.

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

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

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

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

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

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

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

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

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

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

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

При конвейеризации команд стандартный вывод первой команды передается не в файл, а на стандартный ввод следующей команды. Оператор конвейеризации — одинарная вертикальная черта (|).

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

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

  • создать командную конструкцию, достойную увековечивания;
  • поместить ее в простой текстовый файл, который начинается с такой строки: #!/bin/bash (она явным образом задает командный интерпретатор, который будет обрабатывать скрипт, в данном случае — bash);
  • присвоить этому файлу право исполнения (для пользователя, создавшего файл, или для всех — см. раздел об аккаунтах).

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

Диски и дисковые разделы

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

Схема дисковой разметки — это правила дробления диска на разделы. Диски в машинах с архитектурой PC (то есть во всех обычных настольных персоналках) могут быть разделены на четыре физических части — так называемые первичные разделы, Primary Partition (почему именно так — здесь обсуждать не будем). Один из этих первичных разделов может быть определен как раздел расширенный (Extended Partition). А уж он может далее делиться на логические разделы (Logical Partition) в практически неограниченном количестве. На самом деле ограничение есть, и оно составляет 63 логических раздела, но я не представляю себе разумной схемы, способной использовать их все.

Строго говоря, на диске присутствует и ещё один элемент — главная загрузочная запись (MBR — Master Boot Record). Занимая первый физический блок диска (512 байт), она не принадлежит ни к одному из первичных разделов. Но именно в ней записывается информация о них. А также — та информация, которая позволяет загрузить с этого диска установленную на нём систему. Впрочем, подробнее об этом будет говориться в главе О загрузке и загрузчиках. Пока же достаточно запомнить сам факт существования MBR — это потребуется в главе про Инсталляцию.

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

Так вот, некогда в природе существовало только два типа дисковых интерфейсов — IDE и SCSI. Все устройства с интерфейсами первого типа (точнее, конечно, не сами устройства, а соответствующие им файлы) именовались /dev/hda, /dev/hdb (Master и Slave на 1-м канале IDE), /dev/hdc и /dev/hdd (они же на 2-м), и, при наличии дополнительных IDE-контроллеров, так далее. Независимо от того, были ли они жесткими дисками, CD-приводами или, например, Zip-накопителями.

Диски с интерфейсом SCSI величали /dev/sda, /dev/sdb и так далее (очевидно, что для них понятие канала смысла не имело). Причём в эту же линейку имен попадали и файлы любых накопителей с интерфейсом, отличным от IDE, например, внешние диски с USB и FireWire-интерфейсами, флэшки, встроенные и съемные накопители цифровых фотокамер (почему — тайна сия велика есть). А вот CD-приводы со SCSI-интерфейсом назывались иначе — /dev/sr0 и /dev/sr1.

Для CD-приводов любых типов в каталоге /dev, содержащем имена файлов устройств, имелся и специальный файл — /dev/cdrom. Однако он представлял (и поныне представляет) собой символическую ссылку на имя файла реального устройства, например, /dev/hdc.

Дисковые разделы идентифицировались их порядковыми номерами. Цифры с 1 по 4 были зарезервированы за первичными разделами, включая и тот из них, который был определен как расширенный. А логические разделы внутри него нумеровались, начиная с цифры 5. Таким образом, если на мастер-диске первого IDE-канала имелось два первичных раздела, второй из которых определен как расширенный и поделен на три логических, то соответствующие им файлы устройств именовались так:

  • /dev/hda1 — первичный раздел;
  • /dev/hda2 — первичный раздел, определенный в качестве расширенного;
  • /dev/hda5, /dev/hda6 и /dev/hda7 — логические разделы внутри него.

Перечисленные выше файлы устройств (в нашем случае — накопителей, но в принципе всех устройств вообще) создавались статически, при установке системы, вне зависимости от того, имелись ли соответствующие им устройства в реальности или нет — как бы про запас. Это разработчикам ядра Linux’а показалось излишеством, и они перешли на систему динамического создания файлов устройств с помощью специальной файловой системы устройств — devfs.

И сначала подумали kernel-разрабы, что это хорошо: файлы в каталоге /dev создавались только для устройств, реально существующих в системе, в том числе и съемных. Поначалу это понравилось и пользователям (хотя их никто не спрашивал — но ведь разработчики Linux’а такие же его пользователи, как и все остальные). Действительно, теперь при подключении нового устройства, для которого изначально не было предусмотрено собственного имени файла, не нужно было запускать специальный сценарий создания файлов устройств или, паче того, создавать этот файл вручную, с помощью соответствующей команды, и при этом помнить о допустимых старших и младших номерах устройств (в двух словах — это численные идентификаторы каждого имени файла устройства, а не в двух — нас это более не волнует, хотя сами major- и minor-номера никуда не делись). Да и содержимое каталога /dev можно было охватить если не одним взглядом, то двумя-тремя (в прежние времена для этого нужно было быть стойким Аргусом).

Однако прошло немного времени, и в devfs разочаровались все — и разработчики, и пользователи. У первых резонов к тому было очень много, и останавливаться на них я не буду. А для пользователей основные неудобства сводились к двум моментам.

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

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

  • /dev/ide/host0/bus0/target0/lun0/part1 — первый раздел на первом IDE-диске,
  • /dev/ide/host0/bus0/target0/lun0/part2 — второй раздел на нем же,
  • /dev/ide/host0/bus0/target0/lun0/part5 — первый логический раздел

и так далее. Что это всё значит, расшифровывать не буду, поскольку это давно изжито. Правда, был и менее устрашающий вариант, с обозначением разделов как /dev/discs/disc0/part1, /dev/discs/disc0/part2 и так далее — с тем же значением. А в ряде дистрибутивов сохранилась и старая добрая простота — /dev/hda1 и так далее. Правда, не для сохранности нервов пугливых пользователей, а для понимания программами, разработчики которых так и «ниасилили» devfs. Но в итоге каталог /dev утратил свою обозримость и стал похож не на ветку (файлового) дерева, а скорее на переплетенный терновый куст.

Думаю, читатель уже догадался, что файлы устройств вроде /dev/discs/disc0/part1 или /dev/hda1 — не более, чем символические ссылки на истинные имена, то есть /dev/ide/host0/bus0/target0/lun0/part1. Отчего, впрочем, разбираться с ними не легче. Да и на стадии инсталляции ряда дистрибутивов, таких, например, как Gentoo, когда ошибка в именовании дискового раздела может иметь печальные последствия, этим символические ссылки часто отсутствовали, заставляя пользователя вбивать руками столь устрашающие конструкции.

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

Для нас сейчас важно только то, что отныне (и хочется верить, что присно, и вовеки веков) IDE-диски, их разделы и CD-приводы снова стали файлами устройств вида /dev/hda, /dev/hda1, /dev/hdc, SCSI-диски и всякого рода «левые» накопители — /dev/sda и так далее.

Распространившиеся в это же примерно время диски с интерфейсом SATA также виделись программой udev как SCSI-диски (то есть /dev/sda etc.), а SATA-CD-приводы — как устройства /dev/sr0. И это не лишено логики, потому что по принципам своей работы SATA ближе к интерфейсу SCSI, чем к классическому IDE/ATA, который ныне обычно называют PATA.

Таким образом, жить стало проще, стало веселей. Однако это был еще не предел упрощения. Потому что появилась подсистема libata. Сначала она была ориентирована только на SATA-накопители, но позднее к ней прикрутили поддержку PATA. И теперь при использовании libata все диски, независимо от их интерфейса, именуются — /dev/sda, /dev/sdb и так далее. А оптические приводы получают имена типа /dev/sr0 и далее (если это «далее», конечно, есть). Именно таким образом и сконфигурирован Zenwalk, точнее, его ядро, которое грузится при старте с инсталляционного CD и в дальнейшем устанавливается на диск.

Так что всё, что нам надо запомнить для PATA-накопителей, можно представить в небольшой таблицы (табл. 1).

Таблица 1. Пример именования PATA-устройств

Канал Диск Имя файла
1-й IDE Master /dev/sda
Slave /dev/sdb
2-й IDE Master /dev/sdc
Slave /dev/sr0

Примечание: предполагается, что слейвом на 2-м IDE-канале является CD-ROM.

Для SATA-накопителей картина будет еще проще (табл. 2).

Таблица 2. Пример именования SATA-устройств

Разъём Имя файла
1-й /dev/sda
2-й /dev/sdb
3-й /dev/sdc
4-й /dev/sr0

Понятно, что никаких мастеров и слейвов мы не видим. А последний разъём SATA, как и в предыдущем случае, занят CD-приводом.

И, наконец, резюмируем и разговоры про номенклатуру разделов (табл. 3).

Таблица 3. Пример номенклатуры разделов

№№ Имя файла Тип раздела
1 /dev/sda1 Первичный
2 /dev/sda2 Первичный
3 /dev/sda3 Расширенный
/dev/sda5 Логический
/dev/sda6 Логический
/dev/sda# Логический
4 нет Не определён

Как можно видеть, первый же по счету логический раздел внутри расширенного получает имя /dev/sda5, несмотря на то, что 4-й из возможных первичных разделов не определён, и файл устройства, который мог бы ему соответствовать, отсутствует.

Для создания (и удаления) дисковых разделов в Linux предназначена специальная утилита — fdisk. Это — тот жупел, которым из поколения в поколение пугали начинающих пользователей Linux. Хотя на самом деле ничего непреодолимо сложного в ней нет — просто она требует определенной аккуратности. И, кстати говоря, лишь в редких дистрибутивах (например, в Gentoo) она непосредственно используется при установке. Обычно же инсталлятор содержит какое-либо «продвинутое» средство дисковой разметки — от простейшего cfdisk до весьма изощренных DiskDruid, DiskDrake или того безымянного самого по себе инструмента, который используется для дисковой разметки в Debian Installer.

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

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

Файловые системы

Разделы создаются обычно не сами по себе, а для того, чтобы нести на себе некие файловые системы (исключение — раздел подкачки, о котором речь пойдет позже). Файловая система — термин очень многозначный: под ним понимают и способ физического размещения информации на диске, и логическую структуру файлов и каталогов, и систему ядра, отвечающую за файловые операции. О последнем значении мы говорить здесь не будем вообще. А сам термин «файловая система» будем использовать только в первом смысле, закрепив за логической структурой термин «файловая иерархия» (о ней речь пойдет в следующем разделе).

В отличие от Windows, способной работать только с FAT любого рода и с NTFS, Linux в качестве «родных» (native) поддерживает большое количество типов файловых систем: ext2fs, ext3fs, ReiserFS, XFS и JFS. В стадии разработки находится ряд новых, иногда — принципиально новых файловых систем, таких как ext4fs (дальнейшее развитие ext2 и ext3) или Btrfs, интегрирующая в себе управление логическими томами и собственно файловую систему. Однако для практического применения они пока не предназначены, и в ядро Linux их поддержка  включена в качестве экспериментальной.

Файловая система ext2fs — старейшая из используемых в Linux. Отличается исключительным быстродействием, совместимостью и достаточно надежна для использования на десктопе. Правда, после системных сбоев (например, по питанию) она обязательно должна проходить проверку целостности, что при современных объемах дисков может занять изрядное время. Да и вероятность повреждения данных не равна нулю. Так что использовать её следует только при наличии источника бесперебойного питания.

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

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

Конёк ReiserFS — работа с большим количеством маленьких и очень маленьких (в несколько байт) файлов, а таких файлов в любой Unix-системе очень даже много. XFS, напротив, ориентирована на работу с (очень) большими файловыми системами и отдельными файлами мультимедийной направленности, размер которых вполне может составлять не один гигабайт. Ну а JFS, разработка фирмы IBM, — это эпоним журналируемых файловых систем, с нее-то и началось понятие журналирования. Впрочем, никакими другими достоинствами ее Linux-реализация не отмечена, являясь, пожалуй, самой медленной из всего семейства.

В некоторых дистрибутивах одно время включалась поддержка файловой системы Reiser4 (в их числе был и Zenwalk в версиях с 1.3 по 2.8). Это — дальнейшее развитие ReiserFS, представляющее собой уже не только (а может быть, и не столько) файловую систему, а так называемое «пространство имен» (Namespace) для манипулирования дисковыми объектами. Впрочем, официально Reiser4 ядром Linux пока не поддерживается, и я не знаю ни одного из ныне развиваемых дистрибутивов, в котором она поддерживалась бы «из коробки». Ну, а будущее Reiser4 остаётся совершенно неопределённым.

Впрочем, свято место пусто не бывает — и ныне на роль наиболее прогрессивных файловых систем Linux-мира претендуют:

  • ext4fs — дальнейшее развитие линии ext2/ext3, впрочем, уже не совместимое со своими прдшественницами, но зато нативно поддерживаемое ядром решение, грозящее скоро стать умолчальным;
    tux3 — создаваемая на протяжении долгого времени файловая система, далёкая, однако, от завершения и по сей день;
    ZFS — замечательная файловая система, созданная Sun для ОС  Solaris, используемая по умолчанию в OpenSolaris и портированная на FreeBSD, к сожалению, нативной поддержки в Linux не имеет по лицензионным ограничениям, но доступна через механизм FUSE (что это такое — история совсем особая);
    наконец, btrfs — светлое будущее всех линуксоидов, которой посвящён специальный цикл заметок.

Давать советы по выбору файловой системы — занятие неблагодарное. Поэтому рискну дать небольшую наводку. По моему скромному убеждению, будущееLinux-мира — за файловой системой btrfs. Но сей же момент использовать её для хранения мало-мальски важных данных было бы рискованно. Это раз. Два — существуют и реально работают, как показано в соответствующем цикле, средства конверсии файловых систем ext2/ext3  в btrfs и обратно. Так что выбор напрашивается сам собой, а детали будут рассмотрены в одной из ближайших глав.

Для создания файловых систем (процесса, именуемого в DOS/Windows форматированием) предназначены специальные утилиты — mkfs.ext2, mkfs.ext3, mkfs.reiserfs, mkfs.xfs и mkfs.jfs, каждая из которых создает соответствующую файловую систему. Кроме того, существует универсальная утилита mkfs: вызванная с соответствующими опциями (какими — описано в man mkfs), она способна создать любую файловую систему из числа поддерживаемых в Linux (включая FAT16/VFAT/FAT32, но не NTFS).

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

Кроме собственно файловых систем, на одном из дисковых разделов, как правило, размещается еще и так называемое пространство своппинга (подкачки). Оно предназначено для перемещения на него, при необходимости, содержимого оперативной памяти — например, в случае ее переполнения. Собственно говоря, в Linux существует понятие виртуальной памяти — совокупности физической RAM и пространства своппинга, которые, с точки зрения пользователя (и пользуемых им программ), образуют неразрывное единство.

Раздел подкачки создается специальной утилитой — mkswap, после чего нуждается в активации — это делается командой swapon. Впрочем, практически во всех инсталляторах (яркое исключение — опять-таки Gentoo) и то, и другое выполняется прозрачно для пользователя — достаточно соответствующий раздел определить как раздел подкачки.

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

Об одной из таких виртуальных файловых систем мы уже говорили — это злополучная devfs, ныне благополучно изжитая. Но в Linux сохранилась (или добавилась) поддержка иных файловых систем — procfs, sysfs и tmpfs. Первые две пользователь может видеть только как наблюдатель, получая из них информацию о протекающих в системе процессах и наличных устройствах. Кстати, программа udev также черпает сведения, необходимые ей для создания файлов устройств, из файловой системы sysfs.

А вот файловой системой tmpfs пользователь в какой-то мере может манипулировать. Это — файловая система в оперативной памяти, во всём подобная «всамделишней», в частности, на неё можно записывать данные и удалять их, причем, поскольку и то, и другое выполняется без обращения к относительно медленным дисковым устройствам, делать это очень быстро. Однако, как и любая виртуальная файловая система, она существует только до тех пор, пока машина работает. Поэтому tmpfs широко используется там для хранения всякого рода временных данных.

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

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

Именно такая технология используется в установочных дисках дистрибутива Zenwalk сначала на стадии инсталляции, а потом и на работающей системе, если пользователь не внесёт в неё свои изменения. Что отнюдь не возбраняется, но требует определенных знаний, которые, надеюсь, будут приобретены со временем.

Файловая иерархия и её монтирование

И, наконец, файловая иерархия. Сколько бы ни было в системе дисковых разделов и файловых систем на них, для пользователя они предстают в качестве логически единой иерархически устроенной файловой системы древовидного облика (правда, дерево это выглядит поставленным с ног на голову). В основании ее лежит корень (root, символически обозначаемый как /). Обязательными же ветвями являются каталоги — /boot (в нем хранится всё необходимое для загрузки системы, включая её ядро), /bin и /sbin (место помещения исполняемых файлов общесистемных программ), /etc (каталог для общесистемных конфигурационных файлов), /dev (каталог для файлов устройств, о которых недавно шел разговор), /var и /tmp (каталоги для всякого рода регулярно изменяемых данных), /usr, где имеет место быть большинство пользовательских программ со всем сопровождающим их инвентарем типа библиотек и документации, /home — место пользовательских каталогов для данных.

Перечисленные ветви вовсе не обязаны быть единой частью файловой системы в физическом смысле. Напротив, каталог /home почти всегда лежит на отдельном дисковом разделе, отдельные физически файловые системы часто составляют и такие ветви, как /usr, /var и /tmp. Возможно и много более дробное разбиение файлового древа.

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

$ mount -t vfat /dev/hda1 /mnt

включит в файловую иерархию Linux, в каталог /mnt, раздел Windows с файловой системой VFAT или FAT32.

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

Кроме упомянутой выше опции -t, определяющей тип файловой системы, команда mount имеет еще массу опций (см. man mount). И «дюже умные» инсталляторы подчас предлагают, кроме создания раздела, файловой системы, определения точки монтирования, еще и включить те или иные из них (о чем поговорим подробнее в следующем разделе).

Как правило, инсталлятор распознает и «чуждые» файловые системы, такие как FAT любого рода и, в некоторых случаях, NTFS, и также обеспечивает (по умолчанию или после запроса и подтверждения пользователя) их автоматическое монтирование.

Файловые системы, расположенные на сменных носителях (CD, DVD, флэш-драйвы, внешние винчестеры с интерфейсом USB или FireWire и так далее — вплоть до встроенных и сменных накопителей цифровых камер), при старте системы не монтируются. Этот выполняется по мере надобности — с помощью упомянутой выше команды mount. Однако инсталляторы, как правило, в силах установить наличие, по крайней мере, CD/DVD-приводов (еще бы, ведь, скорее всего, дистрибутив с них и устанавливается) и создать в /etc/fstab запись, обеспечивающую монтирование по упрощенной форме, например

$ mount /mnt/cdrom

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

  • имя файла устройства или дискового раздела;
  • точка монтирования;
  • тип файловой системы;
  • опции монтирования — для временно используемых файловых систем это поле должно иметь значение noauto, запрещающее монтирование при загрузке системы, и, скорее всего, user (через запятую), разрешающее монтирование от лица обычного пользователя; по умолчанию это имеет право сделать только root;
  • условия проверки и «дампа» — для временно используемых файловых систем тут можно ограничиться нулями.

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

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

Если в течение рабочего сеанса возникнет потребность, например, сменить компакт в CD-приводе или извлечь флэш-драйв — размонтирование нужно выполнить явным образом, командой umount. Которая в любом случае потребует одного аргумента, точки монтирования или имени файла устройства.

Во многих современных дистрибутивах к редактированию файла /etc/fstab, ручному монтированию и размонтированию устройств приходится обращаться только в исключительных случаях. Корректным монтированием файловых систем при старте системы, как уже говорилось, озаботится программа установки. Что же до сменных носителей — их монтирование обеспечивается механизмом HAL (Hardware Abstration Layer), в результате чего сменные носители монтируются прозрачно для пользователя — сразу же при подключении соответствующего устройства или вставки носителя в привод.

Правда, отключение сменных носителей при использовании механизма HAL потребует от пользователя некоторых манипуляций. А именно — щелчка правой клавишей на пиктограмме рабочего стола, соответствующего CD/DVD или флэш-драйву (USB-винчестеру), и выбора из появившегося контекстного меню — в первом случае пунктов Отмонтировать и затем Извлечь, во втором — пункта Безопасно извлечь. Правда, для CD-приводов в большинстве случаев тот же результат достигается и просто нажатием на кнопку открытия лотка.

Механизм HAL не использует описаний из файла /etc/fstab, и потому никаких дополнений в него вносить не нужно, более того, они могут лишь помешать его работе.

Именно такая схема обращения со сменными носителями используется в дистрибутиве Zenwalk. Точнее, в используемой им по умолчанию рабочей среде Xfce — в отличие от команды mount, представляющей собой часть системного окружения ядра, механизм HAL является атрибутом не системы, а именно интегрированных рабочих сред (GNOME, KDE, Xfce). Поэтому в «голой» консоли, без загрузки какого-либо из перечисленных выше десктопов, никакого автоматического монтирования и размонтирования не будет. Как и в случае, если рабочая среда будет заменена каким-либо менеджером окон.

Практикум по разметке и монтированию

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

Для начала определимся — сколько разделов необходимо для установки Linux? Обязательными считаются два — под корневую файловую систему и под своппинг; именно такая схема разметки предлагается многими инсталляторами по умолчанию. Современные дистрибутивы обычно требуют в типовой установке не менее 2-3 Гбайт дискового пространства — и это без учета пакетов, которые, возможно, придется доустанавливать впоследствии. Так что отвести под Linux 5-7 Гбайт при нынешних объемах дисков будет не внапряг — я последнее время, дабы не ломать голову рассчетами, отдаю под это 10 Гбайт. Что же до раздела подкачки — его размер традиционно определяется равным удвоенному объему оперативной памяти и, опять-таки во избежание ломки головы, остановимся на этой величине.

Часто можно услышать мнение, что при типичных современных объемах оперативной памяти (от 1 Гбайт и более) раздел подкачки не нужен вообще. Резон в этом есть — при указанных объемах памяти своппинга в штатных ситуациях практически не происходит никогда. Однако, возможно, в последующем вам может захотеться использовать файловую систему в оперативной памяти — tmpfs — и задействовать ее, например, под промежуточные продукты компиляции. А поскольку оценить потребное под них место весьма трудно (OpenOffice.org, например, желает под это дело несколько гигабайт), возникает риск переполнения соответствующей файловой системы.

Так что повторюсь еще раз: не стоит жмотничать, и лучше отдать под раздел подкачки один-другой гигабайт, нежели потом сожалеть о его отсутствии. Единственное ограничение касается случая, если оперативной памяти ну очень много (более 2 Гбайт — ныне это уже не фантастика, а реальность). Дело в том, что 32-битные версии Linux’а (а Zemwalk именно таков) не поддерживают объем виртуальной памяти (то есть RAM+Swap) более 4 Гбайт (на самом деле лимит ещё ниже, около 3,3 Гбайт), так что раздел подкачки в 4 Гбайт просто не будет использован.

Вернемся, однако, к корню файловой иерархии. Широким жестом отведя под него 5, 7 или даже 10 Гбайт, мы не учли одного: собственно пользовательских данных (а не ради них ли все и затевалось?). А потому под них нужно выделить собственный раздел (и, возможно, не один — см. ниже). Какого размера? Вам виднее, сколько данных у вас имеется (и предвидится). Обычно тут руководствуются одним из трёх принципов — сколько нужно, сколько есть или сколько не жалко.

Итак, приходим к выводу о необходимости трех разделов — под корень, под своппинг и под каталог /home. Однако это не предел дискодробительства: в ряде случаев на отдельные разделы целесообразно вынести такие ветви файлового древа, как /usr, /var и /tmp, а иногда и еще более глубоко лежащие каталоги, вроде /usr/local (для самостоятельно собираемых пользователем пакетов) и /usr/src (для исходников ядра и, как в Zenwalk’е, также и всех пакетов, устанавливаемых штатным образом).

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

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

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

В-третьих, в дистрибутивах типа Zenwalk, где нет необходимости в хранении таких вещей, как дерево портов, множества скачанных дист-файлов к ним и тому подобного антуража Source Based дистрибутивов, дробное разбиение диска под общесистемные каталоги просто не нужно.

А вот каталог /home целесообразно разбить на несколько подкаталогов, каждый на своем разделе. Почему это удобно? Ответить нетрудно. Сами по себе пользовательские каталоги представляют собой отдельные ветви каталога /home, имеющие вид /home/username1, /home/username2 и так далее. И основное их содержание — это так называемые dot-файлы, содержащие пользовательские настройки различных утилит и приложений. Они далеко не всегда создаются лично пользователем, но обычно возникают сами собой — при первом запуске соответствующей программы. Они совсем небольшие, но их очень много, и отыскать среди них собственно файлы и каталоги с пользовательскими данными нелегко.

Поэтому я последнее время отказался от выделения раздела под каталог /home — все пользовательские каталоги (впрочем, у меня их обычно всего два) лежат в общем дереве корневой файловой системы. Вместо этого я создаю в каталоге /home подкаталоги типа /home/works, /home/soft, /home/docs, /home/media (для рабочих материалов, скачанных из сети программ и дистрибутивов, документации и всякой мультимедии соответственно). И в каждый из них монтирую файловую систему на собственном разделе. Нужно только не забывать устанавливать для них соответствующие права доступа для обычного пользователя (пользователей), о чем будет сказано со временем.

Кроме того, при некоторых обстоятельствах может понадобиться ещё и небольшой (в диапазоне 30-100 Мбайт) раздел в самом начале диска. В качестве загрузчика Zenwalk, как мы увидим со временем, использует Lilo. Однако если планируется использовать на машине много (более двух) операционных систем или активно экспериментировать с разными ядрами, то целесообразно заменить его загрузчиком GRUB, а для него такой специальный раздел, задействуемый под каталог /boot, будет далеко не лишним.

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

Какие разделы создавать под Linux — первичные или логические? Если ограничиться минимально необходимыми — /, swap, /home, — это значения не имеет: три раздела можно сделать и первичными (и еще один Primary Partition останется про запас — например, для Windows).

Однако если прибегнуть к более дробной схеме разметки или использовать более двух операционок, практически неизбежным становится создание логических разделов в Extended Partition. Причем никаких ограничений на их использование давно уже нет — на логических разделах могут лежать и корневая файловая система, и swap, и даже /boot (не говоря уже о всех прочих). Правда, /boot разработчики GRUB’а рекомендуют все же помещать на первичный раздел, причём монтировать его не автоматически, при старте системы, а руками — по мере возникновения потребности (например, для установки нового ядра.

Файловые системы… Тут есть немало поводов поломать голову. Если, конечно, не следовать умолчаниям инсталлятора. А он, скорее всего, предложит нынче по умолчанию ext3fs для всех ветвей файлового древа. С этим можно смело соглашаться — это будет вполне разумным (хотя и не всегда идеальным) выбором, особенно для корневой файловой системы. Выбор же файловых систем для ветвей каталога /home — вопрос скорее привычки и личных препочтений. Так, под каталог для рабочих материалов есть смысл задействовать ReiserFS, на раздел для мультимедийных файлов поместить XFS и так далее.

Выше упоминалось об опциях монтирования. На данном этапе нас интересуют лишь некоторые из них (а имя им — легион). Это — опции noatime и nodiratime, запрещающие обновлять время последнего доступа к файлам и каталогам соответственно, что на десктопе мало для чего нужно. Это несколько способствует повышению быстродействия файловых операций в любом случае. А для файловой системы ReiserFS, в сочетании со специфичной для нее опцией notail, препятствующей упаковке мелких «хвостов» файлов, этот выигрыш становится видимым невооруженным (тестами) взглядом.

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

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

Таблица 4. Предложение по дисковой разметке и сопутствующим материям

Каталог Имя файла Тип раздела Размер Файловая система Опции
/boot /dev/sda1 Первичный 50 Мбайт ext2 noauto
Swap /dev/sda5 Логический RAM*2
/ /dev/sda6 Логический 10 Гбайт ext3 noatime,nodiratime
/home/works /dev/sda7 Логический # Гбайт ReiserFS noatime,nodiratime,notail
/home/media /dev/sda8 Логический ## Гбайт XFS noatime,nodiratime

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

Аккаунты и права доступа

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

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

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

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

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

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

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

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

Команда sudo используется обычно для выполнения единичных директив, которые указываются в качестве её аргумента. После этого следует запрос на пароль пользователя, давшего команду (а не администратора!). После его ввода директива исполняется.

В отличие от su, которая работает всегда и (почти) везде, команда sudo требует некоторой настройки, которая по умолчанию в Zenwalk не выполнена. Этим мы займемся в главе об общесистемных настройках.

Понятие локали

Понятие, необходимое пользователю, существующему за пределами США с их английским американским языком, — есть понятие локали. Локаль (locale) — это совокупность языково-культурных особенностей, таких как страна, язык, набор символов, формат представления чисел, даты и времени, денежной единицы. Для пользователя самыми важными локально-зависимыми параметрами оказываются страна, язык и набор символов.

Так, страна Россия (RU) подразумевает русский же язык (ru); это не так очевидно, как кажется — страна Украина кроме украинской же локали имеет также и русскоязычную. Многоязычие свойственно и локалям многих других стран — классическим примером тут является Швейцария с её четырьмя государственными языками и, соответственно, четырьмя же локалями. А для английского языка, напротив, свойственно участие в локалях очень многих стран (Великобритания, США, Канада, Австралия и так далее)

Для локали ru_RU характерной особенностью является изобилие наборов символов (charset, называемые также кодировками): KOI8-R, CP866, CP1251, ISO8859-5 и еще несколько полузабытых или мало используемых. Такое положение сложилось исторически и не влекло за собой ничего кроме путаницы. И потому в последнее время на роль универсальной, отменяющей кодировки, локали претендует UTF8. Правда, пока желаемой унификации с ее помощью не достигнуто, но прогресс в этом направлении виден невооруженным глазом.

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

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

О пакетах

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

Безальтернативная система установки Zenwalk избавляет пользователя от необходимость знать о пакетах с самого начала что-либо еще (потом-то ему эти знания потребуются, но это будет потом). Взамен лишая возможности выбора — он получает то, что сочли необходимым включить в состав дистрибутива майнтайнеры. Хорошо это или плохо? В результате многих лет использования и опробования самых разных дистрибутивов у меня сформировалось крамольное, с точки зрения поборников абстрактной свободы, мнение: для тех двух полярных групп пользователей, на которых ориентируются «безальтернативные» дистрибутивы (совсем начинающих и многоопытных), это однозначно хорошо.

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

Пользователь же многоопытный не выбирает отдельные пакеты — он их навыбирался на средней стадии приобщения к Linux — а подбирает «безальтернативный» дистрибутив, состав которого наиболее близок к его устоявшимся вкусам и пристрастиям. И который потребует от него лишь минимальных действий по удалению/добавлению отдельных пакетов.

Более того, продолжу свою крамолу: «безальтернативная» установка подошла бы и для многих членов промежуточной, между двумя обозначенными полюсами, группы. Однако на средней стадии приобщения к Linux’у одним из определяющих чувств является — из чего это состоит и как устроено (по себе помню). И потому давать рекомендации тут не буду.

Консоль против Иксов

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

Так вот, Linux изначально предназначался для работы в текстовом режиме. В коем и поддерживает все видеокарты, соответствующие стандарту VESA — то есть все, изготовленные человечеством за последние полтора десятка лет. Правда, в ядре его есть и поддержка собственно графического режима — через так называемый линейный кадровый буфер (frame buffer). Однако программ, использующих такой режим, очень немного, возможности их ограничены, и используются они редко.

Основным же способом вывода графики в Linux является оконная система X (X Window System) или, в просторечии, Иксы. Это — не часть Linux’а, а именно самостоятельная система, предназначенная для работы поверх любых Unix-подобных операционок (и не только их). Тем не менее, она стандартно входит во все дистрибутивы Linux общего назначения, за исключением специализированных (например, сугубо серверных). И часто устанавливается по умолчанию.

Установить Иксы мало — их нужно еще и должным образом настроить. В понятие это входит определение видеокарты, характеристик монитора, мыши, установка экранного разрешения и так далее. С большинством вопросов, касающихся распознавания «железа», успешно справляются инсталляторы юзерофильных дистрибутивов, и соответствующие параметры устанавливаются автоматически (хотя тут часто допустимы и ручные коррективы). А вот доведение до конца локализации предоставляется пользователю: он может указать желаемую клавиатурную раскладку (например, русскую), ее вариант (в современных условиях обычно winkeys — для Windows-маркированных клавиатур), переключатель с латиницы на кириллицу и так далее.

Однако и настройкой Иксов дело не заканчивается. Так как сама по себе оконная система X не способна выполнить никакие пользовательские задачи. Для этого она требует специальной программы — менеджера окон или интегрированной рабочей среды (так называемого пользовательского десктопа).

И, наконец, последнее. Традиционный способ авторизации в Linux — задание логина и пароля в текстовом режиме. После чего Иксы можно (и обычно — нужно) запустить вручную специальной командой. Однако возможна и автоматическая загрузка Иксов при старте системы — и сейчас в юзерофильных дистрибутивах именно это, как правило, и практикуется. В этом случае авторизация происходит посредством специальной программы — десктоп-менеджера. Который, помимо всего прочего, позволяет обычно выбрать менеджер окон или интегрированную среду. Авторизация в графическом режиме принята по умолчанию и в дистрибутиве Zenwalk.

Заключительные замечания

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


[Назад] [Главная] [Вперёд]