You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What version of the software are you using? On what operating system?
munge-0.5.10
Please provide any additional information below.
All of the MUNGE communications are over a local Unix domain socket, and as such, are unaffected by IPv6.
But when munged starts, it calls gethostname() to obtain the hostname, and gethostbyname() to resolve its IPv4 address. This IPv4 address is embedded into the metadata when encoding credentials.
Since the IP address here is not strictly required for authentication, munged should treat a hostname resolution failure as a warning and continue its execution using an IPv4 address of 0.0.0.0.
Reported by Tomas Kouba on 2013-02-08.
Original issue reported on code.google.com by chris.m.dunlap on 11 Feb 2013 at 8:01
The text was updated successfully, but these errors were encountered:
What steps will reproduce the problem?
Configure host to be IPv6-only and start munged.
What is the expected output? What do you see instead?
munged should work on hosts configured for IPv4 and/or IPv6. But on IPv6-only hosts, munged is unable to resolve its hostname:
What version of the software are you using? On what operating system?
munge-0.5.10
Please provide any additional information below.
All of the MUNGE communications are over a local Unix domain socket, and as such, are unaffected by IPv6.
But when munged starts, it calls
gethostname()
to obtain the hostname, andgethostbyname()
to resolve its IPv4 address. This IPv4 address is embedded into the metadata when encoding credentials.Since the IP address here is not strictly required for authentication, munged should treat a hostname resolution failure as a warning and continue its execution using an IPv4 address of 0.0.0.0.
Reported by Tomas Kouba on 2013-02-08.
Original issue reported on code.google.com by
chris.m.dunlap
on 11 Feb 2013 at 8:01The text was updated successfully, but these errors were encountered: