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. Поиск помощи в списках рассылки

If your various searches haven't helped you to get to the root of a problem, it is possible to get help from other, perhaps more experienced people. This is exactly the purpose of the mailing list and its language specific siblings . As with any community, it has rules that need to be followed. Before asking any question, you should check that your problem isn't already covered by recent discussions on the list or by any official documentation.
Once those two conditions are met, you can think of describing your problem to the mailing list. Include as much relevant information as possible: various tests conducted, documentation consulted, how you attempted to diagnose the problem, the packages concerned or those that may be involved, etc. Check the Debian Bug Tracking System (BTS, described in sidebar Раздел 1.3.2.1, «Reporting bugs») for similar problems, and mention the results of that search, providing links to bugs found. BTS starts on:
Чем вежливее и точнее вы задали вопрос, тем выше ваши шансы получить ответ или, как минимум, какую-нибудь подсказку. Если вы получили ответ в частном письме, то подумайте о публикации этой информации для общей пользы. Позвольте вашим последователям, которые столкнутся с этой проблемой, найти решение в архивах списка рассылки с помощью поисковых систем.

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

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