Bug#465158: [Pkg-utopia-maintainers] Bug#465158: network-manager: Please add support for domain-search
tags 465158 + fixed-upstream pending thanks Bas Zoetekouw wrote: tag 465158 + patch thanks Hi! You wrote: ISC DHCP 3.1 provides support for the domain-search option. This is the correct way for a DHCP server to provide a domain search list. Wedging multiple domains into the domain-name option is a horrible hack. It seems, however, that that is what NetworkManager expects, and so how it generates an /etc/resolv.conf. This behaviour should be changed in light of dhclient 3.1, and should do something like this: Attached is a patch that should fix this. It adds support for the domain-search option of dhcp, and uses the logic you suggested to determine what search domains to put in resolv.conf. I have tested the patch only at my local configurationw, which is n-m + dhcp3-client 3.1.0-2 (no resolvconf) on my laptop, and a pre-3.1 dhcp3-server on my server (current etch version), and for that config, it seems to work fine. Testing for other configuration, particular with a new, post-3.1, dhcpd is probably needed, though. Please feel free to send the patch upstream, if you think it's stable enough. Best regards, Bas. Hi Bas, I've forwarded your patch to the upstream author and it has been reviewed and applied to the stable branch (0.6) and also trunk (upcoming 0.7). It didn't make it into the 0.6.6 release though, which was released just a few days ago. I'll upload 0.6.6-1 to unstable with your patch applied the next days. Just wanted to give you an update of the current status. Thanks again for the patch, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#465158: [Pkg-utopia-maintainers] Bug#465158: network-manager: Please add support for domain-search
Bas Zoetekouw wrote: Attached is a patch that should fix this. It adds support for the domain-search option of dhcp, and uses the logic you suggested to determine what search domains to put in resolv.conf. I have tested the patch only at my local configurationw, which is n-m + dhcp3-client 3.1.0-2 (no resolvconf) on my laptop, and a pre-3.1 dhcp3-server on my server (current etch version), and for that config, it seems to work fine. Testing for other configuration, particular with a new, post-3.1, dhcpd is probably needed, though. Please feel free to send the patch upstream, if you think it's stable enough. Hi Bas, first of all, thanks for the patch. I tested it locally (dhcp server from my wlan router) and my resolv.conf now looks like: domain foo.xx search foo.xx nameserver 192.168.2.1 Is it intended behaviour that now both search and domain are set? Unfortunately I don't have access to a dhcpd 3.1 server, so I can't really test if the new domain-search feature works as intended. Bas, you said that you tested it with dhcpd 3.1 (which according to andrew has domain-search support), so why do you think that we also have to test with post-3.1 dhcpd? Cheers, Michael P.S: I updated the patch to apply against head of the current upstream 0.6 branch and intend to send it for review to the upstream mailing list -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#465158: network-manager: Please add support for domain-search
tag 465158 + patch thanks Hi! You wrote: ISC DHCP 3.1 provides support for the domain-search option. This is the correct way for a DHCP server to provide a domain search list. Wedging multiple domains into the domain-name option is a horrible hack. It seems, however, that that is what NetworkManager expects, and so how it generates an /etc/resolv.conf. This behaviour should be changed in light of dhclient 3.1, and should do something like this: Attached is a patch that should fix this. It adds support for the domain-search option of dhcp, and uses the logic you suggested to determine what search domains to put in resolv.conf. I have tested the patch only at my local configurationw, which is n-m + dhcp3-client 3.1.0-2 (no resolvconf) on my laptop, and a pre-3.1 dhcp3-server on my server (current etch version), and for that config, it seems to work fine. Testing for other configuration, particular with a new, post-3.1, dhcpd is probably needed, though. Please feel free to send the patch upstream, if you think it's stable enough. Best regards, Bas. -- +--+ | Bas Zoetekouw | Sweet day, so cool, so calm, so bright, | || The bridall of the earth and skie: | | [EMAIL PROTECTED] | The dew shall weep thy fall tonight;| +|For thou must die. | +-+ diff -Naur network-manager-0.6.5/src/dhcp-manager/nm-dhcp-manager.c network-manager-0.6.5.ok/src/dhcp-manager/nm-dhcp-manager.c --- network-manager-0.6.5/src/dhcp-manager/nm-dhcp-manager.c 2007-04-18 20:13:04.0 +0200 +++ network-manager-0.6.5.ok/src/dhcp-manager/nm-dhcp-manager.c 2008-02-11 20:05:53.667505000 +0100 @@ -472,6 +472,7 @@ guint32 num_ip4_nis_servers = 0; char * hostname = NULL; char * domain_names = NULL; + char * domain_searches = NULL; char * nis_domain = NULL; guint32 * ip4_nis_servers = NULL; struct in_addr temp_addr; @@ -518,6 +519,7 @@ get_ip4_string (manager, dev, host_name, hostname, TRUE); get_ip4_uint32s (manager, dev, domain_name_servers, ip4_nameservers, num_ip4_nameservers, FALSE); get_ip4_string (manager, dev, domain_name, domain_names, TRUE); + get_ip4_string (manager, dev, domain_search, domain_searches, TRUE); get_ip4_string (manager, dev, nis_domain, nis_domain, TRUE); get_ip4_uint32s (manager, dev, nis_servers, ip4_nis_servers, num_ip4_nis_servers, TRUE); @@ -555,14 +557,27 @@ if (domain_names) { - char **searches = g_strsplit (domain_names, , 0); + char **domains = g_strsplit (domain_names, , 0); char **s; - for (s = searches; *s; s++) + for (s = domains; *s; s++) { nm_info ( domain name '%s', *s); nm_ip4_config_add_domain (ip4_config, *s); } + g_strfreev (domains); + } + + if (domain_searches) + { + char **searches = g_strsplit (domain_searches, , 0); + char **s; + + for (s = searches; *s; s++) + { + nm_info ( domain search '%s', *s); + nm_ip4_config_add_search (ip4_config, *s); + } g_strfreev (searches); } diff -Naur network-manager-0.6.5/src/named-manager/nm-named-manager.c network-manager-0.6.5.ok/src/named-manager/nm-named-manager.c --- network-manager-0.6.5/src/named-manager/nm-named-manager.c 2007-04-18 20:13:05.0 +0200 +++ network-manager-0.6.5.ok/src/named-manager/nm-named-manager.c 2008-02-11 21:17:48.084909000 +0100 @@ -319,7 +319,7 @@ static char * compute_searches (NMNamedManager *mgr, NMIP4Config *config) { - int i, num_searches; + int i, num_searches, num_domains; GString *str = NULL; g_return_val_if_fail (mgr != NULL, g_strdup ()); @@ -328,14 +328,54 @@ if (!config) return g_strdup (); - num_searches = nm_ip4_config_get_num_domains (config); - for (i = 0; i num_searches; i++) - { - if (!str) - str = g_string_new (search); + num_searches = nm_ip4_config_get_num_searches (config); + num_domains = nm_ip4_config_get_num_domains (config); + + /* ISC DHCP 3.1 provides support for the domain-search option. This is the + * correct way for a DHCP server to provide a domain search list. Wedging + * multiple domains into the domain-name option is a horrible hack. + * + * So, we handle it like this (as proposed by Andrew Pollock at + * http://bugs.debian.org/465158): + * + * - if the domain-search option is present in the data received via DHCP, + * use it in favour of the domain-name option for setting the search + * directive in /etc/resolv.conf + * + * - if the domain-name option is present in the data received via DHCP, use + * it to set the domain directive in /etc/resolv.conf + * (this is handled in compute_domain() below) + * + * - if only the domain-name option is present in the data received via DHCP + * (and domain-search is not), for backwards compatibility, set the search + * directive in /etc/resolv.conf to the specified domain names + */ - g_string_append_c
Bug#465158: network-manager: Please add support for domain-search
Package: network-manager Version: 0.6.5-5 Severity: wishlist Hi, I'd try to provide a patch, but my C-fu is very, very weak... ISC DHCP 3.1 provides support for the domain-search option. This is the correct way for a DHCP server to provide a domain search list. Wedging multiple domains into the domain-name option is a horrible hack. It seems, however, that that is what NetworkManager expects, and so how it generates an /etc/resolv.conf. This behaviour should be changed in light of dhclient 3.1, and should do something like this: if the domain-search option is present in the data received via DHCP, use it in favour of the domain-name option for setting the search directive in /etc/resolv.conf if the domain-name option is present in the data received via DHCP, use it to set the domain directive in /etc/resolv.conf if only the domain-name option is present in the data received via DHCP (and domain-search is not), for backwards compatibility, set the search directive in /etc/resolv.conf It appears, from my testing, that NetworkManager interacts with resolvconf, so the above only applies when resolvconf is not installed. I've already filed #460609 to have resolvconf update its behaviour. This bug is important for consistent treatment of /etc/resolv.conf when DHCP and the domain-search option is in use. regards Andrew -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]