LXF165-166:Рубрика сисадмина
Olkol (обсуждение | вклад) (Новая страница: «Категория:Постоянные рубрики Д-р Крис Браун Доктор обучает, пишет и консультирует п…») |
Olkol (обсуждение | вклад) |
||
Строка 1: | Строка 1: | ||
[[Категория:Постоянные рубрики]] | [[Категория:Постоянные рубрики]] | ||
− | + | '''''' | |
− | Доктор обучает, пишет и консультирует по Linux. Ученая степень по физике элементарных частиц ему в этом совсем не помогает. | + | '''Доктор обучает, пишет и консультирует по Linux. Ученая степень по физике элементарных частиц ему в этом совсем не помогает.''' |
− | + | == По рецептам доктора Брауна == | |
+ | ''Эзотерическое системное администрирование из причудливых заворотов кишок серверной'' | ||
+ | ====== | ||
+ | [[Файл:Chris_fmt.png |left |100px |thumb|'''Д-р Крис Браун''' обучает, пишет и консультирует по Linux. Ученая степень по физике элементарных частиц ему в этом совсем не помогает]] | ||
+ | {{Врезка|left|Заголовок= Расширение учебного портфолио|Ширина=40%|Содержание= | ||
Linux Foundation предлагает несколько учебных программ, но если раньше они предназначались для настоящих экспертов в области ядра (например, «Внутреннее устройство и отладка ядра Linux» или «Отладка драйверов устройств в Linux»), то недавно учебное портфолио было расширено и включило курсы для пользователей и администраторов, такие как «Администрирование Linux» или «Архитектура облака и его развертывание». Компания предлагает и более короткие программы продолжительностью от двух часов до двух дней, касающиеся щекотливой темы совместимости открытого ПО, в которой я так несведущ, что даже не знаю, что с чем должно быть совместимо или (ближе к теме) почему совместимость открытых программ обеспечить сложнее, чем совместимость закрытых. | Linux Foundation предлагает несколько учебных программ, но если раньше они предназначались для настоящих экспертов в области ядра (например, «Внутреннее устройство и отладка ядра Linux» или «Отладка драйверов устройств в Linux»), то недавно учебное портфолио было расширено и включило курсы для пользователей и администраторов, такие как «Администрирование Linux» или «Архитектура облака и его развертывание». Компания предлагает и более короткие программы продолжительностью от двух часов до двух дней, касающиеся щекотливой темы совместимости открытого ПО, в которой я так несведущ, что даже не знаю, что с чем должно быть совместимо или (ближе к теме) почему совместимость открытых программ обеспечить сложнее, чем совместимость закрытых. | ||
Строка 16: | Строка 20: | ||
Может, в Apple и делают прекрасные интерфейсы, но их приковывание к себе пользователя и склонность к судебным искам с большими деньгами мне несимпатичны. В мыслях у меня некий жест с двумя пальцами, но боюсь его показывать. Вдруг у Apple есть на него патент. | Может, в Apple и делают прекрасные интерфейсы, но их приковывание к себе пользователя и склонность к судебным искам с большими деньгами мне несимпатичны. В мыслях у меня некий жест с двумя пальцами, но боюсь его показывать. Вдруг у Apple есть на него патент. | ||
+ | }} | ||
+ | ===Подсчет ядер=== | ||
+ | |||
+ | ''За кулисами энергоблока сообщества, управляющего разработкой ядра Linux.'' | ||
+ | |||
+ | Вы слышали о Марке Брауне [Mark Brown] или Томасе Гляйкснере [Thomas Gleixner]? Думаю, нет. Как и я. Но согласно последнему отчету от Linux Foundation, эти два разработчика внесли наибольшее количество изменений в ядро, начиная с версии 2.6.5. | ||
+ | |||
+ | Исходные данные для отчета формируются путем мониторинга изменений на git.kernel.org. Исследуются вопросы «Быстро ли это происходит?», «Кто это делает?», «Что они делают?» и «Кто спонсор?». В ядре Linux более 15 миллионов строк кода – это самый крупный проект совместной разработки в истории вычислительной техники. Для сравнения, во всех семи книгах о Гарри Поттере – чуть больше миллиона слов. | ||
+ | |||
+ | Многие студенты моих курсов спрашивают: «Кто управляет ядром?» Бездумный ответ – «Никто», но на деле существует хорошо отлаженный процесс рассмотрения и утверждения патчей-заплаток ядра (кстати, “patch” – официальный термин для описания набора изменений: например, для добавления новой функции, поддержки нового устройства, исправления ошибки или увеличения производительности). Обычно заплатки рассматриваются всей командой, затем утверждаются разработчиками, отвечающими за соответствующую подсистему, и, наконец, принимаются в основной дистрибутив Линусом Торвальдсом – у него исключительное право решать, что войдет в следующий релиз ядра. | ||
+ | |||
+ | Немного цифр: | ||
+ | » 226 – столько компаний работает над ядром 3.2. | ||
+ | |||
+ | » 37 626 – количество файлов в ядре 3.2. | ||
+ | |||
+ | » 14 – средний период времени в минутах между применением патчей к ядру. | ||
+ | |||
+ | » 78 – среднее число дней от выпуска до выпуска. | ||
+ | |||
+ | » 12 243 – максимальное количество патчей, которое когда-либо применялось к версии ядра. | ||
+ | |||
+ | » 17,9 – изменения, приходящиеся на долю индивидуальных разработчиков (%). | ||
+ | |||
+ | ===Итак, вы хотите стать сисадмином?=== | ||
+ | |||
+ | ''Пятая часть серии, которая превратит вас из новичка в звезду системного администрирования. Сейчас мы установим web-сервер. | ||
+ | '' | ||
+ | Наконец в этой серии мы подобрались к тому, что должны делать серверы – обслуживать! Я решил установить web-сервер (хотя и не обычный Apache), но попытался обобщить процесс так, чтобы эти навыки пригодились вам при установке любого сервиса. | ||
+ | |||
+ | На всех уроках этой серии мы пользуемся CentOS 6.2. Если вы хотите следовать за мной, установите CentOS (можно и в виртуальную машину) в соответствии с описанием из первой статьи. У многих команд из обсуждаемых в этом месяце большой объем выходных данных, и на все здесь не хватит места. Если вам нужны подробности, то полный транскрипт многих команд есть на нашем сайте: www.linuxformat.com/archives?issue=165, так что смелее обращайтесь к нему в соответствующих местах. | ||
+ | |||
+ | ===Общая картина=== | ||
+ | |||
+ | Конечно, детали установки и настройки сервиса сильно зависят от разновидности сервиса, но в целом для этого нужно выполнить следующие шаги: | ||
+ | |||
+ | » Установить сервис. | ||
+ | |||
+ | » Найти и прочесть его man-страницу (иногда для файла настройки есть отдельная man-страница). | ||
+ | |||
+ | » Изменить его конфигурацию в соответствии со своими потребностями. | ||
+ | |||
+ | » Настроить запуск сервиса при загрузке системы. | ||
+ | |||
+ | » Запустить сервис вручную. | ||
+ | |||
+ | » Проверить наличие сообщений об ошибках и/или об успешном запуске в лог-файле. | ||
+ | |||
+ | » Проверить сервис. | ||
+ | |||
+ | ===Начинаем=== | ||
+ | |||
+ | В моей CentOS 6 был по умолчанию установлен классический HTTP-сервер Apache, но я решил воспользоваться другим сервером – Lighttpd. На его сайте (lighttpd.net) написано следующее: «Lighttpd – надежный, быстрый, послушный и очень гибкий web-сервер, оптимизированный для высокопроизводительного окружения. У него очень небольшие требования к памяти по сравнению с другими web-серверами, и он бережно расходует ресурсы процессора». Озвучивают его имя как “lighty [легкий]”. | ||
+ | |||
+ | Так как Apache уже установлен на моем компьютере, нужно убедиться, что он не запущен, и не запускать его во время загрузки. Если запустить и Lighttpd, и Apache, они оба попробуют слушать порт 80, а это недопустимо. | ||
+ | |||
+ | # service httpd status | ||
+ | |||
+ | httpd is stopped | ||
+ | |||
+ | # chkconfig httpd --list | ||
+ | |||
+ | httpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off | ||
+ | |||
+ | Сервис отключен – отлично. Но чтобы быть полностью уверенными, лучше удалить httpd совсем: | ||
+ | |||
+ | # rpm --erase httpd gnome-user-share | ||
+ | |||
+ | Почему я также удалил пакет gnome-user-share? Потому что rpm говорит, что он зависит от httpd, и я был вполне уверен, что он мне не нужен. | ||
+ | |||
+ | Надежно избавившись от Apache, перейдем к установке Lighttpd. Оказывается, что последнего нет в официальных репозиториях CentOS, как показывает быстрый поиск: | ||
+ | |||
+ | # yum search lighttpd | ||
+ | |||
+ | No Matches found | ||
+ | |||
+ | Но, введя в Google “CentOS6 lighttpd”, я нашел rpmforge и загрузил оттуда небольшой rpm: | ||
+ | |||
+ | # wget http://packages.sw.be/rpmforge-release/rpmforgerelease-0.5.2-2.el6.rf.i686.rpm | ||
+ | |||
+ | Это версия для 32-битных систем. Чтобы загрузить 64-битную версию, измените i686 на x86_64. Команда rpm -qlp с этим пакетом показала, что это не пакет lighttpd, он просто содержит файл .repo, указывающий на репозиторий rpmforge. Он также содержит файлы определения репозиториев для APT, утилиты управления пакетами Debian, но здесь они нам не нужны. | ||
+ | |||
+ | Установим пакет: | ||
+ | |||
+ | # rpm -i rpmforge-release-0.5.2-2.el6.rf.i686.rpm | ||
+ | |||
+ | warning: rpmforge-release-0.5.2-2.el6.rf.i686.rpm: Header V3 DSA/SHA1 Signature, key ID 6b8d79e6: NOKEY | ||
+ | |||
+ | Вы увидите, что rpm жалуется на невозможность проверить цифровую подпись пакета, так как у нее нет соответствующего публичного ключа (на самом деле, ключи есть в пакете!). Теперь поиск с yum более удачен: | ||
+ | |||
+ | # yum search lighttpd | ||
+ | |||
+ | lighttpd.i686 : Lightning fast webserver with light system | ||
+ | |||
+ | requirements [Молниеносный web-сервер со скромными требованиями к системе] | ||
+ | |||
+ | и мы можем установить его: | ||
+ | |||
+ | # yum install lighttpd | ||
+ | |||
+ | Так, пока неплохо. Посмотрим, что у нас есть, перечислив файлы в пакете: | ||
+ | |||
+ | # rpm -ql lighttpd | ||
+ | |||
+ | ... здесь появится длинный список файлов ... | ||
+ | |||
+ | Этот список дает ответы на несколько важных вопросов (не забудьте, что полный транскрипт есть на нашем сайте): | ||
+ | |||
+ | » Какие исполняемые файлы здесь есть? Их два: lighttpd и lighttpd-angel (что бы это ни было). | ||
+ | |||
+ | » Где находятся файлы настройки? Файл настройки верхнего уровня – /etc/lighttpd/lighttpd.conf, а файлы настройки для отдельных модулей находятся в каталоге /etc/lighttpd/conf.d. | ||
+ | |||
+ | » Куда помещаются файлы, которые должен обслуживать сервер? В каталог /srv/www/lighttpd (согласно официальному стандарту иерархии файловой системы – Filesystem Hierarchy Standard, им вообще-то должен быть /srv/www, но многие системы не следуют этому правилу). | ||
+ | |||
+ | » Есть ли man-страницы? Да, есть одна страница под названием lighttpd. | ||
+ | |||
+ | » Есть ли лог-файл? Да, это /var/log/lighttpd (на самом деле оказалось, что это целый каталог с лог-файлами). | ||
+ | |||
+ | » Есть ли другая документация? Да, в каталоге /usr/share/doc/lighttpd-1.4.28 есть много текстовых файлов. | ||
+ | |||
+ | Следующий шаг – ознакомиться с man-страницей. Она довольно короткая, так как лишь описывает параметры командной строки и отсылает нас к файлам /usr/share/doc за более подробной информацией. Это начинает казаться долгой каторгой, а я хочу немедленного удовлетворения. Поэтому для минимальной демонстрации работы сервера я сделал вот что. | ||
+ | |||
+ | Во-первых, добавил одну строку текста в файл /srv/www/lighttpd/index.html, чтобы у сервера было что обслуживать. При желании можете добавить туда много хитроумного HTML-кода, но для этого теста мне было достаточно строки: | ||
+ | |||
+ | This is a test from Chris! [Это тест Криса!] | ||
+ | |||
+ | Затем попытался запустить сервер: | ||
+ | |||
+ | # service lighttpd start | ||
+ | |||
+ | Starting lighttpd: 2012-09-06 15:16:43: (server.c.722) couldn’t set ‘max filedescriptors’ Permission denied | ||
+ | |||
+ | Ай-яй-яй. Что здесь не так? Сообщение об отсутствии прав доступа от процесса, запущенного от имени суперпользователя-root, необычно и скорее всего означает, что операцию запрещает SELinux. Чтобы это проверить, я попробовал отключить SELinux и снова запустить сервер: | ||
+ | |||
+ | # setenforce 0 | ||
+ | |||
+ | # service lighttpd start | ||
+ | |||
+ | Starting lighttpd: [ OK ] | ||
+ | |||
+ | Теперь все хорошо. Если вы подумали: «Какое умное и проницательное предположение!», скажу, что за последние несколько лет работы с системами в стиле RedHat 6 (в которых SELinux по умолчанию работает в принудительном режиме Enforcing) каждый раз, когда что-то не работает и я не могу найти веской причины, моя обычная реакция – попробовать отключить SELinux. Это не совсем правильное решение, но в нашем случае оно сработало. | ||
+ | |||
+ | Хороший способ узнать, запущен ли сервер – проверить, слушает ли он заданный порт (в данном случае, 80). Это легко: | ||
+ | |||
+ | # lsof -i TCP:80 | ||
+ | |||
+ | COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME | ||
+ | |||
+ | lighttpd 2030 lighttpd 4u IPv4 15277 0t0 TCP *:http (LISTEN) | ||
+ | |||
+ | – у нас все в порядке. | ||
+ | |||
+ | Учтите, запуск сервиса командой service не означает, что он будет запускаться при загрузке системы. Для этого нужно выполнить еще одну команду: | ||
+ | |||
+ | # chkconfig lighttpd on | ||
+ | |||
+ | ===Открываем порт=== | ||
+ | |||
+ | Прежде чем подключиться к серверу, нужно сделать еще одну вещь – открыть порт 80 в брандмауэре. Это легко сделать утилитой system-config-firewall (см. экранный снимок на стр. 61), которой можно воспользоваться, даже если у вас есть только ssh-доступ к серверу. (Не закройте случайно порт для ssh!). Если теперь открыть в браузере адрес сервера (http://192.168.1.64 – у вас, конечно, IP-адрес будет другим), на экране должен появиться текст, который был добавлен в index.html. | ||
+ | |||
+ | Итак, вот оно – наше немедленное удовлетворение! Мы смогли сделать это, не заглядывая в файлы настройки; но у вас вряд ли получится продвинуться намного дальше, как следует не разобравшись в них и не изменив их. Файл настройки верхнего уровня lighttpd (/etc/lighttpd/lighttpd.conf) – типичный пример такого файла, полный пояснений-комментариев и закомментированных записей. Иногда из-за этих комментариев сложно увидеть записи, поэтому вот маленький прием, который поможет от них избавиться: | ||
+ | |||
+ | # grep -v ‘^#’ /etc/lighttpd/lighttpd.conf | grep -v ‘^$’ | ||
+ | |||
+ | Эта команда исключит из содержимого файла комментарии и пустые строки. Выберем несколько основных строк: | ||
+ | |||
+ | var.server_root = “/srv/www” | ||
+ | |||
+ | server.port = 80 | ||
+ | |||
+ | server.username = “lighttpd” | ||
+ | |||
+ | server.document-root = server_root + “/lighttpd” | ||
+ | |||
+ | Они задают соответственно: | ||
+ | |||
+ | » Базовый каталог. Несколько других важных каталогов задаются относительно него. | ||
+ | |||
+ | » Номер порта, который будет слушать сервер. | ||
+ | |||
+ | » Пользователь, от имени которого будет запускаться сервер. Изначально он запускается от имени суперпользователя-root (чтобы связаться с портом 80); затем переключается на указанного пользователя. Этот пользователь добавляется в /etc/passwd при установке пакета. | ||
+ | |||
+ | » Каталог, содержащий обслуживаемое содержимое. | ||
+ | |||
+ | В файле lighttpd также часто задаются параметры производительности. Пример из этого файла – строка | ||
+ | |||
+ | server.max-connections = 1024 | ||
+ | |||
+ | Похоже, что разработчики задали их значения правильно, и я не советовал бы вам менять их, если только не (а) вы знаете, что делаете, и (б) вы сможете объективно измерить любые изменения в производительности при изменении параметров. | ||
+ | |||
+ | ===Таинственный сад=== | ||
+ | |||
+ | Конечно, теперь можно сделать многое другое – включить скрипты PHP CGI, настроить несколько виртуальных хостов и т. д. Каждое из этих действий снова погрузит вас в файлы. На самом деле при установке любого сервиса вы попадаете в новый мини-мир синтаксиса файлов настройки. Это как открыть дверь в таинственный сад, где вы доселе не бывали. | ||
+ | |||
+ | Прежде чем закончить, вспомним о SELinux. Как вы помните, мы отключили его, чтобы быстро все поправить. Однако, как бы я ни относился к SELinux, он свое дело делает, и просто отключить его – не лучшая идея. Вместо этого нужно разработать новую политику SELinux, которая позволила бы Lighttpd делать то, что ему необходимо. Оказывается, это относительно просто. Вот что нужно сделать: сначала с помощью auditd мы запишем в журнал те действия, которые lighttpd пытается выполнить при запуске. Затем воспользуемся маленькой удобной программой audit2allow (из пакета policycoreutils-python), чтобы преобразовать запрещенные операции, записанные auditd в лог-файл, в правила политики SELinux. Наконец, мы установим новые правила с помощью semodule. | ||
+ | |||
+ | Команды приводятся ниже. Не забудьте заглянуть в полный транскрипт за подробностями. | ||
+ | |||
+ | Сначала переформируем всю политику SELinux. Это может занять минуту или две: | ||
+ | |||
+ | # semodule -DB | ||
+ | |||
+ | Мне также пришлось установить программу audit2allow: | ||
+ | |||
+ | # yum install policycoreutils-python | ||
+ | |||
+ | Эта команда установила еще восемь пакетов для разрешения зависимостей. Затем перезапустим демон auditd: | ||
+ | |||
+ | # service auditd restart | ||
+ | |||
+ | Теперь снова включим SELinux и попробуем перезапустить lighttpd. Да, снова ничего не получится, но нам нужно поймать запрещающие сообщения. Они будут записаны в /var/log/audit/audit.log: | ||
+ | |||
+ | # setenforce 1 | ||
+ | |||
+ | # service lighttpd restart | ||
+ | |||
+ | Вот хитрый момент. Мы извлекаем соответствующие сообщения, записанные auditd, и передаем их audit2allow, которая преобразует их в правила политик SELinux: | ||
+ | |||
+ | # grep lighttpd /var/log/audit/audit.log | audit2allow -M lighttpdmaxfds | ||
+ | |||
+ | Сейчас в текущем каталоге появился файл lighttpdmaxfds.te. Это обычный текстовый файл. Также появится скомпилированная (двоичная) версия в lighttpdmaxfds.pp. Ее-то мы и загрузим: | ||
+ | |||
+ | # semodule -i lighttpdmaxfds.pp | ||
+ | |||
+ | Теперь lighttpd нормально запускается с включенным SELinux: | ||
+ | |||
+ | # service lighttpd restart | ||
+ | |||
+ | Stopping lighttpd: [FAILED] | ||
+ | |||
+ | Starting lighttpd: [ OK ] | ||
+ | |||
+ | Наконец, принудительно переформируем политику SELinux: | ||
+ | |||
+ | # semodule -B | ||
+ | |||
+ | (благодарю за помощь Google и некого FL0 на сайте Warp1337). | ||
+ | |||
+ | У меня осталось место только на пару слов о лог-файлах, о которых за всем этим мы позабыли. Для таких сервисов, как lighttpd, которые пишут в свои журналы напрямую (а не через rsyslog), лог-файлы легко найти, выведя список файлов, открытых web-сервером, например, так: | ||
+ | |||
+ | # lsof -c lighttpd | grep /var/log | ||
+ | |||
+ | Команда показывает, что это файлы /var/log/error.log и /var/log/access.log. В них нет ничего особенно интересного, но в лог-файле с ошибками часто есть сообщения, из которых можно понять, почему не работает сервис, особенно если это сервис вроде bind (сервер DNS), очень придирчивый к синтаксису файлов настройки и файлов зон. Вот удобный способ наблюдения за запуском сервера: откройте два терминала рядом и в первом запустите tail -f с именем лог-файла (так вы сможете видеть новые сообщения), а во втором – запустите демон командой service. | ||
+ | |||
+ | Одна из моих самых частых ошибок при решении проблем – обращение к журналам в самую последнюю очередь; на самом деле при диагностике проблемы прежде всего загляните именно в них. | ||
+ | |||
+ | В последней части небольшой серии мы наденем наши шляпы безопасности и обратимся к этой теме. Увидимся! | | ||
+ | |||
+ | ===Устранение ошибок=== | ||
+ | |||
+ | Конечно, при первом запуске ваш сервис будет работать отлично, и вы можете пойти погулять и полюбоваться барашками в небе. Но если что-то пойдет не так, вот несколько стандартных вещей, которые стоит проверить: | ||
+ | |||
+ | » Запущен ли сервис на самом деле? (Поищите его командой grep в выводе ps -ef.) | ||
+ | |||
+ | » Открыт ли нужный(е) порт(ы)? (На этот вопрос ответит lsof -i.) | ||
+ | |||
+ | » Открыт ли порт в брандмауэре? (Запустите iptables -L или воспользуйтесь системной утилитой настройки брандмауэра systemconfig-firewall.) | ||
+ | |||
+ | » Появляются ли какие-то сообщения в лог-файле с момента запуска сервиса до попытки обращения к нему? |
Версия 08:50, 2 ноября 2018
|
|
|
'
Доктор обучает, пишет и консультирует по Linux. Ученая степень по физике элементарных частиц ему в этом совсем не помогает.
Содержание |
По рецептам доктора Брауна
Эзотерическое системное администрирование из причудливых заворотов кишок серверной
==
- Метамодернизм в позднем творчестве В.Г. Сорокина
- ЛитРПГ - последняя отрыжка постмодерна
- "Ричард III и семиотика"
- 3D-визуализация обложки Ridero создаем обложку книги при работе над самиздатом.
- Архитектура метамодерна - говоря о современном искусстве, невозможно не поговорить об архитектуре. В данной статье будет отмечено несколько интересных принципов, характерных для построек "новой волны", столь притягательных и скандальных.
- Литература
- Метамодерн
- Рокер-Прометей против изначального зла в «Песне про советскую милицию» Вени Дркина, Автор: Нина Ищенко, к.ф.н, член Союза Писателей ЛНР - перепубликация из журнала "Топос".
- Как избавиться от комаров? Лучшие типы ловушек.
- Что делать если роблокс вылетает на windows
- Что делать, если ребенок смотрит порно?
- Почему собака прыгает на людей при встрече?
- Какое масло лить в Задний дифференциал (мост) Visco diff 38434AA050
- О чем может рассказать хвост вашей кошки?
- Верветки
- Отчетность бюджетных учреждений при закупках по Закону № 223-ФЗ
- Срок исковой давности как правильно рассчитать
- Дмитрий Патрушев минсельхоз будет ли преемником Путина
- Кто такой Владислав Поздняков? Что такое "Мужское Государство" и почему его признали экстремистским в России?
- Как правильно выбрать машинное масло в Димитровграде?
- Как стать богатым и знаменитым в России?
- Почему фильм "Пипец" (Kick-Ass) стал популярен по всему миру?
- Как стать мудрецом?
- Как правильно установить FreeBSD
- Как стать таким как Путин?
- Где лучше жить - в Димитровграде или в Ульяновске?
- Почему город Димитровград так называется?
- Что такое метамодерн?
- ВАЖНО! Временное ограничение движения автотранспортных средств в Димитровграде
- Тарифы на электроэнергию для майнеров предложено повысить
Подсчет ядер
За кулисами энергоблока сообщества, управляющего разработкой ядра Linux.
Вы слышали о Марке Брауне [Mark Brown] или Томасе Гляйкснере [Thomas Gleixner]? Думаю, нет. Как и я. Но согласно последнему отчету от Linux Foundation, эти два разработчика внесли наибольшее количество изменений в ядро, начиная с версии 2.6.5.
Исходные данные для отчета формируются путем мониторинга изменений на git.kernel.org. Исследуются вопросы «Быстро ли это происходит?», «Кто это делает?», «Что они делают?» и «Кто спонсор?». В ядре Linux более 15 миллионов строк кода – это самый крупный проект совместной разработки в истории вычислительной техники. Для сравнения, во всех семи книгах о Гарри Поттере – чуть больше миллиона слов.
Многие студенты моих курсов спрашивают: «Кто управляет ядром?» Бездумный ответ – «Никто», но на деле существует хорошо отлаженный процесс рассмотрения и утверждения патчей-заплаток ядра (кстати, “patch” – официальный термин для описания набора изменений: например, для добавления новой функции, поддержки нового устройства, исправления ошибки или увеличения производительности). Обычно заплатки рассматриваются всей командой, затем утверждаются разработчиками, отвечающими за соответствующую подсистему, и, наконец, принимаются в основной дистрибутив Линусом Торвальдсом – у него исключительное право решать, что войдет в следующий релиз ядра.
Немного цифр: » 226 – столько компаний работает над ядром 3.2.
» 37 626 – количество файлов в ядре 3.2.
» 14 – средний период времени в минутах между применением патчей к ядру.
» 78 – среднее число дней от выпуска до выпуска.
» 12 243 – максимальное количество патчей, которое когда-либо применялось к версии ядра.
» 17,9 – изменения, приходящиеся на долю индивидуальных разработчиков (%).
Итак, вы хотите стать сисадмином?
Пятая часть серии, которая превратит вас из новичка в звезду системного администрирования. Сейчас мы установим web-сервер. Наконец в этой серии мы подобрались к тому, что должны делать серверы – обслуживать! Я решил установить web-сервер (хотя и не обычный Apache), но попытался обобщить процесс так, чтобы эти навыки пригодились вам при установке любого сервиса.
На всех уроках этой серии мы пользуемся CentOS 6.2. Если вы хотите следовать за мной, установите CentOS (можно и в виртуальную машину) в соответствии с описанием из первой статьи. У многих команд из обсуждаемых в этом месяце большой объем выходных данных, и на все здесь не хватит места. Если вам нужны подробности, то полный транскрипт многих команд есть на нашем сайте: www.linuxformat.com/archives?issue=165, так что смелее обращайтесь к нему в соответствующих местах.
Общая картина
Конечно, детали установки и настройки сервиса сильно зависят от разновидности сервиса, но в целом для этого нужно выполнить следующие шаги:
» Установить сервис.
» Найти и прочесть его man-страницу (иногда для файла настройки есть отдельная man-страница).
» Изменить его конфигурацию в соответствии со своими потребностями.
» Настроить запуск сервиса при загрузке системы.
» Запустить сервис вручную.
» Проверить наличие сообщений об ошибках и/или об успешном запуске в лог-файле.
» Проверить сервис.
Начинаем
В моей CentOS 6 был по умолчанию установлен классический HTTP-сервер Apache, но я решил воспользоваться другим сервером – Lighttpd. На его сайте (lighttpd.net) написано следующее: «Lighttpd – надежный, быстрый, послушный и очень гибкий web-сервер, оптимизированный для высокопроизводительного окружения. У него очень небольшие требования к памяти по сравнению с другими web-серверами, и он бережно расходует ресурсы процессора». Озвучивают его имя как “lighty [легкий]”.
Так как Apache уже установлен на моем компьютере, нужно убедиться, что он не запущен, и не запускать его во время загрузки. Если запустить и Lighttpd, и Apache, они оба попробуют слушать порт 80, а это недопустимо.
# service httpd status
httpd is stopped
# chkconfig httpd --list
httpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
Сервис отключен – отлично. Но чтобы быть полностью уверенными, лучше удалить httpd совсем:
# rpm --erase httpd gnome-user-share
Почему я также удалил пакет gnome-user-share? Потому что rpm говорит, что он зависит от httpd, и я был вполне уверен, что он мне не нужен.
Надежно избавившись от Apache, перейдем к установке Lighttpd. Оказывается, что последнего нет в официальных репозиториях CentOS, как показывает быстрый поиск:
# yum search lighttpd
No Matches found
Но, введя в Google “CentOS6 lighttpd”, я нашел rpmforge и загрузил оттуда небольшой rpm:
# wget http://packages.sw.be/rpmforge-release/rpmforgerelease-0.5.2-2.el6.rf.i686.rpm
Это версия для 32-битных систем. Чтобы загрузить 64-битную версию, измените i686 на x86_64. Команда rpm -qlp с этим пакетом показала, что это не пакет lighttpd, он просто содержит файл .repo, указывающий на репозиторий rpmforge. Он также содержит файлы определения репозиториев для APT, утилиты управления пакетами Debian, но здесь они нам не нужны.
Установим пакет:
# rpm -i rpmforge-release-0.5.2-2.el6.rf.i686.rpm
warning: rpmforge-release-0.5.2-2.el6.rf.i686.rpm: Header V3 DSA/SHA1 Signature, key ID 6b8d79e6: NOKEY
Вы увидите, что rpm жалуется на невозможность проверить цифровую подпись пакета, так как у нее нет соответствующего публичного ключа (на самом деле, ключи есть в пакете!). Теперь поиск с yum более удачен:
# yum search lighttpd
lighttpd.i686 : Lightning fast webserver with light system
requirements [Молниеносный web-сервер со скромными требованиями к системе]
и мы можем установить его:
# yum install lighttpd
Так, пока неплохо. Посмотрим, что у нас есть, перечислив файлы в пакете:
# rpm -ql lighttpd
... здесь появится длинный список файлов ...
Этот список дает ответы на несколько важных вопросов (не забудьте, что полный транскрипт есть на нашем сайте):
» Какие исполняемые файлы здесь есть? Их два: lighttpd и lighttpd-angel (что бы это ни было).
» Где находятся файлы настройки? Файл настройки верхнего уровня – /etc/lighttpd/lighttpd.conf, а файлы настройки для отдельных модулей находятся в каталоге /etc/lighttpd/conf.d.
» Куда помещаются файлы, которые должен обслуживать сервер? В каталог /srv/www/lighttpd (согласно официальному стандарту иерархии файловой системы – Filesystem Hierarchy Standard, им вообще-то должен быть /srv/www, но многие системы не следуют этому правилу).
» Есть ли man-страницы? Да, есть одна страница под названием lighttpd.
» Есть ли лог-файл? Да, это /var/log/lighttpd (на самом деле оказалось, что это целый каталог с лог-файлами).
» Есть ли другая документация? Да, в каталоге /usr/share/doc/lighttpd-1.4.28 есть много текстовых файлов.
Следующий шаг – ознакомиться с man-страницей. Она довольно короткая, так как лишь описывает параметры командной строки и отсылает нас к файлам /usr/share/doc за более подробной информацией. Это начинает казаться долгой каторгой, а я хочу немедленного удовлетворения. Поэтому для минимальной демонстрации работы сервера я сделал вот что.
Во-первых, добавил одну строку текста в файл /srv/www/lighttpd/index.html, чтобы у сервера было что обслуживать. При желании можете добавить туда много хитроумного HTML-кода, но для этого теста мне было достаточно строки:
This is a test from Chris! [Это тест Криса!]
Затем попытался запустить сервер:
# service lighttpd start
Starting lighttpd: 2012-09-06 15:16:43: (server.c.722) couldn’t set ‘max filedescriptors’ Permission denied
Ай-яй-яй. Что здесь не так? Сообщение об отсутствии прав доступа от процесса, запущенного от имени суперпользователя-root, необычно и скорее всего означает, что операцию запрещает SELinux. Чтобы это проверить, я попробовал отключить SELinux и снова запустить сервер:
# setenforce 0
# service lighttpd start
Starting lighttpd: [ OK ]
Теперь все хорошо. Если вы подумали: «Какое умное и проницательное предположение!», скажу, что за последние несколько лет работы с системами в стиле RedHat 6 (в которых SELinux по умолчанию работает в принудительном режиме Enforcing) каждый раз, когда что-то не работает и я не могу найти веской причины, моя обычная реакция – попробовать отключить SELinux. Это не совсем правильное решение, но в нашем случае оно сработало.
Хороший способ узнать, запущен ли сервер – проверить, слушает ли он заданный порт (в данном случае, 80). Это легко:
# lsof -i TCP:80
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
lighttpd 2030 lighttpd 4u IPv4 15277 0t0 TCP *:http (LISTEN)
– у нас все в порядке.
Учтите, запуск сервиса командой service не означает, что он будет запускаться при загрузке системы. Для этого нужно выполнить еще одну команду:
# chkconfig lighttpd on
Открываем порт
Прежде чем подключиться к серверу, нужно сделать еще одну вещь – открыть порт 80 в брандмауэре. Это легко сделать утилитой system-config-firewall (см. экранный снимок на стр. 61), которой можно воспользоваться, даже если у вас есть только ssh-доступ к серверу. (Не закройте случайно порт для ssh!). Если теперь открыть в браузере адрес сервера (http://192.168.1.64 – у вас, конечно, IP-адрес будет другим), на экране должен появиться текст, который был добавлен в index.html.
Итак, вот оно – наше немедленное удовлетворение! Мы смогли сделать это, не заглядывая в файлы настройки; но у вас вряд ли получится продвинуться намного дальше, как следует не разобравшись в них и не изменив их. Файл настройки верхнего уровня lighttpd (/etc/lighttpd/lighttpd.conf) – типичный пример такого файла, полный пояснений-комментариев и закомментированных записей. Иногда из-за этих комментариев сложно увидеть записи, поэтому вот маленький прием, который поможет от них избавиться:
# grep -v ‘^#’ /etc/lighttpd/lighttpd.conf | grep -v ‘^$’
Эта команда исключит из содержимого файла комментарии и пустые строки. Выберем несколько основных строк:
var.server_root = “/srv/www”
server.port = 80
server.username = “lighttpd”
server.document-root = server_root + “/lighttpd”
Они задают соответственно:
» Базовый каталог. Несколько других важных каталогов задаются относительно него.
» Номер порта, который будет слушать сервер.
» Пользователь, от имени которого будет запускаться сервер. Изначально он запускается от имени суперпользователя-root (чтобы связаться с портом 80); затем переключается на указанного пользователя. Этот пользователь добавляется в /etc/passwd при установке пакета.
» Каталог, содержащий обслуживаемое содержимое.
В файле lighttpd также часто задаются параметры производительности. Пример из этого файла – строка
server.max-connections = 1024
Похоже, что разработчики задали их значения правильно, и я не советовал бы вам менять их, если только не (а) вы знаете, что делаете, и (б) вы сможете объективно измерить любые изменения в производительности при изменении параметров.
Таинственный сад
Конечно, теперь можно сделать многое другое – включить скрипты PHP CGI, настроить несколько виртуальных хостов и т. д. Каждое из этих действий снова погрузит вас в файлы. На самом деле при установке любого сервиса вы попадаете в новый мини-мир синтаксиса файлов настройки. Это как открыть дверь в таинственный сад, где вы доселе не бывали.
Прежде чем закончить, вспомним о SELinux. Как вы помните, мы отключили его, чтобы быстро все поправить. Однако, как бы я ни относился к SELinux, он свое дело делает, и просто отключить его – не лучшая идея. Вместо этого нужно разработать новую политику SELinux, которая позволила бы Lighttpd делать то, что ему необходимо. Оказывается, это относительно просто. Вот что нужно сделать: сначала с помощью auditd мы запишем в журнал те действия, которые lighttpd пытается выполнить при запуске. Затем воспользуемся маленькой удобной программой audit2allow (из пакета policycoreutils-python), чтобы преобразовать запрещенные операции, записанные auditd в лог-файл, в правила политики SELinux. Наконец, мы установим новые правила с помощью semodule.
Команды приводятся ниже. Не забудьте заглянуть в полный транскрипт за подробностями.
Сначала переформируем всю политику SELinux. Это может занять минуту или две:
# semodule -DB
Мне также пришлось установить программу audit2allow:
# yum install policycoreutils-python
Эта команда установила еще восемь пакетов для разрешения зависимостей. Затем перезапустим демон auditd:
# service auditd restart
Теперь снова включим SELinux и попробуем перезапустить lighttpd. Да, снова ничего не получится, но нам нужно поймать запрещающие сообщения. Они будут записаны в /var/log/audit/audit.log:
# setenforce 1
# service lighttpd restart
Вот хитрый момент. Мы извлекаем соответствующие сообщения, записанные auditd, и передаем их audit2allow, которая преобразует их в правила политик SELinux:
# grep lighttpd /var/log/audit/audit.log | audit2allow -M lighttpdmaxfds
Сейчас в текущем каталоге появился файл lighttpdmaxfds.te. Это обычный текстовый файл. Также появится скомпилированная (двоичная) версия в lighttpdmaxfds.pp. Ее-то мы и загрузим:
# semodule -i lighttpdmaxfds.pp
Теперь lighttpd нормально запускается с включенным SELinux:
# service lighttpd restart
Stopping lighttpd: [FAILED]
Starting lighttpd: [ OK ]
Наконец, принудительно переформируем политику SELinux:
# semodule -B
(благодарю за помощь Google и некого FL0 на сайте Warp1337).
У меня осталось место только на пару слов о лог-файлах, о которых за всем этим мы позабыли. Для таких сервисов, как lighttpd, которые пишут в свои журналы напрямую (а не через rsyslog), лог-файлы легко найти, выведя список файлов, открытых web-сервером, например, так:
# lsof -c lighttpd | grep /var/log
Команда показывает, что это файлы /var/log/error.log и /var/log/access.log. В них нет ничего особенно интересного, но в лог-файле с ошибками часто есть сообщения, из которых можно понять, почему не работает сервис, особенно если это сервис вроде bind (сервер DNS), очень придирчивый к синтаксису файлов настройки и файлов зон. Вот удобный способ наблюдения за запуском сервера: откройте два терминала рядом и в первом запустите tail -f с именем лог-файла (так вы сможете видеть новые сообщения), а во втором – запустите демон командой service.
Одна из моих самых частых ошибок при решении проблем – обращение к журналам в самую последнюю очередь; на самом деле при диагностике проблемы прежде всего загляните именно в них.
В последней части небольшой серии мы наденем наши шляпы безопасности и обратимся к этой теме. Увидимся! |
Устранение ошибок
Конечно, при первом запуске ваш сервис будет работать отлично, и вы можете пойти погулять и полюбоваться барашками в небе. Но если что-то пойдет не так, вот несколько стандартных вещей, которые стоит проверить:
» Запущен ли сервис на самом деле? (Поищите его командой grep в выводе ps -ef.)
» Открыт ли нужный(е) порт(ы)? (На этот вопрос ответит lsof -i.)
» Открыт ли порт в брандмауэре? (Запустите iptables -L или воспользуйтесь системной утилитой настройки брандмауэра systemconfig-firewall.)
» Появляются ли какие-то сообщения в лог-файле с момента запуска сервиса до попытки обращения к нему?