Re: [2008.09] resolv.conf
On Fri, Sep 26, 2008 at 12:07:17AM -0400, Joel Newkirk wrote: It starts with dnscache. Postinst in dnscache ipk removes the symlink /etc/resolv.conf and replaces it with a real file, pointing always at nameserver 127.0.0.1. (what I had going already) On my Ubuntu desktop, there's a possibly-useful file: /etc/resolvconf/update.d/dnscache - its purpose is to alter /etc/dsncachce/root/servers/@ (the list of servers dnscache is to query for anything uncached) automatically whenever resolvconf is triggered. This would be the way to hook in if resolvconf were working on the Freerunner as intended, which currently appears not to be the case. Alternately (or additionally), /etc/network/if-up.d/ and /etc/network/if-post-down.d/ allow us to perform the same changes automatically whenever an interface is brought up or taken down using ifup and ifdown. I've altered my /etc/init.d/dnscache script to include a 'refresh' feature, that first wipes /etc/dnscache/root/servers/@, then stuffs in any non-localhost nameservers presently listed in /etc/resolv.conf, then adds any nameservers found in /etc/resolvconf/run/resolv.conf, finishing up with any IPs listed in /etc/default/dnscache (default contents opendns.com IPs), wipes /etc/resolv.conf back to localhost only, then finally kicks dnscache so it uses the new servers/@ contents. Once my freerunner is back in front of me I'll test the init script changes - if it works as I hope, I can add a script to the ipk in each of /etc/network/if-up.d/ and /etc/network/if-post-down.d/ that simply call /etc/init.d/dnscache refresh, and/or in /etc/resolvconf/update.d/. That makes the whole thing just work as a single ipk installing dnscache and all the support to override resolvconf AND 'manual' nameserver updates implemented by ifup/ifdown. If resolvconf is discarded it will work fine, just need added logic in the postrm script in the dnscache ipk to recognize resolvconf's absence and restore a basic /etc/resolv.conf instead of trying to restore the symlink. BTW: dnscache vs dnsmasq. I'm far more familiar with dnscache, so I'd lean toward it for that reason, but additionally dnsmasq incorporates a dhcp server - seems a waste for a more-or-less default setup. If dhcp server on the Freerunner is actually desired, it would likely be accompanying support for use of the Freerunner as a gateway router, so IMHO dhcp-server can be dealt with in that specific context. (until DJ Bernstein recently recanted the license on dnscache/djbdns it wasn't an option, but now distributing binaries is permitted) Comments? Suggestions? Flames? I've been discussing this with a mate who showed some interest in the dillema. Every time we thought we had something there was a small gotcha, primarily that the requirement for the dns/metric change stems from the aquisition of a dhcp lease and in turn the addition of new routing and dns info. As the aquisition can occur outside of linkstate, meaning the link can be active but no dhcp client associated, actioning based on interface status didn't seem valid, or at least a little premature or a little too assuming. So to us, the primary flag for action was the aquisition of a lease. Seeing as we are generally dealing with on the fly network association we didn't bother taking into account static assignment. We also figured that the general rule of thumb for metric would be: 1 - wired 2 - wireless 3 - vpn/tap/tun Which should be configurable anyway. Something easy to implement that can be expanded on is the idea. With that in mind and without altering udhcpc to populate an alternate resolv.conf (avoiding modifications to generic network tools completely), it seems the process should go something like: * obtain lease * read resolv.conf * create lookup (iface, ip, metric, searchdomain, dns1, dns2) * recreate resolv.conf from lookup and config file * modify routing table We avoided dealing with a cache purely because it will generally conflict with generic dhcpc function, we were trying to wrap rather than reconfigure. In saying that, a config file could determine whether 127.0.0.1 is written/rewritten and an alternate resolv.conf updated. So the caching daemon could be easily incorporated. Removal from the lookup should possibly be based on linkstate. As with any detailed process, the hardest part was trying to figure out just how to start ... where and how to watch for the change and the most cost effective way. The process is relatively simple. I don't suppose there is dhcp client dbus integration as standard? Being notified rather than polling would be good. Anyway ... that's where we got to. The overall benefit from our perspective was that we could use something like this on any *nix-like operating system that we have. Also the typical ifwatchd and wpa_supplicant delays would not have any effect. Outside of all that, I know netbsd has had some work done to the dhcp client to allow
Re: [2008.09] resolv.conf
On Wed, 15 Oct 2008 13:40:25 +1100, [EMAIL PROTECTED] wrote: On Fri, Sep 26, 2008 at 12:07:17AM -0400, Joel Newkirk wrote: [elided long post quote regarding dnscache and changes to resolvconf+/etc/resolv.conf+dhcp] I've been discussing this with a mate who showed some interest in the dillema. Every time we thought we had something there was a small gotcha, primarily that the requirement for the dns/metric change stems from the aquisition of a dhcp lease and in turn the addition of new routing and dns info. As the aquisition can occur outside of linkstate, meaning the link can be active but no dhcp client associated, actioning based on interface status didn't seem valid, or at least a little premature or a little too assuming. So to us, the primary flag for action was the aquisition of a lease. Seeing as we are generally dealing with on the fly network association we didn't bother taking into account static assignment. We also figured that the general rule of thumb for metric would be: 1 - wired 2 - wireless 3 - vpn/tap/tun Which should be configurable anyway. Something easy to implement that can be expanded on is the idea. With that in mind and without altering udhcpc to populate an alternate resolv.conf (avoiding modifications to generic network tools completely), it seems the process should go something like: * obtain lease * read resolv.conf * create lookup (iface, ip, metric, searchdomain, dns1, dns2) * recreate resolv.conf from lookup and config file * modify routing table We avoided dealing with a cache purely because it will generally conflict with generic dhcpc function, we were trying to wrap rather than reconfigure. In saying that, a config file could determine whether 127.0.0.1 is written/rewritten and an alternate resolv.conf updated. So the caching daemon could be easily incorporated. Removal from the lookup should possibly be based on linkstate. As with any detailed process, the hardest part was trying to figure out just how to start ... where and how to watch for the change and the most cost effective way. The process is relatively simple. I don't suppose there is dhcp client dbus integration as standard? Being notified rather than polling would be good. Anyway ... that's where we got to. The overall benefit from our perspective was that we could use something like this on any *nix-like operating system that we have. Also the typical ifwatchd and wpa_supplicant delays would not have any effect. Outside of all that, I know netbsd has had some work done to the dhcp client to allow multiple instances to communicate via a socket, so maybe something like this is actually being incorporated into the dhcp client code, which would make sense as it really is, all-in-all, a side effect of using dhcp in the first place. It would be nice to see something provided by ISC. I think I've rambled on long enough ... :) Sarton Interesting - I've been approaching it from the other end, trying to alter base configuration instead of adding a 'network manager'-like layer wrapping it all. When I look at the default behavior of the various interfaces, and various means of bringing them up/down, I see differing approaches where some use /etc/resolv.conf, some use resolvconf (the binary), some do their own thing, but none of them really cooperating. I feel if they're all brought in tune (all handling route and DNS additions/removals centrally, instead of each handling route DNS replacements as though they're king) that everything else becomes much simpler. I've been working on resolv.conf plus default routes lately, though most of the time I've been under Raster+FSO. (so frameworkd doing setup for GPRS, and requires it's own fixes to do what I want instead of within /etc/ppp) I've reached the conclusion that it will require changes to udhcpcd config (which currently does a blind replacement of /etc/resolv.conf) and ppp/ip-up.d/08setupdns (which currently creates /var/run/ppp/resolv.conf, then forces a symlink to it from /var/run/resolv.conf). /etc/resolv.conf is a symlink to /var/run/resolv.conf, and if udhcpcd works with it at /var/run/resolv.conf, (which might be better done via resolvconf bin instead, which works with /var/run/resolv.conf itself) then breaking that link is trivial, and the default behaviors would affect only that file, NOT /etc/resolv.conf which could be under new management, or a static 127.0.0.1 if dns caching is installed. And changing udhcpcd and ppp config is needed to address default route headaches as well. I currently have my Freerunner /almost/ working as I want, which is as follows: Local DNS cache with default upstream caches of opendns.org for unchanging simplicity (any static DNS would behave identically at this point in my setup), use Wifi if it's up for default route (metric 20), usbnet if wifi is down but usbnet is up (metric 30), and demand-dialed GPRS if usbnet is unavailable (metric
Re: [2008.09] resolv.conf
On Wednesday 15 October 2008 15:36:40 Joel Newkirk wrote: [...snip] Interesting - I've been approaching it from the other end, trying to alter base configuration instead of adding a 'network manager'-like layer wrapping it all. When I look at the default behavior of the various interfaces, and various means of bringing them up/down, I see differing approaches where some use /etc/resolv.conf, some use resolvconf (the binary), some do their own thing, but none of them really cooperating. I feel if they're all brought in tune (all handling route and DNS additions/removals centrally, instead of each handling route DNS replacements as though they're king) that everything else becomes much simpler. Same thought. The main reason for our approach was due to the varying systems we maintain. More often than not they are *BSD, well for me anyway. This approach should function regardless of the underlying system, so long as it uses, say, udhcpc. I've been working on resolv.conf plus default routes lately, though most of the time I've been under Raster+FSO. (so frameworkd doing setup for GPRS, and requires it's own fixes to do what I want instead of within /etc/ppp) I've reached the conclusion that it will require changes to udhcpcd config (which currently does a blind replacement of /etc/resolv.conf) and ppp/ip-up.d/08setupdns (which currently creates /var/run/ppp/resolv.conf, then forces a symlink to it from /var/run/resolv.conf). /etc/resolv.conf is a symlink to /var/run/resolv.conf, and if udhcpcd works with it at /var/run/resolv.conf, (which might be better done via resolvconf bin instead, which works with /var/run/resolv.conf itself) then breaking that link is trivial, and the default behaviors would affect only that file, NOT /etc/resolv.conf which could be under new management, or a static 127.0.0.1 if dns caching is installed. And changing udhcpcd and ppp config is needed to address default route headaches as well. Yep, which is why we thought making the required changes as an afterthought or delayed event at least, would mitigate the effect of any existing networking changes being made by the OS facilities. I really like the idea of a cache. I also like /etc/resolv.conf being a symlink. In our possible approach, a config file specifying primary and secondary resolv.conf files, with a 127.0.0.1 + opendns override for the primary and the secondary containing whatever was last pushed to /etc/resolv.conf would address static and dynamic dns assignment. Metric per interface would be a config file option aswell. I currently have my Freerunner /almost/ working as I want, which is as follows: Local DNS cache with default upstream caches of opendns.org for unchanging simplicity (any static DNS would behave identically at this point in my setup), use Wifi if it's up for default route (metric 20), usbnet if wifi is down but usbnet is up (metric 30), and demand-dialed GPRS if usbnet is unavailable (metric 40). As I've got it, it should handle DNS changes properly, (subsystems are altering /var/run/resolv.conf) but that's untested since I'm running local caching. Once that's working fully automatically (getting close) I will check non-cached DNS and probably rewrite it to utilize resolvconf bin, then write the support script to tell dnscache to use dhcp-provided DNS servers as upstream caches, and finally look at VPN and a few more exotic possibilities. (I've got two USB ethernet adapters on a hub here that I've tested as a packet-sniffing bridge on the Freerunner, for example ;) Nice ... and now I can grasp why you might be utilising multiple routing tables :) I can definitely see your work filling the gap that currently exists, as much as I don't like the look of resolvconf, I'm all for something that works and this fits within the existing framework. I figured the rule for priority should be VPN first, followed by wifi, then any USB networking device (if in host mode) or usbnet to host (if in gadget mode), and finally (if desired) GPRS. For myself, I have the old T-Mobile unlimited (really, so far) internet3 'VPN' service, so my only concern with GPRS is avoiding its slowness when something faster is available - I realize other people who use GPRS may want to be more in control of it than I. (I've made a desktop icon to enable/disable it, which currently starts up the interface and leaves it in demand-dial waitstate, I'll eventually test it in direct up/down control) Well I guess metric is a personal matter :) ... and I guess that if the VPN is being added as a default route then the possibility of wanting it to be used is highly likely. If it's a dedicated route then metric is moot. OK, so mine should have gone VPN - Wired - Wireless - GPRS. Assuming usb can outperform wireless that is. My goal is to achieve everything without requiring a network manager of any significance. After that I'd like to have a widget in the top
Re: [2008.09] resolv.conf
Joel Newkirk wrote: On Thu, 25 Sep 2008 11:21:08 +1000, Sarton O'Brien [EMAIL PROTECTED] wrote: On Thursday 25 September 2008 10:32:00 Joel Newkirk wrote: On Thu, 25 Sep 2008 02:01:24 +0300, Flyin_bbb8 [EMAIL PROTECTED] wrote: In 2008.8 resolvconf didn't populate it with the nameserver supplied by dhcp when the wifi interface was brought up. I don't know if this is still the case in 2008.9. hmm actually it always filled it in for me from DHCP when connectin to wifi using ifdown eth0 ifup eth0 both in 2008.8 and in 2008.9 Both correct, actually, as it DOES fill it in from DHCP (if used) connecting wifi with 'ifup eth0', but IIRC resolvconf isn't used to do it, it just overwrites resolv.conf. The idea behind resolvconf (the bin) is that IT manages changes to the resolv.conf file, doing things like removing eth0-related DNS nameservers when eth0 goes down, going back to usb0-related nameservers automatically. ifup should feed DNS info to resolvconf and let it manage. Right now, I think DNS and default route changes when interfaces change up/down need some attention from the 'just-works' dept. I still don't quite understand this confusion. udhcpc modifies /var/run/resolv.conf, as do I when needed. Any continually changing value/file should reside in volatile, in my opinion. /etc/resolv.conf has, for as long as I've been playing, symlinked to /var/run/resolv.conf. Except for the backend stuff not agreeing on this location, I have no issues, so long as udhcpc is used and an 'ip r d default' is issued prior to invocation. If the plan is that these values will be written to the filesystem, I'd say I'll be modifying mine to the contrary. Sarton The program resolvconf is intended to work as follows: When an interface comes up, resolvconf should be called to -a add new nameserver(s) associated with the network connection on that interface. When an interface goes down resolvconf should get a -d delete nameserver(s) for the specified interface. The program resolvconf itself is supposed to make any/all changes to resolv.conf (wherever the actual file resides - the debian standard location is /etc/resolvconf/run/resolv.conf, actually) NOT the script or subsystem or network manager or whatever handles the up/down. Based on its configuration (notably /etc/resolvconf/interface-order - debian location) it uses whatever nameserver settings are needed, but remembers the others. So for example, usb0 coming up stuffs 192.168.0.201 in as nameserver, but does it by executing resolvconf. Then eth0 comes up and tells resolvconf its nameserver(s) - resolvconf decides which to use, likely eth0 will be set a higher priority than usb0. Later eth0 goes down. Now resolvconf automatically restores the nameserver settings from usb0. (presuming it is still up) If usb0 went down already, but ppp0 over gprs came up in the meantime, nameservers for ppp0 go live. OK, so this resolvconf thing is inherited from debian and has been implented obviously without much thought to general functionality. I say this in the context of normal (non-debian) services functioning as expected when not massaged by resolvconf. I understand the intention, don't get me wrong, and it is indeed a nice idea. But when all people want to do is gain connectivity with their chosen method, this resolvconf facility seems to be more of a hinderence and is unlike a lot of linux distros. Shouldn't this, at least currently, be optional? If something as fundamental as _core_ network services are going to be overlayed with something like this, it should really be working first, rather thaan people editing files left and right without understanding why. This is just what I think, take it as you will. In the end I am the master of my device ;) I've actually just done a bit of research before posting and it _appears_ this was implemented with good intention, just without the required software support. It seems to be very much of debian origins and a little bit of overkill for managing the facilities on the freerunner, but that's just my opinion. If I was currently using usb0, eth0 and a tun/tap interface simultaneously, that all flapped or had dynamic dns requirments (sounds more like a router) it would make sense to me. I imagine the end goal is to consolidate gprs and wifi dns but currently no resolvconf is going to teach people how to get that going. When om2008 is mature and these kind of connections can be made easily, without much knowledge, this utility would be a godsend ... as it stands you currently need basic linux knowledge to understand why things don't work and then you need to know how to manipulate resolvconf. Maybe it's my BSD upbringing, thanks for the clarification however. :) Sarton ___ Openmoko
Re: [2008.09] resolv.conf
If resolvconf isn't doing what it should, then it is our responsibility as users to file enough bugs with enough pertinent info until it is corrected. If you have a clear use case that fails, open a ticket. I don't care which kind of connection management system is inside openmoko, as long as it works and is flexible to accommodate any networking scenario we may come up with (which pretty much narrows it down to resolvconf IMHO). Let's make it work, ok? File the necessary bugs. Citando [EMAIL PROTECTED]: OK, so this resolvconf thing is inherited from debian and has been implented obviously without much thought to general functionality. I say this in the context of normal (non-debian) services functioning as expected when not massaged by resolvconf. I understand the intention, don't get me wrong, and it is indeed a nice idea. But when all people want to do is gain connectivity with their chosen method, this resolvconf facility seems to be more of a hinderence and is unlike a lot of linux distros. Shouldn't this, at least currently, be optional? If something as fundamental as _core_ network services are going to be overlayed with something like this, it should really be working first, rather thaan people editing files left and right without understanding why. This is just what I think, take it as you will. In the end I am the master of my device ;) I've actually just done a bit of research before posting and it _appears_ this was implemented with good intention, just without the required software support. It seems to be very much of debian origins and a little bit of overkill for managing the facilities on the freerunner, but that's just my opinion. If I was currently using usb0, eth0 and a tun/tap interface simultaneously, that all flapped or had dynamic dns requirments (sounds more like a router) it would make sense to me. I imagine the end goal is to consolidate gprs and wifi dns but currently no resolvconf is going to teach people how to get that going. When om2008 is mature and these kind of connections can be made easily, without much knowledge, this utility would be a godsend ... as it stands you currently need basic linux knowledge to understand why things don't work and then you need to know how to manipulate resolvconf. Maybe it's my BSD upbringing, thanks for the clarification however. :) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.09] resolv.conf
On Thu, 25 Sep 2008 18:45:32 +1000, [EMAIL PROTECTED] wrote: Joel Newkirk wrote: So for example, usb0 coming up stuffs 192.168.0.201 in as nameserver, but does it by executing resolvconf. Then eth0 comes up and tells resolvconf its nameserver(s) - resolvconf decides which to use, likely eth0 will be set a higher priority than usb0. Later eth0 goes down. Now resolvconf automatically restores the nameserver settings from usb0. (presuming it is still up) If usb0 went down already, but ppp0 over gprs came up in the meantime, nameservers for ppp0 go live. OK, so this resolvconf thing is inherited from debian and has been implented obviously without much thought to general functionality. I say this in the context of normal (non-debian) services functioning as expected when not massaged by resolvconf. I understand the intention, don't get me wrong, and it is indeed a nice idea. But when all people want to do is gain connectivity with their chosen method, this resolvconf facility seems to be more of a hinderence and is unlike a lot of linux distros. Shouldn't this, at least currently, be optional? If something as fundamental as _core_ network services are going to be overlayed with something like this, it should really be working first, rather thaan people editing files left and right without understanding why. This is just what I think, take it as you will. In the end I am the master of my device ;) I've actually just done a bit of research before posting and it _appears_ this was implemented with good intention, just without the required software support. It seems to be very much of debian origins and a little bit of overkill for managing the facilities on the freerunner, but that's just my opinion. If I was currently using usb0, eth0 and a tun/tap interface simultaneously, that all flapped or had dynamic dns requirments (sounds more like a router) it would make sense to me. I imagine the end goal is to consolidate gprs and wifi dns but currently no resolvconf is going to teach people how to get that going. When om2008 is mature and these kind of connections can be made easily, without much knowledge, this utility would be a godsend ... as it stands you currently need basic linux knowledge to understand why things don't work and then you need to know how to manipulate resolvconf. Maybe it's my BSD upbringing, thanks for the clarification however. :) Sarton IMHO the simplest effective solution should always head the list. In this instance I think that is to run dnscache or a similar service on the Freerunner itself, pointing somewhere like opendns.com's servers. (ok, maybe not simplest, though the local cache has various benefits. Pointing resolv.conf at opendns.com or wherever is simplest, assuming no network connection actually requires use of it's own DNS - corporate intranet wifi might, to reach 'private' records for example) If needed, newly-connected network connections that come equipped with new DNS servers (IE, wifi with DHCP) can insert/remove their DNS servers from the list used by dnscache, while resolv.conf permanently points at 127.0.0.1. This is what I've had running for a few weeks, but I hadn't yet attempted to get ifup/ifdown manipulating /etc/dnscache/root/servers/@. (which will essentially require a resolvconf-like manager ;) j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.09] resolv.conf
On Thursday 25 September 2008 22:06:29 Joel Newkirk wrote: On Thu, 25 Sep 2008 18:45:32 +1000, [EMAIL PROTECTED] wrote: Joel Newkirk wrote: So for example, usb0 coming up stuffs 192.168.0.201 in as nameserver, but does it by executing resolvconf. Then eth0 comes up and tells resolvconf its nameserver(s) - resolvconf decides which to use, likely eth0 will be set a higher priority than usb0. Later eth0 goes down. Now resolvconf automatically restores the nameserver settings from usb0. (presuming it is still up) If usb0 went down already, but ppp0 over gprs came up in the meantime, nameservers for ppp0 go live. OK, so this resolvconf thing is inherited from debian and has been implented obviously without much thought to general functionality. I say this in the context of normal (non-debian) services functioning as expected when not massaged by resolvconf. I understand the intention, don't get me wrong, and it is indeed a nice idea. But when all people want to do is gain connectivity with their chosen method, this resolvconf facility seems to be more of a hinderence and is unlike a lot of linux distros. Shouldn't this, at least currently, be optional? If something as fundamental as _core_ network services are going to be overlayed with something like this, it should really be working first, rather thaan people editing files left and right without understanding why. This is just what I think, take it as you will. In the end I am the master of my device ;) I've actually just done a bit of research before posting and it _appears_ this was implemented with good intention, just without the required software support. It seems to be very much of debian origins and a little bit of overkill for managing the facilities on the freerunner, but that's just my opinion. If I was currently using usb0, eth0 and a tun/tap interface simultaneously, that all flapped or had dynamic dns requirments (sounds more like a router) it would make sense to me. I imagine the end goal is to consolidate gprs and wifi dns but currently no resolvconf is going to teach people how to get that going. When om2008 is mature and these kind of connections can be made easily, without much knowledge, this utility would be a godsend ... as it stands you currently need basic linux knowledge to understand why things don't work and then you need to know how to manipulate resolvconf. Maybe it's my BSD upbringing, thanks for the clarification however. :) Sarton IMHO the simplest effective solution should always head the list. In this instance I think that is to run dnscache or a similar service on the Freerunner itself, pointing somewhere like opendns.com's servers. (ok, maybe not simplest, though the local cache has various benefits. Pointing resolv.conf at opendns.com or wherever is simplest, assuming no network connection actually requires use of it's own DNS - corporate intranet wifi might, to reach 'private' records for example) If needed, newly-connected network connections that come equipped with new DNS servers (IE, wifi with DHCP) can insert/remove their DNS servers from the list used by dnscache, while resolv.conf permanently points at 127.0.0.1. This is what I've had running for a few weeks, but I hadn't yet attempted to get ifup/ifdown manipulating /etc/dnscache/root/servers/@. (which will essentially require a resolvconf-like manager ;) That all makes sense. Typically I've seen dnsmasq fulfill this function. My point was merely that the current solution is added complexity to a rather neat base filesystem. If this was a package I wouldn't have the same gripe. Using dnsmasq, pointing at localhost, including opendns and using helper scripts to insert and remove dns servers sounds less complex and less confusing, with the added benefit of caching and less modification to the base system. It also means not having to incorporate something that doesn't appear to have had the modifications needed _to_ incorporate it. I don't like the requirement that all the software modifying network settings needs to be resolvconf aware. If we had a generic central solution people could use whatever they want and not incur breakage ... Worst case, something like a resolv.conf pipe to a daemon that updates resolv.conf.auto for dnsmasq would be better. Something central! Looking at the way resolvconf works, it almost seems like we should be patching libc :S ...so we have a generic interface. Anyway ... I can feel fork coming on :P Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.09] resolv.conf
On Thursday 25 September 2008 21:50:51 Matthias Apitz wrote: How is that exactly supposed to work for the usb0 interface? this always has the static IP 192.168.0.202 (coded in /etc/network/interfaces); I've setup in my FreeBSD laptop a DHCP server to offer the IP addr of DNS with this config This is the problem. Nothing useful is in place to facilitate the added bloat (no offense intended). My current argument is that if something is being done, for something as necessary as networking, is should be either simple ... or working. Complex and non-functioning seems to be the alternative :S Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.09] resolv.conf
On Thursday 25 September 2008 21:22:54 [EMAIL PROTECTED] wrote: If resolvconf isn't doing what it should, then it is our responsibility as users to file enough bugs with enough pertinent info until it is corrected. If this were a package I'd agree. Sometime it's up to the users to show some concern. I don't think I want resolvconf working. Despite not being optimised for embedded, it's requirements seem to outweigh it's benefit in my view. To me it seems someone decided to not reinvent the wheel, which is fair enough in most cases. The freerunner currently has square wheels, so I don't see why a custom solution couldn't be developed. There's plenty of time after all, before we actually need a seemless facility like this. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.09] resolv.conf
On Thursday 25 September 2008 21:22:54 [EMAIL PROTECTED] wrote: I don't care which kind of connection management system is inside openmoko, as long as it works and is flexible to accommodate any networking scenario we may come up with (which pretty much narrows it down to resolvconf IMHO). You use debian don't you :P I hadn't even heard of resolvconf until I had no nameservers available :) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.09] resolv.conf
On Fri, 26 Sep 2008 10:24:18 +1000, Sarton O'Brien [EMAIL PROTECTED] wrote: On Thursday 25 September 2008 22:06:29 Joel Newkirk wrote: IMHO the simplest effective solution should always head the list. In this instance I think that is to run dnscache or a similar service on the Freerunner itself, pointing somewhere like opendns.com's servers. (ok, maybe not simplest, though the local cache has various benefits. Pointing resolv.conf at opendns.com or wherever is simplest, assuming no network connection actually requires use of it's own DNS - corporate intranet wifi might, to reach 'private' records for example) If needed, newly-connected network connections that come equipped with new DNS servers (IE, wifi with DHCP) can insert/remove their DNS servers from the list used by dnscache, while resolv.conf permanently points at 127.0.0.1. This is what I've had running for a few weeks, but I hadn't yet attempted to get ifup/ifdown manipulating /etc/dnscache/root/servers/@. (which will essentially require a resolvconf-like manager ;) That all makes sense. Typically I've seen dnsmasq fulfill this function. My point was merely that the current solution is added complexity to a rather neat base filesystem. If this was a package I wouldn't have the same gripe. Using dnsmasq, pointing at localhost, including opendns and using helper scripts to insert and remove dns servers sounds less complex and less confusing, with the added benefit of caching and less modification to the base system. It also means not having to incorporate something that doesn't appear to have had the modifications needed _to_ incorporate it. I don't like the requirement that all the software modifying network settings needs to be resolvconf aware. If we had a generic central solution people could use whatever they want and not incur breakage ... Worst case, something like a resolv.conf pipe to a daemon that updates resolv.conf.auto for dnsmasq would be better. Something central! Looking at the way resolvconf works, it almost seems like we should be patching libc :S ...so we have a generic interface. Anyway ... I can feel fork coming on :P Sarton hmmm. I've been thinking on the situation, and have a proposal, as yet incomplete but IMHO promising - and it's nowhere near as drastic as forking. I see basically two approaches: One is an overarching network manager directly handling all the details, the other (my preferred) is to let DNS take care of itself independently, and address the multiple-default-route issue - probably with route metrics, though more advanced routing setup (requiring full ip binary instead of busybox) with multiple routing tables and rules is probably the better solution there. It starts with dnscache. Postinst in dnscache ipk removes the symlink /etc/resolv.conf and replaces it with a real file, pointing always at nameserver 127.0.0.1. (what I had going already) On my Ubuntu desktop, there's a possibly-useful file: /etc/resolvconf/update.d/dnscache - its purpose is to alter /etc/dsncachce/root/servers/@ (the list of servers dnscache is to query for anything uncached) automatically whenever resolvconf is triggered. This would be the way to hook in if resolvconf were working on the Freerunner as intended, which currently appears not to be the case. Alternately (or additionally), /etc/network/if-up.d/ and /etc/network/if-post-down.d/ allow us to perform the same changes automatically whenever an interface is brought up or taken down using ifup and ifdown. I've altered my /etc/init.d/dnscache script to include a 'refresh' feature, that first wipes /etc/dnscache/root/servers/@, then stuffs in any non-localhost nameservers presently listed in /etc/resolv.conf, then adds any nameservers found in /etc/resolvconf/run/resolv.conf, finishing up with any IPs listed in /etc/default/dnscache (default contents opendns.com IPs), wipes /etc/resolv.conf back to localhost only, then finally kicks dnscache so it uses the new servers/@ contents. Once my freerunner is back in front of me I'll test the init script changes - if it works as I hope, I can add a script to the ipk in each of /etc/network/if-up.d/ and /etc/network/if-post-down.d/ that simply call /etc/init.d/dnscache refresh, and/or in /etc/resolvconf/update.d/. That makes the whole thing just work as a single ipk installing dnscache and all the support to override resolvconf AND 'manual' nameserver updates implemented by ifup/ifdown. If resolvconf is discarded it will work fine, just need added logic in the postrm script in the dnscache ipk to recognize resolvconf's absence and restore a basic /etc/resolv.conf instead of trying to restore the symlink. BTW: dnscache vs dnsmasq. I'm far more familiar with dnscache, so I'd lean toward it for that reason, but additionally dnsmasq incorporates a dhcp server - seems a waste for a more-or-less default setup. If dhcp server on the Freerunner is actually desired, it
[2008.09] resolv.conf
Simple Question Is /etc/resolv.conf still an issue with 2008.09? As far as I'm concerned it is a problem according to a simple Ping, but perhaps I'm wrong with that. Surely to God this should be fix and in the 2008.09 release. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.09] resolv.conf
El día Wednesday, September 24, 2008 a las 03:58:01PM +0100, Arigead escribió: Simple Question Is /etc/resolv.conf still an issue with 2008.09? As far as I'm concerned it is a problem according to a simple Ping, but perhaps I'm wrong with that. Surely to God this should be fix and in the 2008.09 release. I run Om2008.09; I don't know what exactly the issue with the /etc/resolv.conf should be, in fact it is just empty; I don't care because I need diffrent lines in it when I'm in my home office or at work and I just fill in what I need by SSH'ing to the Gadget; what should be there per default? matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e [EMAIL PROTECTED] - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ A computer is like an air conditioner, it stops working when you open Windows Una computadora es como aire acondicionado, deja de funcionar si abres Windows ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.09] resolv.conf
On Wednesday 24 September 2008, [EMAIL PROTECTED] wrote: Nothing should be in there by default!!! In openmoko, the file /etc/resolv.conf is managed dynamically by the program resolvconf. Editing it by hand is a hack (that must only be used when the DHCP server does not provide a nameserver IP, or when the interface is configured by hand). See http://lists.debian.org/debian-devel/2003/07/msg00438.html I know resolvconf is supposed to manage it, but in 2008.8 it didn't. By default usb0 is up, so resolvconf should have populates it with a suitable resolver, but instead it is empty. In 2008.8 resolvconf didn't populate it with the nameserver supplied by dhcp when the wifi interface was brought up. I don't know if this is still the case in 2008.9. Citando Matthias Apitz [EMAIL PROTECTED]: El día Wednesday, September 24, 2008 a las 03:58:01PM +0100, Arigead escribió: Is /etc/resolv.conf still an issue with 2008.09? what should be there per default? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.09] resolv.conf
In 2008.8 resolvconf didn't populate it with the nameserver supplied by dhcp when the wifi interface was brought up. I don't know if this is still the case in 2008.9. hmm actually it always filled it in for me from DHCP when connectin to wifi using ifdown eth0 ifup eth0 both in 2008.8 and in 2008.9 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.09] resolv.conf
On Thu, 25 Sep 2008 02:01:24 +0300, Flyin_bbb8 [EMAIL PROTECTED] wrote: In 2008.8 resolvconf didn't populate it with the nameserver supplied by dhcp when the wifi interface was brought up. I don't know if this is still the case in 2008.9. hmm actually it always filled it in for me from DHCP when connectin to wifi using ifdown eth0 ifup eth0 both in 2008.8 and in 2008.9 Both correct, actually, as it DOES fill it in from DHCP (if used) connecting wifi with 'ifup eth0', but IIRC resolvconf isn't used to do it, it just overwrites resolv.conf. The idea behind resolvconf (the bin) is that IT manages changes to the resolv.conf file, doing things like removing eth0-related DNS nameservers when eth0 goes down, going back to usb0-related nameservers automatically. ifup should feed DNS info to resolvconf and let it manage. Right now, I think DNS and default route changes when interfaces change up/down need some attention from the 'just-works' dept. j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.09] resolv.conf
On Thursday 25 September 2008 10:32:00 Joel Newkirk wrote: On Thu, 25 Sep 2008 02:01:24 +0300, Flyin_bbb8 [EMAIL PROTECTED] wrote: In 2008.8 resolvconf didn't populate it with the nameserver supplied by dhcp when the wifi interface was brought up. I don't know if this is still the case in 2008.9. hmm actually it always filled it in for me from DHCP when connectin to wifi using ifdown eth0 ifup eth0 both in 2008.8 and in 2008.9 Both correct, actually, as it DOES fill it in from DHCP (if used) connecting wifi with 'ifup eth0', but IIRC resolvconf isn't used to do it, it just overwrites resolv.conf. The idea behind resolvconf (the bin) is that IT manages changes to the resolv.conf file, doing things like removing eth0-related DNS nameservers when eth0 goes down, going back to usb0-related nameservers automatically. ifup should feed DNS info to resolvconf and let it manage. Right now, I think DNS and default route changes when interfaces change up/down need some attention from the 'just-works' dept. I still don't quite understand this confusion. udhcpc modifies /var/run/resolv.conf, as do I when needed. Any continually changing value/file should reside in volatile, in my opinion. /etc/resolv.conf has, for as long as I've been playing, symlinked to /var/run/resolv.conf. Except for the backend stuff not agreeing on this location, I have no issues, so long as udhcpc is used and an 'ip r d default' is issued prior to invocation. If the plan is that these values will be written to the filesystem, I'd say I'll be modifying mine to the contrary. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.09] resolv.conf
On Thu, 25 Sep 2008 11:21:08 +1000, Sarton O'Brien [EMAIL PROTECTED] wrote: On Thursday 25 September 2008 10:32:00 Joel Newkirk wrote: On Thu, 25 Sep 2008 02:01:24 +0300, Flyin_bbb8 [EMAIL PROTECTED] wrote: In 2008.8 resolvconf didn't populate it with the nameserver supplied by dhcp when the wifi interface was brought up. I don't know if this is still the case in 2008.9. hmm actually it always filled it in for me from DHCP when connectin to wifi using ifdown eth0 ifup eth0 both in 2008.8 and in 2008.9 Both correct, actually, as it DOES fill it in from DHCP (if used) connecting wifi with 'ifup eth0', but IIRC resolvconf isn't used to do it, it just overwrites resolv.conf. The idea behind resolvconf (the bin) is that IT manages changes to the resolv.conf file, doing things like removing eth0-related DNS nameservers when eth0 goes down, going back to usb0-related nameservers automatically. ifup should feed DNS info to resolvconf and let it manage. Right now, I think DNS and default route changes when interfaces change up/down need some attention from the 'just-works' dept. I still don't quite understand this confusion. udhcpc modifies /var/run/resolv.conf, as do I when needed. Any continually changing value/file should reside in volatile, in my opinion. /etc/resolv.conf has, for as long as I've been playing, symlinked to /var/run/resolv.conf. Except for the backend stuff not agreeing on this location, I have no issues, so long as udhcpc is used and an 'ip r d default' is issued prior to invocation. If the plan is that these values will be written to the filesystem, I'd say I'll be modifying mine to the contrary. Sarton The program resolvconf is intended to work as follows: When an interface comes up, resolvconf should be called to -a add new nameserver(s) associated with the network connection on that interface. When an interface goes down resolvconf should get a -d delete nameserver(s) for the specified interface. The program resolvconf itself is supposed to make any/all changes to resolv.conf (wherever the actual file resides - the debian standard location is /etc/resolvconf/run/resolv.conf, actually) NOT the script or subsystem or network manager or whatever handles the up/down. Based on its configuration (notably /etc/resolvconf/interface-order - debian location) it uses whatever nameserver settings are needed, but remembers the others. So for example, usb0 coming up stuffs 192.168.0.201 in as nameserver, but does it by executing resolvconf. Then eth0 comes up and tells resolvconf its nameserver(s) - resolvconf decides which to use, likely eth0 will be set a higher priority than usb0. Later eth0 goes down. Now resolvconf automatically restores the nameserver settings from usb0. (presuming it is still up) If usb0 went down already, but ppp0 over gprs came up in the meantime, nameservers for ppp0 go live. j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
