On Wed, 2011-01-05 at 15:59 -0800, Russ Allbery wrote: > > Aha! I was working under the incorrect assumption that dnsmasq was all > that was needed after boot to enable networking, but actually > NetworkManager is involved in getting basic connectivity. > > Yes, I don't think there's anything that dnsmasq can do, nor do I think > there's anything that OpenAFS can do in this case. If one is using > NetworkManager, network services just won't be available at boot, and > nothing one can put into the init script will help. They won't be > available until after NetworkManager runs and authenticates, which often > has to wait until the user logs in so that NetworkManager has access to > wireless authentication credentials.
I believe the wired network is up at this point but the wireless is not. > > > Could AFS be fixed to retry DNS queries after a longish timeout either > > when there's no reply or when a REFUSED rcode is received? The behaviour > > of ntpd in the log above shows fairly well how to get it right. > > Starting AFS when there's no network available should generally work when > using dynroot provided that one doesn't attempt to access any files in AFS > until the network is available, but one will get timeouts if one tries to > access AFS before the network is present. > > > It's not clear to me that there exists any sane change in the behaviour > > of dnsmasq that would help things. > > Agreed. I think the bug against dnsmasq can be closed. > > Brent, I'm confused by the bug history here: what happens when AFS doesn't > start? Your log messages in the original bug report only show a log > message that isn't printed, so far as I know, by the init script that > comes with the openafs-client package. What sort of behavior do you see > when AFS is started prior to the network being available? > I have removed the bit in the startup script that was checking for intranet connectivity and am just letting AFS start regardless of network or intranet connectivity. I checked to make sure I am using dynroot and I am. I'm not sure of the history of why the start script was checking for intranet connectivity. Like you said, as long as I don't try to access anything in /afs when not connected, it shouldn't cause any problems always starting AFS. Brent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
