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 package فهرستی از فایل‌های موجود در بسته را نمایش می‌دهد؛ بلافاصله می‌توانید مستندات موجود در یک بسته را با این روش بدست آورید (همچنین فایل‌های پیکربندی، که در /etc/ وجود دارند). دستور dpkg -s package اطلاعات جانبی مربوط به بسته را نمایش می‌دهد و به نمایش بسته‌های توصیه‌شده یا پیشنهادی می‌پردازد؛ در اینجاست که می‌توانید مستندات یا ابزار کاربردی مرتبط با پیکربندی یک نرم‌افزار را جستجو کنید.

در نهایت، فایل‌های پیکربندی دارای توضیحاتی درون خود هستند که روش‌های احتمالی بسیاری را در مورد هر یک از گزینه‌ها شرح می‌دهند. تنها کافی است که این گزینه‌ها را فعال کنید. در برخی موارد، مثال‌های مربوط به فایل‌های پیکربندی در دایرکتوری /usr/share/doc/package/examples/ قرار دارند. از این فایل‌ها می‌توانید به عنوان شروعی برای پیکربندی خود استفاده کنید.

درک اینکه یک daemon یا فرآیند پس‌زمینه چه کاری می‌کند بسیار دشوار است، از آنجا که به صورت مستقیم با مدیرسیستم در ارتباط نیست. برای بررسی اینکه چنین فرآیندی در حقیقت کار می‌کند، باید آن را امتحان کنید، برای بررسی فرآیند پس‌زمینه آپاچی (وب‌سرور) آن را با یک درخواست 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, awffull for Apache), FTP servers, proxy/cache servers, firewalls, e-mail servers, 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.

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 debian-user@lists.debian.org mailing list and its language specific siblings debian-user-lang@lists.debian.org. 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:

در توضیح مشکل هر چه دقیق‌تر باشید، احتمال اینکه پاسخ مثبتی دریافت کنید بیشتر می‌شود یا حداقل برخی پاسخ‌های مرتبط. اگر اطلاعات مفیدی را به صورت خصوصی دریافت کردید، به فکر انتشار آن‌ها به صورت عمومی باشید تا دیگران نیز بهره‌مند گردند. این امکان وجود دارد که با استفاده از موتورهای جستجو، به جستجوی دقیق درون بایگانی میلینگ لیست بپردازید تا دیگران نیز بتوانند به پرسش مورد نظر خود دسترسی داشته باشند.

اگر تمام تلاش‌های شما برای حل مساله به بن‌بست خورد، احتمالا حل مشکل جزو مسئولیت‌های شما نباشد، که در این صورت مشکل از باگ موجود در یک برنامه است. در این مورد، فرآیند مطلوب گزارش باگ به دبیان یا توسعه‌دهنده اصلی برنامه است. برای اینکار، مساله را به صورتی ایزوله کنید که باگ بتواند در آن دوباره تولید شود. اگر می‌دانید کدام برنامه به تولید باگ کمک می‌کند، می‌توانید بسته مربوط به آن را با استفاده از دستور dpkg -S file_in_question پیدا کنید. سیستم ردگیری باگ (https://bugs.debian.org/package) را بررسی کنید تا ببینید باگ در آن وجود نداشته باشد. آنگاه می‌توانید با استفاده از دستور reportbug گزارش باگ خود را ارسال کنید، به همراه تمام اطلاعات مورد نیاز، به خصوص موارد خاصی که اجرای آن‌ها منجر به تولید مجدد باگ می‌شود.

مباحث مطرح شده در این فصل به عنوان روش‌هایی برای حل مسايل مرتبط که در فصل‌های آتی فرا می‌گیرید بکار می‌روند. تا آنجا که امکان دارد از آن‌ها بهره بگیرید!