started by: Juanito
Posted by Juanito on Feb. 10 2008,10:11I just started to compile cups-1.3.5 (and so far it went suspiciously easily) and have a couple of questions:
1. Since cups creates several folders in /var and seems to need these to be present and have the correct permissions in order to work - would it be OK to include these folders in user.tar.gz (rather than have them in the backup)?
2. Is all of epsgs required for cups to work? I can't believe 5MB (compressed) of epsgs stuff is required just for a ps to rastor driver for non-ps printers - or am I missing something?
BTW, the idea is to split cups and hplip and maybe not use hplip at all since the fax part of the two hp all-in-one printers I have (G85, K80) is confirmed as never going to be supported by hplip.
Posted by curaga on Feb. 10 2008,10:461. wouldn't be a proper uci anymore - wasn't the deal write only to /home, /tmp, /opt, and /etc?
It's fine with me though, as I doubt anyone would use cups in a low-ram environment.
Posted by Juanito on Feb. 15 2008,13:14As mentioned - this was "suspiciously easily" and now cups is reverting to type...
I've compiled cups-1.3.5, espgs-7.05 (so I can use some of the files in the base dsl), hpijs-2.1.4 and foomatic-filters-3.0 (and libusb-0.1.12 just in case)
The only printers I have to test cups connect via usb - when I connect one of them, I get something like this:
If I search /dev for usblp or usblp0, I cannot find anything - which might explain why I cannot print to usblp0 - does anybody know why nothing is created in /dev for the printer? (note that the printer module loads automatically and is used by the usbcore module)
I can execute the cups usb backend:
and enter a printer uri=usb://HP/OfficeJet%20K80?serial=ES0911401VOH in cups, but this does not print either - this might be because hpijs cannot handle uri of this format. Note that the cups error_log does not show any errors in debug mode...
I don't want to compile hplip in order to be able to print because I need to verify that cups can print without it.
Posted by ^thehatsrule^ on Feb. 15 2008,18:19afaik, usually things in /dev have to be created manually, if not already included with the distro. Could try using mknod.
i.e. see printer setup in < http://www.trustix.org/content/view/19/47/ >
Posted by Juanito on Feb. 16 2008,09:00Thanks - coincidently, I'd just tried compiling hpijs from hplip and it looks like it created /dev/usblp0.
However, even if I use "sudo mkmod usblp0 c 180 0" the result is the same - I cannot print to it and get "Printer not connected; will retry in 30s..."
Even "echo "test" > /dev/usblp0" does not bring any result.
Bit of a mystery this...
Posted by Juanito on Feb. 18 2008,10:22So... I compiled hplip-2.8.2 separately from cups-1.3.5 - the only thing hplip does as far as cups is concerned is add two backends, hp & hpfax.
Once these have been added however, the cups browser interface automatically detects the printer (uri=hp:/usb/OfficeJet_K80?serial=ES0911401VOH) and the cups test page prints without problems - using the copies of gs, foomatic-rip and hpijs I compiled with cups...
I'm kind of at a loss to understand why the usb backend will not print to a usb printer when the hp backend will print to a usb printer - hplip requires usb headers/libs to compile whereas cups doesn't, but then the cups usb backend manages to query the printer correctly anyway...
Posted by Juanito on Feb. 23 2008,11:33OK, so leaving aside the issue of why I cannot print via the usb backend to a usb port, I'd like to make the cups extension a little more user friendly than the one inside the hplip extension...
The idea would be that a script(s) in the extension would:
1. Create the various directories required in /var (unless they already exist)
2. Copy the various .conf files required to /etc (unless they already exist)
3. Prompt the user to enter a root password (unless it is already set)
4. Start the cups scheduler (unless it is already running)
5. Start firefox & load the cups browser interface < http://localhost:631 > (unless it is already open)
Writing the script(s) is one issue, but probably the bigger issue is if it is OK, dsl-wise, to have a uci extension creating a bunch of folders/files that will not be removed when it is unloaded. I've tried to think of another way to do this - does anybody have a better idea?
Is there a script that would automatically run when a uci is loaded, or would I have to run the above script(s) from an icon/menu item?
Posted by ^thehatsrule^ on Feb. 23 2008,18:54There is (currently) no "autorun" feature. It would be best to have the scripts to be manually invoked, and perhaps have the option of executing a script that will uninstall those files and then unload the extension.
Posted by Juanito on Mar. 30 2008,10:13OK, so I finally got cups-1.3.5 to print after I realised my OfficeJetG85/OfficeJetK80 would need hpoj as well as hpijs. Now I can print from a 2.4MB extension (cups+hpijs+hpoj+foomatic) as opposed to a 20MB extension (cups+hplip+libusb+foomatic+epsgs, plus python, plus...).
In case anybody is interested, the trick is:
...and now on restarting cups admin, the printer is found automatically
Device URI: ptal:/mlc:usb:OfficeJet_G85.
I've started to set up an extension named cups-1.3.5.uci with a menu item/icon that calls a script that creates the folders cups requires (or else it will not work) in /var.
The next thing I would like the script to do is:
IF /etc/cups does not exist
THEN create /etc/cups and copy cupsd.conf to it
ELSE IF /etc/cups/cupsd.conf does not exist
THEN copy cupsd.conf to /etc/cups
IF cupsd is not running
THEN start cupsd [maybe it should be restarted anyway?]
I be grateful if somebody could spare me several hours of messing around with bash, trying to figure out how to do this
Posted by curaga on Mar. 30 2008,11:15the "exists" test is -e.. So
IF /etc/cups does not exist
if [ ! -e /etc/cups ]; then
And cupsd not running:
if ! ps | grep cupsd; then
Posted by Juanito on April 02 2008,05:24Thanks - so far I've managed to script creating folders in /var, copying default conf files to /etc if they are not in the backup and starting the cups scheduler.
The final hurdle is starting the cups browser interface in firefox:
starts the browser interface, but it looks "weird" and various buttons are missing. This does not happen if I load the same draft extension and enter the various commands manually.
Any ideas? Edit: fixed, I'd deleted some files I shouldn't have deleted in ../share/docs/cups
Posted by Juanito on April 02 2008,12:58One of the last remaining issues before I can submit the extension is that /usr/bin/lp, lpr, lpstat & /usr/sbin/lpc need to be replaced with symlinks to /opt/cups-1.3.5/bin/ for printing to work from some applications (or perhaps just removed, if I make symlinks from /opt/cups-1.3.5/bin/ --> /opt/bin).
For ease of use, it might make sense if the menu item/icon script does the above, but then the original files will be missing when the extension is unloaded. I guess I could also make an uninstall menu item/icon script to put them back, but then things start to get longwinded.
Almost forgot - is there are way to test if the root password is set and prompt to set it if not? Did I see somewhere that the latest versions of dsl have a password script?
Posted by Jason W on April 02 2008,15:05I am not on my DSL box, but here is what may work for setting a password:
if ! sudo passwd -S root | grep P; then
It may have to be tweaked for DSL with Busybox and such, but it is an idea. It works from a terminal in another distro.
Posted by lucky13 on April 02 2008,15:06
One thing you could try is to grep for "secure" in /proc/cmdline (maybe showbootcodes | grep secure?). That would cover what's set at boot, but not after.
EDIT: Jason beat me -- I was going to add that a grep to passwd should be adequate for this.
Posted by Juanito on April 02 2008,17:51Thanks - I'm away from a dsl machine at the moment so I cannot check this out at the moment. If the root password had not been set, then the script would have to open a terminal window for the user to be able to enter a password, no?
Posted by curaga on April 02 2008,19:21There's one thing though - if I remember right, DSL has a root password set, it's just not disclosed what it is..
Posted by lucky13 on April 02 2008,19:26
Or at least throw up some kind of error message that there's not a root password set. If curaga is right (I didn't know there's already a root password but hopefully it's randomized one-time-use like Finnix does so someone who figures it out can't pwn every "dsl@box" he sees) you probably want to have the user set one himself regardless. Even if a user uses "secure" cheatcode or has otherwise set one, all he has to do is remember what he used and re-enter it or enter a new one.
Posted by Jason W on April 03 2008,00:15Yes, DSL does apparently have a root passwd set as well as for user dsl. And passwd -S does not work with busybox. Another simple trick may be to include :
if sudo cat /etc/shadow | grep root:$1$$; then
xterm -title "Set Root Passwork" -e sudo passwd
This throws up an xterm window prompting for a root password if it has not already been set by the user, and exits when it has been entered. It looks to me like any time a root password is set, it only has one $ after the 1.
Posted by Juanito on April 03 2008,07:36You're right in that "root:$1$$" changes to "root:$1$" in /etc/shadow after the root password is set, but - for me at least - grep does not seem to pick this up:
- seems grep doesn't like the "$"?
Posted by lucky13 on April 03 2008,11:31That's because $ has to be escaped in shell scripting because it's designated for variables. It can't have a trailing character or that part will be read as a variable. Try putting each $ you want read as $ in , like [$].
Posted by Jason W on April 03 2008,12:28lucky13 is correct about the $ and how to grep them. I had first grepped the entire line but then cut it short before posting. I tried this and it works here now:
if sudo grep root:[$]1[$][$] /etc/shadow; then
xterm -title "Set Root Passwork" -e sudo passwd
Posted by curaga on April 03 2008,13:40Jason: typo in Password (Passwork)
Posted by Juanito on April 03 2008,15:54Great - almost there with the extension, just got to confirm which files need to be in the backup so that the printer(s) are still there after reboot.
Posted by Juanito on April 04 2008,13:42I'm unable to get my printer to persist across boots because the backup will not save the following file:
- which is a socket.
Any idea why this might be?
Posted by ^thehatsrule^ on April 04 2008,14:16Some links from a web search: < http://mandrivausers.org/index.p....y199056 > < http://www.linuxsa.org.au/pipermail/linuxsa/2003-March/052388.html >
Summary (assuming they are correct):
- tar does not support socket files
- most likely they are regenerated, since they are 'live' files
Did you try your extension as-is without that file?
Posted by Juanito on April 04 2008,15:08
- yes, everything else is there and looks normal, there are no error messages, but nothing prints.
As soon as I regenerate the file with:
- the queued file prints. All the other files generated by the command above are there already except for the socket and the printer setup persists across boots.
Anyway, the main purpose of this was to test cups without hplip - I'll be using hplip to print which uses a different backend anyway...
Posted by ^thehatsrule^ on April 04 2008,18:07Well, if you want more ideas:
- maybe back up the /var/run/ptal-mlcd/ dir
- print as root
- try a .unc?
Posted by Juanito on April 05 2008,04:48
- I'd already tried that, I guess as it cannot backup the file, the directory is then empty and the directory does not get saved either.
Thanks for the suggestions, I think I'll leave it here for now.
Posted by ^thehatsrule^ on April 05 2008,05:04I meant to manually specify to place that dir in the .dsl
Posted by Juanito on April 05 2008,08:14cups-1.3.5.uci submitted - thanks to all for the help