I've often found the solution to computer problems I've encountered by searching the web and finding that someone else faced the same problem. I decided to keep this log in hopes that it may be useful to others.
The two main computers I use run Debian GNU/Linux unstable, so most of the issues refer to that distribution.
This is not a detailed recipe, but just some pointers to issues that I've run into. I got all this working a few years ago, but a recent upgrade of packages may have caused some problems, so I revisited all these issues.
On Debian, Exim4 comes with a default configuration that was pretty good for me, except that it doesn't immediately handle Spamassassin, Mailman, or virtual domains.
The easiest to add is Spamassassin, assuming that you are willing to run Spamassassin in the ACL section, rather than as a router. To address this difference first, there are several ways to use Spamassassin. I am not an expert in the intracacies of Exim, but the two choices are basically: do you want Spamassassin to look at email before Exim gets to routing and transporting and report to Exim what it finds (but not changing the copy of the email that Exim is using), or do you want Spamassassin to process the email and change it (usually by adding headers) as part of Exim processing?
The former method (where Exim does not use any changes made by Spamassassin) is using Spamassassin in the ACL section of Exim. This is easier to configure since Exim4 (at least 4.69 on Debian) includes commented-out configuration sections. One part early on specifies where the spamd process is running. The later part indicates what actions to take based on the Spamassassin output.
Important note: if you use this method, then changes that Spamassassin makes to the email are not used. Any changes that you want made to the email must be given in the ACL section of the Exim4 config file. So you need to pay careful attention to this.
The configuration that is commented out is not very good in my opinion. To be fair, there are comments saying that it isn't the only way to do things. A big difference is that by default (I think) Spamassassin would write headers like 'X-Spam-Flag' and 'X-Spam-Report'. But the sample configuration uses headers like 'X-Spam_score' and 'X-Spam_bar'. Also, there's no flag for just indicating whether the email is thought to be spam. So I didn't use the example setup.
I found the instructions at the following site were useful: http://www.maretmanu.org/homepage/inform/exim-spam.php#spam
Note that these headers still aren't exactly the same as the Spamassassin defaults: they use 'X-SA-*' instead of 'X-Spam-*'. You can change that if you really want more typical Spamassassin headers. Also, consider changing the exact threshold values (5.0 and 7.0) to values that make sense for you.
The Exim4 config file does not include support for virtual domain handling. Do a web search for 'vdom_aliases' to see an example (popping up basically the same on several websites) of how to handle this.
Important Notes: The order of routers in the config file does matter. Most examples will tell you a reasonable place to put it. With the examples I found, note that mail to an address ("local_part" in Exim terminology) on a virtual domain that is not present in the virtual domain's forwarding file will cause an immediate failure. If you are using mailing lists on virtual domains, then this can be a problem, since you don't want the mailing list to be "forwarded" but you also don't want to fail. Therefore, you need to have your mailing list router (like the Mailman router below) before the virtual domain router.
On Debian, check the file /usr/share/doc/mailman/README.Exim4.Debian. This has good instructions for getting Mailman to work with Exim4. You need to add a router and a transport section to the configuration.
If you are using virtual domains, see the warning above about putting the Mailman router before the virtual domain router.
I haven't posted in a while. It's not because there have been no challenges, but I've been a bit lazy and none of them have been major until this one.
My wife and I recently decided to replace our aging HP DeskJet 722C with a multifunction printer/scanner/copier/fax. I did some checking on reviews to see what was recommended and GNU/Linux compatible. We decided on a Canon Pixma MP530, which had good reviews on CNET.
But wait! It turns out my search for GNU/Linux compatibility was based on a printer driver available from TurboPrint. It was late at night and I did not realize that this is a non-free driver! I did not discover this error until I had unpacked the printer and tested the copying functions (which don't require the computer at all).
The good news: We have both the printer and scanner functions working without using the Turboprint driver. Here's what I did:
We were able to get good printing functionality using a driver available from the Canon Japan site. Several sites had recommended this for similar printers. I don't think it is completely free software, but I don't feel too bad using a GNU/Linux driver from the company.
alien filename.rpm to convert each of these to deb packagesdpkg -i filename.deb to install each of them.I actually had a little more trouble than this, mostly for unrelated reasons (I tried changing the name of the ppd file without fully understanding what I was doing). But now the printer seems to be working fine for me. I can even use the duplex feature! We have a Windows computer that accesses the printer through CUPS, and this works fine as well. (When I originally set this up for the old printer, I think I had to change a few CUPS configuration files to pass the 'raw' Windows communication directly to the printer. So I did have to install the Windows printer driver. It came on a CD with the printer.)
The only printing feature I would like to have is a CUPS option for grayscale mode. It may be possible to accomplish this by editing the PPD file, but I'm not sure. I may check more on that later.
This was easier to sort out. The SANE project almost supports it out of the box. The support for the Canon Pixma MP530 comes from work done by Wittawat Yamwong.
The current version of the Debian unstable SANE package uses SANE 1.0.18. This didn't just work for me, though I expect that in a version or two it will 'just work' with the MP530.
Wittawat Yamwong has more up-to-date code than SANE currently uses. The SANE code (for Pixma support) comes from an older version of his code; as soon as they incorporate the newer version of his code I bet it will just work.
The only other feature that I wanted was the ability to scan legal documents. These won't fit in the flatbed, so the ADF is the only option. However, the sane-pixma backend has a fixed upper bound on height based on A4 size. To get around this, I went into the source code and changed the upper bound to an appropriate value for legal size (but left the default value). Then I could use scanadf with a command-line option for the height, and it works fine. I'm not going to put more details here, because I don't know whether there is a risk of physical damage if a large height value is sent for a flatbed scan. It would be nice if the SANE interface provided greater scanning heights for the ADF automatically.
I haven't tried faxing yet, but I don't think any computer support is necessary for direct faxes, which is all I plan on.
I got lots of messages ending in "Disabling IRQ #11" during boot. There are lots of emails about this on various lists. A web search will reveal them (though the IRQ number varies). Apparently this issue started somewhere between kernels 2.6.8 and 2.6.12 (or something).
Without the "irqpoll" option, the boot would fail. With the "irqpoll" option, the boot succeeded, but I was still concerned. I thought it was related to the issue below, but now I don't think so.
Workaround: Disabling ACPI in the BIOS caused the messages to stop. I'm not sure exactly why; it is older hardware, so that could be contributing. This is a desktop machine, so I don't mind disabling ACPI.
I started getting lots of these messages in syslog from both my CD and DVD drives. There was no noticeable change in performance, but it bothered me nevertheless. Removing the ide-cd module caused the messages to stop, which I guess isn't surprising.
By removing hal, the messages stop, so apparently there is some problem with hal or hal's interaction with the kernel. Removing hal required that I remove gnome-volume-manager. This is acceptable for me. Hopefully the issue will be corrected in the future.
Workaround: Remove hal. This caused the boot-time names given to my drives to change, which required changes to /etc/fstab.
After a recent upgrade on a machine running Debian unstable, I found that most things worked fine, but emacs couldn't find fonts. Emacs running in the terminal was OK, but when it tried to create its own window, all the characters showed up as boxes.
It turned out that this is because of a major upgrade to X.org, which switched file locations to better conform to the FHS. Details are available on the Debian Wiki.
The solution in my case was to edit /etc/X11/xorg.conf and change the FontPath declarations to look in /usr/share/fonts/X11/.
Page last updated on 2008 Aug 10