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

LXF149:Sysadmin

Материал из Linuxformat
Версия от 15:55, 23 июля 2014; 2sash-kan (обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск
Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)

Содержание

По рецептам доктора Брауна

Д-р Крис Браун Доктор обучает, пишет и консультирует по Linux. Ученая степень по физике элементарных частиц ему в этом совсем не помогает.


Освежающе просто

BitNami Не бейтесь над установкой кучи сложных программ – всю черную работу сделает BitNami.

BitNami (http://bitnami.org) предлагает обширный набор заранее подготовленных программных стеков для установки на ваши серверы. Я насчитал 40, в том числе Drupal, Joomla, Tomcat и популярный стек LAMP.

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

Стеки доступны в трех формах:

  1. Стеки, которые можно установить в Linux.
  2. Образы виртуальных компьютеров (иногда называемые «виртуальными устройствами»), которые запускаются в гипервизоре, вроде VMware.
  3. Образы компьютеров Amazon, разворачиваемые на облаке EC2.

Я выбрал стек Moodle (виртуальная система обучения) и попробовал все три метода:

  • Способ 1 – сжатые самоустанавливающиеся двоичные файлы, скомпилированные InstallBuilder от BitRock, создают самодостаточную установку (по умолчанию – в каталоге /opt), которая включает все зависимости, поэтому она а) устанавливается где угодно, и б) не влияет на уже установленные программы. Однако в Fedora мне пришлось временно отключить SELinux, иначе установщик BitRock принимался чудить.
  • Способ 2 оказался еще проще. От начала до конца на него ушло всего 15 минут (загрузка, распаковка, загрузка системы с образа VMware и вход в Moodle в браузере).
  • Способ 3 оказался самым быстрым (отняв менее пяти минут), но в этом случае вы должны иметь учетную запись Amazon Web Services, и за работу с сервером взимается почасовая оплата.

BitNami реально помогает распространению открытого ПО и делает это бесплатно.


Рулим окнами терминала

Byobu Запустите несколько сеансов командной строки (и наблюдайте за состоянием системы) в одном терминале.

У тех, кто работает в командной строке, наверняка есть привычка держать открытыми дюжину терминалов: парочку для работы на удаленных серверах, один для чтения почты, один с открытой man-страницей, один с открытым файлом настройки и т. д.

На рабочем столе Linux для этого достаточно открыть несколько окон терминала или несколько вкладок в одном окне. Но на серверах обычно нет доступа к рабочему столу. Тем не менее, если перед вами консоль сервера, на ней обычно доступны шесть виртуальных терминалов, между которыми легко переключаться клавишами Alt+F1 – Alt+F6.

Однако на удивление много народу – и среди них те, которых я обучал на курсах – работают с Linux через единственный сеанс SSH, часто из Windows-клиента SSH, типа Putty. Для них это единственное окно в мир Linux размером 80 × 24 символа может быть тесным.

Для решения данной проблемы отличные парни из GNU написали утилиту под названием Screen. Идея Screen в том, чтобы объединить множество сеансов командной строки в одном терминале и позволить вам переключаться между ними с помощью горячих клавиш. Screen работает прекрасно, хотя и довольно прост.

Дастин Керкленд [Dustin Kirkland] слегка приодел Screen оберткой под названием Byobu. Основные задачи Screen – позволить вам открывать новые окна и переключаться между ними, а самое заметное нововведение, которое Byobu добавляет к исходной программе – две строки с информацией о состоянии системы внизу.

В них может отображаться разная информация – например, дата и время, имя пользователя, имя хоста и IP-адрес, использование памяти и жесткого диска и даже примерная стоимость запуска системы на облаке Amazon EC2.

Чтобы выбрать тип отображаемой информации, нужно либо вручную изменить файл ~/.byobu/status и включить и отключить там необходимые параметры, либо задать настройки в окнах конфигурации Byobu. Можно даже полностью отключить одну или обе строки с помощью команд byobu-quiet и byobu-silent.

Дадим волю фантазии

Начальный набор окон для открытия автоматически при запуске Byobu определяется указанием их командных строк в файле ~/.byobu/windows. Например, три строки 

screen -t top top
screen -t logs tail -f /var/log/dmesg
screen -t shell /bin/bash

запустят три окна. Здесь мы видим вызов внутренней команды screen. Параметр -t задает заголовок окна, отображаемый в строке состояния. В Byobu также есть меню для создания нового окна на лету, задания его заголовка и добавления его в список по умолчанию.

Если объединения нескольких окон в один терминал недостаточно, в Byobu также можно разбить любое из окон – как по горизонтали, так и по вертикали – для одновременной работы с несколькими сеансами.

Конечно, если переборщить, окна станут чересчур мелкими, но разделение окна на две части очень удобно. На экранном снимке приведен пример окна, разбитого по горизонтали. В верхней части открыто встроенное меню настройки Byobu, в нижней – Top [англ. верх], что немного сбивает с толку, но я не нарочно! Помните, что все это работает в обыкновенном текстовом терминале – графический рабочий стол не нужен.

Оставшегося места хватит на рассказ об одной из возможностей Byobu. Написав собственный скрипт (или любую исполняемую программу), собирающий определенные данные и отсылающий их на стандартный вывод, можно вывести результат в строку состояния. Скрипт должен находиться в каталоге ~/.byobu/bin и иметь название в виде XX_NAME, где XX – период запуска скрипта в секундах.

Например, я написал скрипт ~/.byobu/bin/10_pcount, который просто подсчитывает количество запущенных процессов: 

#!/bin/sh
COUNT=$(ps -ef | grep chris | wc -l)
echo $COUNT

Эту возможность нужно включить в файле статуса: 

custom=1

После этого число процессов должно появиться в строке состояния.

В общем и целом, обертка Byobu – не предел учености и гламурности, но польза от нее есть.


Мониторинг производительности

Collectd За каждым большим графиком стоит большой агент сбора данных.

