[SOLVED] cups client does not see cups server

[rainer]

I'm a bit embarrassed to post this here: The machine that has the problem has Sabayon running...
I have tried the Sabayon forum (one friendly reply but missing the point), the cups forum (no reply) and my local LUG (no reply). So I dare to post it here because the cups server is a Gentoo machine and I don't think that it's a pure Sabayon problem. But I'm ready to take some flames...

In my family / home office network, I have a small server that I use for some services, among others to provide networked printing. It's a first generation fitpc, running Gentoo. It controls three remote printers, running cups 1.4.1.

We have about eight computers in the house, running Gentoo, Sabayon and Puppy Linux. The machines are all set to see the broadcasting fitpc and use it for printing. The cups versions installed are 1.3.11, 1.4.1. and 1.4.3. Everything works perfectly, and also visitors with Linux or Apple can use our printers instantly.

There is one machine in the network ("augeatur") however, that has lost at some point (incidentally after a Sabayon upgrade) its capability to see the cups server. It is running cups 1.4.3 on a 64bit system, like at one other machine in the network. /etc/cups/cupsd.conf are identical in both machines. augeatur can access through the browser the printers on fitpc (http://fitpc:631) - but the local cups client cannot.

Apart from asking the other forums, I have googled like hell but did not find a hint. Somebody here who can give me a hint where to look?

Thanks,
Rainer

[erik258]

But I'm ready to take some flames...

I've yet to see a linux forum that's friendlier - or more knowledgeable - than this one.

and also visitors with Linux or Apple can use our printers instantly.

And windows too, most likely, although auto-discovery may not work and XP might not be particularly cooperative. IPP is the norm now, it turns out!

Is the machine running 1.4.3 that does work, also running sabayon, and in all other respects the same? If not, I'm going to take the easy approach and say Sabayon's at fault... worthless binary distro... [ kidding, sabayon lovers, kidding ] ; )

Do you know what else on the system got upgraded at the same time? If sabayon has an equivilent of USE flags, have they changed at all?

[darkphader]

Check cupsd.conf , is Browsing On?

[dmpogo]

You can try to change

LogLevel info to

LogLevel debug

in cupsd.conf

on the server and troubled client and see in detail in the log what messages are they passing to each other.

[rainer]

I've yet to see a linux forum that's friendlier - or more knowledgeable - than this one.

Couldn't agree more - but I have seen quite a few heated threads when it comes to Sabayon...

And windows too, most likely, although auto-discovery may not work and XP might not be particularly cooperative.

My wife has Vista laptop - I gave up and installed a local printer for that machine!

Is the machine running 1.4.3 that does work, also running sabayon...?

Yes it is, and both should be exactly on the same level, very latest equo upgrades, no fiddling around with USE flags from my part. Since Sabayon is binary, they may changed the USE flags for the next generation compilation - but I wouldn't know, and I would expect that it affects both machines equally.

and in all other respects the same?

They are not exactly the same (laptop vs. desktop) but architecture is the same.

Do you know what else on the system got upgraded at the same time?

