Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sat 25 Oct 2014, 00:26
All times are UTC - 4
 Forum index » Advanced Topics » Hardware » Printers
CUPS problem - "waiting for localhost"
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
Page 3 of 4 Posts_count   Goto page: Previous 1, 2, 3, 4 Next
Author Message
rcrsn51


Joined: 05 Sep 2006
Posts: 9203
Location: Stratford, Ontario

PostPosted: Wed 12 Jan 2011, 04:49    Post_subject:  

@neurino:
I was messing around with the Debian installer for another printer driver and ended up in exactly your situation. I eventually discovered that the installer had changed permissions on a bunch of other folders and that was causing the
Code:
/usr/lib/cups/cgi-bin/admin.cgi: Permission denied

Check the following folders.

/usr
/usr/local
/usr/share
/usr/share/doc

Each one should have root:root ownership and 755 permissions.

For any one that's wrong, run
Code:
chown root:root xxx
chmod 755 xxx
Back to top
View user's profile Send_private_message 
neurino


Joined: 15 Oct 2009
Posts: 360

PostPosted: Wed 12 Jan 2011, 05:37    Post_subject:  

I installed Google Chrome from a deb package...

Like also mikeb suggested me I found this differences between original puppy sfs and current savefile:

Code:
# 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


but no matter I can restore ownership and permissions things does not change and after every reboot I get ownerships and permission restored like above!

I used

Code:
find / -type d ! -perm 755


to find out possible anomalies but just these 2 are cups-related:

Code:
/etc/cups/ssl
/etc/cups-old/ssl


others are about themes, python etc...[/b]
Back to top
View user's profile Send_private_message 
rcrsn51


Joined: 05 Sep 2006
Posts: 9203
Location: Stratford, Ontario

PostPosted: Wed 12 Jan 2011, 05:48    Post_subject:  

The root:nobody ownerships are fine. CUPS wants them that way. Did you also check the folders I listed above?
Back to top
View user's profile Send_private_message 
neurino


Joined: 15 Oct 2009
Posts: 360

PostPosted: Wed 12 Jan 2011, 06:03    Post_subject:  

rcrsn51 wrote:
The root:nobody ownerships are fine. CUPS wants them that way. Did you also check the folders I listed above?


Yes... all right... no changes Sad
Back to top
View user's profile Send_private_message 
rcrsn51


Joined: 05 Sep 2006
Posts: 9203
Location: Stratford, Ontario

PostPosted: Wed 12 Jan 2011, 10:52    Post_subject:  

Where did you get the Google Chrome package?
Back to top
View user's profile Send_private_message 
neurino


Joined: 15 Oct 2009
Posts: 360

PostPosted: Wed 12 Jan 2011, 11:00    Post_subject:  

Mmh.. I think to remember here

And if I recall right I installed the deb and once I saw it was working I removed it and installed a pet I made joining the deb contents and necessary libs (from GrumphyWolfe see post)

So now my pet is installed but at least once I run the deb package.

I didn't know deb packages could make changes to my folders... Sad Rolling Eyes
Back to top
View user's profile Send_private_message 
rcrsn51


Joined: 05 Sep 2006
Posts: 9203
Location: Stratford, Ontario

PostPosted: Wed 12 Jan 2011, 12:32    Post_subject:  

I can confirm that installing the Chrome deb will kill CUPS. It's not the content of the deb itself - it's how Puppy's dpkg-deb installer utility installs it.

However, it does not appear to be a permissions problem like I saw above with the printer driver. And I can't see anything that has changed so I can fix it. Simply deleting the contents of the Chrome install doesn't help and there are no processes running that affect CUPS.

BTW, the same thing happens with certain older Open Office packages. I'm curious as to whether this also happens with a full install of Puppy.
Back to top
View user's profile Send_private_message 
rcrsn51


Joined: 05 Sep 2006
Posts: 9203
Location: Stratford, Ontario

PostPosted: Wed 12 Jan 2011, 14:22    Post_subject:  

Update:

1. The Chrome deb also kills CUPS in a full install.

2. Installing CUPS 1.4.x in Wary also fails.

3. Installing the Chrome deb in Lupu also kills CUPS.

4. However, this failure does not happen with all debs.

5. The CUPS daemon appears to be running OK at the command line. The problem is specific to the web interface at localhost:631

6. There are other reports on the web of "permission denied" with "admin.cgi", but they were fixable by correcting ownership and/or permissions of various folders.

I have found no way of recovering from this problem other than a new pupsave. It's a mystery.
Back to top
View user's profile Send_private_message 
neurino


Joined: 15 Oct 2009
Posts: 360

PostPosted: Wed 12 Jan 2011, 16:35    Post_subject:  

I rather guess it's something in the deb package:

I'm writing now from a fresh pupsave file from a chrome tab and in the tab aside there's CUPS working, also added my printer with your Samsung pet (trimmed) and printed a sample page succesfully!

I looked into the pet I made with deb contents and, after creating a separate NLS pet, I removed only a cron script to check for apt updates (not very useful in Puppy).

So just installing this pet does not kill CUPS...

Now... if I could not throw my perfectly tuned savefile I'd be grateful... otherwise I'll start over with a new one... Rolling Eyes
Back to top
View user's profile Send_private_message 
rcrsn51


Joined: 05 Sep 2006
Posts: 9203
Location: Stratford, Ontario

PostPosted: Wed 12 Jan 2011, 16:39    Post_subject:  

Quote:
So just installing this pet does not kill CUPS...

Agreed. If you manually extract the deb to a temporary location and make PET out of it, everything works fine. But if you let dpkg-deb extract it directly into the main file system, something subtle changes.
Back to top
View user's profile Send_private_message 
rcrsn51


Joined: 05 Sep 2006
Posts: 9203
Location: Stratford, Ontario

PostPosted: Fri 14 Jan 2011, 20:00    Post_subject:  

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.
Back to top
View user's profile Send_private_message 
neurino


Joined: 15 Oct 2009
Posts: 360

PostPosted: Sat 15 Jan 2011, 08:26    Post_subject:  

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... Rolling Eyes
Back to top
View user's profile Send_private_message 
jpeps

Joined: 31 May 2008
Posts: 3220

PostPosted: Sat 15 Jan 2011, 14:18    Post_subject:  

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.
Back to top
View user's profile Send_private_message 
rcrsn51


Joined: 05 Sep 2006
Posts: 9203
Location: Stratford, Ontario

PostPosted: Sat 15 Jan 2011, 14:35    Post_subject:  

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.
Back to top
View user's profile Send_private_message 
jpeps

Joined: 31 May 2008
Posts: 3220

PostPosted: Sat 15 Jan 2011, 16:15    Post_subject:  

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.
Back to top
View user's profile Send_private_message 
Display_posts:   Sort by:   
Page 3 of 4 Posts_count   Goto page: Previous 1, 2, 3, 4 Next
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
 Forum index » Advanced Topics » Hardware » Printers
Jump to:  

Rules_post_cannot
Rules_reply_cannot
Rules_edit_cannot
Rules_delete_cannot
Rules_vote_cannot
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0836s ][ Queries: 11 (0.0034s) ][ GZIP on ]