Что такое аккаунты
Далее, пользователю хорошо бы иметь представление об учетных записях пользователей (иначе говоря, пользовательских аккаунтах). Linux - система многопользовательская, и на одной машине могут одновременно работать несколько пользователей. Для чего они должны авторизоваться - то есть ввести свое уникальное имя пользователя (логин) и подтверждение аутентичности - пароль. Разумеется, на настольной, особенно домашней, персоналке все эти пользователи физически представляют одно лицо - себя, любимого. Так, у меня на домашней машине, как правило, существует два пользователя - от лица одного я выполняю свою обычную работу (например, сочиняю эти строки), вторая же учетная запись предназначена для всякого рода экспериментов.
Каждый пользователь получает в свое распоряжение собственный домашний каталог (один из подкаталогов /home, имеющий вид /home/username), в отношении которого располагает всей полнотой прав - право на чтение, запись, исполнение файлов (тех, которые в принципе могут исполняться). В отношении же каталогов других пользователей его права, обычно, ограничены только возможностью чтения и, может быть, исполнения. Также и прав на изменение общесистемных каталогов пользователи не имеют.
За одним-единственным исключением - в системе имеется, как правило, пользователь с логином root (не путать с корневым каталогом), по русски называемый обычно суперпользователем или администратором. Он обладает правами на изменение всех файлов и каталогов системы, в том числе и общесистемных. Именно от лица суперпользователя следует производить настройку системы и устанавливать всякие дополнительные программы.
Аккаунт администратора системы почти в обязательном порядке создается на стадии начальной установки системы - для этого инсталлятор предлагает ввести пароль суперпользователя в специальной строке (панели) и затем повторить его для проверки. Обратим внимание - в целях обеспечения безопасности от классового врага, подглядывающего из-за спины, ни в первом, ни во втором случае вводимые символы пароля на экране не отображаются.
Вслед за этим инсталлятор обычно предлагает создать учетную запись обычного пользователя. Здесь от пользователя требуется задать уникальное учетное имя, иногда - свое реальное имя (оно может быть любым - с паспортными данными система не сверяется) и опять-таки дважды повторить пароль. Обычно на стадии первичной установки создается единственный пользовательский аккаунт, но некоторые инсталляторы позволяют создать произвольное их число.
При входе в систему, как уже было сказано, от пользователя потребуется зарегистрироваться - то есть в ответ на приглашение login ввести свое учетное имя и затем, в ответ на приглашение password, подтвердить его паролем. Авторизация может происходить в текстовом режиме или посредством специальных графических программ. В последнем случае перед ним открываются еще некоторые дополнительные возможности - например, выбрать рабочее окружение для данного сеанса, оконный менеджер или интегрированную графическую среду (о чем будет речь в последнем разделе).
При входе в систему вольно авторизоваться как самим собой (то есть обычным пользователем), так и администратором. Однако следует свято придерживаться правила: не выполнять от лица последнего обычную работу (выход в Интернет, обработку текстов, чтение почты и так далее). Аккаунт суперпользователя предназначен исключительно для действий по настройке системы, установки и удаления программ, и так далее. Вся текущая работа должна производиться после регистрации обычным пользователем. Для единичных же действий, требующих привилегий администратора, существует несколько методов временного получения таковых.
В последнее время в ряде дистрибутивов появляется тенденция вообще отказываться от создания учетной записи суперпользователя на стадии инсталляции (типичным примером выступает семейство дистрибутивов Ubuntu). Конечно, его можно создать или при специальном режиме установки, или впоследствии, но идеологически правильным в таких системах будет именно временное получение суперпользовательских прав для выполнения тех или иных административных действий. Что не только способствует общей безопасности системы, но и снижает риск ее случайного повреждения вследствие ошибок пользователя.
Если система не одна
Все, что было сказано выше касательно разметки дисков, исходило из молчаливого допущения, что Linux устанавливается на чистый диск, причем в качестве единственной операционной системы. Либо - на диск, содержимым которого можно пожертвовать. Либо, наконец, просто на второй физический диск.
Однако, скорее всего, обычная пользовательская машина имеет только один диск, который целиком занят какой-либо операционной системой (и я даже подозреваю, какой), отказаться от которой наш пользователь пока морально не готов. Так что нужно обеспечить место для инсталляции Linux и ее сосуществование с Windows любого рода.
Вторая задача - мультисистемная загрузка с возможностью выбора ОС, - будет решена автоматически в процессе установки. А вот наличием свободного (точнее, неразмеченного) пространства на диске пользователь подчас должен озаботиться сам.
Правда, многие из "продвинутых" инсталляторов на стадии дисковой разметки предлагают изменение размера существующего Windows-раздела, выполняя это без потери данных. Однако такое бывает не всегда. И потому способы ручного высвобождения дискового пространства из под виндовского ига входят в минимум кандидата-линуксоида.
Если на диске установлена файловая система FAT32 (или, тем более, FAT16) - задача решается легко. Для этого в любой дистрибутив Linux входит штатное средство - DOS-программа FIPS, которая позволяет уменьшить размер раздела FAT16 или FAT32 (но не NTFS).
Перед применением FIPS требуется дефрагментировать (обязательно!) диск или раздел, подлежащий усекновению, загрузиться в режиме эмуляции DOS, после чего одноименной командой она запускается из командной строки. Затем следует вопрос - отвести ли все свободное место под новый раздел. Разумеется, этого делать не следует, ведь вы сохраняете Windows не для того, чтобы не иметь возможности с ним работать. Тогда вам будет предложено изменить соотношения между старым и новым разделами. Подумав хорошенько (после установки Linux воспользоваться FIPS уже не удастся), вы такое соотношение задаете, после чего подтверждаете выбор (при этом на диск записывается новая таблица разметки) и выходите из программы. Все, у вас существует пустое дисковое пространство, не приписанное пока ни к одной файловой системе, с коим вольно делать все, что угодно.
Мне не известны случаи разрушения данных при использовании программы FIPS. Однако потенциально это процедура опасная (например, при выключении питания по любой причине). И потому перед этим следует озаботиться архивированием хотя бы данных. Впрочем, привычка к регулярному резервному копированию не является вредной ни в какой операционной системе...
Сложнее, если ваш диск несет на себе файловую систему NTFS - против нее FIPS бессилен. А ведь нынче Windows XP фабрично предустанавливается на новым компьютерах именно поверх этой файловой системы. Конечно, можно воспользоваться коммерческими программами типа Partition Magic или дисковых утилит производства фирмы Acronis. Но это - продукты платные, и покупать их из-за разовой операции смысла не имеет (а воровать, даже программы, как известно, грешно). И потому придется прибегнуть к одному из так называемых дистрибутивов Live CD - Linux-систем, работающих непосредственно с компакт-диска, без установки на винчестер.
Linux располагает инструментом для манипулирования разделами, несущими файловую систему NTFS - это parted, универсальная программа дисковой разметки. Она имеет и графические оболочки - gparted и qparted, очень простые в обращении и интуитивно понятные. Только вот для того, чтобы parted (как и его оболочки) был способен работать с NTFS, требуется еще и наличие пакета ntfstools, который далеко не всегда входит в состав дистрибутивов (в том числе и Live CD). Так что нужно подыскать соответствующий дистрибутив. Из известных мне таковым гарантированно является Knoppix - патриарх "живых" Linux-дистрибутивов.
Knoppix имеет а) удобную графическую среду KDE, пригодную для применения даже начинающим пользователем, б) содержит программу parted и ее графический front-end - qparted, и, наконец, в) содержит необходимый нам пакет ntfstools. Так что тем или иным образом обзаводимся этим дистрибутивом - скачиваем или или приобретаем ; часто компакт-диски с Knoppix'ом идут в комплекте с журналами Linux-тематики, такими, как Linuxformat и Chip Linux. К слову сказать, затраты на трафик или покупку в данном случае будут вполне оправданы - Knoppix Live CD может не раз пригодиться "по жизни", например, при аварийно-восстановительных работах после серьезных системных сбоев, от которых не след зарекаться никому, а особенно начинающему пользователю Linux.
Теперь остается только загрузиться с этого Live CD, в графической среде KDE через главное K-меню (аналог кнопки Пуск в Windows) вызвать qparted, в его окне выбрать NTFS-раздел, подлежащий урезанию, и, руководствуясь интуитивно понятными соображениями, урезание это произвести - на столько, насколько нужно.
Раз уж речь зашла о пользовательских данных - возможно, у вас появится искушение использовать в качестве их хранилища уже существующий Windows-раздел. Если он несет на себе FAT любого рода - никаких сложностей не возникнет, Linux прекрасно умеет работать с этой файловой системой и на чтение, и на запись. Хотя при этом будут потеряны многочисленные преимущества нативных файловых систем Linux, как то: надежность, быстродействие, возможности разграничения доступа, и так далее. А вот если Windows-данные лежат на NTFS-разделе - все гораздо сложнее. Штатно Linux позволяет работать с этой файловой системой только в режиме чтения. Конечно, ядро Linux можно пересобрать и так, чтобы оно было способно записывать на NTFS-разделы, но а) запись эта до сих пор считается не вполне безопасной, и б) пересборка ядра - не то занятие, с которого следует начинать знакомство с Linux (хотя пользователи моего поколения именно с этого обычно и начинали). Так что лучше все-таки не жадничать, и предусмотреть для будущей инсталляции Linux место под собственные данные.
Таким образом, при использовании двух ОС на одной машине схема дисковой разметки из таблицы 1 приоритет следующий вид (табл. 2).
Таблица 2. Схема дисковой разметки при наличии двух ОС
Каталог | Размер раздела | Тип раздела | Файловая система | Опции монтирования |
Раздел для Windows | Сколько можно | Первичный, hda1 | NTFS или FAT32 | - |
Корень (/) | 256-512 Мбайт | Первичный, hda2 | Ext3fs | noatime |
Swap | RAM*2 | Логический, hda5 | - | - |
/tmp | 512 Мбайт | Логический, hda6 | ReiserFS | noatime, notail |
/var | 3 Гбайт | Логический, hda7 | ReiserFS | noatime, notail |
/usr | 5 Гбайт | Логический, hda8 | ReiserFS | noatime, notail |
/home | Сколько нужно | Первичный, hda4 | ReiserFS | noatime, notail |
Файловая иерархия и монтирование
И, наконец, файловая иерархия. Сколько бы ни было в системе дисковых разделов и файловых систем на них, для пользователя они предстают в качестве логически единой иерархически устроенной файловой системы древовидного облика (правда, дерево это обычно выглядит посталенным с ног на голову). В основании ее лежит корень (root, символически обозначаемый как /). Обязательными же ветвями являются каталоги - /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, и также обеспечивает (по умолчанию или после запроса и подтверждения пользователя) их автоматическое монтирование. Правда, доступ к разделам с файловой системой NTFS возможен обычно только в режиме чтения: запись на них требует специального инструментария и считается не вполне безопасной.
Файловые системы, расположенные на сменных носителях (CD, DVD, флэш-драйвы, внешние винчестеры с интерфейсом USB или FireWire, и так далее - вплоть до встроенных и сменных накопителей цифровых камер), при старте системы не монтируются. Этот выполняется по мере надобности - с помощью упомянутой выше команды mount. Однако инсталляторы, как правило, в силах установить наличие, по крайней мере, CD/DVD-приводов (еще бы, ведь, скорее всего, дистрибутив с них и устанавливается, и создать в /etc/fstab запись, обеспечивающую монтирование по упрощенной форме, например
$ mount /mnt/cdrom
для монтирования компакта. Для прочих сменных носителей, не монтируемых при старте, но используемых регулярно, соответствующие записи в файл /etc/fstab часто приходится создавать вручную (раньше это требовалось всегда, но ныне есть и другие механизмы - см. далее). Для каждого сменного устройства это делается отдельной строкой, содержащей следующие поля, разделенные пробелами (в любом количестве) или символами табуляции:
имя файла устройства или дискового раздела;
точку монтирования;
тип файловой системы;
опции монтирования - для временно используемых файловых систем он должен иметь значение noauto, запрещающее монтирование при загрузке системы, и, скорее всего, user (через запятую), разрешающее монтирование от лица обычного пользователя, по умолчанию это имеет право сделать только root;
условия провеки и "дампа" - для временно используемых файловых систем тут можно ограничиться нулями.
После этого процедура монтирования сведется к команде mount с одним аргументом - либо точки монтирования, либо имени файла устройства, и необходимости в каких-либо опциях также не возникнет.
Перед выключением машины (или перезагрузкой системы) все задействованные файловые системы должны быть в обязательном порядке размонтированы, что проделывается автоматически при корректном завершении сеанса - командами halt или reboot. Однако если в течении рабочего сеанса возникнет потребность, например, сменить компакт в CD-приводе, или извлечь флэш-драйв - размонтирование нужно выполнить явным образом, командой umount. Которая в любом случае потребует одного аргумента, точки монтирования или имени файла устройства.
Во многих современных дистрибутивах к редактированию файла /etc/fstab, ручному монтированию и размонтированию устройств приходится обращаться только в исключительных случаях. Корректным монтированием файловых систем при старте системы, как уже говорилось, озаботится программа установки. Что же до сменных носителей - их монтирование обеспечивается механизмом HAL (Hardware Abstration Layer), в результате чего сменные носители монтируются прозрачно для пользователя - сразу же при подключении соответствующего устройства или вставки компакт-диска в привод. Механизм HAL не использует описаний из файла /etc/fstab, и потому никаких дополнений в него вносить не нужно (более того, они могут лишь помешать).
Правда, отключение сменных носителей при использовании механизма HAL потребует от пользователя некоторых манипуляций. А именно - щелчка правой клавишей на пиктограмме рабочего стола, соответствующего CD/DVD или флэш-драйву (USB-винчестеру), и выбора из появившегося контекстного меню - в первом случае пунктов Отмонтировать и затем Извлечь, во втором - пункта Безопасно извлечь.
Консоль против Иксов
И последнее, о чем следует знать, - это о текстовом (консольном) и графическом режимах работы. Ибо непонимание их отличий является источником множества недоразумений, связанных, например, с поддержкой видеокарт, различием клавиатурных раскладок в консоли и в Иксах, и так далее.
Так вот, Linux изначально предназначался для работы в текстовом режиме. В коем и поддерживает все видеокарты, соответствующие стандарту VESA - то есть все, изготовленные человечеством за последние полтора десятка лет. Правда, в ядре его есть и поддержка собственно графического режима - через так называемый линейный кадровый буфер(frame buffer). Однако программ, использующих такой режим, очень немного.
Основным же способом вывода графики в Linux является оконная система X (X Window System) или, в просторечии, Иксы. Это - не часть Linux'а, а именно самостоятельная система, предназначенная для работы поверх любых Unix-подобных операционок (и не только их). Тем не менее, она стандартно входит во все дистрибутивы Linux общего назначения, за исключением специализированных (например, сугубо серверных). И часто устанавливается по умолчанию.
Установить Иксы мало - их нужно еще и должным образом настроить. В понятие это входит определение видеокарты, характеристик монитора, мыши, установка экранного разрешения, и так далее. С большинством вопросов, касающихся распознавания "железа", успешно справляются инсталляторы юзерофильных дистрибутивов, и соответствующие параметры устанавливаются автоматически (хотя тут часто допустимы и ручные коррективы). А вот доведение до конца локализации предоставляется пользователю: он может указать желаемую клавиатурную раскладку (например, русскую), ее вариант (в современных условиях обычно winkeys - для Windows-маркированных клавиатур), переключатель с латиницы на кириллицу, и так далее.
В некоторых дистрибутивах (Gentoo, Archlinux) автоматическая настройка Иксов при первичной инсталляции не предусмотрена. В этом случае пользователю придется выполнить ее самому. Впрочем, современные средства автоконфигурирования в Иксах делают этот процесс не очень сложным, хотя и требующим ручной доводки (в отношении экранных шрифтов и клавиатурных раскладок).
Однако и настройкой Иксов дело не заканчивается. Так как сама по себе оконная система X не способна выполнить никакие пользовательские задачи. Для этого она требует специальной программы - менеджера окон или интегрированной рабочей среды (так называемого пользовательского десктопа). Выбор таковых развитые инсталляторы также предоставляют пользователю.
И, наконец, последнее. Традиционный способ авторизации в Linux - задание логина и пароля в текстовом режиме. После чего Иксы можно (и обычно - нужно) запустить вручную специальной командой. Однако возможна и автоматическая загрузка Иксов при старте системы - и сейчас в юзерофильных дистрибутивах именно это, как правило, и практикуется. В этом случае авторизация происходит посредством специальной программы - десктоп-менеджера. Который, помимо всего прочего, позволяет обычно выбрать менеджер окон или интегрированную среду.
Понятие локали
Понятие, необходимое пользователю, существующему за пределами США с ее английским американским языком, - есть понятие локали. Локаль (locale) - это совокупность языково-культурных особенностей, таких, как страна, язык, набор символов, формат представления чисел, даты и времени, денежной единицы. Для пользователя самыми важными локально-зависимыми параметрами оказываются страна, язык и набор символов. Так, страна Россия (RU) подразумевает русский же язык (ru; это не так очевидно, как кажется - страна Украина кроме украинской же локали имеет также и русскоязычную), но многие наборы символов (charset, называемые также кодировками): KOI8-R, CP866, CP1251, ISO8859-5 и еще несколько полузабытых. Такое положение сложилось исторически и не влекло за собой ничего кроме путаницы. И потому в последнее время на роль универсальной, отменяющей кодировки, локали претендует UTF8. Правда, пока желаемой унификации с ее помощью не достигнуто.
Linux - явление интернациональное, и практически все современные его дистрибутивы теоретически поддерживают все возможные в современном мире локали, в том числе и основные русские. Обычно локализация системы выполняется в начале установки и часто сводится к выбору языка, что влечет за собой не только русификацию меню программы инсталляции, но и принудительную установку всех остальных локально-зависимых параметров, в том числе и набора символов (таковым обычно сейчас выступает UTF8). Однако в ряде дистрибутивов возможно независимое определение языка, страны и набора символов. В отношении последнего пользователю, таким образом, предоставляются варианты выбора, практически всегда включающие KOI8-R и UTF8, иногда также CP1251 и другие.
Установки правильной локали недостаточно для полной русификации системы. Это требует также подключения кириллических шрифтов и раскладок клавиатуры с поддержкой кириллицы, а также переключателя с латиницы на кириллицу. Соответствующие действия обычно выполняются инсталляторами. Причем в одних случаях они распространяются и на текстовый, и на графический режим, в иных же - только на последний. И тогда дело кириллизации консоли предоставляется самому пользователю. Как именно - распространяться не буду, на сей счет существует немерянное количество руководств.
Практикум по дисковой разметке
Как уже говорилось выше, ошибки при дисковой разметке и создании файловых систем исправимы в дальнейшем с большим трудом (или неисправимы вообще без переустановки системы). И потому при начальной установке системы к этому вопросу следует подойти со всей ответственностью.
Для начала определимся - сколько разделов необходимо для установки Linux? Обязательными считаются два - под корневую файловую систему и под своппинг; именно такая схема разметки предлагается многими инсталляторами по умолчанию. Современные дистрибутивы обычно требуют в типовой установке не менее 2-3 Гбайт дискового пространства - и это без учета пакетов, которые, возможно, придется доустанавливать впоследствии. Так что отвести под Linux 5-7 Гбайт при нынешних объемах дисков будет не внапряг - я последнее время, дабы не ломать голову рассчетами, отдаю под это 10 Гбайт. Что же до раздела подкачки - его размер традиционно определяется равным удвоенному объему оперативной памяти и, опять такие во избежание ломки головы, остановимся на этой величине.
Часто можно услышать мнение, что при типичных современных объемах оперативной памяти (512 Мбайт - 1 Гбайт) раздел подкачки не нужен вообще. Резон в этом есть - при указанных объемах памяти своппинга в штатных ситуациях практически не происходит никогда. Однако возможно, что в последующем вам захочется использовать файловую систему в оперативной памяти - tmpfs - и задействовать ее, например, под промежуточные продукты компиляции. А поскольку оценить потребное под них место весьма трудно (OpenOffice.org, например, желает под это дело несколько гигабайт), возникает риск переполнения файловой системы. Так что повторюсь еще раз: не стоит жмотничать, и лучше отдать под раздел подкачки один-другой гигабайт, нежели потом сожалеть о его отсутствии.
Вернемся, однако, к корню файловой иерархии. Широким жестом отведя под него 5, 7 или даже 10 Гбайт, мы не учли одного: собственно пользовательских данных (а не ради них ли все и затевалось?). А потому, дабы отделить их от системы, под каталог /home целесообразно выделить собственный раздел. Какой? Вам виднее, сколько данных у вас имеется (и предвидится). Обычно тут руководствуются одним из принципов - сколько нужно, сколько есть или сколько не жалко.
Итак, приходим к выводу о необходимости трех разделов - под корень, под своппинг и под каталог /home. Однако это не предел дискодробительства: в ряде случаев на отдельные разделы целесообразно вынести такие ветви файлового древа, как /usr, /var и /tmp (причины к тому подробно описаны в книжке Введение в POSIX'ивизм - "бумажный" ее вариант в скором времени выйдет в издательстве БХВ-Петербург под названием "Доступный Unix" - ). В этом случае раздел под корневой каталог можно сделать совсем маленьким (256-512 Мбайт), под /usr и /var отвести гигабайт 5 и 3, соответственно, а под /tmp 512-ти мегабайт хватит за глаза - в расчете на то, что в дальнейшем в него можно будет подмонтировать файловую систему в оперативной памяти - tmpfs (в известных мне инсталляторах на стадии установки штатно такой возможности не предусмотрено). Лично мне такая схема представляется почти оптимальной для пользовательского десктопа.
Наконец, при использовании в качестве загрузчика GRUB его разработчиками настоятельно рекомендуется вынести на самостоятельный раздел каталог /boot - размером 30-50 Мбайт. Впрочем, это имеет смысл только в том случае, если на машине планируется использовать несколько (более двух - Linux и Windows) операционных систем.
В дистрибутивах Source Based, использующих портообразные системы, часто практикуется еще более дробная разметка диска. В частности, в них имеет смысл выносить на отдельные разделы не только само дерево портов, но и каталог для скачиваемых из Сети исходников. В Gentoo это будут /usr/portage и /usr/portage/distfiles, в Archlinux - /var/abs и /var/cache/pacman/src, соответственно; в общем, это следует уточнять по документации для конкретного дистрибутива. Как и то, сколько места необходимо отвести на дерево портов - раздел под каталог с исходниками если уж создавать, то лучше создать с очень хорошим запасом.
Какие разделы создавать под Linux - первичные или логические? Если ограничиться минимально необходимыми - /, swap, /home, - значения не имеет: три раздела можно сделать и первичными (и еще одна Primary Partition останется про запас - например, для Windows, о чем речь пойдет чуть дальше).
Если же прибегнуть к более дробной схеме разметки - неизбежным становится использование логических разделов в Extended Partition. Причем никаких ограничений тут давно уже - на логических разделах могут лежать и корневая файловая система, и swap, и даже /boot (не говоря уже о всех прочих). Правда, /boot разработчики GRUB'а рекомендуют все же помещать на первичный раздел - но, повторяю, это имеет смысл только при множестве установленных на данной машине операционок. Я же, со своей стороны, настоятельно советую задействовать именно первичный раздел под каталог /home - пусть и слабая, но дополнительная гарантия сохранности пользовательских данных. А поскольку, как завещал нам Козьма Прутков, шутки с данными глупы и неприличны, - ни одной страховой возможностью в их отношении пренебрегать не след, сколь бы призрачной она ни казалась...
Файловые системы... Тут есть немало поводов поломать голову. Если. конечно, не следовать умолчаниям инсталлятора. А он, скорее всего, предложит нынче по умолчанию ext3fs для всех ветвей файлового древа. С этим можно смело соглашаться - это будет вполне разумным (хотя и не идеальным) выбором. Однако при схеме разметки, декларированной выше как (почти) оптимальная, я бы оставил ext3fs только для корня файловой иерархии. А на разделах для прочих ее ветвей - /usr, /var, /tmp, /home, - создал бы ReiserFS. Хотя в случае с /home - вопрос обсуждаемый: эта ветвь файлового древа может явить собой пример той самой очень большой файловой системы с очень большими файлами. И тогда для нее целесообразной может оказаться XFS...
В предыдущем разделе вскользь упоминалось, что инсталляторы подчас предлагают, кроме выбора файловой системы и точки ее монтирования, задать также некие опции монтирования. Подавляющее большинство их (а имя им - легион) служат весьма специальным целям, обычному пользователю не интересным. Однако минимум одна опция окажется для него полезной, а именно - noatime. Она запрещает обновлять время последнего доступа к файлам (которое само по себе на десктопе мало для чего нужно), способствуя некоторому повышению быстродействия файловых операций. А для файловой системы ReiserFS, в сочетании со специфичной для нее опцией notail, этот выигрыш становится видимым невооруженным (тестами) взглядом).
Подведу итоги своих долгих рассуждений, сведя их в таблицу того, как представляется мне схема разбиения диска для среднестатистического десктопа (табл. 1).
Таблица 1. Предложение по дисковой разметке и сопутствующим материям.
Каталог | Размер раздела | Тип раздела | Файловая система | Опции монтирования |
Корень (/) | 256-512 Мбайт | Первичный, hda1 | Ext3fs | noatime |
Swap | RAM*2 | Логический, hda5 | - | - |
/tmp | 512 Мбайт | Логический, hda6 | ReiserFS | noatime, notail |
/var | 3 Гбайт | Логический, hda7 | ReiserFS | noatime, notail |
/usr | 5 Гбайт | Логический, hda8 | ReiserFS | noatime, notail |
/home | Сколько нужно | Первичный, hda3 | ReiserFS | noatime, notail |
Представление о файловых системах
Разделы создаются не сами по себе, а для того, чтобы нести на себе некие файловые системы. В отличие от Windows, способной работать только с FAT любого рода и (для линии Windows NT/2000/XP) NTFS, Linux в качестве "родных" (native) поддерживает большое количество их типов: ext2fs, ext3fs, ReiserFS, XFS и JFS (в принципе Linux можно разместить и на разделе с FAT16/FAT32, но это - занятие нездоровое по ряду причин).
Файловая система ext2fs - старейшая из используемых в Linux. Отличается исключительным быстродействием, совместимостью и достаточно надежна для использования на десктопе. Правда, после системных сбоев (например, по питанию) она обязательно должна проходить проверку целостности, что при современных объемах дисков может занять изрядное время.
Файловая система ext3fs представляет собой усовершенствованный вариант предыдущей, и усовершенствование это выражено в так называемом журналировании - специальной записи файловых операций, позволяющей в случае сбоев восстановить файловую систему в целостном состоянии. Поскольку эти действия требуют определенных ресурсов, ext3fs существенно проигрывает в быстродействии своей предшественнице, но зато славится непревзойденной надежностью.
ReiserFS, XFS и JFS - также журналируемые файловые системы, каждая со своими особенностями. Конёк первой - работа с большим количеством маленьких и очень маленьких (в несколько байт) файлов, а таких файлов в любой Unix-системе очень даже много. XFS, напротив, ориентирована на работу с (очень) большими файловыми системами и отдельными файлами мультимедийной направленности, размер которых вполне может составлять не один гигабайт. Ну а JFS, разработка фирмы IBM, - это эпоним журналируемых файловых систем, с нее-то и началось понятие журналирования. Впрочем, никакими другими достоинствами ее Linux-реализация не отмечена, являясь, пожалуй, самой медленной из всего семейства.
В некоторых современных дистрибутивах имеется поддержка файловой системы Reiser4. Это - дальнейшее развитие ReiserFS, представляющее собой уже не только (а может быть, и не столько) файловую систему, а так называемое "пространство имен" (Namespace) для манипулирования дисковыми объектами. Впрочем, официально Reiser4 ядром Linux пока не поддерживается, и не смотря на фантастическое быстродействие, надежность ее вызывает определенные сомнения.
Для создания файловых систем (процесса, именуемого в 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) и то, и другое выполняется прозрачно для пользователя - достаточно соответствующий раздел определить как раздел подкачки.
Сведения о дисковой разметке
Разметка диска - один из самых ответственных моментов в ходе установки Linux. Не потому, что она уж так сложна, а потому, что допущенные в ходе ее ошибки могут быть исправлены только с большим трудом и процесс этот чреват потерей данных. И потому представление о дисковой разметке - краеугольный камень кандидатского минимума будущего линуксоида.
Схема дисковой разметки - это правила дробления диска на разделы. Диски в машинах с архитектурой PC (то есть во всех обычных настольных персоналках) могут быть разделены на четыре физических части - так называемые первичные разделы, Primary Partition (почему именно так - здесь обсуждать неуместно). Один из этих первичных разделов может быть определен как раздел расширенный (Extended Partition). А уж он может далее делиться на логические разделы (Logical Partition) в практически неограниченном количестве (на самом деле ограничение составляет 63 логических раздела).
В Linux (и вообще в Unix-подобных системах) диски и их разделы предстают перед пользователем как файлы особого типа - файлы устройств (это касается и любых других устройств, и вообще в Unix все, что имеется в системе, суть файлы). Их имена этих файлов формируются по определенным правилам. Так, обычные IDE-диски (диски с интерфейсом Parallel ATA) именуются /dev/hda (Master на 1-м IDE-канале), /dev/hdb (Slave на нем же), и так далее (здесь и в последующем /dev - это каталог, предназначенный для специально для хранения файлов устройств, так что собственно имена дисковых устройств - hda, hdb и так далее). Диски с интерфейсом Serial ATA предстают перед системой как SCSI-винчестеры (почему - тайна сия велика есть), и именуются: /dev/sda, /dev/sdb и так далее. Кстати говоря, как SCSI-диски (то есть устройства вида /dev/sd?) будут выглядеть также флэш-драйвы, встроенные и сменные носители цифровых камер и мобильные винчестеры с интерфейсами USB и FireWire.
Дисковые разделы идентифицируются порядковыми номерами. Цифры с 1 по 4 отведены под первичные разделы. Раздел, определенный как расширенный, также имеет соответствующий порядковый номер (например, 2). А логические разделы внутри него нумеруются, начиная с цифры 5. Таким образом, если на мастер-диске первого IDE-канала мы имеем два первичных раздела, второй из которых определен как расширенный и поделен на три логических, соответствующие им файлы устройств будут именоваться так:
/dev/hda1 - первичный раздел (предположим, под Windows);
/dev/hda2 - первичный раздел, определенный в качестве расширенного;
/dev/hda5, /dev/hda6 и /dev/hda7 - логические разделы под файловые системы Linux.
Для первого диска SATA именами файлов устройств разделов будут /dev/sda1, /dev/sda2, /dev/sda5, /dev/sda6 и /dev/sda7, соответственно.
Выше была описана наиболее распространенная (и традиционная для Linux) номенклатура дисковых накопителей и их разделов. Однако в некоторых дистрибутивах пользователь может толкнуться с иной системой их именования, например:
/dev/ide/host0/bus0/target0/lun0/part1 - первый раздел на первом IDE-диске,
/dev/ide/host0/bus0/target0/lun0/part2 - второй раздел на нем же,
/dev/ide/host0/bus0/target0/lun0/part5 - первый логический раздел,
и так далее. Это - номенклатура, принятая в дистрибутивах, использующих так называемую файловую систему устройств - devfs. Она может быть представлена и в менее устрашающем варианте - с обозначением разделов как /dev/discs/disc0/part1, /dev/discs/disc0/part2 и так далее - с тем же значением.
Сама по себе devfs в современных дистрибутивах Linux отмирает, и ее номенклатура устройств встречается ныне как рудимент, поэтому распространяться о ней я не буду. На данном этапе пользователю достаточно знать, что и /dev/ide/host0/bus0/target0/lun0/part1, и /dev/discs/disc0/part1, - это не более чем эквивалент /dev/hda1, далее по аналогии.
Для создания (и удаления) дисковых разделов в Linux предназначена специальная утилита - fdisk. Это - тот жупел, которым из поколения в поколение пугали начинающих пользователей Linux. Хотя на самом деле ничего непреодолимо сложного в ней нет - просто она требует определенной аккуратности. И, кстати говоря, лишь в редких дистрибутивах (например, в Gentoo) она непосредственно используется при установке. Обычно же инсталлятор содержит какое-либо "продвинутое" средство дисковой разметки - от простейшего cfdisk до весьма изощренных DiskDruid, DiskDrake или того безымянного самого по себе инструмента, который используется для дисковой разметки в Debian Installer.
Развитые средства дисковой разметки позволяют обычно не только создать разделы на чистом диске или неразмеченном дисковом пространстве, но и манипулировать с разделами существующими - изменять размер, переносить в другую часть диска, дублировать, причем делать это без потери содержимого. Правда, часто манипулирование разделами возможно не для всех файловых систем, в отношении которых это может понадобиться. И всегда следует помнить - любой сбой в ходе манипулирования разделами (например, по питанию) приведет к безвозвратной потере данных. И потому затевать такие манипуляции без резервирования критически важной информации было бы опрометчиво.
В большинстве инсталляторов процедура разбиения диска на разделы совмещена с созданием на них файловых систем. Однако в принципе это - совсем отдельная процедура, о чем будет говориться в следующем разделе.
Принято считать, что для установки
Принято считать, что для установки Windows знать ничего не нужно, тогда как Linux предъявляет очень высокие требования к начальной подготовке пользователя. Оба эти мнения, мягко говоря, спорные. Пользователю Windows любого рода, впервые устанавливающему эту систему, не худо бы иметь представление по крайней мере о двух вещах - дисковых разделах и файловых системах (или хотя бы знать о существовании FAT разного рода и NTFS). Для пользователя же Windows к этому минимуму добавляется еще и представление о пользовательских аккаунтах. Иначе систему он, конечно, установит, но использование ее будет не самым эффективным. В частности, размещение на одном разделе системы, приложений и пользовательских данных - а именно это и предлагает по умолчанию установщик Windows, - чревато в дальнейшем риском потери последних.
С другой стороны, от пользователя Linux в аналогичной ситуации никаких сверхъестественных познаний не требуется. Более того, современные юзерофильные дистрибутивы теоретически позволяют обойтись вообще без оных - их инсталляторы в силах проделать за него всю работу. Однако некий минимум сведений позволит ему принимать в ходе установки осмысленные решения.
В этой заметке я и решил собрать такой минимум сведений, который желателен пользователю, принявшему решение впервые установить Linux на своей машине. И владение которыми можно рассматривать как минимум для кандидата в линуксоиды. Как и в случае с кандминимумом научным, без этих сведений в обыденной жизни вполне можно обойтись, но наличие некоего набора базовых знаний способно облегчить жизнь пользователя как в ходе установки, так и, особенно, после нее, во время использования системы.
К числу таких базовых сведений я отнес бы представления о:
дисковой разметке,
файловых системах,
файловой иерархии и монтировании,
пользовательских аккаунтах,
системной локали.
В круг базовых сведений следует включить также понимание различий между текстовым и графическим режимами - грубо говоря, между консолью и Иксами. Именно эти вопросы и составит предмет настоящей заметки.
и все, что, по моему
Вот и все, что, по моему мнению, необходимо знать кандидату в линуксоиды перед установкой своего первого дистрибутива. Возможно, я упустил какие-то важные для начинающего ведения. И поэтому буду признателен за соответствующие дополнения, коррективы и вообще комментарии. Высказать их можно как по почте, так и в форума .
Кандминимум-2, или где искать информацию по Linux и Unix
Фонд открытого программного обеспечения производит ПО хорошего качества, которое способно решать задачи. Если Вы хотите его использовать, предполагается, что Вы выделите некоторое время на то, чтобы научиться им пользоваться. Доминик Хамфрис, FSF |
Добавляем данные, собственно
Добавление записей в базу данных производится (как вариант) с помощью утилиты ldapadd. Она воспринимает на входе файл специального формата — так называемый LDIF, LDAP Data Interchange Format (эти файлы так и принято именовать, с расширением ldif). Нетрудно догадаться, что такие или подобные файлы будут управлять всеми операциями с данными.
Вот примерный, из документации, файл, который вы можете создать в любом тестовом редакторе, например в vim (параметры вашего домена, вместо comizdat.com, подставьте по месту; а можете и не подставлять — мы не обидимся).
dn: dc=comizdat,dc=com
objectclass: dcObject
objectclass: organization
o: Comizdat
dc: comizdat
dn: cn=Manager,dc=comizdat,dc=com
objectclass: organizationalRole
cn: Manager
Первая строка каждого блока определяет так называемый узел поиска — DIT, Data Information Tree Node. От этого узла будет производиться поиск. Собственно, в приведенном примере добавляется две записи: одна описывает организацию Comizdat, вторая — тип работника (organizationalRole) Manager.
Вообще-то файл ldif не предназначен для набора руками, так что будьте начеку. Во-первых, все пробелы являются значимыми и не будут удаляться ни в начале, ни в конце строки. Если вы поставите лишний пробел в имени пользователя, то потом будете долго его искать. Один пробел или табуляция в конце строки обозначает перенос строки на следующую, с чем тоже нужно быть осторожным.
Особый формат имеют также и бинарные данные: они помечаются дополнительным двоеточием и должны быть закодированы по Base64 (ну, я надеюсь, вы можете перекодировать в уме в этот форматJ). Короче, для генерации ldif-файла лучше всего пользоваться программной оболочкой, которая контролирует эти тонкости и не допустит ошибок. Сам формат ldif-файла хорошо описан здесь: .
Все записи данных обязательно относятся к одному или нескольким классам, задаваемых параметрами objectClass. Класс задает набор допустимых атрибутов (полей), некоторые из которых обязательные, а некоторые — опциональные. Для полей заданы формат, правила сортировки, тип, кодировка и т.д. Для атрибутов может быть определено несколько наименований, обычно два — полное и сокращенное. К примеру, поля c, o, ou являются сокращениями от countryName, organizationName и organizationUnitName.
Кроме того, что файл ldif имеет общий формат, он еще должен удовлетворять схемам, которые описывают допустимые классы и их атрибуты. Распространенные схемы обычно хранятся в каталоге /usr/local/etc/openldap/schema и имеют расширение *.schema. Другие схемы поставляются с пакетами, их использующими: например, DHCP-демон поставляется со схемой dhcp.schema. Схемы состоят из двух частей: сначала определяются атрибуты с уникальными именами, из которых впоследствии конструируются классы.
Прежде чем использовать в своей базе данных какую-нибудь схему, вы должны включить ее в файл конфигурации slapd.conf с помощью команды include. Например, для стандартных адресных записей в файл конфигурации включена запись include /usr/local/etc/openldap/schema/core.schema.
При создании нового класса от уже существующего, наследуются существующие поля и добавляются новые. Сами атрибуты тоже упорядочены — наподобие того как упорядочены суффиксы в системе имен DNS: сначала записи группируются по более общему признаку, например по стране, потом — по организации и т.д. Существует две распространенные классификации: глобальная (имя — домен) и организационная (имя — отдел — организация — страна). Естественно, что в вашей схеме группировка может быть совсем другой. В конце концов, самым достоверным документом по атрибутам являются сами схемы — и прежде чем описывать собственные классы, я бы посоветовал как следует построчно разобраться с core.schema.
Теперь вы можете приписать этот файл в вашу базу данных и протестировать наличие новой записи, связанной с вашим доменом:
ldapadd -x -D “cn=Manager,dc=comizdat,dc=com” -W -f 1.ldif
lpadsearch -x -b ‘dc=comizdat,dc=com’ ’(objectclass=*)’
Обратите внимание на пробел между строками одиночными кавычками, ограничивающими "где начать искать" и "фильтр классов" — без них вы получите ошибку "галимый домен".
Пару слов о том, что значат параметры: -x значит «простая аутентификация», для локального подключения приемлемо; -D — домен, к которому следует "прибить" новые данные; -W — запросить пароль; -f — получать поток из файла, а не стандартного ввода; -b — указывает, что поиск нужно начать от определенной «поисковой базы», то есть узла.
Прочие параметры вы можете посмотреть и с помощью man-страниц.
Еще один момент: аутентификация LDAP никак не связана с правами суперпользователя. Вообще-то, запросы к LDAP и чтение разрешены кому ни попадя. И если вы против такого поведения, читайте в документации как сделать, чтобы такого не было.
На этом мы, пожалуй, и завершим введение в OpenLDAP, поскольку разговор о специфике создания баз данных и конструировании запросов соответствует скорее формату книги, чем статьи. Могу только сказать, что запустить систему в работу просто, поскольку вначале вы можете пользоваться только 5% всех возможностей (и, тем не менее, получать от этого пользу). А такие возможности, как репликация или еще более сложные каскадные обновления, а также использование LDAP для системного администрирования, вы освоите по мере необходимости.
Эпилог
В результате: что вам может дать LDAP? Практически то, для чего он предназначен,— быстрый и согласованный доступ к адресной информации, включая телефоны и адреса электронной почты, будь то ваши сотрудники, партнеры или клиенты. Если ваша компания нуждается в единой адресной книге (а это так и есть) и вы хотите сделать ее доступной из стандартных почтовых клиентов (а это так и должно быть) — то вам нужно поднимать LDAP-сервер.
Кроме того, как вы можете убедиться, многие системные утилиты воспринимают LDAP как хранилище собственных настроек — и это тоже можно использовать.
Остаются лишь вопросы: на какой платформе ставить сервер (Linux), какой именно (OpenLDAP), как организовать администрирование и делать ли его доступным извне вашей локальной сети. Но это уже не технические, а организационные проблемы, решение которых вам подскажет элементарный здравый смысл.
LDAP: каталог для всех
Арсений Чеботарёв,
Есть такие вещи, о которых все говорят, но мало кто задумывается. Такая ситуация складывается со службами каталогов — такими как LDAP. Давайте посмотрим на эти вещи внимательно и разберемся, что там может быть полезным — как пользователям, так и администраторам.
LDAP на других платформах
Возможно, вы относитесь к особой категории пользователей и являетесь поклонником серверных платформ Windows? Ну, в таком случае вам тоже доступен LDAP. Собственно, главным ресурсом по этому вопросу является декларация "Майкрософт" по LDAP, доступная на
.
Вкратце: все в этом мире вторично, за исключением Active Directory. С этой точки зрения Active Directory имеет LDAP-совместимый интерфейс. Особого парадокса тут нет: LDAP — это, скорее, метод доступа, совершенно инвариантный к методам физического хранения и управления данными, а также безразличный к операционной среде. И поскольку данные могут быть запрошены через стандартный порт 389 с помощью стандартных же запросов, то можно говорить о поддержке LDAP в Windows. Хотя вместо простых и понятных хеш-таблиц Berkeley DB здесь используются иерархические защищенные хранилища Active Directory.
У этого вопроса есть и обратная: в Active Directory API существуют функции, которые позволяют выполнять запросы к другим LDAP-серверам и на их основе обновлять данные. Этот компонент называется LDAP-провайдер.
Наконец, если вы совсем уж особенный человек и MacOS X предпочитаете всем остальным операционным системам, то и в этом случае для вас не все потеряно в плане установки LDAP-сервера. С использованием LDAP в качестве клиента эта операционка, естественно, не имеет никаких проблем. Теоретически MacOSX принадлежит к семейству BSD, так что для нее можно скомпилировать любой открытый софт. Хотя на самом деле многие испытывают значительные трудности на этом пути, так что лучше все-таки пользоваться "фирмой".
На всякий случай...
На этапе configure может возникнут проблема, известная как BerkleyDB version incompatible. Связана она с тем, что символические ссылки по-прежнему указывают на старую версию. В этом случае следуйте указаниям совета, найденного мною на : убейте симлинк db.h в /usr/include и замените его реальным файлом db.h из /usr/local/BerkekeyDB.4.2/include/; в /etc/ld.so.conf добавьте строку /usr/local/BerkekeyDB.4.2/lib и запустите ldconfig; запустите конфигурацию таким вот образом:
env CPFLAGS=-I/usr/local/BerkeleyDB.4.2/include; export CPFLAGS; LDFLAGS=-L/usr/local/BerkeleyDB.4.2/lib; export LDFLAGS; ./configure
У меня на Mandrake 9.2, на котором до этого стоял DBD 4.1, после этих махинаций все стало пучком.
После удачной компиляции прохождение make test доставит вам полнейшее удовольствие — благодаря людям из Мичигана, все проходит с полным аншлагом. Тесты, как вы можете убедиться, включают не только запросы и операции с данными, но и репликации, в том числе каскадные. Другое дело, что не один месяц пройдет, пока вы поймете значение всех этих тестов.
Настройки
Если вы покончили с компиляцией, то следующий шаг — конфигурация файла настроек (обычно расположенного по адресу /usr/local/etc/ldap/slapd.conf). В этом файле содержатся три типа разделов: глобальные настройки, настройки для узла (backend) и настроки для отдельной базы данных. Каждая более детальная настройка может отменять более общие параметры — то есть настройки по зоне отменяют глобальные настройки и т.д.).
По умолчанию в настройках стоят достаточно работоспособные параметры, в частности настройки каталогов (каталоги должны быть уже созданы на этапе инсталляции) и типа доступа к базе данных. Единственное, что может нуждаться в изменении, это суффиксы для вашего домена: параметры suffix и rootdn.
Обратите также внимание на параметр rootpw secret. Это вовсе не указание сделать пароль администратора LDAP секретнымJ — это и так понятно — просто пароль по умолчанию пишется как secret. Его-то вы и должны вводить при внесении данных с помощью ldapadd. Понятно, что вы захотите его поменять на что-то более впечатляющее, вроде R5>(hg#!).
После конфигурации вы можете запустить и проверить самый элементарный поиск по базе данных LDAP:
/usr/local/libexec/slapd
ldapsearch -x -b '' -s base
'(objectclass=*)' namingContexts
Результат должен быть таким, как показано на рисунке ниже: система отвечает на запрос, хотя и говорит, что записи не найдены. Это естественно — откуда бы им там взяться?
Общедоступная теория
По мере того как почтовые сервисы приобретали популярность, у пользователей стали возникать проблемы с поиском людей и их почтовых адресов. Очевидной стала необходимость в больших специализированных базах данных, которые бы хранили тысячи, а то и миллионы записей, а также в механизмах доступа к этим данным по сети, включая надежную аутентификацию.
Вообще-то, в мире UNIX всегда существовали методы и утилиты поиска, типа finger или whois, но они хорошо работали, в основном, в масштабах одного сервера — и для новых реалий не подходили.
Задача заключалась в создании централизованных адресных книг для целых корпораций с развитой сетью отделений, а также с международными филиалами, подключаемыми по интернету. Ко всему, было принято решение сделать этот каталог платформонезависимым. Поэтому IBM, Lotus, Microsoft и Netscape договорились о применении единого метода доступа — LDAP — для доступа к адресной информации. К этому соглашению приложили усилия и многие другие гранды сетевого компьютинга, к примеру Sun и Novell.
LDAP расшифровывается как Lightweight Directory Access Protocol — то есть "легковесный протокол доступа к каталогам". Эта самая "легковесность" LDAP наводит на мысль, что где-то должен существовать и его "тяжеловесный" собрат. И действительно: в качестве прототипа выступал полновесный протокол доступа к каталогам DAP, известный также как X.500 или "Проект "Белые Страницы”" (White Pages Project).
Этот протокол был разработан консорциумом OSI и ориентирован на локальные корпоративные сети и большие мэйнфреймы. Адаптацию этого сложного и редко используемого всуе протокола к нуждам современного интернета и персональным компьютерам выполнили хакеры Мичиганского университета, которые вообще известны креативными поделками. В последнее время LDAP используется для доступа и к не-X.500-совместимым серверам каталогов, а к информиции, отличной от адресных книг.
На сегодня существует три версии LDAP. Причем первая не в счет — в ней сразу же были найдены серьезные проблемы. Вторая, и самая распространенная, версия LDAP2 зафиксирована в документах RFC 1777, 1778 и 1779. Наиболее современной на момент написания этой статьи была версия LDAPv3, окончательно «устаканенная» в 1997 г. В этой версии, с одной стороны, лучше поддерживается X.500, а с другой — больше внимания уделено не-X.500-серверам.
Каталог LDAP, аналогично файловой системе UNIX, построен в виде дерева: корневой узел содержит ссылки на записи, некоторые из которых могут указывать на другие каталоги. Обычно всей организации соответствует корневой каталог. В качестве подкаталогов выступают отделы, филиалы или любые другие имеющие для вас смысл атрибуты. Подкаталоги могут быть автоматически реплицированы в обоих направлениях — любая из сторон может инициировать процесс синхронизации подкаталога. Типичное применение автоматических обновлений — синхронизация между главным каталогом компании и каталогами подразделений.
Возможность построения сетей каталогов — это основа для постепенного развертывания служб LDAP: можно начать с одного минимально настроенного сервера и постепенно расширять его функциональность.
Собственно LDAP реализуется в виде клиента и сервера. Сервер LDAP хранит и индексирует записи определенного формата. В качестве полей выступают имя пользователя, его физический и электронный адреса, телефоны и т.д. Администрирование сервера производится по правилам среды: для Linux это файлы настройки и командная строка, для Windows и Mac OS — графические приложения. В последнее время для администрирования, в том числе удаленного, все чаще применяется веб-интерфейс. Серверы, согласно X.500, могут объединяться в сеть, так что пользователь в поисках нужной информации может переходить от одного сервера к другому.
Кроме того, для повышения производительности существуют и LDAP-прокси серверы, эффективно кэширующие частые запросы.
Клиентом чаще всего выступает почтовый клиент. Он содержит форму запроса к удаленному серверу, наподобие той, что используется для поиска в ICQ. Обычно клиентское ПО реализует не все возможности (которых очень много), а какое-то их подмножество. В той или иной мере LDAP поддерживают все современные почтовые клиенты, такие как Outlook Express, Eudora, Netscape, OS X Mail и т.д. Часто доступ к LDAP-серверу, особенно глобальному, можно получить через веб-интерфейс.
Быстро получить окно поиска на заданном сервере обычно можно, введя в окне браузера URL вида ldap://server[:port]. К примеру, в нашей локальной сети это будет ldap://192.168.0.99. Через косую черту вы можете сразу указать параметры поиска (конечно же, обычно эту строку будет формировать какое-то приложение). Так, ввод в браузер ldap://192.168.0.99/cn=Antonchuk,dc=comizdat,dc=com непосредственно отобразит информацию о главном редакторе К+П. Этот тип URL поддерживается Internet Explorer и Firefox (Netscape) — но не поддерживается, например, в Opera.
Как уже было сказано, LDAP, помимо системы обслуживания запросов, изначально включает и систему аутентификации. Администратор задает привилегии пользователей и определяет записи, к которым тот или иной из них может осуществлять доступ. Списки правил доступа (ACL, Access Control List) позволяют настроить доступ любым образом: в типичном случае пользователь имеет право изменять собственную частную информацию, а все остальные — просматривать ее. Однако можно, например, защитить отдельные поля частной записи от просмотра или модификации.
Собственно, существуют и общественные LDAP-серверы, доступные для поиска всему миру (к примеру, BigFoot или Infospace) — но все-таки основное применение протокол находит на уровне больших и средних корпораций. Не прекращаются попытки создать методы объединения отдельных серверов с целью создания "глобального каталожества". Но до реального воплощения пока далеко.
Также LDAP используется для каталогов сетевых ресурсов и других вещей, отличных от персональных данных. Например, тот же Netscape Communicator при создании пользовательского экаунта создает запись в централизованной базе данных LDAP и пытается хранить там все ваши настройки, такие как закладки часто посещаемых вами страниц.
В этом смысле LDAP в некоторых сферах может поконкурировать с методом доступа SQL, поскольку работает напрямую через TCP/IP и хорошо адаптирован к работе в сети. Однако учтите, что LDAP ориентирован на быстрый поиск и доступ (чтение) данных — но внесение изменений не является настолько же быстрой и эффективной операцией. Так что этот протокол ориентирован, скорее, на статические данные: адреса, телефоны, пароли, сетевые ресурсы — и не подойдет для информации, которая склонна быстро меняться.
По сути, LDAP — не реляционная база данных. Структура базы LDAP скорее напоминает XML, где запись представляет собой комбинацию атрибут: значение. Поскольку существует возможность определять новые типы полей, то в LDAP можно сохранить любую текстовую или бинарную информацию. Это обуславливает большую гибкость для описания новых полей и структур, но в общем случае поиск по неиндексированному полю — операция довольно медленная.
Полезные ссылки
Несколько слов о тех интернет-ресурсах, которые могут помочь с информацией по теме.
Главная ссылка, с которой можно начать освоение LDAP и откуда почерпнул максимум информации я сам, это сайт .
Кроме того, вы можете сразу направиться на , где лежит последний дистрибутив.
Наконец, если вы хотите использовать LDAP в административных целях, вас наверняка заинтересует документ, описывающий применения LDAP в «потусторонних» контекстах, таких как раздача DHCP, учет трафика и сетевых ресусов: .
Пролог
Первый раз я вплотную столкнулся с LDAP при работе с почтовым сервером exim. Как известно, этот сервер является попыткой народа из Кембриджа бросить вызов старому и нудному как сто пней sendmail’у. В качестве полезного и приятного удобства exim предоставляет возможность черпать любые списки (например, почтовых адресов, серверов или хостов) независимо из различных источников: из самого файла настройки (включая вычисляемые регулярные выражения), из выходного потока внешних программ, из баз данных. И, в том числе, из служб каталогов. И если с основным перечнем все более или менее понятно, то эти самые каталоги оказались пробелом в моих познаниях — и как любой истинный искатель приключений я ломанулся на поиски инфы. Ниже — краткий конспект моих поисков.
С чего начать? Можно с инсталляции
Конечно, теория — это круто, но без практики она никому не нужна. Итак, на повестке дня — установка LDAP-сервера. Конечно, первое, с чем нужно определиться, это платформа. Обычно это Linux или FreeBSD, но LDAP-серверы доступны и на других платформах, в частности на MS Windows и Mac OS X.
Рассмотрим только канонический случай, то есть установку под Linux. Как принято в мире открытых систем, если кто-то реализует протокол, то код этот будет использоваться и в дальнейшем как референсный. Поэтому в качестве стандарта де-факто используется код, написанный в Мичиганском университете.
Вполне естественно, что открытая версия LDAP называется OpenLDAP. Последний релиз и документацию вы можете найти на — на момент подготовки статьи последняя версия имела номер 2.2.17.
Собственно, всем заведуют две утилиты: slapd — демон LDAP запросов; slurpd — демон репликации.
Дополнительно OpenLDAP предоставляет библиотеки для встраивания LDAP в ваши приложения (приведен также пример клиентского приложения). Библиотека классов для работы с LDAP называется JLDAP — и она тоже доступна как часть дистрибутива OpenLDAP.
Рассмотрим установку OpenLDAP из исходников, поскольку только этот метод гарантирует последнее обновление и, кроме прочего, добавит вам извилин.
Прежде чем устанавливать OpenLDAP, следует обзавестись движком базы данных Sleepycat Berkeley DB — без этого вы не сможете сконфигурировать и скомпилировать OpenLDAP. Для версии OpenLDAP 2.2.17 нужно установить версию Sleepycat 4.2 (текущая подверсия — 4.2.52, закачать ее можно по адресу либо с КП-диска). Для полной уверенности в правильной работе Sleepycat примените два патча, полученные с сайта: скопируйте текстовые файлы патчей в корневой каталог приложения и выполните команды:
patch -p0< patch[2].4.2.52.1.txt
patch -p0< patch[2].4.2.52.1.txt
Полную инструкцию по компиляции BDB под POSIX/UNIX вы можете найти по адресу .
После установки DB можно приступать инсталляции. На момент написания файл архива назывался openldap-stable-20040923.tgz (его тоже можно найти на КП-диске). Если вы не хотите вдаваться в параметры компиляции, тогда просто выполните следующие команды:
cd /usr/src/
tar xfz openldap-stable-20040923.tgz
cd openldap-2.2.17
./configure
make depend
make
make test
make install
Инструментарий
В первую очередь нам понадобится чудесный пакадж (а для кого и пакет - на сайте есть .rpm пакеты) с исходниками SynCE. Скачать его можно на официальном сайте , если у вас их нет. патч для вашего ядра
"Оправдание"
Возможно, вы скажете, что тема данной статьи далека от системного администрирования, но с каждым днем все больше и больше людей становятся счастливыми обладателями устройств под управлением WinCE. И кому же, как не системному администратору иметь под рукой такой гаджет, только далеко не каждый из них имеет установленную Windows на своей машине, а синхронизироваться надо. Именно этой аудитории слушателей и посвящена данная статья.
Пересборка ядра
На этом этапе нам необходимо включить в ядро поддержку PocketPC.
USB SUPPORT -> USB host (если уже не включена)
Далее Serial Converter -> USB generic serial driver
-> USB Compaq iPAQ / HP Jornada / Casio EM500 Driver (Модулем)
Проверка USB
Вставляем iPAQ в крэдл и включаем его. Смотрим /var/log/messages (dmsg). У меня наладонник определился сразу: kernel: usbserial.c: Compaq iPAQ converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
если у вас что-то наподобие: hub.c: new USB device 00:10.2-2, assigned address 3 usb.c: USB device 3 (vend/prod 0x413c/0x4001) is not claimed by any active driver.
то просто подгрузите модуль ipaq: # modprobe ipaq
Соединяемся
Теперь нам надо запустить dccm, только делайте это с правами обычного пользователя (запускайте от root'а только на свой страх и риск!), у меня это пользователь doc: # su doc # dccm
если же у вас на наладоннике стоит пароль, то набирайте: # dccm -p 0000
где 0000 - ваш пароль.
Запускаем наше соединение: # synce-serial-start
Происходит инициализация соединения, если у вас возникли ошибки -> читайте логи.
Теперь в вашем распоряжении еще пара-тройка команд:
pcp - копировать файл.
копировать с машины на PocketPC: # pcp /home/doc/some.file ":/My Documents/Business/some.file"
так же и с PocketPC на машину: # pcp ":/My Documents/Business/some.file" /home/doc/some.file
pls показать содержимое директории
pmkdir создать директорию
pmv переместить или переименовать файл
prm удалить файл
prmdir удалить пустую директорию
prun запустить программу
pstatus показать информацию об устройстве
synce-install-cab инсталлировать .cab файл
Если до конца не понятно как работает программа, то всегда есть замечательная команда man.
Установка и настройка SynCE
Распаковываем исходники SynCE и устанавливаем в систему: # tar zxvf ./synce-xx.xx.tar.gz # cd ./synce-xx.xx.tar.gz # make # make install
Настраиваем на подключение по последовательному порту: # synce-serial-config ttyUSB0
или # synce-serial-config ttyUSB0 192.168.131.102:192.168.131.201 192.168.0.1
где 192.168.131.102 - сервер, 192.168.131.201 - клиент для соединения ppp0, а 192.168.0.1 - DNS сервер.
При написании этой статьи была
При написании этой статьи была использована машина с установленной Slackware Linux 10 (CURRENT), но я думаю, что этот материал будет актуальным и для пользователей других дистрибутивов. В качестве подопытного был использован HP iPAQ 2210.
Атомарные операции
Под атомарными операциями подразумеваются команды изменения данных в оперативной памяти, которые выполняются процессором с полной блокировкой шины памяти, т. е. ни один другой процессор гарантированно не будет конкурировать с монополистом. Так, на платформе i386, для реализации атомарных операций используется специально для этого предназначенный командный префикс lock, заставляющий процессор выполнять следующую команду с блокировкой шины памяти. В Linux в качестве атомарной выбраны операции инкремента и декремента с проверкой счетчика на равенство нулю. (Архитектура i386 также содержит команду test and set bit, которая используется для атомарного изменения бита с одновременной проверкой его.)
Эти примитивы являются наиболее общими случаями для координации параллельных вычислений, на основе которых можно построить семафоры, спин-блокировку и другие, более сложные механизмы координации работы процессоров. Однако для семафоров и спин-блокировок, как частных случаев, есть более эффективные реализации. Впрочем, на некоторых платформах, таких как PowerPC или S390, семафоры реализованы через атомарные операции. В общем коде ядра атомарные операции достаточно распространены.
Фрагменты кода
Кроме этих специализированных функций в ОС Linux в различных местах ядра есть фрагменты кода, которые так же используются только в многопроцессорной конфигурации. Например, такие фрагменты есть в планировщике (функция schedule), в которой предусмотрены механизмы перемещения процессов с одного процессора на другой. Обеспечивается работа с контроллерами прерываний, которых в многопроцессорной системе несколько. Большинство этого кода содержится в файле arch/<arch>/kernel/smp.c. Впрочем часто они опираются на универсальные для Linux многопроцессорные примитивы.
Собственно, поддержка многозадачности была реализована еще в ядре версии 2.0, однако там имелась блокировка всего ядра без выделения отдельных объектов. Версия 2.2 уже позволяла блокировать целиком отдельные крупные объекты, такие как буферы и таблицы. Современная стабильная версия 2.4.20 уже умеет блокировать отдельные записи в очередях и строки в таблицах. Таким образом, разработчики ядра постепенно уменьшают объемы блокируемых фрагментов памяти, что позволяет более эффективно использовать потенциал параллельных вычислений.
Кластерные технологии и распределенные вычисления
С точки зрения ядра операционной системы поддержка кластеров и распределенных систем заключается в эффективной работе с сетью, что выражается во взаимодействии с сетевым процессором. Собственно, сейчас практически любой компьютер является многопроцессорным, кроме центрального процессора есть еще микропроцессоры видеоплат, дисков и сетевых плат. Каждый из процессоров работает со своей собственной операционной системой, которая должна корректно взаимодействовать с ядром Linux. Так, в первом драйвере для платы Gigabit Ethernet каждый полученный по сети пакет вызывал прерывание центрального процессора и, в результате, могла возникнуть ситуация, когда прерываний генерировалось так много, что процессор был полностью загружен их обработкой. В следующих версиях эта проблема была решена путем компоновки пакетов в большие блоки. Тем не менее, разработчикам программного обеспечения постоянно приходится помнить о «многопроцессорности» даже однопроцессорного компьютера.
Следует отметить, что сейчас пропускная способность специальных высокоскоростных компьютерных сетей сравнялась с производительностью внутренней шины. Объясняется это, видимо, тем, что системная шина должна работать синхронно, поэтому развивать их сложнее, чем последовательные технологии передачи, которые обычно работают асинхронно и поэтому развиваются быстрее. Если современные тенденции останутся без изменения, то может оказаться, что кластерные однопроцессорные решения будут даже эффективнее, чем многопроцессорный компьютер. Правда, SMP может возродиться на новом уровне - внутри одного кристалла. Такие решения уже начинают появляться; пример — архитектура HyperThreading, поддерживаемая в процессорах Xeon.
В ОС Linux имеется все необходимое для построения кластеров стандартными средствами — достаточно для нескольких компьютеров сделать единую файловую систему, например, с помощью NFS, и уже можно задействовать такие стандартные для Unix механизмы взаимодействия процессов, как сокеты и разделяемые файлы. Собственно для составления кластера нужно немного — балансировка нагрузки на узлы кластера с перемещением процессов с одного узла на другой. Именно этим и занимается свободно распространяемый пакет Beowulf, который пользуется большой популярностью у создателей кластеров.
Следует отметить, что на кластере нужно исполнять приложения, которые уже написаны с учетом параллельных вычислений и «знают», что разные части программы будут выполняться на разных узлах кластера. Основные стандартные компоненты современных многоуровневых систем, как правило, соответствуют этим требованиям. Так сервер Apache каждый запрос отрабатывает отдельным потоком, и может быть эффективно использован как на одной SMP-машине, так и на сбалансированном по нагрузке кластере. Серверы приложений и баз данных, такие как WebSphere, DB2, Oracle, MySQL, Postgress, также могут быть сконфигурированы с учетом многопроцессорности (а иногда — и многокомпьютерности), что позволяет запускать их на кластере и балансировать нагрузки на каждый узел.
Для взаимодействия процессов, принадлежащих одному приложению, но работающих на разных узлах кластера можно использовать как стандартные для Unix механизмы взаимодействия: потоки, трубы, разделяемые файлы, так и специализированные библиотеки передачи сообщений. Для Linux самыми популярными из таких библиотек являются PVM и MPI, хотя они могут обеспечивать взаимодействие компонентов, работающих под управлением разных операционных систем. Если приложение написано с их использованием, то оно идеально подходит для работы на кластере.
Авторами книги «Параллельные вычисления» Валентином и Владимиром Воеводиными была проведена большая работа по изучению существующих программ, написанных на языке Фортран для решения задач минимизации, линейной алгебры и математической физики. На основе этого исследования ими была разработана теория изучения и выделения параллельной структуры программ для определенного ими линейного класса алгоритмов. Оказалось, что среди 12 тыс. строк, изученных ими алгоритмов, к линейному классу можно свести около 90-95% текстов. Таким образом, постепенно появляются теоретические основы для выделения параллельной структуры алгоритмов с последующей их реализацией в виде параллельных программ. В то же время часто в бизнес-приложениях решаются комбинаторные задачи, которые связаны с изучением небольшой выборки из достаточно большого массива информации.
Собственно, многие ресурсоемкие задачи представляют собой достаточно короткие фрагменты кода, обрабатывающие небольшую выборку данных из большого массива. Такие фрагменты можно выносить на удаленные компьютеры в отдельные потоки и только выдавать им новые порции данных, получать и обрабатывать результат. Именно так и устроено большинство распределенных вычислительных систем, например, seti@home. В них есть центральный сервер, раздающий задания множеству клиентов, получающий и обрабатывающий результаты. Клиенты в большинстве своем работают только в фоновом режиме при минимальной загрузке центрального процессора. Хотя все приложения, которые требуют распределенных вычислений, индивидуальны, имеется базовый набор компонентов, позволяющих упростить создание необходимой инфраструктуры. В качестве примера можно привести свободно распространяемый пакет Globus Toolkit, который позволяет разрабатывать кроссплатформные распределенные системы. Таким образом, для Linux как для наиболее распространенного представителя семейства Unix сегодня имеется полный спектр решений для параллельных вычислений.
Одним из способов повышения производительности
Часто выделяют три технологии обеспечения параллельной работы: симметричные многопроцессорные системы (SMP — symmetrical multiprocessing), кластерные конфигурации и распределенные вычислительные системы (Grid). SMP требует поддержки как со стороны аппаратуры, так и со стороны операционной системы, а кластеры и Grid-среды больше зависят от организации сетевого взаимодействия.
Параллелизм ядра
В ОС Linux имеется поддержка симметричных многопроцессорных архитектур, причем ее реализация не потребовала специальных серьезных изменений в ядре; в рамках постепенной эволюции ядра к нему был добавлен минимальный набор необходимых примитивов.
Для абсолютно независимых процессов, не использующих совместных ресурсов, поддержка SMP не нужна: они будут работать, по возможности используя каждый свой процессор со своей же порцией оперативной памяти, а их общая производительность в двухпроцессорной конфигурации будет почти вдвое больше, чем в однопроцессорной. Использование специальных средств координации нужно только в том случае, когда два процесса пытаются одновременно получить доступ к одному ресурсу, как правило, лежащему в памяти. В этом случае операционная система должна организовать доступ к нему так, чтобы один процессор случайно не испортил результаты работы другого. Для этого в ОС Linux предусмотрена система контроля доступа к областям памяти и блокировок на чтение и запись.
Блокировки требуют соблюдения правил доступа к памяти, на поддержку которых тратятся определенные вычислительные ресурсы, причем даже работая на однопроцессорных компьютерах, поэтому, чтобы не включать в ядро Linux лишний код используется условная компиляция по макроопределению CONFIG_SMP, устанавливаемому утилитой autoconf. Все фрагменты кода, помеченные этим макросом, относятся к многопроцессорной системе; таких мест в общем коде операционной системы, содержащемся в каталоге kernel, восемнадцать. В основном они сосредоточены в планировщике, системе управления потоками, обработке исключительных ситуаций и сигналов, в коде управления таймером. Ядро, собранное с этим макросом, обычно поставляется в отдельном пакете, который устанавливается только в случае необходимости. В частности, если Linux устанавливался на компьютер с одним процессором, а потом в него был добавлен второй, то нужно переустановить ядро.
В ядре Linux для организации параллельных вычислений предусмотрено три группы примитивов: атомарные операции (include/asm-<arch>/atomic.h, где вместо <arch>нужно подставить код соответствующей аппаратной архитектуры), семафоры (include/asm-<arch>/semaphore.h) и спин-блокировка (include/linux/spinlock.h). Из 17 вариантов различных процессорных архитектур, для которых разработана ОС Linux, поддержка SMP не реализована только у четырех: ARM, М68000, SuperH и встроенных сетевых процессорах Etrax. Разберем каждую из этих групп.
Реализация атомарной функции down в ядре Linux
static inline void down(struct semaphore * sem) { __asm__ __volatile__( "# atomic down operation\n\t" /*A*/ LOCK "decl %0\n\t" /* -sem->count */ /*B*/ "js 2f\n" "1:\n" /*C*/ LOCK_SECTION_START("") /*D*/ "2:\tcall __down_failed\n\t" "jmp 1b\n" /*E*/ LOCK_SECTION_END :"=m" (sem->count) :"c" (sem) :"memory"); }
Данная inline-функция уменьшения значения семафора написана на встроенном ассемблере gcc, которым компилируется ядро Linux. В строке, помеченной литерой A, выполняется атомарная операция уменьшения счетчика на единицу. В строке B проверяется стал ли счетчик после этого отрицательным, и если это произошло, управление передается на строку, помеченную литерой D, в которой вызывается функция __down_failed, дожидающаяся освобождения семафора и захватывающая его.
Макрос из строки C определен в файле include/linux/spinlock.h. Он заставляет компилятор собирать фрагмент кода между литерами C и E в отдельной секции ядра. Это означает, что код до строки C вставляется компилятором в тело функции, откуда вызвана down (поскольку она помечена модификатором inline), а для кода между C и E отводиться специальное место в памяти. На него исполнение передается только в случае, если семафор закрыт.
в качестве параметра передается ссылка
#define spin_lock_string \ "\n1:\t" \ /*A*/"lock ; decb %0\n\t" \ /*B*/"js 2f\n" \ LOCK_SECTION_START("") \ /*C*/"2:\t" \ "cmpb $0,%0\n\t" \ "rep;nop\n\t" \ /*D*/"jle 2b\n\t" \ /*E*/"jmp 1b\n" \ LOCK_SECTION_END
Спин-блокировка полностью реализована в виде макроопределения, которому в качестве параметра передается ссылка на блокируемый объект. В строке A делается атомарная попытка захватить объект. Если она не удается, то (строка B) управление передается в отдельную секцию ядра, аналогично тому, как это было сделано в функции down. После этого процесс попадает в жесткий цикл между строками C и D, где постоянно проверяется, освободился объект или нет. Причем эта проверка выполняется не атомарно, т. е. не блокирует шину памяти. Как только объект освободился (строка E) управление передается в начало до строки A для повторной атомарной попытки его захвата.
Семафоры
Семафоры — стандартное средство синхронизации процессов в Unix. Для того чтобы их можно было использовать и в SMP-системах, нужно обеспечить атомарность изменения счетчика семафора, поэтому в многопроцессорных версиях функций up (увеличение счетчика семафора) и down (его уменьшение) также используются атомарные команды (для i386 с префиксом lock). Основное отличие семафора от атомарных операций в том, что он предоставляет стандартный сервис, доступный для пользовательских программ. Есть варианты семафоров, которые останавливают процесс, пока не будут открыты, а есть не блокируемые семафоры, помеченные суффиксом interruptible. Для некоторых платформ семафор базируется на атомарных операциях, а для остальных оказалось лучше написать отдельный, более эффективный код. В частности, для платформы i386 пошли по второму варианту. Впрочем, в общем коде ядра семафоры используются достаточно редко, чаще встречается его частный случай — спин-блокировка.
Спин-блокировка
Термин spin lock можно перевести как «блокировка в цикле» или «вращающаяся блокировка». Однако, похоже, его авторы попытались обобщить понятие спина, как свойство ядерных объектов физической природы, таких как электроны, на ядерные объекты ОС Linux. Мы будем использовать термин «спин-блокировка», чтобы подчеркнуть эту связь. Смысл механизма спин-блокировки состоит в том, чтобы предоставить процессу возможность монопольно захватить какой-либо объект памяти. При этом получить доступ на чтение объекта могут несколько процессов одновременно, но запись может происходить только в том случае, когда нет других читающих и пишущих процессов. Чтобы воспользоваться механизмом спин-блокировки достаточно, чтобы объект имел тип spinlock_t. По сути своей спин-блокировка является частным случаем семафора, однако для всех платформ, поддерживающих SMP, ее реализуют с помощью специального кода.
Генезис
Исследование, предпринятое в настоящей публикации,- эвристическое, поскольку посвящено средствам и методам решения задач. Не побоимся воспользоваться термином "эвристика", употреблявшимся некоторыми философами прошлого, а в наше время наполовину забытым, а наполовину дискредитированным. По существу, большая часть статьи иллюстрирует реальный, практический аспект эвристики: автор делает попытку познакомить читателя с интересными и полезными программными разработками - и тем самым соблазнить его заняться решением собственных проблем и, кроме того, побудить задуматься над методами и средствами, которые при этом применяются.
В общем, сегодня речь пойдет о расширении возможностей операционной платформы Linux с помощью ресурсов, используемых Microsoft Windows, и идей, у нее же заимствованных.
Горячее подключение
Еще один элемент из множества, упрощающих пользователю жизнь,- подсистема Linux hotplugging - позволяет использовать аппаратные средства немедленно после их подключения. Проблема, решаемая этой подсистемой, состоит в минимизации системного администрирования посредством динамического изменения конфигурации операционной системы. Подзадачи, выполняемые hotplugging, подразумевают: связывание драйверов с новыми устройствами; конфигурирование драйверов; конфигурирование устройств; конфигурирование подсистемы; запуск приложений.
Они выполняются системными администраторами при помощи сценариев оболочки, которые именуются policy agents, и утилит. Сценарии используются в случаях, когда важна гибкость. К примеру, способы хранения и управления конфигурационными данными могут различаться в разных дистрибутивах. Особенно широко варьируются такие административные задачи, как настройка сети,- и часто, вместо логичной простоты, предпочтение отдается чрезмерной сложности. Управляет агентами программа /sbin/hotplug (не путать с "Архитектором" :) ). В большинстве случаев сценарии являются не чем иным, как общим клеем; в свою очередь, использование общего hotplug-каркаса представляется шагом к минимизации ненужных вариантов в таких административных средствах.
Первоначально hotplugging включала поддержку USB- и PCI- (Cardbus) устройств и могла автоматически конфигурировать некоторые общие сетевые интерфейсы. Позже была добавлена поддержка IEEE 1394 (Firewire/i.Link) и возможность закачки при необходимости микропрограмм для USB-устройств. Сейчас с hotplugging взаимодействует большинство других подсистем, и ее поддержка присутствует почти во всех современных дистрибутивах Linux, включая RedHat, Debian и United Linux. Большое количество отдельных пакетов использует свои собственные расширения для автоматизации таких операций, как закачка микропрограмм и настольная компоновка.
Начиная с ядра версии 2.4, hotplugging является стандартной подсистемой Linux; работает также с 2.2, а в 2.6 она интегрирована с драйверной моделью, так что любая шина (sysfs-adapted) или драйверный класс могут сообщать о hotplug-событиях, инициированных горячим добавлением или удалением устройств.
Работает подсистема следующим образом. Во время загрузки системы действует системный сервис /etc/rc.d/init.d/hotplug, который управляет инициализацией оборудования, включая "холодное" подключение (cold plugging), посредством вызова файлов /etc/hotplug/тип.rc для каждого типа устройства (usb, pci - для PCI и Cardbus; net - для сетевой организации ит.д.), поддерживаемого системой. Данные типы определены ядром Linux и передаются как первый аргумент к вызовам /sbin/hotplug.
По завершению инициализации вся hotplug-деятельность выполняется сценарием /sbin/hotplug. Ему помогают файлы /etc/hotplug/тип.agent, которые управляют выбором и загрузкой драйверных модулей, основываясь на содержащихся в них данных MODULE_DEVICE_TABLE. За загрузкой модулей следует выполнение драйверов и оборудование специфической инициализации программами /etc/hotplug/тип/модуль. Сценарии эти используются для установки разрешений, запуска демонов, закачки микропрограмм и т.п. Handmap-средства (файлы /etc/hotplug/тип.handmap) ассоциируют сценарии с устройствами, для которых отсутствуют драйверы ядерного режима; usermap-средства (/etc/hotplug/тип.usermap) позволяют конфигурировать устройства, использующие драйверы пользовательского режима. Наконец, необязательные журнальные файлы /etc/hotplug/*.agent служат для хранения записей о событиях, которые были некорректно обработаны.
Также доступно ПО diet hotplug, предназначенное для загрузки ОС с горячо подключаемых устройств. Это исполняемая бинарная версия /sbin/hotplug, не предоставляющая гибкости в администрировании, присущей сценарию,- но работающая в более ограниченной среде, где нельзя воспользоваться bash и схожими с ней инструментальными средствами.
на SourceForge.net.
Конец первой части
В заключение, отметим, что рассмотренные средства и методы чаще всего не являются лучшими в своих областях применения и, тем более, единственными в своем роде. Это те вещи, которые обладают, прежде всего, открытостью (исключение - DriverLoader, где лишь малая часть GPL'd), простотой, новизной, интересностью и известностью… в узких кругах. Статья не претендует на роль исчерпывающей - хотя бы потому, что цель ее состоит в обозначенных в начале "соблазнениях" и "побуждениях".
Как говорится, выводы каждый сделает для себя сам - самостоятельно установив, запустив, и удалив рассмотренное ПО. Этот алгоритм действий можно слепо чтить, придерживаясь его как закона, можно временами делать своего рода "вылазки", можно даже молчаливо бездействовать. Но, с другой стороны, разве это не замечательно: узнавать, искать, экспериментировать, исследовать, пытаться - в свое удовольствие?
Переход в спящий режим / Пробуждение
Энтузиастами Linux community - Найджелом Каннингэмом (Nigel Cunningham), Флоурентом Чейбодом (Florent Chabaud), Павелом Мэйчиком (Pavel Machek) и Гэйбоуром Кьюти (Gabor Kuti) - разработано средство, функциональное назначение которого эквивалентно sleep/wake Windows-систем: выключение машины с сохранением текущего состояния основной памяти на диске и его восстановление при последующей перезагрузке. Как результат: не требуется ни повторного открытия документов, ни перезагрузки приложений. Очевидно, что такой процесс намного быстрее "нормального" выключения и загрузки ОС - это еще не считая времени, затрачиваемого на… вспоминание характера выполняемой работы и используемого ПО, а также его загрузку.
Имя этому средству - Software Suspend for Linux, или swsusp.
Software Suspend for Linux хранит дамп в разделе подкачки - следовательно, последний должен иметь достаточный объем. Кроме того, для корректного использования средства требуется добавить дополнительный параметр в файл lilo.conf (или эквивалентный ему): например: append="resume=/dev/hda1"
Строка эта сообщит программе о том, что /dev/hda1 является swap-разделом и ей придется использовать swap-сигнатуру этого раздела как указатель на данные при приостановке системы. Данный раздел - не обязательно тот, на котором действительно находится информация, это должен быть какой-либо swap-раздел (Sic!).
Пока что swsusp не входит в дерево 2.4.X, посему потребуется загрузить исходный код ядра и воспользоваться последним доступным патчем. Сделав это, следует активизировать соответствующие опции в конфигурационном файле /usr/src/linux/.config, собрать и установить patched-ядро, скорректировать lilo.conf и перезапустить lilo. Теперь остается выполнить перезагрузку, с тем чтобы получить готовую, наиболее элементарную часть Software Suspend.
Что же касается 2.5.X, то swsusp, начиная с 2.5.18, непосредственно включается в основное дерево разработки этого ядра; из-за отличной драйверной модели большая часть функциональности версии 2.4 отсутствует в 2.5, вновь - пока.
Удобным способом использования swsusp является сценарий bash suspend.sh, исполнив который с опцией --install, вы получите пару файлов: сценарий перехода в спящий режим hibernate и его конфигурацию suspend.conf. Размещение их зависит, как известно, от предпочитаемого/используемого вами дистрибутива Linux; в большинстве случаев они должны находится в /usr/local/sbin/hibernate и /etc/suspend.conf.
Алгоритм тестирования новообретенного свойства таков (приведены этапы для Red Hat или Mandrake): Переключение на консоль с помощью сочетания клавиш <Ctrl+Alt+F1>. Получение прав root (Hi, this is Ken. What's the root password?). Останов X-сервера посредством команды init 3. Запуск hibernate.
После этих действий должно произойти "залегание" машины "в спячку". Включив в следующий раз питание компьютера, вы тем самым восстановите предыдущий сеанс работы в той же консоли. Для возвращения в графический режим следует ввести init 5 и залогиниться в X.
Вместе с Software Suspend распространяются опциональные патчи, расширяющие его возможности в плане взаимодействия с другими патчами: acpi-option - для инициирования перехода ко сну с помощью команды вида echo 4 > /proc/acpi/sleep laptop-option - swsusp-совместимый вариант патча работы в лептоповом режиме Джэнс Эйксбо (Jens Axboe); увеличивает время работы от аккумулятора посредством задержки операций записи на диск, пока не окончено чтение,- и тем самым предотвращает необязательные дисковращения; win4lin-option - предоставляет возможность sleep/wake во время работы ПО Win4Lin; bootsplash-option - для использования прогресс-полосы bootsplash вместо обычного текстового экрана; swsusp-*-xfs-option - поддержка XFS-демонов.
Применять эти патчи следует с соблюдением строгого порядка (не требуемые игнорируются): acpi, preempt, Win4lin, bootsplash, kdb, XFS ипр. xfs-option. Software Suspend. Прочие опциональные патчи.
Последнюю стабильную версию Software Suspend (коей на момент написания статьи является 1.0 и иже с ней опции), а также сценарий suspend.sh можно скачать по адресу: prdownloads.sourceforge.net/swsusp/swsusp-1.0-2.4.21.tar.gz? download.
Разделение swap-пространства
Вспоминаются времена, когда объемов жестких дисков для пользовательских нужд было недостаточно. Особенно несладко жилось экспериментаторам, увлеченных поиском краеугольного камня computer science - "уникальной, совершенной и, наконец, бесплатной и не-Windows операционной системы", которым для содержания нескольких систем приходилось предпринимать попытку за попыткой, чтобы хоть сколько-нибудь приблизить отношение "емкость HDD / потребности" к величине, большей или равной единице.
Оказывается, помимо стандартных очисток, уничтожений абсолютно и не очень "не нужных" файлов, попросту себясдерживания и самоограничения, существуют по-своему экзотические методы избавления от этой проблемы. Рассмотрим один из них: совместное использование swap-пространства между Linux и Windows - но сделаем это не столько из-за полезности этого метода (тем более что говорить о полезности во времена 80-долларовых 40-гигабайтных накопителей, по меньшей мере, странно), сколько из любопытства. Все-таки всегда полезно рассмотреть интересное решение.
Предполагается, что наличествует две ОС: один из дистрибутивов Linux и разновидность Windows (приведены действия для минимального соответствия 1:1, но ничто не мешает использовать их и для других, более масштабных вариантов). И, само собой, будем считать, что в нашем распоряжении немного терпения (к слову сказать, это вообще главное требование всех эвристических исследований).
Этапы метода таковы: Linux: отключение (комментирование) подкачки в /etc/fstab; смена типа раздела подкачки с Linux swap на FAT16 или удаление существующего swap-раздела и создание соразмерного ему нового с FAT16; Windows: форматирование новопроинициализированного раздела (ему должна быть назначена буква) и присвоение метки тома swap space; установка его разделом для размещения swap-файла: win386.swp - в Windows 9x, Me; pagefile.sys - в случае Windows NT, 2k или XP; Linux: добавление - монтирования нового раздела в /etc/fstab и команд mkswap и swapon с аргументом /mnt/swap-раздел/swap-файл в /etc/rc.d/rc.local, или эквивалентный ему.
Совместное использование драйверов
Вот мы и подошли к заключительной части обзора, написанной под впечатлением недавно появившейся технологии DriverLoader, как метода sharing-драйверов. Мы остановимся лишь на тех аспектах ее работы, которые показались автору наиболее привлекательными и которые наилучшим образом согласуются с его собственной концепцией эвристики.
По словам разработчиков (молодой канадской компании ), DriverLoader суть идеальное решение поддержки в среде Linux сетевых устройств, для которых отсутствуют необходимые open-source драйверы. Революционная "обертка совместимости" (а на самом деле - еще один модуль ядра) позволяет стандартным драйверам Windows NDIS 5.0 (Network Driver Interface Specification) корректно функционировать в системах платформы Linux x86.
10 октября минувшего года компания представила свое инновационное технологическое "демо" (версию 1.0), посредством которого владельцы устройств 802.11g 54mbps Wireless LAN (шины CardBus и PCI), базирующихся на чипсетах Broadcom, получили возможность пользоваться ими в Linux. А уже 9 ноября вышла версия ПО с поддержкой (кроме Broadcom) Intel PRO/Wireless (Centrino), Intersil (Prism GT/Duette/Indigo), Atheros, Cisco (Aironet), Realtek (RTL8180L) и Texas Instruments (ACX100) WLAN Windows-драйверов. Данные чипсеты используются во многих как лептоповых, так и настольных беспроводных сетевых адаптерах производства Acer, Actiontec, Asus, Belkin, Buffalo/MELCO, Cisco, D-Link, Dell, eMachines, Fujitsu, Gateway, HP/Compaq, IBM, Linksys, Microsoft, Motorola, NETGEAR, SMC, Sony, Toshiba, Z-Com и многих других.
Для конечных пользователей DriverLoader доступна бесплатно. Большинство файлов пакета распространяются на условиях собственной лицензии Linuxant Inc., запрещающей модификацию кода ПО,- остальная же часть (файлы каталога modules/GPL) лицензирована на основе GNU General Public License. Поддерживаются популярные 2.4 и 2.6-ядро-based дистрибутивы Linux: RedHat, SuSE, Mandrake, Debian и производные.
После скачивания требуемого формата пакета (.{арх}.rpm,.deb или.tar.gz), применяется соответствующий метод инсталляции: rpm-i driverloader-{версия}.{арх}.rpm, dpkg -i driverloader_{версия}_{арх}.deb или unpacking+making. Чтобы сконфигурировать устройство, следует выполнить команду dldrconfig (может также использоваться для изменения некоторых опций конфигурации или перекомпиляции модулей ядра после установки его обновлений). Если все прошло без ошибок, для завершения установки остается обратится с помощью веб-браузера по адресу 127.1:18020/ или имя_вашего_хоста:18020/ на DriverLoader's web configurator и пройти авторизацию как root. Потребуется указать программе размещение.inf- и.sys-файлов драйвера (на CD, распространяемом с продуктом, или ) и ключ лицензии (). Теперь, когда процесс окончен, устройство просто обязано появится как нормальный сетевой интерфейс, управляемый обычными средствами дистрибутива (к примеру, redhat-config-network или DrakConf).
Восстановление данных
Это решение должно пригодиться: тем, кто по неосторожности избавился от важного файла, не позаботившись при этом о резервной копии; тем, кто вообще убежден в необратимости операции удаления файлов в Unix-подобных операционных системах; может быть, даже тем, кто (как автор этих строк) просто интересуется красивыми разработками и желает найти аналог средства, с помощью которого можно восстанавливать файлы в среде Windows, для ext2, стандартной файловой системы Linux.
На самом деле файловые данные в действительности не удаляются (но могут быть перезаписаны) и информация, размещаемая в inode (владелец, права доступа, размер, блоки данных, занимаемые файлом и т.д.), не модифицируется - теряется же, прежде всего, связь между именем файла и inode. Чтобы избежать перезаписи дисковых блоков или inodes, прежде занимаемых удаленным (при помощи rm или unlink) файлом, все операции ввода-вывода на соответствующем разделе должны быть немедленно прекращены, а сам раздел демонтирован. Возможен также вариант перемонтирования раздела в режиме "только для чтения".
Далее в ход пускается тяжелая артиллерия - отладчик файловой системы debugfs, предоставляющий возможность raw-доступа к файловой системе. По сути, debugfs является интерактивным интерфейсом к библиотеке ext2fs: он транслирует введенные команды в вызовы функций библиотеки. Для наших целей хватает трех его команд - lsdel, cat и dump: lsdel выводит список всех удаленных файлов, откуда необходимо почерпнуть информацию о требуемых релевантных удаленных inodes. Более или менее полезными полями вывода являются: Owner, Size, Mode и Time deleted; Cat используется для просмотра содержимого inode: cat <номер_inode> наконец, команда dump несет ответственность за восстановление файла, с опцией -p она оставляет атрибуты файла без изменений, вызов ее таков: dump -p <номер_inode>имя_восстановленного_файла
Для автоматизации и облегчения процесса восстановления данных служит утилита, созданная Томом Пиком (Tom Pycke) - recover. Ее работа заключается в поиске и индексировании всех inodes на жестком диске, помеченных как удаленные, с помощью все того же debugfs. Затем пользователю предлагается ответить на некоторые вопросы, связанные с удаленным файлом, как то: название файла-устройства накопителя на жестких дисках, примерные дата и время удаления, приблизительный размер, UID, текстовая строка из файла. Если recover находит подходящие inodes, он запрашивает имя каталога, в который и будут помещены восстановленные файлы.
Переходим к идентификации файлов. Поскольку имя файла не подлежит восстановлению - это факт, то можно попробовать определится хотя бы с типом. Сначала в ход пускается стандартная Unix-утилита file, с помощью которой не составит особого труда опознать файл с исходным текстом программы, написанной на каком-нибудь языке программирования, media-файл, почтовый файл, каталог и т.п. Сложности, однако, возникают с двоичными файлами, к числу которых относятся исполняемые, библиотечные и базы данных. В случае исполняемых файлов на помощь может прийти strings, которая извлекает последовательности ASCII-символов из файла. Библиотеки несколько труднее в идентификации из-за невозможности их исполнения, хотя и здесь есть решение - команда objdump.
Debugfs находится в пакете e2fsprogs: sourceforge.net/projects/e2fsprogs, но, прежде чем брать его из Сети, убедитесь, не установлен ли он с вашего дистрибутива Linux. Адрес последней версии recover.
Жизнь с Linux: совместно используемые ресурсы и… идеи
Андрей Кухар,
Существуют ресурсы, которые хотелось бы использовать, и идеи, применение которых не менее желательно.
О ресурсах и идеях, взятых из окружения Windows и эксплуатируемых в Linux, и пойдет речь