Code: Select all
/usr/lib/cups/cgi-bin/admin.cgi: Permission deniedCode: Select all
chown root:root xxx
chmod 755 xxxCode: Select all
# ls -l /initrd/pup_ro2/etc/cups/
total 19
-rw-r--r-- 1 root root 1077 2010-09-13 21:47 command.types
-rw-r----- 1 root root 1218 2010-01-14 00:50 cupsd.conf
-rw-r----- 1 root 7 2470 2010-09-13 12:41 cupsd.conf.default
drwxr-xr-x 2 root root 3 2010-09-20 17:21 interfaces
-rw-r--r-- 1 root root 4543 2010-09-13 12:41 mime.convs
-rw-r--r-- 1 root root 6298 2010-09-13 12:41 mime.types
drwxr-xr-x 2 root root 35 2007-09-23 00:28 ppd
-rw-r----- 1 root root 405 2009-11-19 10:03 printers.conf
-rw-r--r-- 1 root root 946 2009-11-19 10:03 pstoraster.convs
-rw-r----- 1 root nobody 186 2010-09-13 12:41 snmp.conf
drwxr-xr-x 2 root root 3 2010-09-20 17:21 ssl
# ls -l /etc/cups/
total 40
-rw-r----- 1 root nobody 1247 2011-01-11 22:12 cupsd.conf
-rw-r----- 1 root 7 2470 2010-09-13 12:41 cupsd.conf.default
drwxr-xr-x 2 root root 4096 2009-07-20 02:08 interfaces
-rw-r--r-- 1 root root 4543 2010-09-13 12:41 mime.convs
-rw-r--r-- 1 root root 6298 2010-09-13 12:41 mime.types
drwxr-xr-x 2 root nobody 4096 2009-07-20 02:08 ppd
-rw-r----- 1 root root 186 2010-09-13 12:41 snmp.conf
drwx------ 2 root nobody 4096 2009-07-20 02:08 ssl
Code: Select all
find / -type d ! -perm 755Code: Select all
/etc/cups/ssl
/etc/cups-old/ssl
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.
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.