Re: Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]
On Tue, Jan 29, 2013 at 9:47 PM, Miloslav Trmač m...@volny.cz wrote: Hello, just a minor point, not getting into the wider should getaddrinfo() be the primary interface debate... On Tue, Jan 29, 2013 at 4:58 AM, Nick Jones nick.fa.jo...@gmail.com wrote: As a quick summary: I would suggest, in addition to addressing the outstanding bugs and issues covered by the Fedora feature, a flag be added to the set of getaddrinfo parameters that instructs it NOT to do DNS lookups, only perform alternative resource lookups supported by nss. This flag would be something like: AI_NODNS This will allow application developers to make use of getaddrinfo for resolving names using non dns sources (hosts file is DNS, so this means ldap and others), then perform internet domain lookups using an alternative DNS library that is standardised in Fedora. That's unnecessarily difficult for the application developers. Application should have a single API to call; if they have to call two separate APIs, some of them won't. Mirek Admittedly there is a problem with adding the AI_NODNS flag, in addition to what you mentioned. That is, what happens when an application compiled to use AI_NODNS is run against an older libc. The binary interface is the same but not the behavioural interface, therefore the application will run but will perform two dns lookups. One way to get around this is by adding a versioned symbol for getaddrinfo, which is no different from the current non versioned symbol. It will be present for enforcement of runtime and rpm build time compatability. Another way is to add a new functional interface like: getnondnsaddrinfo, except with a better name, which performs non dns lookups only. Adding new interfaces to glibc is only done when necessary so a lot of justification for either would be needed, rightly so. I agree that splitting name resolution into two parts is an added complication for application developers, but I feel getaddrinfo itself is split into two of parts: - name resolution using databases such as ldap via nss - name resolution using a dns A or record lookup Making getaddrinfo and nss fully asynchronous will not happen soon, but my suggestion is to split the behaviour to allow an application to be able to resolve names from non-dns sources (which is an important function) then make use of a more modern dns resolver. The behaviour of existing binaries run against the a libc will not be changed in any way. They will continue to use getaddrinfo as they have always done. New applications will have the freedom to lookup a name using getaddrinfo first, then perform the specifically A or record lookup using a dedicated dns library that is fully asynchronous, and also supports richer dns functionality, thus can be re-used for other purposes. Nick -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]
On Mon, Jan 21, 2013 at 6:25 PM, Daniel P. Berrange berra...@redhat.com wrote: On Fri, Jan 18, 2013 at 09:37:37AM +0800, Nick Jones wrote: On Wednesday, January 16, 2013 10:11 PM, Jaroslav Reznik wrote: As the Feature was renamed and the content of Feature has been extended as requested by FESCo, re-announcing it to the community for re-review. See https://fedorahosted.org/fesco/ticket/986 = Features/Fix Network Name Resolution = https://fedoraproject.org/wiki/Features/FixNetworkNameResolution * Detailed description Currently the getaddrinfo() function doesn't work as it was desinged. Many of its features are buggy and cannot be used without extensive workarounds. Many software packages are using getaddrinfo() with such workarounds. Many can trigger its failures. And many packages that don't use getaddrinfo() will be ported in the near future. One feature I would like to see added to future glibc, is a fully asynchronous version of getaddrinfo, and also getnameinfo. Asynchronous for non filesystem fds at least. The glibc maintainers don't seem to be against this idea and I am willing to put time into design and implementation. Perhaps I'm misunderstanding what you're after, but doesn't getaddrinfo_a already provide an async version of getaddrinfo ? Asynchronous Hostname Lookup API http://www.akkadia.org/drepper/asynchnl.pdf That said I don't see the reverse - getnameinfo_a In the summary of this Fedora feature for fixing name resolution is this snippet: Fedora could be seen as the leader in linux networking getaddrinfo is important for Linux systems, and the existing issues with it's implementation are well worth fixing, but when it comes to DNS, getaddrinfo is holding Fedora and Linux back. Even though DNS is not the only source of 'names' that getaddrinfo can return, it is the most important, and in the context of DNS, getaddrinfo will not let Fedora reach the above stated goal. It's not just the lack of support for asynchronous usage, getaddrinfo is a very feature poor resolver: - No support for alternative DNS record types: mx, txt ((ab)used for a lot of things) - No support for DNSSEC - No TCP fallback for that matter, which is essential for the above - Probably lot more, I'm no expert on dns What is needed for networking leadership is: - a feature rich resolver, supporting the above as well as query and response filtering, ala AI_ADDRCONF - an implementation of an IPv6 migration strategy along the lines of Happy Eyeballs - can be used both asynchronously or synchronously - ideally pulls in no dependencies outside libc, except perhaps libidn - ideally the DNS packet parsing routines use only ANSI C - can be used by both C and C++ applications, and is easily bound to other scripting languages, even in the async case - provides reverse lookup - more I can't think of right now but I hope others will add more The question is does this all get added into glibc? 1) Yes: - glibc getaddrinfo gets updated to support this through the addition of new hints flags and return values, or a new function interface is created instead of shoehorning into the old interface, in any case the old getaddrinfo interface will always be callable using traditional, existing semantics and run time linking to existing apps will not be broken - the nss layer gets rewritten to support asynchronous usage (and decent error reporting and additional lookup domains maybe samba?) - perhaps the resulting work gets packaged into a proposed extension to POSIX 2) No: - simply say: forget it, lets do proper DNS outside of libc I say 1) could be possible over the course of a few years but for now, 2) is more realistic. As a quick summary: I would suggest, in addition to addressing the outstanding bugs and issues covered by the Fedora feature, a flag be added to the set of getaddrinfo parameters that instructs it NOT to do DNS lookups, only perform alternative resource lookups supported by nss. This flag would be something like: AI_NODNS This will allow application developers to make use of getaddrinfo for resolving names using non dns sources (hosts file is DNS, so this means ldap and others), then perform internet domain lookups using an alternative DNS library that is standardised in Fedora. Given that in most systems, the nss alternatives are local file based, and given the option of using nsscache, these lookups could be considered reasonably constrained therefore NOT in need of asynchronous implementations. Over time, the alternative DNS library could be considered for inclusion in the core c library, and could replace the DNS lookup aspect of getaddrinfo, at least for A and lookups, and more if additional query flags are defined for getaddrinfo or if an alternative function interface is defined. In addition, work can be done to make the nss layer asynchronous, or at least constrain it to local file resources and standardise on the use of nsscache
Re: Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]
On Wednesday, January 16, 2013 10:11 PM, Jaroslav Reznik wrote: As the Feature was renamed and the content of Feature has been extended as requested by FESCo, re-announcing it to the community for re-review. See https://fedorahosted.org/fesco/ticket/986 = Features/Fix Network Name Resolution = https://fedoraproject.org/wiki/Features/FixNetworkNameResolution * Detailed description Currently the getaddrinfo() function doesn't work as it was desinged. Many of its features are buggy and cannot be used without extensive workarounds. Many software packages are using getaddrinfo() with such workarounds. Many can trigger its failures. And many packages that don't use getaddrinfo() will be ported in the near future. One feature I would like to see added to future glibc, is a fully asynchronous version of getaddrinfo, and also getnameinfo. Asynchronous for non filesystem fds at least. The glibc maintainers don't seem to be against this idea and I am willing to put time into design and implementation. I have a number of high level ideas for this project that I would like to have documented as starting points. I am not a fedora community member, so someone will need to help me raise bugzillas and paste my notes on the wiki. Nick -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: TFTP not working on F15 as well as updated F14
On Tue, 2011-10-11 at 21:22 +0100, Aaron Gray wrote: On 11 October 2011 18:49, Tom Callaway tcall...@redhat.com wrote: On 10/11/2011 01:46 PM, Aaron Gray wrote: I have two F15 machines one a desktop which is running the new Gnome 3 desktop and a laptop not running the new desktop. TFTP is not working on the desktop machine on F15 as it was not working on the updated F14. It worked on F14 before the update. I installed two servers using PXE using it. I assume you mean TFTP server, here. Can you attach copies of the relevant config files and any errors that show up in the logs (server or client side)? Tom, AFAICT by using a remote machine both the server and client are not functioning. I will go through everything again tomorrow and do a proper report as it is late now. Many thanks for getting back to me and offering to look into this, Aaron Is your issue similar to: https://bugzilla.redhat.com/show_bug.cgi?id=739534 ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
