[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug? kadmind binds only to IPv6 addresses, if IPv6 is enabled
From: "Love" <email@example.com>
>> It seems that kadmind binds to *:749/tcp, which causes an IPv6 enabled
>> host to insist that 749/tcp is already bound even for IPv4.
>> By starting kadmind with the -d option it will report that the socket is
>> already bound for af=2.
> last time I checked, linux also answered ipv6 used ipv4 mapped addresses
> for ipv6 sockets, so, didn't it just work ?
Nope, if it would simply work, I wouldn't complain... ;o)
IMO, to have the functionality you mentioned above, it is necessary to
activate IPv6 in IPv4 tunneling, which isn't always what you want...
>> Would it be difficult to enhance kadmind in that way?
> Not really, just need to share code between kadmind and kdc, but isn't it
> easier to start kadmind from inetd ?
> [excerpt from documentation]
This was the first thing I tried and it didn't work either (that's why I
even came to the idea to let kadmind run on its own). We use xinetd, btw.
The thing is that xinetd (like the "old fashioned" inetd) only allows a weak
kind of access control to certain services, i.e. does allow/deny access for
requests from different subnets, but doesn't really care about binding to
special addresses. And if you can only specify a port on an IPv6 enabled
machine, this port is bound for all types of addresses. So, the same problem
Apart from that, running services from xinetd is not really what I prefer,
since we have amanda running as a backup service on the same machine and if
something kills xinetd, amanda dies with it... ;o(
Also, you cited a phrase that caught my attention (although nobody explains
it any further) that it's not recommended to start kadmind from inetd.
Eventually, I'll try to write a patch for kadmind on my own and suggest it
here for further discussions...