LXF154:По рецептам доктора Брауна - История изменений

Olkol в 07:37, 24 июня 2018

2018-06-24T07:37:33Z

Olkol в 00:26, 17 июня 2018

2018-06-17T00:26:33Z

Olkol в 16:32, 16 июня 2018

2018-06-16T16:32:01Z

Внесённые изменения

Olkol в 08:22, 16 июня 2018

2018-06-16T08:22:14Z

Olkol: Новая страница: «Категория: Постоянные рубрики left {{Врезка|Ширина=25%|Заголовок…»

2018-06-16T08:08:05Z

Новая страница: «Категория: Постоянные рубрики left {{Врезка|Ширина=25%|Заголовок…»

Новая страница

[[Категория: Постоянные рубрики]]
[[Файл:LXF00.tut1.chris2_fmt.png|100px|left]]
{{Врезка|Ширина=25%|Заголовок=|Содержание=Эзотерическое системное администрирование из причудливых заворотов кишок серверной}}
:'''''Д-р Крис Браун''': Доктор обучает, пишет и консультирует по Linux. Ученая степень по физике элементарных частиц ему в этом совсем не помогает.''

==По рецептам доктора Брауна==
===Как небо и земля===
[[Категория:СРАВНЕНИЕ]]
{{Врезка|left|Заголовок=О долговечности
и цифровых данных |Содержание=
Давным-давно у меня было хобби: я записывал музыкальные композиции на цифровых синтезаторах в Cakewalk – приложении для записи и редактирования MIDI, и извел на это кучу времени, причем с приличными результатами. Я подумал было восстановить их – у меня уцелели исходные файлы Cakewalk; но они на дискетах, и мне их не прочитать. Даже если удастся извлечь потоки данных с носителя, сильно сомневаюсь, что любое из современных приложений распознает формат файлов.

Хотя прошло всего 15 лет, информация по сути утрачена. В своей статье Ensuring the Longevity of Digital Information [Обеспечение долговечности цифровой информации] Джефф Ротенберг [Jeff Rothenberg] указывает три уровня, на которых может утеряться цифровая информация: (а) обычная порча носителя; (б) устаревание носителя и устройств для его чтения; (в) развитие форматов документов в направлении обратной несовместимости (в версии 5 не открыть документ, созданный в версии 1). Его статью можно прочесть на www.clir.org/pubs/archives/ensuring.pdf.

===Ротенберг был неправ===

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

Шекспир выразил оптимистичный взгляд на долговечность в своем сонете «Могу ль тебя сравнить я с летним днем?», завершающемся словами: «Жить будешь в них, свой продолжая век, Доколе зрит и дышит человек» [перевод Игоря Фрадкина, – прим. пер.].

Когда речь заходит о хранении цифровых данных, мне ближе точка зрения Клайва Джеймса [Clive James]: «Слова, что имя твое – навек, с моих не сорвутся губ: в забвение канет любой человек, и я не настолько глуп».
|Ширина=25%}}

<big>Трудно представить две книги о системном администрировании, более разные по стилистике и содержанию, чем эти...</big>
[[Категория:СРАВНЕНИЕ]]
{{Врезка|right|Заголовок=Золотая середина|Содержание=

Одна из моих любимых книг по системного администрированию за все времена UNIX and Linux System Administration Handbook [Руководство по системному администрированию систем UNIX и Linux] Немет, Снайдера, Хайна и Уэйли [Nemeth, Snyder, Hein & Wayley]. Она стоит посередине подходов «как» и «почему» описанных мною книг. В ней вы найдете смесь рассказа о командной строке с обширными рассуждениями о лучших подходах. Я рассказывал об этой книге прежде (в LXF139, если у вас есть старые номера), но не могу не порекомендовать ее снова.
|Ширина=25%}}

'''В''' этом месяце я хочу рассказать вам о паре книг. Обе они – по системному администрированию, примерно в той же степени, в которой Моцарт и Джими Хендрикс оба музыканты: потому что на этом сходство и заканчивается.

Первая, Red Hat Certified Technician & Engineer '''[Сертифицированный специалист и инженер Red Hat]''' Асгхара Гхори [Asghar Ghori] – во многом книга из серии «как это сделать», и посвящена Red Hat Linux. Вторая, The Practice of System and Network Administration ['''Практика системного и сетевого администрирования'''] Лимончелли, Хогана и Чалупа [Limoncelli, Hogan & Chalup] – скорее книга из серии «почему», не связанная ни с какой конкретной ОС, не говоря уж о дистрибутиве Linux.

Если вы хотите узнать, какая команда расширит логический раздел, читайте Гхори. Если вы хотите узнать, почему стоит заранее и регулярно выделить время для техобслуживания, читайте Лимончелли (этому у него отведена целая глава).

Книга Гхори предназначена для помощи в сдаче экзаменов RH202 и RH302, но не привязана намертво к заданиям экзаменов – это удобное справочное руководство для администраторов RHEL 5. В начале описываются темы «конечного пользователя» (основные команды, файлы, каталоги, права доступа, редактирование текста и оболочки).

Затем после разочаровывающей главы о написании скриптов оболочки Гхори переходит к темам, интересным системному администратору – установке, управлению пакетами, разделам, менеджеру логических томов, RAID, swap, запуску системы, ядру, резервному копированию и широкому набору сетевых сервисов. Дана масса примеров запуска команд, таблицы параметров команд и файлов настройки – хотя я заcек пару ошибок.

Книга Лимончелли написана на ином уровне. Ее целевая аудитория – сисадмины средних и крупных организаций, и о командной строке речь здесь не идет. Некоторые разделы посвящены устройствам (например, 60-страничная глава о проектировании дата-центра), а некоторые – сервисам (главы о печати, электронной почте, хранилищах, резервном копировании и web-серверах).

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

==Etcetera в иллюстрациях – часть 2==
[[Файл:LXF54.braun1.png|400px|right]]

''Месяц за месяцем изучайте файлы в /etc по нашему удобному руководству. Познакомимся с fstab.''

'''Ф'''айл /etc/fstab (сокращение от “filesystem table” – таблица файловой системы) определяет, как вся файловая система Linux формируется из различных источников (дисковые разделы, логические уровни, экспортируемые каталоги NFS и т. д.), образуя единую иерархию. В нем задаются файловые системы (с технической точки зрения, блочные устройства) и их точки монтирования в дереве каталогов Linux. Этот файл применяется много лет. Его синтаксис достаточно прост, но если вы не уверены в {{Врезка|right|Заголовок=Рис. 1.|Содержание=
Синтаксис fstab достаточно прост, но в случае ошибок система может перестать загружаться правильно.
|Ширина=20%}}своем знании, изменять этот файл не стоит – ошибка здесь может привести к тому, что система перестанет загружаться.
{{Врезка|left|Заголовок=Точки монтирования|Содержание=
Точка монтирования – просто каталог, используемый как точка присоединения для подключения файловой системы в дерево каталогов. В нем нет ничего экзотического, хотя обычно этот каталог пуст. Если он не пуст, его содержимое будет перекрыто смонтированной файловой системой. Возможно многоуровневое монтирование, но этот подход не слишком распространен.
|Ширина=25%}}

Три примера строк из этого файла на первом рисунке иллюстрируют три способа определения монтируемой файловой системы. Традиционное имя устройства, такое как /dev/sda6 – самый старый и самый простой способ, но он может привести к проблемам при добавлении новых дисков, так как изменятся имена устройств. Более надежный вариант – использовать текстовую метку, записываемую в раздел при создании файловой системы. Обычно текст метки соответствует планируемой точке монтирования. В порядке альтернативы, здесь можно указать UUID. В средней строке на рисунке показана запись для монтирования NFS с файлового сервера foo. Доступ к этим файлам осуществляется по протоколу NFS – это не считается блочным устройством, и мы не запускаем fsck для этой части файловой системы: делать это нужно на сервере.

Монтирования для записей, приведенных на рис. 1, выполняются автоматически, обычно командной mount -a в загрузочном скрипте.

Строки на рис. 2 служат другой цели. Здесь опция noauto означает, что запись будет проигнорирована командой mount -a (и монтирование во время загрузки производиться не будет). Вместо этого строка связывает имя устройства с точкой монтирования, поэтому его можно смонтировать простой командой:

$ mount /dev/sdc

вместо

$ mount /dev/sdc /media/cdrom

Опция user означает, что монтировать устройство могут обычные пользователи. По умолчанию монтировать и размонтировать устройства может только суперпользователь-root.

В файле fstab вы также увидите записи, которым соответствуют не физические файловые системы, а псевдофайловые системы, которые являются лишь плодом воображения ядра. Они представляют структуры данных ядра в виде файлов. В них входят файловая система proc (обычно монтируется в /proc) и файловая система sysfs (монтируется в /sys).

[[Файл:LXF54.braun2.png|right|500px]]

{{Врезка|right|Заголовок=Рис. 2.|Содержание=
Типичная запись в fstab для съемных устройств типа CD или DVD, которая позволяет их монтировать обычным пользователям.
|Ширина=20%}}

==Etcetera в иллюстрациях – часть 3==

''Теперь настал черед знакомства с файлом nsswitch.conf – указателем
на источники информации.''
{{Врезка|left|Заголовок=Рис.3.|Содержание=
Типичная запись в fstab для съемных устройств типа CD или DVD, которая позволяет их монтировать обычным пользователям.
В файле /etc/nsswitch.conf указываются доступные источники информации для поиска имен хостов и пользователей, а также других сведений.|Ширина=20%}}
[[Файл:LXF54.braun3.png|right|500px]]
В стандартной библиотеке C в Linux есть семейство функций, называемых «разрешителями»: они разрешают запросы. Так, функция getpwuid() находит учетную запись пользователя по его числовому идентификатору, а функция gethostbyname() находит компьютер по имени, возвращая (среди прочего) его IP-адрес. А, скажем, функция getservbyname() ищет сервис по имени, возвращая номер его порта и протокол.

Эти функции существуют с давних пор – они были в UNIX еще до того, как проблеск Linux мелькнул в глазах Линуса Торвальдса. В те далекие времена информация размещалась в локальных файлах, таких как /etc/passwd, /etc/hosts и /etc/services – и больше ничего не было. Позже появились другие источники информации. Например, в Sun Microsystems придумали NIS, и у нас появился DNS для разрешения имен хостов. Sun также добавила несколько примочек, чтобы «разрешители» искали информацию более чем в одном месте. Как будто припоминаю, что строки в /etc/passwd, начинавшиеся с «+», велели «разрешителю» также пойти и заглянуть в NIS.

Современные «разрешители» используют более элегантный и наращиваемый механизм направления к определенному источнику информации – так называемый файл переключения сервисов имен (Name Service Switch) /etc/nsswitch.conf. Формат этого файла показан на рисунке вверху. Он достаточно прост, хотя содержит одно неочевидное обозначение – [NOTFOUND=return], которое представляет собой пример действия. Оно предоставляет более тонкий контроль над логикой процесса поиска, связывая статус запроса (один из списка SUCCESS, NOTFOUND, UNAVAIL или TRYAGAIN) с действием (return или continue). Обратите внимание, что статус NOTFOUND означает, что сервис был успешно опрошен, но сообщил, что у него нет данных в ответ на полученный запрос, а не то, что не удалось найти сам сервис.
{{Врезка|left|Заголовок=Вкратце|Содержание=
«За кулисами» всю трудную работу выполняют библиотеки (их имена указаны напротив источников данных в nsswitch.conf).
|Ширина=20%}}
Наращиваемость механизма поиска означает, что можно добавлять новые источники информации. Это работает благодаря тому, что в nsswitch.conf задается простое соответствие между именами сервисов и библиотеками, их реализующими. Например, встретив mdns4 в записи hosts в nsswitch.conf, разрешитель имени хоста выполнит запрос с использованием разделяемой библиотеки /lib/libnss_mdns4.so. Интерфейс для доступа к этим библиотекам стандартный, поэтому разработчик может добавить собственный сервис.
[[Файл:LXF54.braun4.png|left|300px]]
При добавлении библиотеки libnss_xyz он добавляет источник информации xyz. Функции разрешителя верхнего уровня (и вызывающие их программы) вызовут его автоматически, если xyz есть в файле nsswitch.conf. В некоторых дистрибутивах Linux есть графические утилиты для редактирования nsswitch.conf. Утилита systemconfig-authentication в Fedora позволяет задать источник информации об учетной записи пользователя. В Ubuntu для тех же целей можно воспользоваться скриптом authclientconfig, хотя его основное назначение – облегчение обновления nsswitch.conf со стороны установочных скриптов пакетов. Полная документация по nsswitch.conf имеется на http://www.gnu.org/s/hello/manual/libc/Name-Service-Switch.html.

@@ Строка 124: / Строка 124: @@
 Linux поддерживает RAID на уровне сопоставителя устройств внутри ядра, а настраивается RAID утилитой командной строки mdadm, которая позволяет создавать, наращивать и управлять устройствами программного RAID. У этой утилиты масса параметров, и внимательное чтение ее man-страницы может запросто занять целый вечер. В вашей системе она может быть не установлена по умолчанию. Например, в Ubuntu потребуется пакет mdadm:
-$ sudo apt-get install mdadm
+<pre> $ sudo apt-get install mdadm </pre>
 Рассмотрим пример. Пусть у вас четыре диска (sdb, sdc, sdd и sde), и вы хотите сформировать из них массив RAID 5. Следующая команда сделает всю работу:
-# mdadm -C /dev/md0 -n4 /dev/sdb /dev/sdc /dev/sdd /dev/sde -l5
+<pre># mdadm -C /dev/md0 -n4 /dev/sdb /dev/sdc /dev/sdd /dev/sde -l5</pre>
@@ Строка 199: / Строка 199: @@
 *Здесь RAID 0 реализован поверх RAID 1.
 |Ширина=40%}}
 Теперь на этом устройстве RAID можно создать файловую систему точно так же, как на обычном разделе диска или на любом другом блочном устройстве:
-# mke2fs -j /dev/md0
+<pre># mke2fs -j /dev/md0</pre>
 Затем ее можно смонтировать или добавить в /etc/fstab обычным образом.
@@ Строка 211: / Строка 212: @@
 Устройство RAID /dev/md0, которое мы только что создали, не будет повторно создано после перезагрузки системы, если не добавить соответствующую строку в файл /etc/mdadm.conf. Можно сделать так, чтобы mdadm добавила ее за нас – примерно так:
-# mdadm --examine --scan >> /etc/mdadm.conf
+<pre># mdadm --examine --scan >> /etc/mdadm.conf</pre>
 Или можно вручную пересоздать устройство RAID:
-# mdadm --assemble --scan
+<pre># mdadm --assemble --scan</pre>
 ==Нет новостей — это хорошая новость==
@@ Строка 221: / Строка 222: @@
 Итак, ваш массив RAID жужжит себе помаленьку, но однажды утром один из дисков выходит из строя. К счастью, устройство RAID продолжит функционировать, а сервер продолжит работать: его единственная причина жить – оставаться рабочим в подобных обстоятельствах. Но теперь у вас нет избыточности, и хотя вероятность, что в тот же день выйдет из строя другой диск, мала (с той же вероятностью можно получить второй прокол по дороге в гараж на проколотой шине), вы должны узнать о неисправности, чтобы поскорее заменить поврежденный диск. Для этого можно воспользоваться mdadm в режиме мониторинга. В моей CentOS 5 для этого используется сервис mdmonitor, запускаемый при старте системы. Его можно запустить, скомандовав
-# service mdmonitor start
+<pre># service mdmonitor start</pre>
 А настроить его запуск при старте системы можно командой
-# chkconfig mdmonitor on
+<pre># chkconfig mdmonitor on</pre>
 В режиме мониторинга mdadm будет наблюдать за состоянием устройств RAID и создавать события, если произойдет что-то важное. События включают DeviceDisappeared, RebuildStarted, RebuildFinished, Fail и FailSpare. Некоторые из этих событий (касающиеся плохих новостей) приведут к том, что на адрес назначения, указанный в mdadm.conf, будет отправлено письмо. Вам понадобится нечто вроде этого:
-MAILADDR chris@localhost
+<pre>MAILADDR chris@localhost</pre>
 Если для отслеживания состояния системы вы пользуетесь утилитой уровня предприятия вроде Nagios, к ней есть модуль расширения для отслеживания состояния устройств RAID. Наверное, не помешает проверить правильность реакции RAID на отказ диска еще до этого отказа. Отказ диска легко имитируется следующим образом:
+<pre>
 # mdadm /dev/md0 --fail /dev/sdc
@@ Строка 249: / Строка 250: @@
 8 64 3 active sync /dev/sde
-8 32 - faulty spare /dev/sdc
+8 32 - faulty spare /dev/sdc </pre>
-Если ваш бюджет позволяет вам приобрести лишний диск, можете применить его для «горячей замены», воспользовавшись опцией --spare-devices команды mdadm. Это купит вам ощущение спокойствия. Диски «горячей замены» также можно совместно использовать в нескольких устройствах RAID, поместив их в одну разделяемую группу. Подробнее о программном RAID в Linux расскажут man-страницы mdadm и mdadm.conf; или зайдите на raid.wiki.kernel.org.
+Если ваш бюджет позволяет вам приобрести лишний диск, можете применить его для «горячей замены», воспользовавшись опцией --'''spare-devices''' команды '''mdadm'''. Это купит вам ощущение спокойствия. Диски «горячей замены» также можно совместно использовать в нескольких устройствах RAID, поместив их в одну разделяемую группу. Подробнее о программном RAID в Linux расскажут man-страницы '''mdadm''' и '''mdadm.conf'''; или зайдите на '''raid.wiki.kernel.org.'''

@@ Строка 1: / Строка 1: @@
 [[Категория: Постоянные рубрики]]
 [[Файл:LXF00.tut1.chris2_fmt.png|100px|left]]
-{{Врезка|Ширина=25%|Заголовок=|Содержание=Эзотерическое системное администрирование из причудливых заворотов кишок серверной}}
+{{Врезка|Ширина=98%|Заголовок=Эзотерическое системное администрирование из причудливых заворотов кишок серверной|Содержание=}}
 :'''''Д-р Крис Браун''': Доктор обучает, пишет и консультирует по Linux. Ученая степень по физике элементарных частиц ему в этом совсем не помогает.''

@@ Строка 59: / Строка 59: @@
 Монтирования для записей, приведенных на рис. 1, выполняются автоматически, обычно командной mount -a в загрузочном скрипте.
 Строки на рис. 2 служат другой цели. Здесь опция noauto означает, что запись будет проигнорирована командой mount -a (и монтирование во время загрузки производиться не будет). Вместо этого строка связывает имя устройства с точкой монтирования, поэтому его можно смонтировать простой командой:
@@ Строка 83: / Строка 82: @@
 ''Теперь настал черед знакомства с файлом nsswitch.conf – указателем
 на источники информации.''
-{{Врезка|left|Заголовок=Рис.3.|Содержание=
   Типичная запись в fstab для съемных устройств типа CD или DVD, которая позволяет их монтировать обычным пользователям.
 В файле /etc/nsswitch.conf указываются доступные источники информации для поиска имен хостов и пользователей, а также других сведений.|Ширина=20%}}
 Эти функции существуют с давних пор – они были в UNIX еще до того, как проблеск Linux мелькнул в глазах Линуса Торвальдса. В те далекие времена информация размещалась в локальных файлах, таких как /etc/passwd, /etc/hosts и /etc/services – и больше ничего не было. Позже появились другие источники информации. Например, в Sun Microsystems придумали NIS, и у нас появился DNS для разрешения имен хостов. Sun также добавила несколько примочек, чтобы «разрешители» искали информацию более чем в одном месте. Как будто припоминаю, что строки в /etc/passwd, начинавшиеся с «+», велели «разрешителю» также пойти и заглянуть в NIS.
 {{Врезка|left|Заголовок=Вкратце|Содержание=
-Современные «разрешители» используют более элегантный и наращиваемый механизм направления к определенному источнику информации – так называемый файл переключения сервисов имен (Name Service Switch) /etc/nsswitch.conf. Формат этого файла показан на рисунке вверху. Он достаточно прост, хотя содержит одно неочевидное обозначение – [NOTFOUND=return], которое представляет собой пример действия. Оно предоставляет более тонкий контроль над логикой процесса поиска, связывая статус запроса (один из списка SUCCESS, NOTFOUND, UNAVAIL или TRYAGAIN) с действием (return или continue). Обратите внимание, что статус NOTFOUND означает, что сервис был успешно опрошен, но сообщил, что у него нет данных в ответ на полученный запрос, а не то, что не удалось найти сам сервис.
- {{Врезка|left|Заголовок=Вкратце|Содержание=
 «За кулисами» всю трудную работу выполняют библиотеки (их имена указаны напротив источников данных в nsswitch.conf).
 |Ширина=20%}}
 Наращиваемость механизма поиска означает, что можно добавлять новые источники информации. Это работает благодаря тому, что в nsswitch.conf задается простое соответствие между именами сервисов и библиотеками, их реализующими. Например, встретив mdns4 в записи hosts в nsswitch.conf, разрешитель имени хоста выполнит запрос с использованием разделяемой библиотеки /lib/libnss_mdns4.so. Интерфейс для доступа к этим библиотекам стандартный, поэтому разработчик может добавить собственный сервис.
-[[Файл:LXF54.braun4.png|left|300px]]
 При добавлении библиотеки libnss_xyz он добавляет источник информации xyz. Функции разрешителя верхнего уровня (и вызывающие их программы) вызовут его автоматически, если xyz есть в файле nsswitch.conf. В некоторых дистрибутивах Linux есть графические утилиты для редактирования nsswitch.conf. Утилита systemconfig-authentication в Fedora позволяет задать источник информации об учетной записи пользователя. В Ubuntu для тех же целей можно воспользоваться скриптом authclientconfig, хотя его основное назначение – облегчение обновления nsswitch.conf со стороны установочных скриптов пакетов. Полная документация по nsswitch.conf имеется на http://www.gnu.org/s/hello/manual/libc/Name-Service-Switch.html.