![[Home]](http://www.itsayellow.com/wikis/srp2trans2_492w.png)
The continuing saga of my battle to install and maintain Fedora Core 3.
I like the fact that Adobe finally has updated its PDF reader for Linux, after possibly a decade of no development whatsoever. Way to go guys! Oh, and by the way, the scroll wheel on the mouse still doesn’t %$&*ing work!!
Ahem. Anyway, the default behavior when you move a page, either by scrolling or by using the “hand-grabber” mouse cursor, seems to be to completely redraw the whole page. It’s annoying. If you move the page even a few pixels, the page will keep redrawing and strobing.
To fix this, first recover from your epileptic fit. Then in Adobe Reader 7, go to Edit->Preferences->Startup. Select “Use page cache”. This will fix the issue. It probably uses more memory, but at least you won’t be having fits on the floor from the strobing display of your pdf file.
I just wanted to give props to Kaffeine, the KDE-optimized audio/video player. It’s a front-end to xine, a free audio/video engine. Together they play just about any video format that I’ve thrown at them. And Kaffeine does it with style. It’s one of the most satisfying, solid, and stylish open-source programs I’ve used. (See also Firefox.)
Make sure you know how to spell it. It’s German. Not that there’s anything wrong with that.
It turns out the major problem cups was having with my Windows machines trying to print was not that they were remote, or Windows. It didn’t like the fact that it was getting sent “raw” preprocessed data suitable for sending directly to the printer.
So I downloaded Adobe's PostScript driver for Windows and the ppd file for my printer from http://www.linuxprinting.org/ . I installed the Adobe PostScript driver, and when it asked for the network address of my printer, I entered the http:// URI for my cups IPP daemon.
As soon as my Windows computers were sending PostScript to my linux box and cups daemon, printing worked.
So that’s something to try if your remote IPP printing isn’t working with cups. I tried various methods to make cups print the raw stream, but really I just have no clue how to make cups work, so at some point I gave up and was just happy that printing works again.
I use KDE with Fedora Core 3, and it seems that Mozilla Firefox doesn’t know how to respect my choice for default email program unless I brutally force it to.
The way to force it is to add the following “hidden preference” to the file user.js in your user directory for Firefox:
user_pref("network.protocol-handler.app.mailto","/usr/local/bin/thunderbird");
If your executable for thunderbird is not in /usr/local/bin, then replace the second string with whatever the full path to thunderbird is.
user.js is like prefs.js, except that firefox will explicitly not ever write to user.js, even though it will write and modify prefs.js.
Here are some other hidden preferences that I use in firefox:
When you press tab in a web page, only move the focus between form elements--don’t focus on the hyperlinks in the page as well:
user_pref("accessibility.tabfocus", 3);
Show more “unhidden” preferences in the Advanced tab of the Firefox preferences window. These new preferences let you control how to display links in firefox that were sent to it by external programs:
user_pref("browser.tabs.showSingleWindowModePrefs", true);
The first of the following two prefs turns on autoscroll, or what normally happens in Windows when you push the scroll wheel as a button, see a scroll icon, and then can scroll the page proportionally to the location of the mouse. The second preference is very important. It turns off pasting the contents of the clipboard into the URL location if you push the middle click in the middle of the web page area. Normally, if you at any point middle-click in the middle of your webpage, it will load whichever url is in the clipboard into the browser. This is usually gibberish. This hidden pref turns that “feature” off:
user_pref("general.autoScroll", true);
user_pref("middlemouse.contentLoadURL", false);
Hmmm. Well printing on cups via IPP from Windows machines broke on Dec. 2 for no apparent reason. My laptops still talk to cups on my linux box, they show up in the logs, and their jobs show up fine as “Completed” in the cups queue. But they never get sent to the printer. And there are no errors. Just silently it all doesn’t work. I can still print locally from my linux machine fine. In the cups access_log and error_log it looks as though all clients are connecting and submitting jobs fine, but in page_log, none of the remote jobs show up as being printed.
Anyone who might know why this is happening? If so leave some comments. Or post a reply to my plea for help. I can’t think of anything I changed before it stopped working. It’s possible I up2date’d something, but I can’t think of anything related to printing.
If anyone has an idea how to start debugging this I’d be happy to know too. I made the logs capture everything with the “debug2” setting, but it still didn’t show anything unusual except the absence of printing.
I executed /sbin/chkconfig --list | grep on to see all of the things that the system automatically starts on boot at different runlevels. I then went through them to find any obvious things that I don’t use.
To turn something off: /sbin/chkconfig <process> off
There’s a bunch of other stuff pertaining to nfs that I can probably get rid of also. I also probably can get rid of portmap, since I don’t use any RPC protocols (I think.) But I think I’ve done enough damage for one day. I have to make sure I would never want to use nfs someday…
Then, I observed the same thing when converting text to postscript with the excellent program enscript. Viewing the postscript file in ghostview would show the text spilling over the intended margins. This led me to believe that maybe it wasn't just a printer issue, but a postscript or font issue.
It turns out it was a font issue. The issue is with a package called urw-fonts-2.2-6. This package is the Fedora Core 3 version of the free fonts which are the equivalents of the basic PostScript fonts. It appears that with this version, ghostscript displays bigger Courier fonts than it should. So it thinks that a certain number of Courier characters will fit on a line, but when displaying them they spill off the right side. Since my printer is PCL and not actually PostScript, ghostscript is doing the rendering of text files before they are sent to the printer to be printed. Thus both viewing in ghostview and printing directly to my printer show the too-large fonts.
My solution is to "downgrade" to urw-fonts-2.1-7. Now everything prints and view fine.
[Ref]
enscript -2jr myfile.txtThat will print directly to your default printer. With the --output=output.ps option, you could output to a file called 'output.ps'.
It even prints a nice header at the top of the page by default. You can customize everything, make interesting headers, etc. But I find that just by not printing text files in huge font and avoiding using many sheets of paper is reason enough to use it.
Here is my custom header that I use for enscript: matt.hdr. To use it, you download that file, and typically put it in /usr/share/enscript (or wherever your enscript *.hdr files are) and then execute the follwoing command:
enscript -2jr --fancy-header=matt myfile.txt
I finally not only got the printer to work for my linux computer, but also convinced it to serve the printer for our windows laptops.
I use cups, with a fairly normal configuration, but I made sure to Deny From None, and Allow From All. (I have an intranet behind a firewall so this is ok.)
I made sure to also disable my iptables firewall on my linux machine, also ok because I’m behind another firewall. You can keep iptables if you want, but you need to unblock port 631 for trusted computers.
I tried to use samba for a while, but found it excruciatingly painful. My windows machines could print to the printer via samba – sort of. There seemed to be a lot of miscommunication and freeze-ups on the WinXP side of things.
In the end, the best way to have the windows computers connect turned out to be as an “Internet Printer” in Windows terms. Or using cups IPP in linux terms. See this tutorial for an excellent explanation. The key for me was to discover the proper way to word the url. For a linux IP address of, for example, 192.168.1.2, and a printer named ‘myprinter’:
http://192.168.1.2:631/printers/myprinter
This form uses port 631, which is the where cups listens for IPP. The subdirectory and printer name were what I didn’t realize I had to add before.
On the windows machine, I went to “Add a Printer”, checked “Add a network printer”, checked “Connect to a printer on the Internet or on a home or office network”, and then entered in the blank the URL above. I then hit next, and when it asked for a driver, I gave it the native driver for my printer that I downloaded off the internet into a directory, using “Have Disk…”
The page I linked to above says that for Fedora you need to add configuration to cups to make it print a raw stream from the windows machines. On my more recent Fedora 3, I found it worked right off the bat with no extra configuration.
I have a APC Uninterruptible Power Supply, and so I thought, what better way to run it with linux, than with their native PowerChute Business Edition, for linux! Boy was I wrong.
Apparently (from APC tech support) this software doesn’t run any UPS over the USB link, even though almost all of their UPSes nowadays use USB to talk to the computer. Also it has absolutely no documentation. If you go to the official link on the APC website for the documentation for this software product, it will direct you to one file which is a single page of information entitled “Troubleshooting” which discusses a particular problem with a particular hotfix for Micros0ft Wind0ws. There’s a readme file, but that only tells you how to install it and turn their monitoring agent on, but after that, there’s a whole java web interface that I guess you’re supposed to guess about. (The tech support guy actually told me how to use it.)
A much more civilized approach is to get apcupsd, which after trying to get PowerChute to work, is the equivalent of running through a field of daisies on a sunny day. Or whatever you like doing on a sunny day.
If you have to use any USB device on a linux 2.6 system, required reading should be the following: Beginnings of Comprehension and Enlightenment. Especially the latter will help you to take a random generic USB device, and turn it into something far more identifiable, such as /dev/palm, /dev/lp-brother, or even /dev/ups. Much magic happens in /etc/udev, such as assigning device names to loaded drivers (/etc/udev/rules.d) to defining permissions of devices (/etc/udev/permissions.d). And it’s not just for USB. For instance, my nvidia graphics card drivers are loaded by udev and have their permissions also set by udev. Knowing udev means living a richer, happier life with a linux 2.6 kernel.
Another great tool specifically for USB information is usbview. It’s a great help in writing rules for udev. It updates in real time, so you can unplug and plug USB devices and see how they show up.
Recently on a computer at work we had some jerk trying every common username and password through ssh, and we wanted to be sure that the little guy hadn’t actually gotten in and mucked anything up. A colleague alerted me to chkrootkit, a program you can run to check for “rootkits” which are basically automated hacking programs. It’s the first thing to look for if you’re concerned about someone hacking your system.