Frustrations with Kubuntu Dapper Flight 6 and how it handles CUPS 1.2svn
A few weeks ago, Jonathan had asked me on IRC in passing why kprinter and KDEPrint 3.5.1 didn't work with CUPS-1.2. My reply had been like "CUPS-1.2 hasn't even released an alpha or beta tarball -- w.t.h. does Ubuntu Dapper plan to include an SVN version of a piece of core software which has a yet unknown release date??" Of course, this is not Jonathan's personal field of work -- Kubuntu just inherits the CUPS version and setup which the Ubuntu main developers decided for.
Regarding an impending CUPS-1.2 release, prospects have become much brighter in the meanwhile. During March, Mike Sweet released 2 Betas and the first Release Candidate. So a final 1.2.0 release seems pretty close now.
After reading last night that "Dapper Flight 6" was available, I decided to download the Live CD version of Kubuntu. Download took 6 hours, but luckily was completed after I woke up.
So the first thing I opened after booting was Konqueror with "http://localhost:631/". Indeed, a headline "Common UNIX Printing System 1.2svn" welcomed me. Hmmm... which version from SVN did they use? I know for a fact that the exact revision is shown if you compile from sources. So why did the Ubuntu developers patch it away? Was it in the name of "user friendlyness"? I can't see any reason why they then left in the 3 letters "svn", or even the "1.2" ones. At any rate, for the sake of clarity, it is *much* better to leave alive all info available when offering pre-beta software to one's users -- especially if it is a testing release itself like "Flight 6" is one.
I had to run "dkpg -l cupsys" to conclude from the "r4929" part of the package name that this current Dapper Live CD included an arbitrary SVN version that's already 10 weeks old. So my next riddle was: "If they indeed do include bleeding edge, untested core system software in Dapper -- why don't they do it for real then? Why don't they go for the most recent revision available? Or why didn't they at least take the official Beta 2 release from 3 weeks ago?" -- CUPS SVN Revision 4929 is at least 10 weeks old; Beta 2 (which happened around revision 5261) was released on 10th of March; RC1 is from 24th of March. Current SVN revision is at r5362...
Anyway, the CUPS localhost:631 page welcomed me with this message:
- Administrative commands are disabled in the web interface for security reasons. Please use the GNOME CUPS manager (System > Administration > printing). /usr/share/doc/cupsys/README.Debian.gz describes the details and how to reenable it again.
Needless to say, that Kubuntu doesn't include something called "GNOME CUPS manager", neither in the menu, nor to be found from the command line.
However, that README.Debian.gz didn't include any description of "details and how to reenable it again". Very frustrating! Now, I'm probably able to find out what to do once I take some more time; but this morning I only had 30 minutes -- and these were not enough for me to get it into a working condition. (I'm now on a train, with just a few notes from this mornings experience, writing all this down).
But what was even more of an annoyance is that not only administrative commands were unavailable. The *whole* of the CUPS web interface seemed to be disabled! Not even the help pages were accessible! All I can see is the start page; clicking any of the links does do nothing. I wonder how they made that. (My first thought, that they had removed the executable bit from CUPS' admin.cgi was not confirmed -- all CUPS *.cgi programs are there, with all exec bits set).
Looking at the cupsd.conf file reveals this: They have set "Browsing Off". And that's not even inside the main cupsd.conf file -- they use the (very uncommon) "Include" directive, to suck in a file named "browse.conf" that has this setting.
Now talk all about security you want; but "Browsing Off" just blocks a user from auto-discovering other printers attached to CUPS print servers which may be in the same network and which announce their queues via a simple UDP package broadcasting mechanism. I can't see how this substantially increases security for users (you also don't make using WiFi an Olymic Steeple Chase either, do you?) -- but of course, you do decrease the comfort, user-friendlyness, power-to-get-work-done, usability and fun to work with Kubuntu.
I suspect that the CUPS packager is just very unfamiliar with CUPS browsing. I remember an email discussion with one of the Debian guys from a few years back, which clearly showed that the person in charge then initially was completely clueless about how CUPS browsing worked. So let me repeat:
Browsing On #BrowseAddress @LOCAL
is completely safe for CUPS clients. "Browsing On" makes them pick up and autodiscover any (UDP) printer announcements from local CUPS servers. It enables them to print with "zero configuration". It makes printing "just work", out of the box (provided the CUPS server is correctly configured). It gives them all printers without installing any printer locally. It gives them all driver information to be used from their clients without any need to set up a printer driver locally. It does not turn their box into a print server! It does not make their box broadcast themselves. It does not make their box listening to and accepting TCP/IP connections. It does not do any dangerous things. Only this...
Browsing On BrowseAddress @LOCAL
...will convince their local cupsd to act as an active node that announces its own locally installed printers to the world around itself. @LOCAL is a shortcut that includes all local interfaces (i.e. the ones named ethN, wlanN, lanN,...), whatever their current IP address is, but excludes all "non-local" (a.k.a. dialup) interfaces, like DSL adapters, modems and ISDN cards (i.e. the ones named pppN, isdnN,...). And even if these announcements do happen, it takes a few additional configuration settings to actually also accept print jobs from remote clients.
Anyway, in the 30 minutes I had I was unable to figure what I could do to make the CUPS web interface work on Kubuntu Dapper Flight 6 as it is intended to work. (Hmmm... maybe there is even a bug in this old revision of CUPS SVN involved). Also (and needless to say after all this), KDEPrint's CUPS admin interface didn't even start up. I'm giving up on Kubuntu Dapper Flight 6 for now...
But I'm trying to be positive in all my frustration, so here is the bright side of it: the Ubuntu developers *at least* included a clear hint on a well visible spot so a user can discover that things are unusual, and may conclude that all common advice he may get on any of the standard printing support lists ([one], [two]) may just be a dog's breakfast. That is way better than what f.e. SUSE does: they also patch CUPS away from the officially documented default settings, but without patching the CUPS documentation at the same time.