 |  |
No, a QuickDNS pretty much can't solve this - we'd have to do some
Re: Applescripts Question
From: Men & Mice Support
Date: Monday, January 27, 2003
Time: 10:45:09 am
truly odd and annoying stuff to work around this.
Basically, QuickDNS for Mac OS X manages the standard BIND name
server, named. named looks for its configuration file in a particular
location, /etc/named.conf. The Mac OS X 10.2 upgrader moves this file
to /etc/named.conf.applesaved, and then creates a new version at
/etc/named.conf.
This causes all kinds of problems for QuickDNS.
Your best bet is to install the Mac OS X 10.2 update, then
immediately follow the "simple version" instructions in that
knowledge base article. It's really very easy. The complications
arise if you try to do anything else before fixing the issue - pretty
much anything you might be tempted to do will either do nothing or
make the problem much worse.
____________________________________________________________________
Chris Buxton Men & Mice
support@menandmice.com Making DNS Easy
At 9:04 AM -0800 1/27/03, Mark Duling wrote:
>Will the next release of QDNS solve the upgrade problem? I am still
>at Mac 10.1.5 and QDNS 3.5. I know this is partly (or fully) an
>Apple issue but I wondered if waiting for a next release of QDNS
>might be a smoother upgrade. Or will I have to do what the
>knowledge base article says when upgrading from a working version on
>10.1.5 in any case?
>
>Mark
>
>>It sounds like you installed the Mac OS X 10.2 update over an
>>existing, working installation of QuickDNS on Mac OS X 10.1.x. If
>>this is the case, please read this knowledge base article:
>>
>><http://kbase.menandmice.com/view.html?rec=30>
>>____________________________________________________________________
>>Chris Buxton Men & Mice
>>support@menandmice.com Making DNS Easy
>>
>>At 8:24 PM -0500 1/25/03, Dan Kirsch wrote:
>>>I'm running QDNS 3.5 on both my primary and secondary server (Mac OS X
>>>10.2 and 10.1). My primary server has decided to get fussy during an
>>>upgrade of OSX and the bottom line is that for some reason it looks like
>>>what shows up for zones under the primary is garbage (all the zones are
>>>missing, can't remember what is there but it is garbage). So I was
>>>trying to use the Applescripts to either import from the good secondary
>>>slave server or export to the bad primary server. Either way didn't
>>>seem to work for some reason, although it seemed like it was working
>>>when I tried to import from the good secondary server data while working
>>>at the bad primary server -- but the zones didn't update.
>>>
>>>Can anyone please give me a sanity check on what procedure I should be
>>>using so that I at least know that I'm trying the right Applescript.
>>>Should I best be trying to import from the secondary to the primary, or
>>>should I be trying to export from the secondary to the primary? And
>>>clues as to what I might have done wrong would be appreciated. Thanks!
>>>
>>>
>>>
>>>Dan Kirsch
>>>Hudson Associates
Messages In This Thread:
Return to Digital Point Solutions' Home Page