Перейти к содержанию книги Kali Linux Revealed
6.3 Подача грамотно составленного отчета об ошибке
Если все ваши попытки разрешить проблему увенчались неудачей, то вполне вероятно, что проблема связана с ошибкой (багом) в самой программе. В данном случае проблему можно детально изложить в отчете об ошибке. Вы можете продолжить поиск отчетов об ошибке, которые идентичны вашей, но давайте все же рассмотрим саму процедуру составления отчета об ошибке и предоставления его Kali, Debian, или напрямую разработчикам, таким образом, чтобы вы окончательно поняли, как именно следует составлять ваш собственные отчет об ошибке.
Целью отчета об ошибке является предоставление достаточной информации для того, чтобы разработчики или специалисты по эксплуатации (предположительно) неисправной программы могли воспроизвести проблему, отладить ее поведение и разработать исправление ошибки. Это означает, что ваш отчет об ошибке должен содержать соответствующую информацию и должен быть направлен к правильному человеку или команде проекта. Отчет также должен быть хорошо написанным и тщательным, что в свою очередь обеспечит более быстрый ответ.
Точная процедура для отчета об ошибке будет различаться в зависимости от того, кому именно вы будете отправлять отчет (Kali, Debian, или напрямую разработчикам), но есть некоторые общие рекомендации, применимые ко всем случаям. В этой главе мы обсудим эти рекомендации.
6.3.1 Общие рекомендации
Давайте обсудим общие рекомендации и основные принципы, которые помогут вам составить и подать отчет об ошибке, который будет понятным, всеобъемлющим и увеличит шансы того, что ошибка будет устранена разработчиками своевременно.
Как обращаться
Составляйте ваш отчет исключительно на английском. Сообщество свободного программного обеспечения (The Free Software community) является международным, и, если вы не знаете своего собеседника, вы должны использовать простой английский. Если вы являетесь носителем английского языка, используйте простые предложения и избегайте конструкций, которые могут вызвать сложности в понимании для людей с ограниченными навыками английского языка. Несмотря на то, что большинство разработчиков очень интеллектуальны, не все из них обладают сильными навыками английского языка. Так что давайте постараемся, чтобы любой сотрудник мог с легкостью понять суть содержимого.
Относитесь с уважением к работе разработчиков. Помните, что большинство разработчиков Free Software (включая тех, кто стоит за Kali Linux) доброжелательны и тратят свое ограниченное свободное время на работу с программным обеспечением, которое вы свободно используете. Многие делают это из альтруизма. Таким образом, когда вы отправляете отчет об ошибке, будьте почтительны (даже если проблема выглядит как очевидная ошибка разработчика) и не стоит думать, что они должны вам немедленно исправить ошибку. Будьте благодарными за их вклад.
Если вы знаете, как модифицировать и перекомпилировать программное обеспечение, предложите помочь разработчикам в тестировании любых патчей, которые они представляют вам. Это покажет им, что вы тоже готовы инвестировать свое время.
Будьте активными и готовыми предоставить дополнительную информацию. В некоторых случаях, разработчик может обратиться к вам с просьбой предоставить большее количество информации, или воссоздать проблему используя другие варианты или обновленные пакеты. Вы должны постараться отвечать на подобные запросы как можно быстрее. Чем быстрее вы ответите на подобного рода запрос, тем выше шансы на то, что разработчики смогут разрешить проблему быстро, пока первичные данные еще свежи.
Хотя вы должны стремиться быстро реагировать, вы также не должны чересчур торопиться: представленные данные должны быть правильными и должны содержать все, что запросили разработчики. Они будут очень раздосадованы, если им потребуется обращаться к вам за чем-то во второй раз.
Что необходимо указывать в отчете об ошибке
Подробные инструкции о том, каким образом можно воссоздать проблему. Чтобы иметь возможность воспроизвести проблему, разработчики должны знать, что вы используете, каким образом вы ее получили, и как вы ее установили.
Вы должны предоставить точные, пошаговые инструкции, описывающие, как воспроизвести проблему. Если вам нужно использовать некоторые данные для воспроизведения проблемы, прикрепите соответствующий файл к отчету об ошибке. Попытайтесь придумать минимальный набор инструкций, необходимых для воспроизведения ошибки.
Предоставьте необходимый контекст и укажите свои ожидания. Объясните, что вы пытались сделать и каким образом вы ожидали, что программа будет вести себя.
В некоторых случаях ошибка срабатывает только потому, что вы использовали программу для выполнения тех задач, какие она не предназначена выполнять. Объясняя, чего вы пытались достичь, вы позволяете разработчикам ясно понимать так это или нет.
В некоторых других случаях поведение, которое вы описываете как ошибку, на самом деле может быть нормальным поведением программы. Постарайтесь излагать свои мысли максимально ясно, когда будете описывать то, что вы ожидали от программы. Это прояснит ситуацию для разработчиков. Они могут либо исправить поведение программы, либо улучшить документацию, но, по крайней мере, они будут знать, что поведение их программы запутывает некоторых пользователей!
Будьте максимально конкретными. Включите номера версий программного обеспечения, которое вы используете и, по возможности, укажите номера версий их зависимостей. Когда вы ссылаетесь на что-то, что вы скачали, укажите его полный URL-адрес.
Когда вы получите сообщение об ошибке, укажите его точно в таком виде, в каком вы его получили. Если возможно, включите копию вывода на экране или снимок экрана. Включите копию любого соответствующего файла журнала, однако предварительно убедитесь, что вы удалили все конфиденциальные данные.
Упоминание возможных вариантов исправлений или обходных решений. Перед подачей отчета об ошибке вы, вероятно, попытались решить проблему. Объясните, что вы пробовали, и какие результаты вы получили. Будьте предельно ясны в том, что вы реально пытались сделать и что является всего лишь гипотезой с вашей стороны.
Если вы выполняли интернет поиск и находили какого-либо рода разъяснения касательно вашей проблемы, вы можете указать это, особенно если вы нашли похожий отчет об ошибке в Debian трекере.
Если вы нашли способ достижения желаемого результата без вызывания ошибки, пожалуйста, задокументируйте это. Это поможет другим пользователям, которые пострадали от одной и той же проблемы.
Длинные отчеты об ошибках являются вполне нормальным явлением. Отчет об ошибке с двумя строками является недостаточным; для обеспечения всей необходимой информации обычно требуется несколько абзацев (или иногда страниц) текста.
Предоставьте всю информацию, которую вы можете. Постарайтесь придерживаться того, что имеет значение, но если вы не уверены, то помните, что слишком много лучше, чем слишком мало.
Если ваш отчет об ошибках действительно длинный, найдите время, чтобы структурировать его содержимое и представить краткое резюме в начале.
Различные советы
Избегайте подачи дублированных отчетов об ошибках. В мире свободного программного обеспечения все трекеры ошибок являются общедоступными. Открытые проблемы можно просмотреть, и у них даже есть функция поиска. Таким образом, перед подачей нового отчета об ошибке попытайтесь определить, была ли ваша проблема уже сообщена кем-то другим.
Если вы обнаружите существующий отчет об ошибках, подпишитесь на него и, возможно, добавьте дополнительную информацию. Не публикуйте комментарии, такие как «Я тоже» или «+1»; они не имеют никакого смысла. Но вы можете указать, что вы готовы к дальнейшим испытаниям, если исходный заявитель этого не предлагал.
Если вы не нашли отчета о своей проблеме, то можете смело переходить к регистрации. Если вы нашли связанные с вашей проблемой свидетельства, обязательно укажите их.
Обязательно убедитесь в том, что вы используете последнюю версию. Разработчиков очень сильно запутывают отчеты об ошибках относительно проблем, которые они уже решили, или проблем, которые они не могут воспроизвести с использованием версии, которую они на данный момент используют (разработчики почти всегда используют последнюю версию своего продукта). Даже когда старые версии поддерживаются разработчиками, такая поддержка часто ограничивается исправлениями в области безопасности или более серьезными проблемами. Вы уверены, что ваша ошибка одна из них?
Вот почему перед подачей отчета об ошибке вы должны убедиться, что используете последнюю версию проблемной системы или приложения, и что вы можете воспроизвести проблему в случае необходимости.
Если Kali Linux не предлагает самую последнюю версию приложения (ни в kali-rolling ни в kalibleeding-edge, смотри раздел 8.1.3.3, «Репозиторий Kali-Bleeding-Edge Repository»), у вас есть альтернативное решение: вы можете попробовать выполнить ручную установку последней версии на одноразовой виртуальной машине, или вы можете просмотреть восходящий ChangeLog (или Git commit историю), чтобы увидеть, что не было никаких изменений, которые могли бы устранить проблему, (и затем вы можете регистрировать ошибку, не смотря на то, что вы не пробовали последнюю версию).
Не смешивайте несколько проблем в одном отчете об ошибке
Регистрируйте один отчет об ошибке для каждой отдельной ошибке. Таким образом, последующие обсуждения не становятся слишком беспорядочными, и каждая ошибка может быть исправлена в соответствии с ее собственным особенностями. Если вы этого не сделаете, то либо одна и та же ошибка должна будет видоизменяться множество раз и может быть закрыта только в том случае, когда все ошибки будут устранены, либо разработчики должны будут регистрировать дополнительные отчеты, которые необходимо было сделать вам в первую очередь.
6.3.2 Где регистрировать отчет об ошибке
Чтобы иметь возможность решить, где записать отчет об ошибке, вы должны хорошо понимать проблему, и вы должны определить, в какой части программного обеспечения заключена проблема.
Идеально, вам необходимо отследить проблему прямо до конкретного файла в вашей системе, а затем вы можете использовать dpkg для того, чтобы определить какой пакет владеет эти файлом и кем поставляется этот пакет. Давайте предположим, что вы нашли ошибку в графическом приложении. После просмотра списка запущенных процессов (вывод команды ps auxf), что приложение было запущено с исполняемым файлом /usr/bin/Sparta :
Вы узнаете, что /usr/bin/sparta предоставляется пакетом sparta, который находится в версии 1.0.1+git 20150729-Okalil. Тот факт, что строка версии содержит kali, указывает на то, что пакет поставляется Kali Linux (или был изменен Kali Linux). Любой пакет, который не имеет kali в своей строке версии (или в имени пакета), поставляется Debian (Debian Testing вообще).
Двойная проверка перед тем, как в идеале подать файлы с ошибками в Debian
Если вы обнаружили ошибку в пакете, импортированном прямо из Debian, он должен сообщаться и исправляться со стороны Debian. Однако, перед этим убедитесь, что проблема воспроизводима в простой системе Debian, поскольку Kali, возможно, вызвала проблему, изменив другие пакеты или зависимости.
Самый простой способ сделать это — настроить виртуальную машину, на которой запущен Debian Testing. Вы можете найти установочный образ ISO для Debian Testing на веб-сайте Debian Installer:
https://www.debian.org/devel/debian-installer/
Если вы можете подтвердить проблему на виртуальной машине, вы можете отправить отчет об ошибке в Debian, выполнив функцию отчет об ошибке в виртуальной машине и следуя инструкциям.
Большинство отчетов об ошибках в отношении поведения приложений должны быть направлены непосредственном владельцам этих проектов, кроме случаев, когда вы сталкиваетесь с проблемой интеграции: в этом случае неполадка является ошибкой вызванной тем, как программное обеспечение пакетируется и интегрируется в Debian или Kali.
Например, если приложение предлагает параметры времени компиляции, которые пакет не разрешает или приложение не работает из-за отсутствующей библиотеки (таким образом, в результате возникает недостающая зависимость в метаинформации пакета), вы можете столкнуться с проблемой интеграции. Когда вы не знаете, с какой проблемой вы сталкиваетесь, обычно лучше всего зарегистрировать проблему с обеих сторон и перекрестно ссылаться на нее.
Определение проекта, к которому относится ошибка и нахождение места, куда можно подать/зарегистрировать отчет об ошибке на самом деле довольно легко. Вы просто должны просмотреть необходимый сайт, на который есть ссылка в поле «Домашняя страница» (Homepage) метаданных пакетирования.
6.3.3 Как регистрировать отчет об ошибке
Создание отчета об ошибке в Kali
Kali использует веб-трекер ошибок на http://bugs.kali.org/, где вы можете анонимно проконсультироваться относительного любого рода отчетах об ошибках, но если вы хотите прокомментировать или опубликовать новый отчет об ошибке, вам нужно будет зарегистрировать учетную запись.
Регистрация учетной записи на баг трекере. Для начала просто нажмите на Создать новый аккаунт (Signup for new account) на веб-сайте баг трекера, как показано на рисунке 6.1, «Начальная страница Kali баг трекера».
Затем, укажите имя пользователя, e-mail адрес, и ответьте на запрос CAPTCHA. Далее нажмите на кнопку Signup для продолжения (Рисунок 6.2, «Страница регистрации»).
Если все прошло успешно, следующая страница (Рисунок 6.3, «Страница подтверждения регистрации») сообщит вам о том, что регистрация вашего аккаунта продолжается и что система баг трекера отправила вам письмо для подтверждения создания вашей учетной записи, на предоставленный вами ранее электронный адрес. Вам нужно будет перейти по ссылке, которая указана в полученном вами письме для того, чтобы активировать ваш аккаунт.
Как только ваш аккаунт был активирован, нажмите Proceed, чтобы перейти на страницу входа в баг трекер.
Создание отчета
Чтобы начать свой отчет, войдите в свою учетную запись и нажмите на ссылку «Сообщить о проблеме» (Report Issue) на целевой странице. Вам будет представлена форма с множеством полей для заполнения, как показано на рисунке 6.4, «Форма для создания отчета об ошибке».
Ниже приведено краткое описание всех полей формы:
Категория (обязательно для заполнения). Это поле описывает категорию ошибки, которой посвящен отчет. Отчеты, которые относятся к конкретному пакету, должны быть зарегистрированы в категориях Kali Package Bug или Kali Package Improvement. Другие отчеты должны использовать категории General Bug или Feature Requests. Оставшиеся категории предназначены для особых случаев: категория Tool Upgrade может быть использована для того, чтобы сообщить разработчикам Kali о доступности новой версии программного обеспечения, пакетированного в Kali. Категория New Tool Requests может быть использована для предложения новых инструментов для пакетирования и интеграции в дистрибутив Kali.
Воспроизводимость — В этом поле указывается, может ли проблема воспроизводиться предсказуемым образом, или она постоянно возникает случайным образом.
Серьезность и приоритетность — Эти поля лучше всего оставить без изменений, поскольку они предназначены главным образом для разработчиков. Они могут использовать их для сортировки списка проблем в соответствии с серьезностью проблемы и приоритетом, в соответствии с которым она должна обрабатываться.
Версия продукта — В этом поле должно быть указано, какую версию Kali Linux вы используете (или хотя бы ту, которая наиболее близка к той, что вы используете). Подумайте дважды, прежде чем сообщать о проблеме в старой версии, которая больше не поддерживается.
Краткое содержание (обязательно для заполнения) — Это, по сути, является заголовком вашего отчета об ошибке, и это первое, что люди увидят. Убедитесь, что он передает причину, по которой вы отправляете отчет. Избегайте общих описаний, таких как «Х не работает», и вместо этого старайтесь следовать подобной конструкции «X с ошибкой Y при условии Z».
Описание (Description (обязательно для заполнения)) — Это тело вашего отчета. Здесь вы должны ввести всю информацию, которую вы собрали о проблеме, с которой вы столкнулись. Не забывайте все рекомендации, приведенные в предыдущем разделе.
Действия по воспроизведению (Steps to Reproduce) — В этом поле перечислены все подробные инструкции, объясняющие, каким образом можно вызвать данную проблему.
Дополнительная информация (Additional Information) — В этом разделе вы можете предоставить любую дополнительную информацию, которая, по вашему мнению, имеет отношение к проблеме. Если у вас есть рекомендации относительно того, как исправить или обойти проблему, предоставьте их в этом разделе.
Загрузить файл (Upload File) — Не все можно объяснить простым текстом. В этом поле вы можете прикреплять произвольные файлы к своим отчетам: скриншоты, чтобы показать ошибку, образцы документов, запускающие проблему, файлы журналов и т. д.
Просмотреть статус (View Status) — Оставьте это поле «общедоступным» («public»), чтобы каждый мог видеть ваш отчет об ошибке. Используйте «конфиденциально» («private») только для отчетов, связанных с безопасностью, которые содержат информацию о нераскрытых уязвимостях безопасности.
Создание отчета об ошибке в Debian
Debian использует (в основном) систему отслеживания ошибок на основе электронной почты, известную как Debbugs. Чтобы открыть новый отчет об ошибке, вы отправите электронное письмо (со специальным синтаксисом) на адрес submit@bugs.debian.org. Это присвоит номер ошибке XXXXXX и сообщит вам, что вы можете отправить дополнительную информацию, отправив XXX XXX@bugs.debian.org. Каждая ошибка связана с пакетом Debian. Вы можете просмотреть все ошибки данного пакета (включая ту ошибку, о которой вы хотите составить отчет) на https://bugs.debian.org/ package. Вы можете проверить историю данной ошибки на странице https://bugs.debian.org/XXXXXX.
Настраиваем Reportbug Хотя вы можете сообщить о новой ошибке с помощью простого электронного письма, мы рекомендуем использовать reportbug, потому что это поможет вам составить серьезный отчет об ошибке со всей необходимой информацией. В идеале вы должны запустить его из системы Debian (например, на виртуальной машине, где вы воспроизвели проблему).
Первый запуск reportbug запускает сценарий конфигурации. Сначала выберите уровень навыка. Вы должны выбрать Новичка (Novice) или Стандарт (Standard); мы используем последний, потому что он предлагает более детальный контроль. Затем выберите интерфейс и введите свои личные данные. Наконец, выберите пользовательский интерфейс. Сценарий конфигурации позволит вам использовать локальный агент транспорта почты, SMTP-сервер или, в крайнем случае, SMTP-сервер Debian.
Использование Reportbug После завершения фазы настройки вы можете начать создание отчета об ошибке. Вам будет предложено указать имя пакета, хотя вы также можете указать имя пакета непосредственно в командной строке с помощью reportbug package.
В отличие от рекомендаций, приведенных выше, если вы не знаете, с каким пакетом следует подать ошибку, вы должны связаться с форумом поддержки Kali (см. Раздел 6.2 «Kali Linux сообщества»). На следующем шаге reportbug загружает список ошибок, поданных с данным пакетом, и это в свою очередь позволяет вам узнать, можете ли вы найти в нем свою ошибку.
Если вы обнаружили, что отчет о вашей ошибке уже подан, вы сможете отправить дополнительную информацию, иначе вам будет предложено подать новый отчет об ошибке:
После предоставления однострочной сводки о вашей проблеме вы должны оценить ее серьезность в расширенном масштабе:
Если вы не уверены, просто соблюдайте правила стандартной процедуры. Вы также можете отметить свой отчет несколькими ключевыми словами:
Применимо ли что-либо из нижеперечисленного к вашему отчету?
Большинство из тегов будут понятны скорее лишь посвященным, но если ваш отчет содержит исправление проблемы, вам следует выбрать тег patch.
Когда этот этап будет завершен, reportbug откроет текстовый редактор с шаблоном, который вы должны отредактировать (пример 6.2, «Шаблон, созданный reportbug»). Он содержит несколько вопросов, которые вы должны сначала удалить и на их месте указать собственный ответ, а также некоторую информацию о вашей системе, которая была автоматически собрана. Обратите внимание, как структурируются первые несколько строк. Они не должны быть изменены, поскольку они будут проанализированы баг трекером, чтобы назначить отчет соответствующему пакету.
Пример 6.2 Шаблон созданный reportbug
После сохранения отчета и закрытия текстового редактора вы возвращаетесь к reportbug, который предоставляет множество других опций и предложений для отправки результативного отчета.
Создание отчета об ошибке для любого другого проекта свободного программного обеспечения (Free Software Project)
Существует большое разнообразие проектов свободного программного обеспечения, использующих различные рабочие процессы и инструменты. Эта разница также применима к всеми используемым баг трекерам. Хотя многие проекты размещены на GitHub и используют GitHub Issues для отслеживания их ошибок, есть также много других, на которых размещаются собственные трекеры, основанные на Bugzilla, Trac, Redmine, Flyspray и других. Большинство из них работают в Интернете и требуют, чтобы вы зарегистрировали учетную запись для отправки нового отчета.
Здесь мы не будем описывать все трекеры. Это зависит только от вас, какой трекер вы будете использовать из всех существующих трекеров для других проектов свободного программного обеспечения, но поскольку GitHub относительно популярен, мы кратко рассмотрим его здесь. Как и в случае с другими трекерами, вы должны сначала создать учетную запись и войти в нее. Затем перейдите на вкладку «Проблемы» (Issues), как показано на рисунке 6.5, «Главная страница проекта GitHub».
Затем вы можете просматривать (и искать) список открытых проблем. Если вы уверены, что ваша ошибка еще не зарегистрирована, вы можете нажать кнопку «Новая проблема» (New issue) (Рисунок 6.6, страница проблем проекта GitHub »).
Теперь вы находитесь на странице, где вы должны описать свою проблему (рисунок 6.7, «Форма GitHub для создания новой проблемы»). Несмотря на отсутствие шаблона, подобного тому который предоставлялся в reportbug, механизм отчетности об ошибках довольно прост. Он позволяет вам прикреплять файлы, применять форматирование к тексту и многое другое. Конечно, для достижения наилучших результатов обязательно следуйте нашим рекомендациям по созданию подробного и хорошо описанного отчета.
Перейти к содержанию книги Kali Linux Revealed
Это интересно: