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.


I have a theory on Linux distributions that move to "Enterprise ready".

The theory says that in order to be "Enterprise ready" (they think) it has to remove all "just-works" and end-user level configuration so that it does not step on the toes of the company's administrator.

However, given your report about removing essential version information and not updating documentation accordingly, I have another theory!

This new theory says that Ubuntu Dapper is not about being "Enterprise ready" but about testing administrators, e.g. something a company could use to test if a person applying for an admin job has the necessary qualifications.

Afterall making something work that has been deliberately broken requires extraordinary background knowledge, something every company would like their admins to have.

There is a third theory!
The package has been a mistake the packager wasn't aware of beforehand, but might appreciate a bug report. I guess not being able to configure printing qualifies as "crave" for a desktop oriented distribution

By krake at Sun, 04/02/2006 - 16:50

I know one of the main selling points of Linux is security.
But I also thought another main selling point was the ability to set things up the way WE want rather than the way some software company THINKS we should want it.

I'm not a Linux expert by any stretch of the imagination.
But just this weekend, I install Kubuntu and struggled for the better part of Sunday afternoon trying to get a darned printer to work.

I tried to do it the right way and learn in the process. Then in disgust I ran to the office and copied all the cups and samba .conf files I had on a working Mandriva install to a CD. Brought them home and compared them again the Kubuntu .confs. Finally pieced together enough to get the printers to work and my laptop to be able to print to printers connected to this desktop as well.

Then much to my surprise I read this !
I knew I wasn't having that big of a brain fart.

Someone with authority, please convince others with authority to STOP making these types of decisions for us. Tell us HOW to do it if we choose, but don't go making decisions like this for us. Let us decide what's right. Or at least make it somewhat easy to fix. Otherwise, I can't see all that big of a difference between Linux and MS (and each flavor of Linux seems to exert some sort of change for us).

By aipforum at Mon, 04/03/2006 - 20:20

... if you all as developers (kdedevelopers.org) have problems with these situations, what is the average user expected to do about them.

I am finding, that from Ubuntu you have very similar problems, see bugs # 37018, 37019, 37985 and 37986 at https://launchpad.net/distros/ubuntu/+bugs?

As I have little previous experience with CUPS, I have a hard time getting things straight.

There seems to be a discrepancy between CUPS and the gnome-cups-manager ( or the equivalent in KDE ). When I log on to localhost:631 ( at least I can ) all printing is done from some imaginary "guest" account.

It would be extremely helpful for me if you let me have an example of your working cups and samba files, and also file your findings as bugs on malone, if you haven't done so already.

Your question "So is Linux becoming the next MS ?" at this point in time can clearly be answered with "NO". distrowatch.com lists 100 "distributions" they think worth noticing, not talking about the countless others. All of them supporting at least 3 different Kernels plus their individual payload.

This reminds me very strongly of the days before MS, and Linus by no means is Bill. Linux has come a long way, true. But it is still lagging vastly behind.

By casualprogrammer at Sun, 04/09/2006 - 07:57

As you can see at [1] Martin Pitt (pitti) is looking into packaging the cups RC and the 1.2 final release also.

The localhost:631 question _is_ addressed in the README.Debian.gz file:

" - Administration over the web interface is disabled by default since it
requires the CUPS daemon to be able to read /etc/shadow. If you want to
enable web administration with shadow passwords (authentication type
'basic'), put the user cupsys into group shadow by

adduser cupsys shadow

as root.

Only users who are in group 'lpadmin' can administrate printers (using
gnome-cups-manager, lpadmin or any other frontend but the web
interface). To allow printer administration to user joe, put him into
this group by executing

adduser joe lpadmin

(again as root).

The Browsing On issue I've reported on [2]

[1] https://lists.ubuntu.com/archives/ubuntu-devel-announce/attachments/20060330/a61a58f7/DapperDevStatus30-March-2006v1.1-0001.pdf
[2] https://launchpad.net/distros/ubuntu/+source/cupsys/+bug/37747

By jayavarman at Sun, 04/02/2006 - 18:19

"localhost:631 question _is_ addressed"
Sure; but it didn't work for me.

Also, from what I read (and still remember right now), that README is not written recently; it's addressing stuff from CUPS-1.1.x, and doesn't even mention CUPS-1.2.

From what I remember, cupsys was already part of the shadow group, and yet it didn't work. So the README wasn't dealing with the point promised in the front page hint.

I can't reboot into the Live CD right now to check again; I need to get work done on the real system, and I'll be away until Wednesday from tomorrow morning 5:00 h.

And second: the statement/consideration that "the web interface needs to be disabled by default because we don't want cupsys to be able to read the shadow file" is incomplete and flawed: if you setup the "AuthType" directive to be "BasicDigest" or "Digest", all passwords for CUPS admin will be completely separated from the system passwords. CUPS will then start to maintain its own password file, in "/etc/cups/passwd.md5". Of course, you need to take care to populate that password file with all user entries you want to become CUPS admins. This is done with the command "lppasswd -a username".

This way you can still have a web based, safe-to-use (and working) admin tool for your users, and do not need to take it away from them altogether for the sake of security. [Of course: make sure that you inform your users how to bootstrap that security system with running "sudo lppasswd -a username" (or some such) in the first place! You seem to know already how to do that, given the patched web interface I encountered.]

Do you know how many users were not able to print (because they could not install a printer), just because of that??? "Uhmmmm... we now have a secure system, that doesn't let me get my work done. But that's fine, because it's secure now."

But anyways: thanks for your feedback and the links you provided; it is much appreciated.

By Kurt Pf. at Sun, 04/02/2006 - 20:28

I did find the browse.conf and find the setting odd, and changed it. I was also adviced (on #kubuntu) to make cupsys a member of the shadow group. Yet i wasn't allowed to add a printer until after I set a root password.

By sredna at Sun, 04/02/2006 - 19:18

Problems like this are one of the reasons I've switched from Kubuntu to Debian. I seemed to have annoying problems like this with every "easy" distro that I have tried. At least with Debian, things seem to "just work" as long as you have the correct packages installed.

Elijah Lofgren

By elijahlofgren at Sun, 04/02/2006 - 23:33