On opensuse 11.2 x86 I’ve installed and configured bind using Yast in pretty much the same way as I had in 11.0 (like the way 11.2 creates reverse records automatically for a configured domain btw)
Dig returns pretty much the info I’d expect, thought that was it done, nice and easy, but … machine had no internet connection, played around a bit and this is basically the situation:
If I boot the machine with bind set to autostart, no internet, even if I then stop bind and do service network restart
If I boot the machine without bind autostarting, then start bind with /etc/init.d/named start, I have internet, everything digs ok, and other machines on the lan are able to use it for their dns just fine
Any ideas why bind autostarting would ‘break’ the net connection but manually starting it doesn’t?
Wow … lot of views for no replies … my talent for coming up with odd ones seems to know no bounds
Fooled around a bit and I’ve come to the conclusion it’s some kind of kde issue
Tried a couple of different ways to start named, including adding /etc/init.d/named start to /etc/init.d/boot.local, and setting it to start in runlevel 3 only (and not in runlevel 5) in Yast/System/Services
Every way I’ve tried starting named only works correctly if I boot into runlevel 3, if I have it boot straight into kde (runlevel 5), depending on how I’m starting named, one of the following happens:
Either the machine I’m running named on has no internet, or other machines on the lan can’t use it for dns
Why I can start it with /etc/init.d/named start once I’m in kde with no problems, but it won’t run as a service if I’m booting into kde I have no idea … Doesn’t running it as a service in Yast actually use the same command?
Figuring out why it does that needs someone more knowledgeable than me I’ve decided, I’ve only had it booting into kde for convenience of setting things up as it’s a new install
In the long haul it’ll be booting to a console login anyway, and as it seems to be auto-starting named ok without any unwanted side-effects that way it shouldn’t be a problem
Darned annoying when you’ve something like that happening and no idea why though!
I wasn’t criticising the speed of responses mate, just the fact there were so many views with none of the viewers giving any response kinda supports my saying it’s a bit of an odd one
Meaning no obvious solutions and/or possibilities to try, when there are any with that many views you’re likely to get at least one ‘have you tried …’ type response
Here’s a curious thing
I thought it worth trying booting straight into xcfe with bind auto-starting … and it all worked fine, so I thought ok, let’s try kde again
And it now works with kde too! Works in all scenarios/runlevels now
God only knows why booting into xcfe apppears to have solved the kde problem … perhaps the lil rodent on the splash screen scared away the gremlin
I’m gonna file this one under ‘don’t worry about why it worked, just be happy that it did’
Thanks for the reply/info mate, read the threads with interest, the segfault one particularly, it never crossed my mind that it may have been an apparmor issue
However I’m not sure that was it in my case as it fixed itself after booting into xcfe as I said in my last post (there weren’t any bind errors in the logs btw, I’d already checked for that)
Why the boot into xcfe fixed it I have no idea, would booting into a different desktop environment even have an effect on apparmor in some way? Was it even apparmor causing my issue in the first place?
Again no idea, don’t know much about apparmor because I’ve never had cause to fool round with it
