|
JUN
5
2006
|
How Dapper LTS Succeeded To Spoil CUPS Printing (Part Three -- Installed on Harddisk)I installed Kubuntu Dapper now from the Live CD to the harddisk. The hardware is very "low end": Intel P IV 1.80 GHz, 256 MByte RAM, 20 GByte HD. But it should be good enough to check the printing capabilities of Dapper, and see how the packagers modified the CUPS setup away from how CUPS.org's defaults. After all, the complaints and calls for help I received must have a reason... [image:2074 align="left" hspace=8 vspace=4 border=0 size="original" class="showonplanet"] The installer worked flawlessly for me; took about 25 minutes until it was done. I had to use the "cfdisk" commandline tool in oder to get the partitioning done the way I wanted it. The GUI installer calls a partitioner that reminds of qparted -- but that doesn't seem to support ReiserFS. The only other thing I changed from the default: I created a 1 GB swap partition, so that I counterbalance a bit on my rather poor RAM facilities. I am still heavily wondering why Ubuntu developers do give away many MByte (to include Firefox and OpenOffice packages for MS Windows(!)) of their precious Linux install CD space, but do not seem to have enough room left for inclusion of openssh-server (which only takes 205 kByte).... The lack of an option to startup sshd and securely login over the network to a freshly installed Dapper (or one running from Live CD) severly limits any possibility for professional helpdesk people (or personal friends) to support someone experiencing problems. One other sidenote -- I found one more glitch, that developers may want to fix in the next release: the installer should ask for an eventual proxy to be used. In my case, the installer's initial attempt to run an immediate security update failed, because it could not connect to the repository. I knew how I could work around that -- but will any newbie know? Now I have a KDE 3.5.2 running on the desktop; for printing there's a CUPS version which dpkg identifies as "1.2.0-0ubuntu5". Before I do any update or upgrade, I'll first inspect the default packages and printing setup, and run a few tests. My hope is that all problems suffered through so far are only due to the peculiarities involved with running a computer from a Live CD, and the complications stemming from overlaying the read-only CD ROM iso image with a writeably layer that is hosted in the system's RAM, using UnionFS. ... Surprise, surprise! Installing printers into a "real" Dapper (meaning it is installed on harddisk) is the same mis-success as was when it ran from the Live CD. Now let's update and upgrade what's updateable and upgradeable, and see if this changes anything for the better.... ... Nope. No cigar. So far no official package update fixes my problem. [ <----- Since most (K)Ubuntu users probably do not know what kind of features are available via the CUPS web interface (if it was not artificially crippled by the packagers), <----- here is a screenshot that shows just one example. It exposes the "Set Printer Options" page, that may be used by to set print option defaults for all users. I'll add some more feature screenshots in my next blog entry. ] As I already mentioned before, the CUPS web interface is heavily crippled in its functionality: the original CUPS printer web administration is disabled. Thankfully, on the new shiny Dapper, http://localhost:631/ has at least a hint telling users so.
Great! So, for the sake of a (doubtful) increase in security, users are taken away their ability to easily add and configure printers. Hmmm... let's read on; there are two more sentences. They read:
WTF? I have a Kubuntu, and it tells me to use GNOME CUPS manager?? Alrightiiee then, let's try it.... Gosh! Can't find it. There is no menu with an entry like that; and there is neither the commandline tool gnome-cups-manager on Kubuntu... (I did of course try to run kaddprinterwizard and other KDEPrint tools, hoping that, in lieu of the missing gnome-cups-manager, these would do the job; do I need to tell you that these didn't work either?)
OK, move on to see what that README.Debian.gz tells us. Supposedly, running the commands adduser cupsys shadow and adduser kurt lpadmin should do it. The second one should add user kurt to the lpadmin group 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. The reasons behind these steps are: since Dapper maintainers patched CUPS to run cupsd from the "cupsys" account, that user needs to be made part of the "shadow" group whose members are allowed to read the shadow password file. And user kurt needs to be in the "lpadmin" group so he can manage printers without needing full root privileges. So I did run these two commands; and as commands, they succeeded; but their intented purpose they did not achieve. While kurt is now part of the lpadmin group, and cupsys is part of shadow... you guessed it: the CUPS web interface still does not let me add a new printer, or delete an existing one, or setup the default printjob options. So Ubuntu packagers went to the length of patching that sentence into the CUPS local documentation. That's nice; they seem wanting to keep me informed about their changes. But apparently they did not check if their advice also works... Please fix that! And please, please, please: do not send your users to a gzip-compressed README, that is not directly accessible, and that confuses them with all kinds of unrelated content. *If* you insist upon crippling CUPS in the name of supposedly increased security, please add a proper documentation how to re-establish its full functions. By proper documentation I mean: add a HTML page that is part of the localhost:631 CUPS documentation. Put your explanation into that HTML document, add a hyperlink, make that document accessible directly from the same sentence where you try to justify your user-unfriendly actions. Thank you! I could even stop my series of rants now; but I decided to instead dissect Dapper's CUPS setup a bit. I'll use it as an example to highlight some of the new features offered by CUPS to end users (though they will not yet be missed by most (K)Ubuntu users -- because packagers are hiding them very well from them). I'll outline how I would like to have CUPS configured for maximum usability, without neglecting security. Maybe it helps one user or the other to fix things for himself? (Hrmmm... and maybe one or the other editor of $online_or_print_publication is interested in a solid review article that features the new stuff that is shipping with CUPS 1.2.0? Yes, I may be looking for a new job quite soon...) See you!
|
 |
Comments
SSH
Oh for goodness sake! Give up with the whinging about lack of SSH already!
People having SSH running without them knowing it is a bad idea. I'm sure we've even had a KDE developer report that they've had a machine hacked through SSH here.
Check out your SSH logs - if you haven't done some fancy firewalling, chances are they'll be full of brute force attacks. You really think most computer users pick secure enough passwords for this not to be a problem?
Yeah, right.
"People having SSH running
"People having SSH running without them knowing it is a bad idea."
Did I ask for that? Did I ask for "running it without people knowing it"? No. I asked for the package to be present, so it installs, and may be started up if need be.
Thanks for your understanding.
To be honest, I was quite
To be honest, I was quite thrown back as well when I saw the package not available. A shame.
Tell me
How long have you been in open source projects?
Its amazing, then, that you are able to demonstrate how badly you can work in a community of technicians.
Where are the bugreports you registered on the ubuntu site? I asked for them in an earlier blog.
Why on why blame ubuntu if you spent a LONG time researching this stuff only days after their release without any registered bugs before the release (no, telling people in person on IRC does not count as registering a bug!). Bugs can only be fixed if they are known.
Really, you can be more constructive, I know you can ! :)
But why is it so?
Why should it be impossible for a developer to file a bug themselves? Why should users be expected, even forced, to be dealing with the developer tools? (Do you know how many bugzillas I have membership at? About N-1 more than I ever wanted.)
Open source will never thrive if it won't stop backstabbing users. "Ha! YOU didn't conform to Random Policy #34-B, so these bugs are YOUR fault! K THX BYE." How long does it really take for a developer to add a TODO item to their list? If it's more than 30 seconds, why? How can it be made faster? If the process is failing the users (which apparently it is), how can it be improved?
When I worked in a gas station, I saw hundreds of customers and a handful of co-workers who haven't amounted to anything because they're not worried about how to do better. Throwing blame, hiding behind procedures, and otherwise ignoring the problem are likewise not focusing on fixing anything and attaining something better.
If you want bugs reported, why can't you go talk to users and report them yourself? Find someone to do it for you. Make it so your developers can quickly report bugs as, say, WHINE instead of NEW, so that someone can be assigned to check out the whining before putting out a broken release. Slip the release if you need to. Users don't take crap, even if it was on time.
Or, you know, just save the trouble and don't do dumb stuff in the first place. How much time, frustration, and blog posting+commenting would have been saved if the packagers had stuck to something that worked? Did the Web interface really need crippled? If you can't trust localhost to be configuring printers on a live CD, there are more fundamental problems than whether someone will add an unauthorized printer.
Why does the law of the "technical community" trump the user? Software exists for users. Open source would not be released as open source if the developers didn't want more than 1 user. If the technical community doesn't want to realize that people outside it view its internal procedures in much the same way that they view corporate policies, how will those procedures ever change? Meanwhile, this barrier to entry will remain in place, and the vast majority of people will be turned away from open source.
Will the future continue this tradition, or will we choose something better?
re: why?
If you want bugs reported, why can't you go talk to users and report them yourself? Find someone to do it for you. Make it so your developers can quickly report bugs as, say, WHINE instead of NEW, so that someone can be assigned to check out the whining before putting out a broken release.
This made me smile. The filing of a bugreport v.s. writing 4 blog/rants about it. Hmm, which do you honestly think takes longer? Can we expect developers to read through rants calling those developers incompetent fools?
The rest of your post kind of misses the point entirely, its not about finding bugs (though thats always important) its about a experienced user knowing which path to take; and ranting and giving many people a bad name in the process is not the right path.
In defence of this rant...
Enough! I have already filled out a bug report on this problem, and let me tell you, this rant has recieved more attention from the community than my bug report has.
So, yes, it is important to fill out bug reports, but these rants actually help me understand what-in-the-world is going on, and maybe now people will actually pay attention to the problem!
It much easier to rant than
It much easier to rant than to file constructive bug-reports, and it also gains higher visibilities, which means higher chance of getting a fast fix; but it should be limited to times when the developers have really fucked up and deserves to be told so.
In defence of Kurt, I think
In defence of Kurt, I think his real problem is not that Ubuntu's people have changed things but that they've taken an already complex system in CUPS, that should work anyway, and changed it to a point where it doesn't work.
Kurt's point is that there shouldn't be any more work for anyone in the form of bug reports simply because there shouldn't be any bugs here. It should be a straightforward working set up that's been around, and people have used, for years.
But why the rant?
As Jeff Waugh said recently [1]:
Kurt, "you don’t need to rant to contribute your thoughts to the FLOSS process. [...] why did you feel the need to dip them in venom? Remember that asking FLOSS developers to do something is kind of like asking if you can borrow their car — don’t tell someone their ride is a hunk of junk while asking for the keys! [...] I’m also surprised you chose to rant — there are so many other, probably more solution-oriented things you could have done…"
[1] http://perkypants.org/blog/2006/06/05/but-why-the-rant/
Pages