Product SiteDocumentation Site

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

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

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

When you want to configure an unknown package, you must proceed in stages. First, you should read what the package maintainer has documented. Reading /usr/share/doc/package/README.Debian will allow you to learn of specific provisions made to simplify the use of the software. It is sometimes essential in order to understand the differences from the original behavior of the program, as described in the general documentation, such as howtos. Sometimes this file also details the most common errors in order for you to avoid wasting time on common problems.
Далее вам следует заглянуть в официальную документацию программного обеспечения; для поиска различных источников документации вернитесь к Раздел 7.1, «Источники документации». Команда dpkg -L пакет выводит список файлов, содержащихся в пакете, и таким образом позволяет быстро установить наличие документации (а также файлов конфигурации, расположенных в /etc/). dpkg -s пакет выведет метаданные пакета и отобразит все рекомендованные или предложенные пакеты. Там вы можете найти документацию или утилиту, упрощающую настройку программы.
В заключение, конфигурационные файлы зачастую самодокументированы и содержат множество поясняющих комментариев с указанием различных вариантов значений для каждой переменной. Иногда комментарии настолько избыточны, что бывает достаточно просто выбрать необходимую для активации строку из всех доступных. В отдельных случаях образцы конфигурационных файлов помещаются в каталог /usr/share/doc/package/examples/. Они могут послужить отправной точкой для вашего собственного файла.

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

Понимание действий демонов несколько сложнее, поскольку они не взаимодействуют напрямую с администратором. Вам необходимо протестировать демона для выяснения его текущего состояния. Например, для проверки демона Apache (веб-сервер) отправьте ему HTTP-запрос.
Каждый демон обычно записывает все свои действия, а также любые возникшие ошибки, в так называемые «файлы журналов» или в «системные журналы». Журналы хранятся в /var/log/ или в одном из его подкаталогов. Точное имя файла журнала какого-либо демона ищите в его документации. Стоит отметить, что единичный тест не всегда эффективен за исключением тех случаев, когда он покрывает все возможные случаи применения; некоторые проблемы возникают только при особых обстоятельствах.
Администратору следует регулярно просматривать последние журналы сервера в качестве предупредительной меры. Таким образом он сможет диагностировать проблемы ещё до того, как раздражённые пользователи сообщат о них. Действительно, пользователи могут ждать несколько дней повторного возникновения проблемы прежде, чем сообщать о ней. В большинстве случаев доступны специализированные инструменты для анализа содержимого больших файлов журналов. В частности, такие утилиты существуют для веб-серверов (например, analog, awstats, awffull для Apache), для FTP серверов, прокси/кэш серверов, межсетевых экранов, почтовых серверов, DNS серверов и даже для серверов печати. Другие инструменты, например, logcheck (это программное обеспечение обсуждается в разделе Глава 14, Безопасность), могут сканировать эти файлы с целью поиска индикаторов, на которые стоит обратить внимание.

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

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

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

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