Recommendations to (K)Ubuntu Dapper users: How to restore an uncrippled CUPS [1: web interface admin functions]
[1] Restoring the CUPS web interface admin functions
(K)Ubuntu Dapper maintainers have crippled the CUPS 1.2 web interface. If you open http://localhost:631/ (link only works if you have CUPS up and running) you'll even get notified about it:
- -->
- Administrative commands are disabled in the web interface for security reasons. [....] /usr/share/doc/cupsys/README.Debian.gz describes the details and how to reenable it again.
So it is "security reasons", huh? I'll deal a bit later with this statement, and how valid or not it is.
Let's first look at the way the measure is implemented. After all, the motivation may be completely valid. But if it indeed is, then users surely would deserve a completely clean way of disabling it, no? An implementation of that cropping measure that keeps them fully informed? Instead, the message is rather hidden amongst the rest of the page. Have a look (click screenshot on the left for full size):
[image:2107 align="left" size="preview" hspace=8 vspace=4 border=0 class="showonplanet"]
It certainly doesn't look like a lot of "usability" thought has been wasted on that change. The warning gets lost amongst the rest of the page. The page still has many other elements in it which demand attention. It has lots of links links (11, to be precise), which are even emphasized by button-like images, get high-lighted by "mouse-over"... and, in the end, they are completely non-functional and misleading because upon clicking them they do not do what their labels indicate.
Well, when I say "completely non-functional", you may be curious and try it. So did many other users. And lost lots of time by doing so. Because the links do indeed take you to the next pages. However the next pages will not have the warning quoted above. They'll present themselves like they were fully functional. They have more seductive links and buttons, such as inviting to "Add Printer", "Modify Class", or "Set Printer Options". If you click on those, new dialogs come forth. You can do a lot of stuff. Until the end, when you want to commit your changes: then the password dialog comes up. But no password will work. Not the root password, and not your user password. By that time you may or may not remember the half-hidden warning of the main page (which you may or may not have noticed in the first place...).
Now, if the packagers already go to the length of patching not only a half-hidden sentence into the web interface, but even change the CUPS source code to keep a CUPS-1.1 functionality (more about that later) that was removed in 1.2;, given this background, I'm surely not asking too much if I want these changes to be implemented in a more unambiguous way so users are not led to complain in CUPS.org newsgroups about missing features. At least it would give a more honest picture about the Dapper packagers' changes to the users. What about....
- ....making the sentence better highlighted (like colorize the font in red), so it is easily noticed by users?
- ....removing the buttons + links that misleadingly suggest users can still "Manage Printers", "Manage Server", and so on?
It's easy. Even I can do it. And I'm neither a Web, HTML, PHP nor C or C++ developer, just a user that has some shell scripting experience. Have a look (click screenshot on the right for full size):
[image:2108 align="right" size="preview" hspace=8 vspace=4 border=0 class="showonplanet"]
Of course, the best choice in the interest of users would be to not cripple the web interface at all! But, Ubuntu packagers: if you decide for crippling the web interface, better remove all those useless buttons altogether! They only seduce users into clicking them; when then the next web pages indeed does appear, users naturally expect them to also work (which they don't).
Oh, and before you tell me, that in this case users could not easily restore the full CUPS functionality, because of the removed links: they can. Just provide two versions of the relevant file: /usr/share/cups/doc-root/index.html{.ubuntu,.orig} and put it into the README how to enable one or the other. Heck, you could even wrap all the required changes into the dpkg-reconfigure cupsys script!
[image:2110 align="left" hspace=4 vspace=2 border=0 class="showonplanet"]
So what things do users miss when the web interface is disabled?
[image:2111 align="left" hspace=4 vspace=2 border=0 class="showonplanet"]
The first few shots are what you may already be familiar with. Most of these are functions were already there in CUPS 1.1.
Screenshots (click on thumbnails for full size) are more illustrative than words. You aren't allowed to...
[image:2112 align="right" hspace=4 vspace=2 border=0 class="showonplanet"]
- ...set printer options,
- ...add new printers,
- ...create classes of printers,
- ...set an error or operation policy for a printer,
- ...start/stop printers,
- ...pause/resume/cancel jobs,
- ...move jobs to different printer,
- ...use the auto-discovery feature for uninstalled network printers
and much, much more.
[image:2115 align="right" hspace=4 vspace=2 border=0 class="showonplanet"]
Particularly annoying is the disabling of two features. First, the new easy to use, one-click configuration settings demonstrated in the screenshot to the right (click to enlarge). They let users easily access features like: [x] Show printers shared by other systems [ ] Share published printers connected to this system [ ] Allow remote administration [ ] Allow users to cancel any job (not just their own) [ ] Save debugging information for troubleshooting
[image:2116 align="right" hspace=4 vspace=2 border=0 class="showonplanet"]
Second, removing the ability to access and edit the cupsd.conf configuration file from the web interface (including the ability to restore a working, default setup):
OK, winding up the complaining part now. Back to re-enabling the full functions of the web interface...
Why is that damn web interface even important, you ask? There are several reasons, each one good enough on its own. The closer you get to printing or admin functions required in "small businesses" or "enterprises", the more important do they get. But even home users would benefit from acknowledging them:
- it is easier to use for newbie users than the commandline interface is
- it is the only non-commandline user interface supported by the CUPS developers themselves
- it is the only non-commandline user interface that works the same across all platforms and distros (sans the insane modifications some packagers make)
- it even works in non-GUI terminals, if you use a text based browser such as links, lynx or w3m
- it is the only user interface that is always up to date with the current release of CUPS (all third party frontends do necessarily have a delay before they support new features)
- the Gnome CUPS Manager supports only a fraction of the CUPS 1.1 or 1.2 functionality
- while the KDEPrint CUPS Manager supports all of the CUPS 1.1 functionality, it is not yet up to date with CUPS 1.2, and even if -- KDE is not every user's choice!
- it is currently the only user interface that supports some of the newest cool features in CUPS 1.2 (such as the "one click reconfiguration of CUPS"; or the SNMP network printers autodiscovery tool -- for details about this, wait for my next entry in this blog series)
So how do we re-enable it now? The named README.Debian.gz essentially tells us: run the two commands
- adduser cupsys shadow and
- adduser joe lpadmin (replace "joe" by your own name)
and be done. The second one should add user joe to the lpadmin group (which by default is the only user group allowed to manage CUPS functions) and establish his ability to administer CUPS; the first one should let him also do so via the official CUPS web interface, not just the commandline (or frontends such as KDEPrint's Printer Manager, or Gnome's CUPS Manager), because the Dapper CUPS daemon runs from the cupsys account.
So, adding user cupsys to the shadow group, and each user who should be able to administer CUPS to the lpadmin group will do the trick: the CUPS web interface in principle will work again to its full extend (sans some bugs which may still be present in Dapper's packages).
There's more to it. CUPS 1.1.x for more than 3 years had an officially supported configuration directive "RunAsUser Yes", which allowed the CUPS daemon to run without root privileges. This measure, in theory, is meant to increase security. However, CUPS developers found it didn't increase security in practice, but on the other hand led to many, many more user problems with the base functionality. Therefore they removed RunAsUser again in CUPS 1.2.0. Debian and Ubuntu however want to keep this function that was removed upstream. Maintainers patch CUPS and hardcoded it to run the scheduler program ("cupsd") and the *.cgi apps responsible for the web interface with the access rights of the "cupsys" account:
root@obiwan:/home/kurt# ps u | egrep '(cupsd|cgi)'
cupsys 11040 3.8 2.4 8372 6212 ? SNs 07:42 10:18 /usr/sbin/cupsd
cupsys 11044 1.8 1.4 132 126 ? SNs 07:43 0:08 /usr/lib/cups/cgi-bin/printers.cgi
In effect, this is a hardcoded "RunAsUser Yes" with "User cupsys" setting. Therefore that "cupsys" user needs to be made part of the "shadow" group whose members are allowed to read the /etc/shadow password file. And user joe needs to be in the "lpadmin" group so he can manage printers without needing full root privileges.
I'm not going into the detailled arguments of that particular point ("RunAsUser") in question now. Admittedly, I'm not very much convinced by the Debian/Ubuntu camp's arguments -- but I can't argue too well against them either. For some more details, readers may want to look at one of the many relevant threads in the CUPS forums.
However, I am very much convinced of all other points I have to make. And that is why this series will continue...