Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using host name in /etc/cups/cupsd.conf Listen directive could make cupsd listen on the wrong IP #4618

Closed
michaelrsweet opened this Issue Apr 10, 2015 · 6 comments

Comments

Projects
None yet
1 participant
@michaelrsweet
Copy link
Collaborator

commented Apr 10, 2015

Version: -feature
CUPS.org User: thebodzio

This is most likely caused by the way systemd org.cups.cupsd.service is defined.

System: Arch Linux

Relevant packages' versions: systemd 218-2, cups 2.0.2-3

Description:

When cupsd is instructed in /etc/cups/cupsd.conf to listen only on some selected interfaces (IPs), instead of listening on all available (�Port� directive), it may happen, that the daemon ends up listening on the wrong IP, if �Listen� directive was supplied with host name instead of an explicit IP address and cupsd wasn't able to query DNS to supply proper IP for the host name. It's most likely to happen, when the host running cupsd relies on DHCP to configure its interfaces and cupsd is started before relevant interfaces are brought up.

For example:

I'm booting my system. In /etc/cups/cupsd.conf (attached to this report) I've got 3 �Listen� directives: one set to localhost, one to socket and one to my host name (�gizmo:631�). When the host is up and running, I can see (ss -tuln | grep -i 631) that cupsd listens on localhost (127.0.0.1) and on 127.0.0.2, instead of the IP assigned to my host via DHCP. Restarting cupsd service (I'm using systemd), of course, solves the problem, but it's at least inconvenient to do so after each reboot.

Obviously setting IP to some explicit value would be, most of the time, a feasible option, but that kind of hard-coding things may be dangerous too.

Maybe dependency on network would be in order in cupsd service?

Steps to reproduce:

  • Make sure cupsd listens only on interfaces defined by â��Listenâ�� directives in /etc/cups/cupsd.conf and at least one of these interfaces is defined as a host name.
  • Make sure that previously given host name's IP can be retrieved by DNS query.
  • Make sure org.cups.cupsd.service is enabled and relevant interface is configured by DHCP.
  • Boot the system.
  • Check the IPs of the interfaces the cups daemon listens on.
@michaelrsweet

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 10, 2015

CUPS.org User: thebodzio

For some reason my cupsd.conf wasn't attached to the original post.

@michaelrsweet

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 10, 2015

CUPS.org User: thebodzio

Second attempt to attach cupsd.conf�

@michaelrsweet

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 13, 2015

CUPS.org User: mike

OK, "Listen hostname" is entirely dependent on DNS to return the right values. Since there are a lot of variables (besides the order which cupsd is started) for when network facilities are available, you really need to have the hostname and any addresses listed in /etc/hosts to make that work reliably.

Moreover, if you have a dynamic address you should not be using "Listen hostname" at all. Instead, stick to "Listen *:631" or just "Port 631" - the default ACL will limit access to the local subnet(s), and you can tweak those to prevent access from outside addresses.

@michaelrsweet

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 15, 2015

CUPS.org User: thebodzio

OK, "Listen hostname" is entirely dependent on DNS to return the right values.

Yup�hence my suggestion to depend on �network�, which may not solve all the problems but some�for sure. Can it cause any new problems?

Since there are a lot of variables (besides the order which cupsd is started)
for when network facilities are available, you really need to have the
hostname and any addresses listed in /etc/hosts to make that work reliably.

Yes, but that's even more evil than just using an explicit IP address right from the start�

Moreover, if you have a dynamic address you should not be using "Listen
hostname" at all. Instead, stick to "Listen *:631" or just "Port 631" - the
default ACL will limit access to the local subnet(s), and you can tweak those
to prevent access from outside addresses.

You're right, but in that case what good is �Listen� for, beside specifying local sockets? I mean, since we have ACLs to rely on for prescribing access rights, it should be perfectly enough to be able to decide which port we'll be listening on. All the rest can be defined with the said ACLs. Besides, we can always block some address class(es) on firewall (e.g. in case when cups server is connected to more than one LAN and we want to �enable it� only for some selected network(s)).

I must admit, man page for cups.conf, in section about �Listen�, doesn't present a form �Listen hostname:port�, but, clearly, it is implemented. Maybe it should be dropped altogether, or at least described clearly in just the way you did it for me?

@michaelrsweet

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 15, 2015

CUPS.org User: mike

Yup�hence my suggestion to depend on �network�, which may not solve all the problems but some�for sure. Can it cause any new problems?

Yes, because we can't bind to an interface. Network addresses change...

As for changing the documentation for Listen, quite frankly this has never been an issue. For most users the only value they ever use is "Listen localhost:631", which binds cupsd to the loopback interface (and in fact we have hardcoded lookups for "localhost" to bypass common DNS issues). When sharing is enabled we switch to "Port 631".

Using "Listen hostname" with a dynamically assigned address is just not done...

@michaelrsweet

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 15, 2015

CUPS.org User: thebodzio

Yes, because we can't bind to an interface. Network addresses change...

Fair enough. They may change.

As for changing the documentation for Listen, quite frankly this has never
been an issue.

Well, it looks like I went right up to the fringe ;}

For most users the only value they ever use is "Listen
localhost:631", which binds cupsd to the loopback interface (and in fact we
have hardcoded lookups for "localhost" to bypass common DNS issues).

When sharing is enabled we switch to "Port 631".

Using "Listen hostname" with a dynamically assigned address is
just not done...

OK then. I'm willing to stop right there. I can manage the situation as it is, but I think that if, by any chance, such complain will be repeated, at least a simple note in documentation, like �Don't rely on hostname in dynamically configured environments�, would be in order.

In the meantime, thanks for all the explanation and help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.