Существует немало утилит с web-интерфейсом, которые строят аккуратные графики загрузки системы и производительности ваших серверов. На ум приходит Landscape, (https://landscape.canonical.com), а также Munin (http://munin-monitoring.org) и Cacti (http://cacti.net). Некоторые из этих программ используют RRDtool Тоби Этикера [Tobi Oetiker] (www.mrtg.org/rrdtool) для хранения данных и построения графиков, и все они пользуются какими-либо агентами сбора данных.

Collectd (http://collectd.org) – демон, который собирает статистику производительности системы через равные интервалы времени и сохраняет значения несколькими способами. Правда, он только копит замеры производительности, но не содержит механизма их отображения. Собственно, сам демон Collectd делает очень немногое. Это лишь связующий элемент, который скрепляет собой огромный набор модулей расширения. Есть пять типов таких модулей – они приведены в таблице внизу. Как видите, большинство их предназначено для сбора данных. Модули существуют практически для всего, что ни вообрази – стандартных данных, таких как использование процессора и памяти и объем свободного места на диске; статистики сервисов, в том числе частота TCP-соединений, пропускная способность NFS-сервера и трафика DNS; можно даже определить температуру жесткого диска (с помощью SMART). Полный список модулей приведен на странице http://collectd.org/wiki/index.php/Table_of_Plugins.

Отслеживаем

Все компоненты связываются вместе в файле настройки /etc/collectd/collectd.conf. Вот его сокращенная версия – номера строк добавлены для удобства ссылок: 

1. LoadPlugin syslog
2. <Plugin syslog>
3. LogLevel info
4. </Plugin>
5. LoadPlugin battery
6. LoadPlugin cpu
7. LoadPlugin df
8. LoadPlugin disk
9. LoadPlugin entropy
10. LoadPlugin load
11. LoadPlugin memory
12. LoadPlugin processes
13. LoadPlugin rrdtool
14. LoadPlugin swap
15. LoadPlugin users
16. <Plugin rrdtool>
17. DataDir “/var/lib/collectd/rrd”
18. </Plugin>
19.
20. #LoadPlugin apache
21. #<Plugin apache>
22. # <Instance “foo”>
23. # URL “http://localhost/server-status?auto”
24. # User “www-user”
25. # Password “secret”
26. # VerifyPeer false
27. # VerifyHost false
28. # CACert “/etc/ssl/ca.crt”
29. # Server “apache”
30. # </Instance>
31. #</Plugin>

В строке 1 загружается модуль журналирования syslog, а в строках 2 – 4 он настраивается. В строках с 5 по 15 загружаются простые модули для ввода данных; они не требуют дальнейшей настройки. В строках с двадцатой и далее показан закомментированный пример модуля ввода данных Apache. Вообще в файле масса закомментированных примеров, которыми вы можете воспользоваться. В нашем примере не показан параметр Interval (по умолчанию равен 10 секундам). Если результаты хранятся в файле RRD, это значение нужно выбирать заранее, потому что из-за природы баз данных RRD при изменении этого интервала придется начинать все сначала и удалять базы данных.

С конфигурацией, заданной в этом файле, и запущенным демоном данные будут собираться в базы данных RRD (RRD-файлы) в каталогах в /var/lib/collectd/rrd/machine-name. У каждого модуля один или несколько каталогов. Не опасайтесь, что ваш диск будет постепенно переполняться данными: карусельная природа баз данных RRD означает, что их размер фиксирован и не увеличивается с течением времени. В дальнейшем можно объединить данные или построить графики с помощью стандартных средств RRD.

Чтобы увидеть отличный web-интерфейс для просмотра данных, собранных Collectd, зайдите на сайт Сергиуша Павловича [Sergiusz Pawlowicz] – https://pawlowicz.name/MyServers.

Пять типов модулей

ТИП МОДУЛЯ НОМЕР ЧТО ОН ДЕЛАЕТ
Input [Вход] 80 «Уши» Collectd. Периодически собирает данные (путем чтения /proc, мониторинга сетевого трафика, опроса датчиков устройств и т.д.).
Output [Выход] 6 Сохраняет данные или готовит их для последующей обработки. Например, модуль CSV записывает данные (через запятую) в текстовые файлы, пригодные для импорта в редактор электронных таблиц. Модуль RRDtool записывает значения в файлы RRD.
Logging [Журналирование] 2 Модуль LogFile записывает сообщения в файл журнала; модуль SysLog отправляет их в syslog.
Notification [Оповещение] 2 Отображает предупреждение, когда отслеживаемое значение выходит за пределы заданного диапазона.
Binding [Связывание] 3 Позволяет встроить интерпретаторы Perl, Python и Java в Collectd, чтобы на этих языках можно было писать дополнительные модули без запуска внешнего процесса.


Сборка из исходников

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

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

Но иногда некоторые из нас – особенно те, кто падок до новинок мира открытого ПО – решают скомпилировать приложение из исходников. В большинстве случаев код мы не трогаем – а обычно даже не читаем его. Мы просто загружаем его и компилируем. Работают над ним лишь немногие.

Для примера я решил загрузить и скомпилировать утилиту сжатия и архивации P7zip, которую можно найти на http://sourceforge.net. Имя загружаемого файла было таким: p7zip_9.20.1_src_all.tar.bz2, откуда можно заключить, что это сжатый tar-архив. Я загрузил его в подходящий каталог (я выбрал ~/Download) и распаковал таким образом: 

$ tar xjvf p7zip_9.20.1_src_all.tar.bz2

Обычно архив распаковывается в собственный отдельный каталог; в данном случае это p7zip_9.20.1. В этом каталоге найдите файл с названием README или INSTALL, где должны быть инструкции по сборке приложения. В данном случае нас побаловали довольно подробным README.

Сделай сам

Сборку некоторых пакетов программ с открытым исходным кодом выполняет утилита под названием Autoconf, которая создает «умный» конфигурационный скрипт. Его нужно запустить на первом этапе сборки пакета. Скрипт проверяет окружение компьютера, убеждается, что в системе есть все необходимое для сборки пакета, и создает makefile, который скомпилирует пакет на вашем компьютере. В P7zip этот механизм не используется; вместо этого предлагается выбрать подходящий makefile из 50 приложенных вариантов и скопировать его в нужный каталог. Поэтому мои команды для сборки пакета выглядят так: 

$ cp makefile.linux_any_cpu makefile.machine
$ make

make выполняет всяческие компиляции с G++ и GCC и в итоге создает исполняемый файл в каталоге p7zip_9.20.1/bin/7za. Пока все наши действия ограничивались каталогом загрузки и выполнялось от имени обычного пользователя. Но обычно программу удобно установить в подходящем системном каталоге, для чего нужны права администратора. В makefile часто есть цель install, поэтому достаточно выполнить команду:

  1. make install

В P7zip вместо нее есть скрипт установки (install.sh). Для указания каталога верхнего уровня, где будет установлено приложение, этот скрипт использует переменную окружения (DEST_HOME). Каталог, рекомендуемый для размещения локально скомпилированных программ – /usr/local: тогда они отделены от программ, установленных системой, большинство из которых находится в /usr. (Вообще говоря, согласно стандарту иерархии файловой системы программы следует устанавливать в /opt, но большинство людей игнорируют эту рекомендацию.) В нашем случае /usr/local – каталог установки по умолчанию, и для установки пакета достаточно просто запустить скрипт, не изменяя его: 

# ./install.sh

Он разместит двоичные файлы в /usr/local/bin, man-страницы (если они есть в пакете) – в /usr/local/man, и т. д. Вот и все. У меня есть работающая программа (7za) и связанные с ней man-страницы, и все это без файлов RPM или Deb.


Установка из исходников: за и против

ЗА ПРОТИВ
Вы получаете доступ к приложениям, которых нет в репозиториях дистрибутива, или к более свежим версиям программ. С зависимостями придется разбираться самим – например, проверять, все ли необходимые библиотеки есть в системе. Иногда это тяжкое бремя.
Можно выбирать функции, вставляемые в приложение, и каталоги, где разместить двоичные файлы, библиотеки, man-страницы и файлы настройки. За проверку обновлений и их своевременную установку будет отвечать не кто иной как вы.
Можно проанализировать и изменить исходный код в соответствии со своими нуждами. Нужно устанавливать соответствующую цепочку утилит для сборки – например, компиляторы GCC и G++ и утилиту Make.
Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF149:Sysadmin&oldid=15462»
Персональные инструменты
купить
подписаться
Яндекс.Метрика