CUPS problem - "waiting for localhost"
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.
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.
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...
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...
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.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.
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.
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.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.
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.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.
*EDIT: or "job completed" but no printout; or filter errors for geany.
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.
I then used the new sfs in a fresh Lupu frugal install with no pupsave. The HP printer was recognized and worked properly.
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.
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.
Lots of things can cause this message. I would put CUPS in debug mode and see if you can track it down./usr/lib/cups/filter/foomatic-rip failed
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
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.
/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.