That was a large number of packages, almost all of KDE got upgraded. I saw poppler popping up in the list. But there was a difference of a few days between the two machines, so the list of updated packages is obviously different. Unfortunately there is no history function in the package manager (at least I wouldn't know).

Not very helpful, I know. I'd happily post log or configuration files but which ones? Just for the sake of completeness, here

/etc/cups/cupsd.conf

Code: Select all

# Log general information in error_log - change "warn" to "debug"
# for troubleshooting...
LogLevel warn

# Administrator user group...
SystemGroup lpadmin


# Only listen for connections from the local machine.
Listen localhost:631
Listen /var/run/cups/cups.sock

# Show shared printers on the local network.
Browsing On
BrowseOrder allow,deny
BrowseAllow all
BrowseLocalProtocols CUPS

# Default authentication type, when authentication is required...
DefaultAuthType Basic

# Restrict access to the server...
<Location />
  Order allow,deny
</Location>

# Restrict access to the admin pages...
<Location /admin>
  Order allow,deny
</Location>

# Restrict access to configuration files...
<Location /admin/conf>
  AuthType Default
  Require user @SYSTEM
  Order allow,deny
</Location>

## leaving out the printer configuration details

and here /etc/cups/client.conf

Code: Select all

ServerName /var/run/cups/cups.sock

which is (as far as I know) the crucial one to see all printers connected to other cups servers on the network.

Can I find out more?

Tks,
Rainer

[rainer]

@ dmpogo

After setting the log level to debug, I get an endless repetition of

Code: Select all

D [19/May/2010:15:47:56 +0200] CUPS-Get-Printers
D [19/May/2010:15:47:56 +0200] CUPS-Get-Printers client-error-not-found: No destinations added.
D [19/May/2010:15:47:56 +0200] Returning IPP client-error-not-found for CUPS-Get-Printers (no URI) from localhost
D [19/May/2010:15:47:56 +0200] cupsdSetBusyState: Not busy
D [19/May/2010:15:47:56 +0200] cupsdReadClient: 14 WAITING Closing on EOF
D [19/May/2010:15:47:56 +0200] cupsdCloseClient: 14

on the troubled machine. Nothing interesting at all on the server (except, maybe, the clients=0 line...):

Code: Select all

D [19/May/2010:15:26:38 +0200] cupsdNetIFUpdate: "lo" = localhost:631
D [19/May/2010:15:26:38 +0200] cupsdNetIFUpdate: "eth0" = fitpc:631
D [19/May/2010:15:26:38 +0200] cupsdNetIFUpdate: "lo" = localhost:631
D [19/May/2010:15:26:38 +0200] cupsdNetIFUpdate: "eth0" = fe80::201:c0ff:fe03:6a20%eth0:631
D [19/May/2010:15:26:38 +0200] Report: clients=0
D [19/May/2010:15:26:38 +0200] Report: jobs=425
D [19/May/2010:15:26:38 +0200] Report: jobs-active=0
D [19/May/2010:15:26:38 +0200] Report: printers=3
D [19/May/2010:15:26:38 +0200] Report: printers-implicit=0
D [19/May/2010:15:26:38 +0200] Report: stringpool-string-count=5378
D [19/May/2010:15:26:38 +0200] Report: stringpool-alloc-bytes=17584
D [19/May/2010:15:26:38 +0200] Report: stringpool-total-bytes=61960

And just to reconfirm: At the same time that cups doesn't find its counterpart on fitpc, Firefox happily displays the three printers when I enter http://fitpc:631...

I'm lost!

[dmpogo]

OK, could you post cupsd.conf on the troubled client ?

[rainer]

Here we go:

Code: Select all

#
# "$Id: cupsd.conf.in 8805 2009-08-31 16:34:06Z mike $"
#
# Sample configuration file for the CUPS scheduler.  See "man cupsd.conf" for a
# complete description of this file.
#

# Log general information in error_log - change "warn" to "debug"
# for troubleshooting...
LogLevel debug

# Administrator user group...
SystemGroup lpadmin


# Only listen for connections from the local machine.
Listen localhost:631
Listen /var/run/cups/cups.sock

# Show shared printers on the local network.
Browsing On
BrowseOrder allow,deny
BrowseAllow all
BrowseLocalProtocols CUPS

# Default authentication type, when authentication is required...
DefaultAuthType Basic

# Restrict access to the server...
<Location />
  Order allow,deny
</Location>

# Restrict access to the admin pages...
<Location /admin>
  Order allow,deny
</Location>

# Restrict access to configuration files...
<Location /admin/conf>
  AuthType Default
  Require user @SYSTEM
  Order allow,deny
</Location>

# Set the default printer/job policies...
<Policy default>
  # Job-related operations must be done by the owner or an administrator...
  <Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job CUPS-Move-Job CUPS-Get-Documen$
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>

  # All administration operations require an administrator to authenticate...
  <Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default CUPS-Get-Devices>
    AuthType Default
    Require user @SYSTEM
    Order deny,allow
  </Limit>

  # Only the owner or an administrator can cancel or authenticate a job...
  <Limit Cancel-Job CUPS-Authenticate-Job>
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>

  <Limit All>
    Order deny,allow
  </Limit>
</Policy>

# Set the authenticated printer/job policies...
<Policy authenticated>
  # Job-related operations must be done by the owner or an administrator...
  <Limit Create-Job Print-Job Print-URI>
    AuthType Default
    Order deny,allow
  </Limit>

  <Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job CUPS-Move-Job CUPS-Get-Documen$
    AuthType Default
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>

  # All administration operations require an administrator to authenticate...
  <Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default>
    AuthType Default
    Require user @SYSTEM
    Order deny,allow
  </Limit>

  # All printer operations require a printer operator to authenticate...
  <Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer Startup-Printer Promote-Job Schedule-Job-After CUPS-Accept-Jobs $
    AuthType Default
    Require user @SYSTEM
    Order deny,allow
  </Limit>

  # Only the owner or an administrator can cancel or authenticate a job...
  <Limit Cancel-Job CUPS-Authenticate-Job>
    AuthType Default
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>

  <Limit All>
    Order deny,allow
  </Limit>
</Policy>

#
# End of "$Id: cupsd.conf.in 8805 2009-08-31 16:34:06Z mike $".
#

[darkphader]

Maybe it's an encryption issue. Try putting:

Code: Select all

DefaultEncryption Never

in both cupsd.conf files and restarting cups on both.

[dmpogo]

Hm, you may try to ask the troubled client to poll the server with

BrowsePoll server.ip.address

and see what will happen (and what debug it generates). May be it will give some hints.

[rainer]

dmpogo and darkphader - thanks a lot!

I tried both systematically and found that

Code: Select all

BrowsePoll 192.168.1.2

does the trick, so from a practical point of view, my problem is solved, I can print. I marked the thread as solved, although two questions remain:

• The print server's address is now "hard wired" - this is not how cups should work, as I understand. I'll experiment with some more generic solutions when I have time (BrowsePoll On - does it exist?)
  and: Why this machine only, all others don't need an explicit poll instruction. Any other screw I could turn?

I appreciate these are academic questions but maybe you have some hints for me where to look next.

Anyway, it works and thanks for that!
Rainer

[dmpogo]

I marked the thread as solved, although two questions remain:

• The print server's address is now "hard wired" - this is not how cups should work, as I understand. I'll experiment with some more generic solutions when I have time (BrowsePoll On - does it exist?)
  and: Why this machine only, all others don't need an explicit poll instruction. Any other screw I could turn?

Using BrowsePoll has its legitimate use in CUPS environment (basically, for accessing servers that do not broadcast to your subnet),
although in your case it is indeed not as it was supposed to work.
So, yes, the original question is not answered, although it confirms that the issue was that the client did not see broadcasts from server.

That makes me think that perhaps something is on a network level. Firewall ? One way to look at it, is to launch wireshark on the client and capture
traffic on your network interface. CUPS broadcasts and replies are very visible, so you will see whether you are getting broadcasts from the CUPS server.

[dmpogo]

• The print server's address is now "hard wired" - this is not how cups should work, as I understand. I'll experiment with some more generic solutions when I have time (BrowsePoll On - does it exist?)

"BrowsePoll ip" does not exactly hardwire the print server for the client. What it does, is that the client in addition to listening for broadcasts from all the servers , itself takes initiative to ask a specified server(s) for the list of printers. And you can then print over concatinated lists obtained from all the sources. So if you put this same client in another network, it will happily receive broadcasted printer lists there. In this sense generic BrowsePoll On makes no sense.

[rainer]

One way to look at it, is to launch wireshark on the client and capture
trafic on your network interface. CUPS broadcasts and replies are very visible, so you will see whether you are getting broadcasts from the CUPS server.

Bingo: No broadcasts visible on the troubled machine, the "twin" with no issues sees them all the time. But why? What could keep one machine on the network from seeingthe CUPS broadcasts that are actually there?

[dmpogo]

One way to look at it, is to launch wireshark on the client and capture
trafic on your network interface. CUPS broadcasts and replies are very visible, so you will see whether you are getting broadcasts from the CUPS server.

Bingo: No broadcasts visible on the troubled machine, the "twin" with no issues sees them all the time. But why? What could keep one machine on the network from seeingthe CUPS broadcasts that are actually there?

After checking the obvious - that troubled machine really has the IP on the same network that the rest (and did not get something strange via some zeroconf/bonjour or whatever), the only thing that comes to mind is that there is some default firewall set up by Sabayon (that may explain that the issue appeared after the update)

[erik258]

Or perhaps your broadcast address is set incorrectly? Or perhaps subnet mask (from which, combined with the ip address, the broadcast address is usually automatically derived)?

[rainer]

Well, IP address is correct (192.168.1.100, checked), and CUPS broadcasting reaches all other clients in the network, so I don't think there is a problem on the server side. I'll check the firewall issue for the troubled machine - may take some time since I have to get into the subject first. Will post results if any!
Thanks again,
Rainer