Clueless: Administration of a central CUPS server by HTTPS and admin_uri/SERVER_NAME #678
Unanswered
noseshimself
asked this question in
Q&A
Replies: 1 comment 1 reply
-
The URIs reported back to the programs are going to have "localhost" because the programs are communicating locally with the scheduler (cupsd) - over the domain socket. The server name is what gets advertised for remote clients... The CGIs should be rewriting the URIs to provide relative URLs in the web interface (to use the same hostname, port, and scheme) but if that isn't working then you've found a bug. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I spent a day now trying several approaches but do not see where I'm wrong.
I'm running a central print server (to make it more difficult in a docker container) connected to a (Nebula) mesh overlay network. Printing is not a problem but doing the administration is...
I set ServerName in cupsd.conf to the FQDN of the server and the names and IP addresses are correctly set in the name server (printing would not work without it nor would I reach the web interface at all if that wasn't the case.
I even replaced the local resolver configuration of the base Debian container by my own to ensure that host names and addresses in /etc/hosts are the same.
But something is not really believing me:
So where is this localhost coming from?
Logging shows
that someone resolved the "printserv.mydomain.com" to (one of) its (correct) IP addresses bit the admin_uri and printer_uri_supported are not containing this address and the administration pages are using these addresses.
I must have been doing something fundamentally wrong but I'm completely out of clues here... And I can't be the only one ever messing this up.
Beta Was this translation helpful? Give feedback.
All reactions