CUPS problem - "waiting for localhost"

Problems and successes with specific brands/models of printers
Message
Author
User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#41 Post by rcrsn51 »

Here is another chapter in this saga. During Lupu development, someone complained that their CUPS had died like yours. We eventually tracked it down to an old Open Office sfs, even though there were no apparent ownership or permission problems coming from it.

So I unpacked the sfs and discovered that the /usr folder inside had 700 permissions, which made it unreadable by an unprivileged user. This has the effect of blocking the temporary unprivileged CUPS user from running the CUPS web interface.

I changed the privileges to 755 and repacked the sfs. That version worked properly with CUPS.

I still don't know how CUPS is seeing these incorrect privileges. However, it appears that installing an unknown DEB into a working Puppy environment is a dangerous thing. This may explain why other community members complain about CUPS mysteriously quitting on them.

User avatar
neurino
Posts: 362
Joined: Thu 15 Oct 2009, 13:08

#42 Post by neurino »

I checked all my (3: devx, gimp, my python sfs) mounted sfs's permissions in /initd and found nothing wrong...

There's still something we don't know deb packages do when installed beside changing folder permissions...

What about a deb2pet tool?

I'm just waiting for a fast way to install a bunch of pets (about 20) "all in one" before I switch to a new savefile and get rid of this behavior... :roll:

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#43 Post by jpeps »

rcrsn51 wrote:

I changed the privileges to 755 and repacked the sfs. That version worked properly with CUPS.

I still don't know how CUPS is seeing these incorrect privileges. However, it appears that installing an unknown DEB into a working Puppy environment is a dangerous thing. This may explain why other community members complain about CUPS mysteriously quitting on them.
Interesting about the privileges. IMHO, CUPS is the weakest link in linux; almost anything breaks it. Anything that touches or affects a /var can break it, for example. Most recently, I found simple remasters (eliminating nothing below /usr) broke CUPS, while everything else worked. Reinstalling the printer didn't help. I'm thinking a new pupsave is the key, as CUPS needs a very specific setup that can't be altered.

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#44 Post by rcrsn51 »

The thing to understand about CUPS is that it is designed to work in a multi-user environment where security is important. It really doesn't like to work in an all-root situation like Puppy, so it employs temporary users such as root:nobody. You can see this in play if you look at the ownership of the folder /var/run/cups.

If you do a remaster where these root:nobody folders become owned by root:root, then CUPS will fail. You need to delete them all and let the CUPS daemon rebuild them.

By comparison, the old CUPS 1.1.x didn't care as much about security issues, so it would happily run in an all-root Puppy. It was only when Puppy upgraded to CUPS 1.3 and 1.4 that these problems started occurring.

There isn't anything fundamentally "weak" or "broken" about CUPS. But if you want to use it in Puppy, you have to recognize the way it works.

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#45 Post by jpeps »

rcrsn51 wrote:The thing to understand about CUPS is that it is designed to work in a multi-user environment where security is important. It really doesn't like to work in an all-root situation like Puppy, so it employs temporary users such as root:nobody. You can see this in play if you look at the ownership of the folder /var/run/cups.

If you do a remaster where these root:nobody folders become owned by root:root, then CUPS will fail. You need to delete them all and let the CUPS daemon rebuild them.

By comparison, the old CUPS 1.1.x didn't care as much about security issues, so it would happily run in an all-root Puppy. It was only when Puppy upgraded to CUPS 1.3 and 1.4 that these problems started occurring.

There isn't anything fundamentally "weak" or "broken" about CUPS. But if you want to use it in Puppy, you have to recognize the way it works.
Thanks for pointing this out. I just noticed that cups changes /var/run/cups/cert from root:root to nobody:lpadmin.

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#46 Post by jpeps »

rcrsn51 wrote:
There isn't anything fundamentally "weak" or "broken" about CUPS. But if you want to use it in Puppy, you have to recognize the way it works.
I think there's a few more issues going on then permissions in getting cups to work. I never did find a way to get a remaster working with cups, although everything else works. All files look fine, everything is there. No errors, cups doesn't recognize the print job. Tried with and without a pupsave, installing the printer from scratch (which seems to install okay). Print a test file, nothing, no jobs listed*. USB printer is correctly listed as "online", and works okay with original distro.

*EDIT: or "job completed" but no printout; or filter errors for geany.

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#47 Post by rcrsn51 »

I thought that I would play around with this issue some more. I took the lupu_520.sfs and manually unsquashed it. I then installed the HP printer driver package into the unsquashed file system, along with the files to represent an installed printer. I then resquashed it, leaving all the /var folders empty, like they are in the original sfs.

I then used the new sfs in a fresh Lupu frugal install with no pupsave. The HP printer was recognized and worked properly.

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#48 Post by jpeps »

Yeah..no problem at all for my networked HP940c either; in fact I can print with my old pupsave. My USB connected HP laserjet Pll02w is a different matter: Here's the listing in cups:

P1102w Foomatic/foo2zjs-z2 (recommended) Idle - "Printer is now online."

Print a test page, and no jobs show even show up. I remastered by simply removing homebank from lupu_520.sfs and resquashing; didn't touch any /var or /etc files.

EDIT: using "lp -d HP_LaserJet_Professional_P1102w" I can get an error:
"/usr/lib/cups/filter/foomatic-rip failed"

Must be driver specific. Strange it works fine on the original distro..Have no idea why the remaster breaks it, though.

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#49 Post by rcrsn51 »

P1102w Foomatic/foo2zjs-z2 (recommended)
Is this one of the printers that requires the hot-plug firmware download? I wonder if it's not working.

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#50 Post by jpeps »

rcrsn51 wrote:
P1102w Foomatic/foo2zjs-z2 (recommended)
Is this one of the printers that requires the hot-plug firmware download? I wonder if it's not working.
Yes, foo2zjs includes it.

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#51 Post by rcrsn51 »

/usr/lib/cups/filter/foomatic-rip failed
Lots of things can cause this message. I would put CUPS in debug mode and see if you can track it down.

1. Open /etc/cups/cupsd.conf
2. Change "loglevel info" to "loglevel debug"
3. Restart CUPS
4. Print a test page
5. Go to /var/log/cups
6. Open the error log file
7. Start at the bottom and work up

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#52 Post by jpeps »

I'm getting different logs for different attempts; was getting a "Dirty files" error, but then got:

/usr/bin/foo2zjs-wrapper: line 182: /dev/null: Permission denied
/usr/bin/foo2zjs-pstops: line 111: 3848 Broken pipe
(/usr/lib/cups/filter/foomatic-rip) exited with no errors.

line 111 is just any argument, so nothing is getting passed. I don't think the /dev/null issue should stop anything, but may be wrong.

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#53 Post by rcrsn51 »

Have a look at the permissions on /dev/null. I''m seeing 666.

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#54 Post by jpeps »

That was it....works. The remaster must have changed it to 644. Nice thinking! Sure glad we have a cups master on board. :D

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#55 Post by rcrsn51 »

Glad to help.

Like I said, there's nothing fundamentally wrong with CUPS. But you need to recognize how it behaves in an all-root environment.

Post Reply