[Bug 1313004] Re: IPv6 static routes without gateway fail to be set
This is fixed in wily. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1313004 Title: IPv6 static routes without gateway fail to be set To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1313004/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1313004] [NEW] IPv6 static routes without gateway fail to be set
Public bug reported: When using network-manager, and specifying the IPv6 routes, I am able to enter and save IPv6 Settings static routes with no gateway or metric. Upon hitting save, the dialog closes apparently successfully but this entry appears in the syslog (actual address defaced): Apr 25 19:28:26 zanfur-fb NetworkManager[7181]: keyfile: ipv6.route2: route defa:cede:face:defa::/64 gateway 0 metric 0 Apr 25 19:28:26 zanfur-fb NetworkManager[7181]: build_ip6_address_or_route: ignoring invalid IPv6 gateway '0' Additionally, upon opening the connection again through the same dialog, the routes are empty. Checking the connection file in /etc/NetworkManager/system-connections, the routes are unlisted. When editing the connection file directly, upon saving I see a similar syslog entry, even when I put '::' in for the gateway. When I leave it as a zero-width string, the message says '' instead of '0' but is otherwise the same. When attempting to connect, the connection completes just fine but the route is of course ignored. EXPECTED BEHAVIOR: Able to save ipv6 routes with no gateway, and have them established upon connection (e.g. for VPN connections, where there is typically no gateway other than the VPN endpont itself). ACTUAL BEHAVIOR: IPv6 routes without a gateway are silently dropped from the config. SYSTEM: Ubuntu trusty tahr 14.04, network-manager 0.9.8.8-0ubuntu7, network- manager-openconnect-gnome 0.9.8.0-1ubuntu2, kernel 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux. Running on a Lenovo T440s, though that doesn't much matter here. ** Affects: network-manager (Ubuntu) Importance: Undecided Status: New ** Tags: ipv6 route vpn -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1313004 Title: IPv6 static routes without gateway fail to be set To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1313004/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1229886] Re: Grub2 cannot bring Win 7 out of hibernation - error 0xc000009a
I have the same problem, but also a fair bit of information gleaned from experimentation. Here are my notes: My setup: * Lenovo T530 (yes, it can hold 3 internal hard drives, two SATA and one mSATA) * Windows 7 EFI on /dev/sda1=(hd0,gpt1), Windows install on /dev/sda2=(hd0,gpt2) * Ubuntu 12.04.3 EFI on /dev/sdc1=(hd2,gpt1), Ubuntu install on /dev/sdc2=(hd2,gpt2) * grub-efi is installed on (hd2,gpt1)/efi/grub/grubx64.efi * rEFInd is installed on both EFI partitions under /efi/refind/refind_x64 * Attempts to resume Windows from hibernate using grub result in the 0xc09a windows error Things of note: I *had* resume working without issue, using MBR booting rather than UEFI booting and using the drivemap -s grub command to fake the bios ordering for windows (windows MBR resume *only* looks for the BCD on the first bios drive...so stupid), but when my SSD crashed I installed a fresh from-disk copy of Win7 Pro. To do this, I actually *removed* all my linux drives from the machine so that the windows installer had no chances of screwing up the linux partitions or boot sequence, so windows installed thinking it was the only OS on the only drive on the system. It installed itself using UEFI booting, which caused me headaches until I converted my linux grub install to use grub- efi. However, I've collected lots of data in my floundering yet ultimately successful attempts to get windows booting from grub- efi...though I still can't resume from hibernate using grub. Here's what I've found: * It doesn't matter if the linux disklabel is GPT or msdos/MBR -- so long as you insmod the proper grub module for the partition table, behavior is exactly similar (can boot linux just fine, and can boot windows but not resume windows from hibernate) * It doesn't matter if you use the standard UEFI image location of /EFI/Boot/bootx64.efi for grub or if you use the standard /EFI/grub/grubx64.efi location, exact same behavior. * It doesn't matter if grubx64.efi is installed on the same EFI as windows, or on a different drive (though I must point out that my grub modules are on a different drive -- I have not tested with Ubuntu and Windows on the *same* drive entirely) * It doesn't matter if the grub EFI partition is partition 1, or partition 3, or partition 4, or if the EFI partition is near the start of the disk or near the end...I've tried all combinations and it's the exact same behavior, both with GPT and MBR disklabels. * No matter how many times hibernate fails to resume, if I boot directly to the windows EFI image (not through grub), the resume succeeds. Similarly, it will succeed if I boot directly to rEFInd (not through grub), either of them, and then attempt to resume windows from there. Here's the most interesting stuff I've found: * rEFInd *can* resume windows from hibernate, using its default of loading /efi/Microsoft/Boot/bootmgfw.efi. * rEFInd can reusme windows from either refind installation, even -- it doesn't care if it's the same drive or not. * rEFInd ***CAN'T*** resume windows from hibernate if you've chainloaded to it from grub. Same behavior. Basically, I can chainload from rEFInd to rEFInd all day long (I have two installs, one on each OS drive) and then resume windows from hibernate, but once I've let grub into the chain, resume from hibernate breaks. If I reboot and select a boot path that does not include grub, that same previously-failed resume attempt will succeed. Grub is clearly doing something to alter the EFI environment in a way that breaks windows resume, and in a way that rEFInd does not. For now, I'm booting using rEFInd, which is annoying because the OS ordering is random each boot...but at least it functions. I'm parsing through the rEFInd source code and the EFI chainloading code, looking for conceptual differences, but I'm in a little over my head there. I hope this information helps other, more knowledgeable people find the answer more quickly. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1229886 Title: Grub2 cannot bring Win 7 out of hibernation - error 0xc09a To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1229886/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
I would if I considered it a bug. (I didn't fully describe the current
state of samba4, because I figured it was irrelevant: You can alter the
interfaces it binds to, but not for *only* the dns resolver -- so
currently, if you want samba4 listening on the wildcard address you'll
need the dns resolver listening there too.) It would be a nice feature,
sure. But, it's nm-dnsmasq is the one breaking away from standards in
ways that will break other packages, so I'm reporting the conflict here.
Btw, named immediately notices because of the
/etc/network/if-{up,down}.d/bind9 scripts that trigger rndc reconfig
when an interface goes up or down.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from starting
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
I would if I considered it a bug. (I didn't fully describe the current
state of samba4, because I figured it was irrelevant: You can alter the
interfaces it binds to, but not for *only* the dns resolver -- so
currently, if you want samba4 listening on the wildcard address you'll
need the dns resolver listening there too.) It would be a nice feature,
sure. But, it's nm-dnsmasq is the one breaking away from standards in
ways that will break other packages, so I'm reporting the conflict here.
Btw, named immediately notices because of the
/etc/network/if-{up,down}.d/bind9 scripts that trigger rndc reconfig
when an interface goes up or down.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from starting
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
In response to #131 and #134 by Thomas: I would argue that will it conflict with anything that exists? is the wrong question, here. Certainly it will conflict in the future, and removing the users ability to run a DNS service on the wildcard address is suboptimal at best, even if they don't *need* to. To directly answer the question about something that conflicts: the internal resolver of the samba4 packages. They're beta right now, but the scheduled release date is December, and there's no parameter (yet) for altering the port or interfaces. This is actually the one that bit me originally. To answer what does it give us?, currently NM invokes a single dnsmasq instance that must be shared between all users. This isn't ideal, because NM connections can be per-user, and this could lead information disclosure at worst and oddly-rearranged DNS resolve orders at best. With an NSS module, you could spin up one dnsmasq instance for the system on a possibly priviliged port (but not 53) and one per user (above 1024), and link them together as forwarders so that only the user owning the connection will use the resolution they've specified in the GUI. It would require som tracking of which user's instance is on which port,and auto-invoking them when necessary, and shutting it down when the user logs out, but would allow for much more flexible and clean separation of user settings. For the record, I am happy to write the NSS plugin myself, but it would require some changes in NM core itself, so I would have to work with someone on the NM team to implement it. If you're interested, and know who that would be, please do let me know. I will also create a new bug report as requested. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
In response to #131 and #134 by Thomas: I would argue that will it conflict with anything that exists? is the wrong question, here. Certainly it will conflict in the future, and removing the users ability to run a DNS service on the wildcard address is suboptimal at best, even if they don't *need* to. To directly answer the question about something that conflicts: the internal resolver of the samba4 packages. They're beta right now, but the scheduled release date is December, and there's no parameter (yet) for altering the port or interfaces. This is actually the one that bit me originally. To answer what does it give us?, currently NM invokes a single dnsmasq instance that must be shared between all users. This isn't ideal, because NM connections can be per-user, and this could lead information disclosure at worst and oddly-rearranged DNS resolve orders at best. With an NSS module, you could spin up one dnsmasq instance for the system on a possibly priviliged port (but not 53) and one per user (above 1024), and link them together as forwarders so that only the user owning the connection will use the resolution they've specified in the GUI. It would require som tracking of which user's instance is on which port,and auto-invoking them when necessary, and shutting it down when the user logs out, but would allow for much more flexible and clean separation of user settings. For the record, I am happy to write the NSS plugin myself, but it would require some changes in NM core itself, so I would have to work with someone on the NM team to implement it. If you're interested, and know who that would be, please do let me know. I will also create a new bug report as requested. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
You've got the basic idea. The nsswitch.conf file is where Name Service services are configured, and hosts is one of them. DNS is *one* way to look up hosts, but so is files (/etc/hosts) and mdns4 (avahi). Anything that extends how names are translated to addresses should, imnho, be done through NSS. This is because *everything* supports NSS. For instance, NIS and NIS+ hosts are done through NSS, and this is supported by essentially everything, because it's the standard. All of the enterprise directory services I've come across use an NSS plugin (usually the nis one). It's just simply the right way to do it. I wouldn't worry about resolver libraries that don't use glibc. They're typically DNS-specific, and are typically configured by their own files anyway. Dig, for instance, will use whatever server you tell it to, and ignore resolv.conf (though it uses it as a default). Same goes for the host tool -- they're used for querying specific DNS servers. However, those resolvers *also* ignore /etc/hosts, because that's referenced by the files NSS plugin. Any service that uses gethostbyname(3) is using glibc, and that's going to be everything except edge cases that are intentionally doing their own thing anyway. Things that try to emulate glibc behavior by first checking /etc/hosts and then /etc/resolv.conf are simply doing it wrong, and will miss (for instance) avahi, NIS, and any other directory service that may be installed. I'm surprised at the idea that it will be less work to modify glibc. Even if it's technically easier to make a change in the glibc code than to create your own NSS plugin, you have a myriad of problems: NM functionality would now have a dependency on a nonstandard patch of glibc, the documentation for /etc/resolv.conf will be inconsistent for only this distribution, there could (will) be resistance by the glibc folks, who knows what you'll break when you alter how glibc behaves, etc. However, with an NSS module, we have a huge number of advantages: * It's the standard way of achieving this type of thing and is hence supported by most everything * It's the standard way of achieving this type of thing so it's very well documented * It's the standard way of achieving this type of thing so it's very modularized and isolated, and if NM stops working it will continue along the chain without screwing up plugins further up like (unlike when dnsmasq dies with the proposed glibc change) * It's the standard way of achieving this type of things so the things that don't support it are, in general, doing it wrong and that's a bug on their end * It's the standard way of achieving this type of thing so there's already a package (libnss-mdns) that adds a hosts NSS module, meaning both that we know it works and that it is officially supported by ubuntu * It could be owned by the NM project instead of creating a dependency on a glibc patch that would not be taken up by distributions very quickly * You could make it do other interesting things like have static /etc/hosts-like entries per connection. You get the idea. If you want to see an example of an NSS hosts plugin packaged for ubuntu, that hooks into /etc/nsswitch.conf, look at the nss-mdns source package. The debian/libnss-mdns.postinst script that runs upon installation is what handles inserting it into /etc/nsswitch.conf, and can easily be adapted to handle inserting a NM plugin. If you want another example of an ubuntu package dealing with NSS plugins look at the auth-client-config package, though this one only handles the passwd, group, and shadow services. In short: An NSS plugin has vastly less risk of breaking software because Ubuntu already uses it and things aren't breaking (and it's also the standard, anyway), could actually be part of the NM project as opposed to owned by glibc, and will likely be easier than modifying glibc anyway due to fewer dependencies. This seems like win-win-win to me. To be clear, I'm advocating that we make a small NSS plugin wrapper around calls to a dnsmasq (or other) mini name server controlled by NM, that runs on a non-privileged port and can be spawned per-user. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
You've got the basic idea. The nsswitch.conf file is where Name Service services are configured, and hosts is one of them. DNS is *one* way to look up hosts, but so is files (/etc/hosts) and mdns4 (avahi). Anything that extends how names are translated to addresses should, imnho, be done through NSS. This is because *everything* supports NSS. For instance, NIS and NIS+ hosts are done through NSS, and this is supported by essentially everything, because it's the standard. All of the enterprise directory services I've come across use an NSS plugin (usually the nis one). It's just simply the right way to do it. I wouldn't worry about resolver libraries that don't use glibc. They're typically DNS-specific, and are typically configured by their own files anyway. Dig, for instance, will use whatever server you tell it to, and ignore resolv.conf (though it uses it as a default). Same goes for the host tool -- they're used for querying specific DNS servers. However, those resolvers *also* ignore /etc/hosts, because that's referenced by the files NSS plugin. Any service that uses gethostbyname(3) is using glibc, and that's going to be everything except edge cases that are intentionally doing their own thing anyway. Things that try to emulate glibc behavior by first checking /etc/hosts and then /etc/resolv.conf are simply doing it wrong, and will miss (for instance) avahi, NIS, and any other directory service that may be installed. I'm surprised at the idea that it will be less work to modify glibc. Even if it's technically easier to make a change in the glibc code than to create your own NSS plugin, you have a myriad of problems: NM functionality would now have a dependency on a nonstandard patch of glibc, the documentation for /etc/resolv.conf will be inconsistent for only this distribution, there could (will) be resistance by the glibc folks, who knows what you'll break when you alter how glibc behaves, etc. However, with an NSS module, we have a huge number of advantages: * It's the standard way of achieving this type of thing and is hence supported by most everything * It's the standard way of achieving this type of thing so it's very well documented * It's the standard way of achieving this type of thing so it's very modularized and isolated, and if NM stops working it will continue along the chain without screwing up plugins further up like (unlike when dnsmasq dies with the proposed glibc change) * It's the standard way of achieving this type of things so the things that don't support it are, in general, doing it wrong and that's a bug on their end * It's the standard way of achieving this type of thing so there's already a package (libnss-mdns) that adds a hosts NSS module, meaning both that we know it works and that it is officially supported by ubuntu * It could be owned by the NM project instead of creating a dependency on a glibc patch that would not be taken up by distributions very quickly * You could make it do other interesting things like have static /etc/hosts-like entries per connection. You get the idea. If you want to see an example of an NSS hosts plugin packaged for ubuntu, that hooks into /etc/nsswitch.conf, look at the nss-mdns source package. The debian/libnss-mdns.postinst script that runs upon installation is what handles inserting it into /etc/nsswitch.conf, and can easily be adapted to handle inserting a NM plugin. If you want another example of an ubuntu package dealing with NSS plugins look at the auth-client-config package, though this one only handles the passwd, group, and shadow services. In short: An NSS plugin has vastly less risk of breaking software because Ubuntu already uses it and things aren't breaking (and it's also the standard, anyway), could actually be part of the NM project as opposed to owned by glibc, and will likely be easier than modifying glibc anyway due to fewer dependencies. This seems like win-win-win to me. To be clear, I'm advocating that we make a small NSS plugin wrapper around calls to a dnsmasq (or other) mini name server controlled by NM, that runs on a non-privileged port and can be spawned per-user. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1055880] Re: 30_os-prober does not add drivemap for Windows 7
I can confirm this problem, explain the root cause, and confirm the fix. Steps to reproduce problem: 1. Obtain a Windows 7 install (I used Windows 7 Professional) 2. Install a second drive with higher boot priority in the BIOS 3. Install Ubuntu (I tested with 12.04.1 and 12.10) on the second drive. *Drive*, not merely partition. 4. Boot into the new Windows 7 (loader) grub entry 5. Attempt to hibernate via the shutdown menu (the following are optional information gathering steps) 6. Attempt to hibernate via running poweroff /h in an Administrator cmd window 7. Attempt to list BCD values via running bcdedit /enum in an Administrator cmd window 8. Look at the boot configuration in System Properties - Advanced - Startup and Recovery. Expected results: 5. Machine enters hibernate 6. Machine enters hibernate 7. Printout of Windows boot loader options and available Windows 7 installations 8. Fields in the panel filled out with appropriate values (such as Windows 7 Professional and a timeout of 10) and editable. Actual results: 5. Screen blanks, computer locks (the need a password variety, not a freeze), does not hibernate 6. Same as 5, but you see the error The system cannot find the file specified.(2) 7. Error message The boot configuration data store could not be opened. The system cannot find the file specified. 8. All fields are blank and you are unable to set them. I spent multiple hours tracking down why this occurred, and attempting to bash the Windows 7 Boot Configuration Data system into accepting being on the second drive. I even went so far as to completely erase and recreate the entire BCD descriptor. It works fine for booting, but not for hibernation -- and by extension, Hybrid Sleep, meaning that Windows 7 sleep functionality is broken on many installs. The source of this particular issue is that hibernation in Windows 7 is done in part by modifying the BCD to point to the hibernation file, similar to when calling bcdedit to edit boot entries, but Windows 7 *only* looks for the BCD on the boot device. Specifically, it only looks at the primary partition on the boot device that has the bootable flag set, and boot device in this context means the first hard disk in the BIOS ordering (i.e. drive 0x80 in BIOS-speak). I scoured technet looking for any way to modify this behavior and came up short, finding only an until next reboot solution for EFI devices. I actually had grub on both drives at one point in my tests, and I could boot into Windows 7 using either by changing the boot order in my BIOS. Whenever I booted from the different drive than windows, I coulnd't hibernate or access any of the BCD information using any of steps 5, 6, 7, or 8 above. I *could* manually specify the BCD with the bcdedit tool using its /store parameter to explicitly specify the BCD store file, successfully altering parameters for subsequent boots, but anything that was supposed to operate on the current BCD store would fail. After determining that it was in fact related to BIOS boot order, I tried setting grub to swap the bios identifiers using the drivemap declaration in grub.cfg, which worked perfectly to resolve all the described issues. It looks like someone beat me to writing a bug report, though, so I'm adding this here. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1055880 Title: 30_os-prober does not add drivemap for Windows 7 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1055880/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1055880] Re: 30_os-prober does not add drivemap for Windows 7
I neglected to mention that during my swaps back forth in BIOS drive ordering, none of these problems ever occurred when I booted from the same drive that Windows was on, even when I booted from on that drive, though they always occurred when I booted from the other (until I implemented to solution described above, of course). Windows really seems to care that its boot files are on the first drive. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1055880 Title: 30_os-prober does not add drivemap for Windows 7 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1055880/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
Are you sure? I am only aware of named.conf's listen-on { IP_ADDRESS;
}. If there is a feature such as you describe then presumably named
binds ALL:53 and then filters according to the addresses on the
specified interfaces.
Nope, I just verified, you're quite correct. I hadn't heard of it
either, but upon (mis)reading comments above I presumed without
verifying. Bad on me.
A question about the NSS plugin idea. Will this work only for software
that uses glibc? What about alternative resolver libraries?
Anything that uses the gethostbyname(3) call uses the NSS chain. That
means essentially everything that isn't a resolver itself uses
nsswitch.conf. DNS resolver libraries won't use NSS by design, because
they are the resolvers themselves that are *used* by NSS. This is why
there are no names in their respective configuration files, save for
what they're serving (remote addresses are specified by address). If
any DNS resolver itself reads nsswitch.conf, it's doing somethign Very
Wrong.
The idea of NSS is that the DNS resolvers aren't *supposed* to use it.
They are the exporters of NSS services, not the consumers. I don't know
of any of them that use NSS for their own resolution; they are just one
link in the NSS chain that is used by the (libc) name resolver
libraries. When you hit the DNS service itself, you really *don't* want
it to start the NSS chain over, because that would just lead to a loop.
My proposal for using NSS in place of NetworkManager's dnsmasq is to
create a new NSS plugin and place it earlier in the NSS chain than the
standard DNS resolver. For instance, a line like so:
hosts: files mdns4_minimal [NOTFOUND=return] network_manager
[NOTFOUND=return] dns mdns4
This is straight from my Precise install, with the addition of the
network_manager [NOTFOUND=return] stanza. It says that first you
check /etc/hosts (that's files), then a subset of avahi
(mdns4_minimal [NOTFOUND=return]), then your NM plugin
network_manager [NOTFOUND=return], plain old DNS (dns), then avahi
again (mdns4).
It would not conflict with any other NSS plugin, because they are all
tried in turn until a match is found. If you place it directly in front
of the DNS resolver plugin in nsswitch.conf, it will be used before the
standard DNS lookup, allowing you to do all the fancy connection-
specific magic you need to do, while returning Try Next for anything
non-connection specific, thus allowing the normal DNS resolver plugin
(which reads resolv.conf) to do things as normal. This is *instead* of
hooking in at resolv.conf, as you do now. People can install any
resolver they want, and it works as designed. This lets you listen on
high-numbered ports as well, *and* lets you have per-user dnsmasq
instances (per user vpns?), while still running Bind or a normal dnsmasq
instance on *:53.
Right now, the dnsmasq for NM basically hijacks resolv.conf, which means
it's hooking into the DNS NSS plugin's resolution (it's the plugin that
reads resolv.conf, not the applications, using code in libc). This is
causing conflicts, because in order to use resolv.conf, you need to be
running on port 53 -- and it would take re-writing parts of the DNS NSS
plugin (or libc!) to change this. But, you don't need to do that at
all. Just insert the NM NSS plugin *before* the DNS NSS plugin, and you
can do all the fancy things you want, without ever breaking any DNS
resolution at all. If you don't have anything special to do, return
notfound and DNS will do its thing. Alternatively, you can *replace*
the DNS NSS library with your own (add yours to nsswitch and remove the
dns one), and do all processing in there, which will likely involve
querying the local dnsmasq instance directly without even bothering with
resolv.conf.
Really, the Name Service Switch subsystem is the system designed to
handle Switching between multiple Name Service providers. That's where
such things need to be. See documentation:
http://www.gnu.org/software/libc/manual/html_node/Name-Service-
Switch.html
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from starting
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
Are you sure? I am only aware of named.conf's listen-on { IP_ADDRESS;
}. If there is a feature such as you describe then presumably named
binds ALL:53 and then filters according to the addresses on the
specified interfaces.
Nope, I just verified, you're quite correct. I hadn't heard of it
either, but upon (mis)reading comments above I presumed without
verifying. Bad on me.
A question about the NSS plugin idea. Will this work only for software
that uses glibc? What about alternative resolver libraries?
Anything that uses the gethostbyname(3) call uses the NSS chain. That
means essentially everything that isn't a resolver itself uses
nsswitch.conf. DNS resolver libraries won't use NSS by design, because
they are the resolvers themselves that are *used* by NSS. This is why
there are no names in their respective configuration files, save for
what they're serving (remote addresses are specified by address). If
any DNS resolver itself reads nsswitch.conf, it's doing somethign Very
Wrong.
The idea of NSS is that the DNS resolvers aren't *supposed* to use it.
They are the exporters of NSS services, not the consumers. I don't know
of any of them that use NSS for their own resolution; they are just one
link in the NSS chain that is used by the (libc) name resolver
libraries. When you hit the DNS service itself, you really *don't* want
it to start the NSS chain over, because that would just lead to a loop.
My proposal for using NSS in place of NetworkManager's dnsmasq is to
create a new NSS plugin and place it earlier in the NSS chain than the
standard DNS resolver. For instance, a line like so:
hosts: files mdns4_minimal [NOTFOUND=return] network_manager
[NOTFOUND=return] dns mdns4
This is straight from my Precise install, with the addition of the
network_manager [NOTFOUND=return] stanza. It says that first you
check /etc/hosts (that's files), then a subset of avahi
(mdns4_minimal [NOTFOUND=return]), then your NM plugin
network_manager [NOTFOUND=return], plain old DNS (dns), then avahi
again (mdns4).
It would not conflict with any other NSS plugin, because they are all
tried in turn until a match is found. If you place it directly in front
of the DNS resolver plugin in nsswitch.conf, it will be used before the
standard DNS lookup, allowing you to do all the fancy connection-
specific magic you need to do, while returning Try Next for anything
non-connection specific, thus allowing the normal DNS resolver plugin
(which reads resolv.conf) to do things as normal. This is *instead* of
hooking in at resolv.conf, as you do now. People can install any
resolver they want, and it works as designed. This lets you listen on
high-numbered ports as well, *and* lets you have per-user dnsmasq
instances (per user vpns?), while still running Bind or a normal dnsmasq
instance on *:53.
Right now, the dnsmasq for NM basically hijacks resolv.conf, which means
it's hooking into the DNS NSS plugin's resolution (it's the plugin that
reads resolv.conf, not the applications, using code in libc). This is
causing conflicts, because in order to use resolv.conf, you need to be
running on port 53 -- and it would take re-writing parts of the DNS NSS
plugin (or libc!) to change this. But, you don't need to do that at
all. Just insert the NM NSS plugin *before* the DNS NSS plugin, and you
can do all the fancy things you want, without ever breaking any DNS
resolution at all. If you don't have anything special to do, return
notfound and DNS will do its thing. Alternatively, you can *replace*
the DNS NSS library with your own (add yours to nsswitch and remove the
dns one), and do all processing in there, which will likely involve
querying the local dnsmasq instance directly without even bothering with
resolv.conf.
Really, the Name Service Switch subsystem is the system designed to
handle Switching between multiple Name Service providers. That's where
such things need to be. See documentation:
http://www.gnu.org/software/libc/manual/html_node/Name-Service-
Switch.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from starting
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
Another drawback is that you still need to manually configure bind (and others) to only listen on particular addresses. If you're using dhcp this presents a problem, because you don't actually know the address. With bind, this is okay, mostly, because you can say to listen on everything for a particular interface (but then you can't listen on 127.0.0.1, because it's the same interface as 127.0.1.1), but other servers only have per-address configurations. The NSS plugin idea is *exactly* what NSS was designed for, and literally doesn't conflict with any name resolver in any way. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
Another drawback is that you still need to manually configure bind (and others) to only listen on particular addresses. If you're using dhcp this presents a problem, because you don't actually know the address. With bind, this is okay, mostly, because you can say to listen on everything for a particular interface (but then you can't listen on 127.0.0.1, because it's the same interface as 127.0.1.1), but other servers only have per-address configurations. The NSS plugin idea is *exactly* what NSS was designed for, and literally doesn't conflict with any name resolver in any way. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
I just read this entire chain, and I'm surprised not to see mention of using an NSS plugin, like Avahi (and ldap and NIS and /etc/hosts and DNS itself). I expect it would be simple enough to write a small NSS plugin that merely calls the NM-dnsmasq (running on localhost on a port other than 53) and placing it in front of (or instead of) dns on the hosts line in /etc/nsswitch.conf. This would not conflict at *all* with any local DNS servers, and would work for anything that used the libc resolver. It's also vastly cleaner than the let's change multiple upstream packages options I see listed above. For extra points, it's probably past time to make a dbus nss plugin, which could be configured to talk to NM, which in turn would ask its personal dnsmasq instance running on any available port, or however it decided to track such things in the future. This would be a clean interface, with all resolving going through libc, with a well-defined API chain (libc --NSS-- dbusplugin --DBUS-- NetworkManager --DNS-- dnsmasq), and allow for NetworkManager to change the last step (DNS protocol to dnsmasq) to whatever in the future without re-architecting anything underneath. Or have the NSS plugin directly access dnsmasq and have NetworkManager manage its configuration, to follow dnsmasq port changes or what have you. It's not as future-proof, but it still gets the job done without conflicting with any resolvers. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
I just read this entire chain, and I'm surprised not to see mention of using an NSS plugin, like Avahi (and ldap and NIS and /etc/hosts and DNS itself). I expect it would be simple enough to write a small NSS plugin that merely calls the NM-dnsmasq (running on localhost on a port other than 53) and placing it in front of (or instead of) dns on the hosts line in /etc/nsswitch.conf. This would not conflict at *all* with any local DNS servers, and would work for anything that used the libc resolver. It's also vastly cleaner than the let's change multiple upstream packages options I see listed above. For extra points, it's probably past time to make a dbus nss plugin, which could be configured to talk to NM, which in turn would ask its personal dnsmasq instance running on any available port, or however it decided to track such things in the future. This would be a clean interface, with all resolving going through libc, with a well-defined API chain (libc --NSS-- dbusplugin --DBUS-- NetworkManager --DNS-- dnsmasq), and allow for NetworkManager to change the last step (DNS protocol to dnsmasq) to whatever in the future without re-architecting anything underneath. Or have the NSS plugin directly access dnsmasq and have NetworkManager manage its configuration, to follow dnsmasq port changes or what have you. It's not as future-proof, but it still gets the job done without conflicting with any resolvers. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
