Product SiteDocumentation Site

7.2. Общие процедуры

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

7.2.1. Настраиваем программу

Настройку неизвестного вам пакета необходимо выполнять в несколько этапов. Во-первых, стоит прочитать документацию, которую подготовил сопровождающий пакета. Чтение /usr/share/doc/package/README.Debian позволит вам узнать о каких-либо специальных мерах, упрощающих использование программного обеспечения. Иногда это бывает важно для понимания отличий в работе от поведения оригинальной версии программы, которое описано в общей документации, например, в практических руководствах. Иногда в этом файле перечислены наиболее распространённые ошибки с тем, чтоб вы не тратили время на устранение общих проблем.
Далее вам следует заглянуть в официальную документацию программного обеспечения; для поиска различных источников документации вернитесь к Раздел 7.1, «Источники документации». Команда dpkg -L пакет выводит список файлов, содержащихся в пакете, и таким образом позволяет быстро установить наличие документации (а также файлов конфигурации, расположенных в /etc/). dpkg -s пакет выведет метаданные пакета и отобразит все рекомендованные или предложенные пакеты. Там вы можете найти документацию или утилиту, упрощающую настройку программы.
В заключение, конфигурационные файлы зачастую самодокументированы и содержат множество поясняющих комментариев с указанием различных вариантов значений для каждой переменной. Иногда комментарии настолько избыточны, что бывает достаточно просто выбрать необходимую для активации строку из всех доступных. В отдельных случаях образцы конфигурационных файлов помещаются в каталог /usr/share/doc/package/examples/. Они могут послужить отправной точкой для вашего собственного файла.

7.2.2. Наблюдение за работой демонов

Понимание действий демонов несколько сложнее, поскольку они не взаимодействуют напрямую с администратором. Вам необходимо протестировать демона для выяснения его текущего состояния. Например, для проверки демона Apache (веб-сервер) отправьте ему HTTP-запрос.
Каждый демон обычно записывает все свои действия, а также любые возникшие ошибки, в так называемые «файлы журналов» или в «системные журналы». Журналы хранятся в /var/log/ или в одном из его подкаталогов. Точное имя файла журнала какого-либо демона ищите в его документации. Стоит отметить, что единичный тест не всегда эффективен за исключением тех случаев, когда он покрывает все возможные случаи применения; некоторые проблемы возникают только при особых обстоятельствах.
As a preventive operation, the administrator should regularly read the most relevant server logs. They can thus diagnose problems before they are even reported by disgruntled users. Indeed users may sometimes wait for a problem to occur repeatedly over several days before reporting it. In many cases, there are specific tools to analyze the contents of the larger log files. In particular, such utilities exist for web servers (such as analog, awstats, webalizer for Apache), for FTP servers, for proxy/cache servers, for firewalls, for e-mail servers, for DNS servers, and even for print servers. Other tools, such as logcheck (a software discussed in Глава 14, Безопасность), scan these files in search of alerts to be dealt with.

7.2.3. Поиск помощи в списках рассылки

Если ваши поиски не привели к установлению корня проблемы, то, возможно, вам стоит попросить помощи более опытных людей. Подобная помощь является целью списка рассылки . Как и в случае любого сообщества, он имеет определённые правила, которые стоит соблюдать. Прежде чем задать какой-либо вопрос, вам стоит уточнить, что ваша проблема не обсуждалась ранее в рассылке или где-либо в официальной документации.
Как только выполнены эти два условия, вам стоит обдумать описание вашей проблемы в списке рассылки. Включите в описание как можно больше имеющей отношения к проблеме информации: различные выполненные тесты, чтение документации, ваши попытки диагностирования проблемы, затронутые пакеты или пакеты, которые могут иметь отношение, и т. д. Попробуйте отыскать подобные проблемы в системе отслеживания ошибок Debian (BTS, описана во врезке ИНСТРУМЕНТ Система отслеживания ошибок) и упомяните о результатах поиска, а также предоставьте ссылки на найденные ошибки. BTS размещается по адресу:
Чем вежливее и точнее вы задали вопрос, тем выше ваши шансы получить ответ или, как минимум, какую-нибудь подсказку. Если вы получили ответ в частном письме, то подумайте о публикации этой информации для общей пользы. Позвольте вашим последователям, которые столкнутся с этой проблемой, найти решение в архивах списка рассылки с помощью поисковых систем.

7.2.4. Отчёт об ошибке в случае сложной проблемы

Если все ваши усилия по устранению проблемы не привели к результату, то возможно, что решение находится вне вашей компетенции и проблема является следствием ошибки в программе. В таком случае следует сообщить об ошибке в Debian или непосредственно разработчикам. Для этого вам необходимо максимально изолировать проблему и создать минимально необходимую тестовую ситуацию, в которой она может быть воспроизведена. Если вам известна программа, являющаяся источником проблемы, то вы можете установить соответствующий пакет с помощью команды dpkg -S file_in_question. Проверьте также систему отслеживания ошибок (https://bugs.debian.org/package) чтоб удостовериться, что отчёт там ещё не заведён. Затем вы можете отправить свой собственный отчёт командой reportbug, включив в него как можно больше информации, в частности, полное описание минимального тестового случая, который позволит воспроизвести ошибку.
В этой главе приведены методы эффективного решения тех вопросов, что могут возникнуть при чтении следующих глав. Используйте их при первой необходимости!