[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Change by Matej Cepl : -- nosy: +mcepl ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Stijn Hoop added the comment: I hereby put my patch in the public domain and/or under any desired copyright license as required by the Python project to accept it. Regards, Stijn Hoop On Fri, 22 Oct 2021 21:03:26 + Richard van den Berg wrote: > Richard van den Berg added > the

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Richard van den Berg added the comment: In that case Stijn Hope should create the PR since he wrote the patch. Anyone else could get in trouble for using his code without proper permission. -- ___ Python tracker

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Christian Heimes added the comment: We no longer accept patches. Contributors have to create a PR on GitHub, so we can record contributions and verify the contributor license agreement. -- ___ Python tracker

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Richard van den Berg added the comment: Here is the updated patch. Is python5004-test.c enough as a test case? -- Added file: https://bugs.python.org/file50390/python2.7-socket-getfqdn.patch ___ Python tracker

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Christian Heimes added the comment: Could you or somebody else please create a PR with patch and a test case? -- versions: +Python 3.11 -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Richard van den Berg added the comment: I just ran into this 12 year old issue. Can this be merged please? -- nosy: +richard.security.consultant ___ Python tracker ___

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Jan Hudec added the comment: Confirming the fixed version linked in previous comment by Thomas Waldmann is correct and matches what `hostname -f` does. -- nosy: +bulb versions: +Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Change by Christian Heimes : -- nosy: +christian.heimes ___ Python tracker ___ ___

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Thomas Waldmann added the comment: Embarassing as always to stumble over some stuff and then find a 9y old ticket here, where it is discussed and even (almost) solved. Our ticket: https://github.com/borgbackup/borg/issues/3471 Fixed getfqdn we use now instead of

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

devurandom added the comment: In my case, /etc/hostname, /proc/sys/kernel/hostname, `uname -n`, `hostname -f` all show the same FQDN, but `python -c 'import socket ; print(socket.getfqdn())'` still prints the short hostname. /etc/hosts is empty except for localhost. /etc/nsswitch.conf

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Changes by devurandom : -- nosy: +devurandom ___ Python tracker ___ ___ Python-bugs-list

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

James Shewey added the comment: According to the man page for gethostbyaddr "The gethostbyname*() and gethostbyaddr*() functions are obsolete. Applications should use getaddrinfo(3) and getnameinfo(3) instead." - so perhaps using the correct API call might be a good start to resolving this

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Changes by Mark Lawrence breamore...@yahoo.co.uk: -- nosy: -BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5004 ___ ___

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Stijn Hoop added the comment: So after a good nights sleep: does it not make sense to use the canonical hostname iff the name argument is not present / empty? Otherwise, fall back to the documented steps? That way extra API is avoided, and I can't think of a case where you would rather have

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

R. David Murray added the comment: That is an interesting proposal, yes. I suppose someone that needs the getaddrinfo semantics for something other than the local host can just call it directly. Now, do we add the fact that we are doing this to the current alogarithmic documention? :)

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Stijn Hoop added the comment: OK, fair enough. From reading sources, it appears that hostname is using getaddrinfo(3) on kernelhostname with hints-ai_flags AI_CANONNAME, while Lib/socket.py simply uses gethostbyaddr(kernelhostname), and falls back on kernelhostname in case of errors.

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Stijn Hoop added the comment: Attached is a very lightly tested patch that matches hostname -f behaviour on my system. I suspect this should be OK but it definitely needs more testing than just my system... -- keywords: +patch Added file:

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

R. David Murray added the comment: The problem with your patch is that it changes the (effective) meaning of the 'name' parameter. Before the patch, name can be an IP address. After the patch, that will fail on Fedora. (It also fails on my Gentoo system). It is interesting to note, as

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Stijn Hoop added the comment: OK, dumping my current findings here, as I'm still not sure what the expected results should be. First of all, Lib/socket.py calls gethostbyaddr with a name. As in, gethostby _ADDR_ with a name. This works because Modules/socketmodule.c internally uses

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

R. David Murray added the comment: Yeah, a new function was a thought that had crossed my mind as well. getfqdnbyname, maybe? Or gethostnamefqdn? Then deprecate calling getfqdn without an argument. I agree that gethostbyaddr accepting a non-IP is weird. I have no idea why it was

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Stijn Hoop added the comment: Still seeing this on Fedora 18 / Python 2.7.3. I only have loopback in /etc/hosts [TUE\shoop@pclin281] ~ cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

R. David Murray added the comment: Note that socket.getfqdn is a wrapper around a couple of socket calls that are just wrappers of OS level socket calls. If you take a look at socket.py you'll see the definition. As Martin said earlier, if you (or anyone else) can figure out what hostname

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Jeff McNeil added the comment: Gave this a go myself... $ ./python Python 3.4.0a0 (default:57a33af85407, Oct 27 2012, 21:26:30) [GCC 4.4.3] on linux Type help, copyright, credits or license for more information. import socket socket.getfqdn() 'host.domain.com' $ hostname -f

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Ankit Toshniwal ankitoshni...@gmail.com added the comment: I cannot reproduce this issue. I just tested this on my mac. atoshniw@prusev-mn:~/Documents/code/python-dev/bin #hostname -f prusev-mn.helloworld.com atoshniw@prusev-mn:~/Documents/code/python-dev/bin #python Python 2.6.1 (r261:67515,

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Mark Lawrence breamore...@yahoo.co.uk added the comment: Would someone with appropriate knowledge please take a look to see if this is still an issue. -- components: +Library (Lib) -Extension Modules nosy: +BreamoreBoy stage: - needs patch versions: +Python 2.7, Python 3.1, Python 3.2

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Changes by Antoine Pitrou pit...@free.fr: -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5004 ___ ___ Python-bugs-list mailing

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Martin v. Löwis mar...@v.loewis.de added the comment: I think anybody willing to invest the time could acquire the appropriate knowledge, at least to determine whether it's still an issue (i.e. trying to reproduce it). To fix it, one would then need to read the source code of hostname, and

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

New submission from Daniel Frnake dfra...@wellohorld.com: On Linux and presumably on other POSIX-like systems, socket.getfqdn() doesn't work if a system resolves its own FQDN using DNS rather than /etc/hosts. My system's FQDN is 'fugue.tank.wellohorld.com'. My /etc/hosts is empty except for

[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

Changes by Daniel Franke dfra...@wellohorld.com: -- components: +Extension Modules -Library (Lib) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5004 ___