|
|
As mentioned in the last section, one of the most powerful tools at your disposal is a community of people who have had the same problems you're having. However, like any tool, you need to be sure to use it properly and carefully.
Debian has a large, vibrant community of developers and users who often devote countless hours of their own time to helping other people troubleshoot their problems. Most of these people are not only generous enough to help you solve your problem, but they're also practical enough to make sure that you leave with a better understanding of how things went wrong in the first place and how to avoid such a situation in the future.
As mentioned, the canonical location for a Debian package's documentation is /usr/share/doc/packagename/. Additionally, Debian Policy requires that all shell commands contain manual pages. Run apt - get install man - db manpages to install both the man page reader (man - db) and a set of common, shared man pages (manpages).
Sometimes, however, if the documentation is particularly disk-space-intensive, the package's documentation will be put into a second package. If /usr/share/doc/packagename/ doesn't contain what you're looking for, and the manual page was either nonexistent or inappropriate, you should run apt-cache search pdckagename doc. That will show you any relevant documentation packages.
Last but not least are on-line sources of documentation. Debian provides a portal page for common documentation resources at www.debian.org/doc/. From that Web page, you'll also find links to The Linux Documentation Project (LDP), which deserves special mention. It contains many thousands of pages worth of guides and references for the documentation-hungry user. The Linux Documentation Project's official website is available at www.tldp.org/, and you can download and install the documentation for local use-just apt-cache search doc-linux and install any packages you think are appropriate.
One of the more often-overlooked aspects of getting support, whether free or paid, is etiquette. Everybody has limits, both support personnel and users, and either side being demanding can quickly wear down patience and result in a poor experience on all sides. In that vein, here are some pointers you might want to keep in mind when you're getting support:
Above all, be polite.
If the person who's helping you asks you to run commands and provide them with the output, try to do so reasonably quickly so that nobody is left waiting.
If you're being helped over the phone or in person or via some other real-time communications medium and you need to take a break, don't be afraid to say as much. Chances are, the person who's helping you wouldn't mind the chance for a coffee break either.
If you have a question, go ahead and ask it-in a forum dedicated to support, permission to ask questions is implicit.
Instead of telling somebody that "it doesn't work," try to give some details. It'll save you some time, as the first question the person providing the support will always ask is, "in what way doesn't it work?"
Not everybody is created equal, and if you find that somebody who's supposedly trying to help you is either being offensive or giving bad advice, try to get in touch with the individual responsible for that particular support forum. Tell them about your encounter so that others don't have the same experience.
Now that you know the basic ground rules, let's go over your options for free support. As I've stressed, there are all sorts of people who enjoy spending some free time helping others.
The first thing anybody helping you will need to do is diagnose the problem. To assist in that process, you want to try to collect as much information related to your problem as possible. Not only will it be quicker for you, but it will be less stressful for the individual who's helping.
If you're getting an error of some sort, have it handy. If you can, copy and paste the error to a file for easy reference. Avoid writing things manually at all costs-even the slightest typo can cost hours worth of false leads. Also be sure to include the full command-line you're running, or document the steps required to reproduce the error. These are the first things you'll be asked when somebody tries to help out, and being able to answer their questions quickly and easily will likely make them quite happy.
If the application which is giving you the error is console-based, and doesn't require any user input, you can redirect all of its output to a log file:
# command -all --options here > command.log 2>&1
This will create a file called command.log in the current directory. If the application requires user input, you'll need to copy and paste all the relevant output manually.
If the application has any configuration files, be sure to have those handy as well. You can and should edit out any sensitive information (such as passwords), but tell the person who's helping that you did so.
Mailing lists are a primary source of support for many people. While the answers won't necessarily be prompt (though many of the simpler questions are answered within minutes), it's a fairly convenient method of communication. A mailing list is a special e-mail address which, when sent an e-mail, forwards the message to many recipients. It's like a broadcast, in a way, except that it goes to only those people who are interested. These are the people who have subscribed to the list.
The primary Debian technical support and user mailing list is debian-user@lists.debian.org. You can subscribe to it via a web form at http://lists.debian.org/debian-user/. This list is very high-traffic, so you may not want to subscribe to it unless you like lots of e-mail. You can still send an e-mail to the list, but mention that you aren't subscribed and that people should send any replies directly to you (instead of through the list).
There are many other Debian mailing lists, some of which are versions of debian-user@lists.debian.org, except for specific languages. For a complete index, check out http://lists.debian.org/.
Mailing lists have been around for many years, and common Free/Open Source Software e-mail applications deal with them extremely well. However, most commercial e-mail applications are quite lacking in this respect. One of the side-effects of this has been a rise in the popularity of so-called "web boards."
These have been pretty slow to catch on in Debian, as mailing lists are simply so well-supported that many don't have the need to use anything else. However, at some point in the future there may be an official Debian web board for technical support. In the meantime, you can use an unofficial web board at www.debianforum.com/. At the time of writing, this forum has just been opened, so it doesn't have many active users. You may or may not get help there.
A popular option for people looking for help is the use of IRC, which stands for Internet Relay Chat. Like mailing lists, IRC has been around for well over a decade. It's a near-real-time protocol, meaning that when you type out a message, others see it within a second or two.
There are many popular IRC networks, and most of them have a Debian "channel." A channel is a group chat, where many people see every message sent to the channel. The most official of these channels is #debian on irc.debian.org. If you wish to access this network, you'll need to download and install an IRC client. If you have Internet access for your Debian installation (meaning your networking is working, of course), I would suggest either the irssi (for a console environment) or xchat (for a graphical environment) packages. They're both good IRC clients. They'll also both connect you to irc.debian.org by default. When you've connected, simply issue the /join #debian command, wait for the channel to appear, and then start talking.
When you're using IRC and speaking in a channel, you should avoid pasting large amounts of text at once, and avoid hitting your enter key too often. Be sure to type full and complete sentences. Both of these suggestions help improve the channel's usability for everybody else-if everybody hits Enter after every third word and pastes 10 or 20 lines of text every few seconds, nobody will be able to follow any conversations. Instead, put your text in a file and place it somewhere from which it can be downloaded. If you don't have a readily-accessible server for this purpose, www.pastebin.de/ allows you to paste your text and provide a URL for others to follow.
The quickest and easiest way to report bugs in Debian is via the reportbug package. This provides a console-based, step-by-step procedure that walks you through reporting a bug. After installing the package, however, you do need to tell it your name and e-mail address. I've included a sample ~/.reportbugrc below:
# cat ~/.reportbugrc real name "Your Name Here" email "your@email.address" #
Create that file with whatever editor you prefer-the file format should be self-explanatory, but if you need more information, consult its manual page via man reportbug.
After this, simply run reportbug packagename. It will walk you through reporting a bug step-by-step.
After you report a bug, the maintainer of the package will hopefully be getting in touch with you shortly. Be warned, though; package maintainers are sometimes quite busy, and if your bug report is particularly thorough, the only response you'll get is an e-mail telling you the bug has been fixed.
If you've decided to run Sid, you probably wish to keep abreast of any developments.
If you are administering a large number of Sid machines, then by far the best option is to have one or more "prototype" machines with every package you have installed on all your various Debian machines. Test each upgrade before you roll it out to the other machines, and you'll get a really good feel for what the upgrade entails (they're typically quite painless).
In addition to a test/prototype machine (or in lieu of one, if you don't have one handy), the packages apt-listchanges and apt-listbugs are helpful. apt-listchanges allows you to view packages' changelogs and news items before they're installed. apt-listbugs allows you to view any major bugs that have been filed against a package since it was last upgraded.
At the time of this writing, there's discussion revolving around a daily "State of Sid" mailing list, which will allow users to subscribe and receive daily notifications on any known breakage. Check http://lists.debian.org/ to see if this mailing list exists yet.
| Web Resource |
http://people.debian.org/~dbharris/tracking-sid/has some links, documentation, and scripts that you might like to look at if you run Sid. |
If you're running a company, chances are you're interested in paying somebody to provide a guaranteed level of service. This is quite understandable, and you have a couple of options-in-house support and commercial support.
Most small- and large-scale Debian users prefer to use in-house support for its cost-effectiveness and quality. Since Debian is built by the systems administrators who use it, self-support is without a doubt the preferred support method. If you're interested in hiring individuals familiar with Debian to support your systems (as opposed to training your own pre-existing staff), you can send an e-mail to debian-jobs@lists.debian.org detailing the responsibilities and compensation of the position. Alternatively, if the position is of a sensitive nature, you can e-mail debian-private@lists.debian.org, which is read only by official Debian Developers. Messages sent to debian-private@lists.debian.org are kept in confidence.
If you'd rather pay a third party maintain your Debian systems, there are two primary options: Hewlett-Packard Services and Progeny. Both of these support vendors deal with each client on a case-by-case basis. You can contact Hewlett Packard Services via www.hp.com/hps/, and you can negotiate a support contract with Progeny by sending an e-mail to sales@progeny.com.
|
|