[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Better control over what mDNS announces
> Both of these (but especially the first) violate (one of) the
> point(s) of mdns - finding services without explicit network
Probably yes. But the current behaviour (for me) violates the point of a
working printing ystem _with_ explicit network configuration.
It appears to be one of these "make it Just Work at home" features that make
it fail in a larger-scale office environment.
> Unless you (ipf,pf,npf)-filter them unoperational - those should
> work, as they're (well, should be) only announced on the local link
> where the connection will work.
No, because CUPS isn't configured to listen on IPv6.
> However, if you want that as an _option_, ok with me.
Yes, sure, I'm speaking of options.
> when the idea of more than one address for a machine was new and exotic.
In my environment, more than one address _on one interface_ is indeed a
special case (roving aliases for things like gateway/resolver you can't
sensibliy announce vis DNS).
> They're not distinguished as well as you might think even on IPv4
Yes, I know. Stil I keep the notion of a main and alias addresses in my setup.
> I think more useful would be to have options to only announce or ignore
> a specific set of addresses. Will also help for the former case.
I thought of that. But it may be difficult to express in the config.
> (To a certain degree your perceived problem seems to come from cups
> not exercising control over what addresses it uses and which it
> wants announced? That is, less than optimal integration of mdns into
For PPD downloading, the server providing the CUPS service used to announce
cups-ea.math.uni-bonn.de and my DNS provided a client with an address in the
client's net that CUPS was known to listen on.
Now (in the Beautiful World of Bonjour) CUPS announces elbe.local and the
client gets offered a bunch of addresses for elbe.local by mDNS.
Now we ran into two obscure problems: First, during our tests on a
development server, CUPS announced trave.local and mDNS responded with
(relative, IPv4) address .30, which worked. Then we moved to a production
server which happened to also be one of our resolvers. So mDNS announced
.20 (the basic address) plus .3, which is a roving alias for DNS resolution
and CUPS is not configured to listen on .3.
Second, the machine has IPv6 support in the kernel, thus link-local addresses,
but is not really set up to use IPv6 at this time. But mDNS announced the LL
v6 address and then loading the PPDs failed. I want to be in control of
whether we provide CUPS (or NFS or the Icinga Classic UI or whatever) over
IPv4 or IPv6 for a set of clients. I don't want Bonjour to take over.
Main Index |
Thread Index |