0

We have a Mac OS X 10.5.8 Server running DNS (and a few other services).

When I connect to it (using Server Admin 10.5.3 [which comes from the Server Admin 10.5.7 tools]), and click to look at the DNS settings, all appears normal -- it shows many reverse entries and two top-level domains. However, when I select one of our domains and open the disclosure triangle, the list is empty! [There should be over a dozen entries, and the reverse entries do show up.] If I then tell it I want to add, say, an A Record to the domain, almost everything disappears -- and I am left with a list showing our two domains, one with a disclosure triangle underneath it showing a single entry, and one reverse entry to correspond to the new A record.

named appears to be working fine. DNS names resolve. It appears to simply be that Server Admin is having problems with the data on the computer. No one here would have manually created a DNS entry.

Now, while I think I've backed up the DNS (I backed up /var/named/, /etc/named.conf, and /etc/dns/, as mentioned here), I'm really not sure if just replacing the files would restore the DNS settings we have if things go south. I am contemplating going to settings and changing the log level from "Information" to "Debug", but 1) I am just a little concerned that it might write a bad configuration to the disk, and 2) I think it would only affect named and not Server Admin, and, so far as I can tell, named is not having a problem. (Nothing looks strange in /Library/Logs/named.log when I open it via Console/Terminal. Oddly, though, when I click on the 'log' button for DNS in Server Admin, I see no text at all, just a fully white window. When I look at one of our secondary DNS servers, I am able to see the log file through Server Admin.)

This entry appears in the system log when I run Server Admin on the server:

Jun 17 09:02:08 od1 Server Admin[3892]: Unexpected call to doMarkConfigurationAsDirty by 'DNS' plugin during updateConfigurationViewFromDescription

It seems to occur after I've looked at DNS, look at another service, and then click back on DNS.

Think that the most likely cause is a corrupt configuration file, I glanced through all the files that I backed up, and none of them is obviously gobbledygook.

Here are some oddities I find when running Server Admin from a remote computer to manage the DNS.

  1. When I click to see the log file for DNS, the server starts writing messages like these to its system.log:

    Jun 17 09:59:04 od1 kernel[0]: Limiting open port RST response from 252 to 250 packets per second
    Jun 17 09:59:06 od1 kernel[0]: Limiting open port RST response from 258 to 250 packets per second
    

This stops when I click on a different service.

  1. The inderterminate progress indicator (the spinning wheel that appears beside the "Revert" and "Save" buttons in the bottom-right corner of Server Admin) looks really strange. As far as I can tell, instead of just spinning and waiting, it is being told to start spinning repeatedly, resulting in a jerky animation.

  2. Here are some of the messages being logged on the computer running Server Admin:

At startup:

*** ERROR: -[GRAxes computeLayout]:1124 - plotRect height = 0.000000 <= 0.0 ***
*** ERROR: -[GRChartView computeLayout]:1194 - Layout for overlay axes (0x18758f50) failed. ***

(These messages don't concern me too much as they go away for a while if you delete ~/Library/Preferences/com.apple.ServerAdmin.plist).

At shutdown:

2010-06-17 10:02:17.202 Server Admin[7770:10b] *** -[GroupTextField windowDidResignKey:]: unrecognized selector sent to instance 0x16e12490

More concerning are these messages:

2010-06-17 09:59:47.269 Server Admin[7770:10b] Unexpected call to doMarkConfigurationAsDirty by 'DNS' plugin during updateConfigurationViewFromDescription
Server Admin(7770,0xb0453000) malloc: *** error for object 0x1c115390: double free
*** set a breakpoint in malloc_error_break to debug
2010-06-17 10:01:00.795 Server Admin[7770:10b] *** -[ServiceEntry sessionHost]: unrecognized selector sent to instance 0x2af500

Any thoughts on:

  • what the problem is
  • how I can troubleshoot it
  • or how to fix it?

If I do need to wipe out DNS and restart, is there a good way to do this?

3 Answers 3

1

My guess is that there's something in the zone file in a format slightly different from what Server Admin (well, technically servermgrd) expects -- I've seen it get confused by something as simple as the "wrong" number of spaces between fields.

To troubleshoot it, I'd suggest removing everything from the zone file (the one in /var/named/zones) below the SOA record, except for NS records (you said you have a backup, right?). It should look something like this:

 ;GUID=34FEA604-B204-A7D7-95A5-B6D812B46454

$TTL 10800
example.com. IN SOA server.example.com. admin.example.com (
    2010042600  ;Serial
    86400       ;Refresh
    3600        ;Retry
    604800      ;Expire
    345600      ;Negative caching TTL
 ) 

example.com. IN  NS server.example.com.

note: I'm not sure, but I think there has to be a blank line at the end of the file. If you need to preserve normal DNS service while troubleshooting, you can move the other records to the other zone file -- the one in /var/named -- where named will read them normally, but servermgrd won't look.

Anyway, with the zone file trimmed to a minimum, quit & relaunch Server Admin and see if it behaves normally (i.e. can you view the log, add entries to the zone, etc). If it works normally, try adding the records back into the /var/named/zones file again a bit at a time -- I suspect that one or more of them is slightly weird and if you leave it out (i.e. recreate it from Server Admin rather than adding to the zone file directly) you can probably get things back to normal.

2
  • Yes, you were correct. It all came down to a comment that Server Admin wrote to a file but could not read back. I worked late on Friday to fix it and have details what happened in another answer. Jun 21, 2010 at 15:42
  • I'm going to accept this as the answer in the general case, and invite people to look at the answer that worked in my specific instance. Jun 23, 2010 at 19:29
2

I discovered and fixed a similar problem on our MacOS X 10.5 server.

It turned out to be parentheses characters "(" and ")" in a text field in one of the DNS zone files. I used a text editor at the command line to remove the parentheses and now Server Admin is working fine again.

On 10.5, the zone files are located at /var/named/zones.

Use grep to scan the zone files for the ")" character:

sudo grep -R --include "*" \) .

Scroll through the output and look for anything unusual. (All the zone files will have an open and close parenthesis at the top; you're looking for a record in the file.) You may want to grep for the open parenthesis too if you don't find anything.

When you've located a suspect file, open it for editing:

sudo nano db.mydomain.zone.apple

Find the offending line and remove the parentheses character(s). Save and close. Re-launch Server Admin.

There may be other offending characters too, but in my case, it's always been the parentheses.

1
  • Good to know. That looks like it was my problem, too. Nov 14, 2011 at 18:56
0

On Friday, I decided I'd take down DNS and rebuild it. (Sigh).

The best instructions on starting over were ones I found here, although I found that I had to do a little more than was stated there.

First, I backed up DNS (as mentioned in the question at top).

I turned off DNS. (Well, I meant to. I turned it off a step or two later, but this is when I think it should be turned off.)

I edited /etc/dns/publicView.conf.apple to remove the names of all the zones we had created, while leaving untouched the ones that we did not create. Here is the file with a big comment in the middle where all the zones had been. (I didn't actually place a comment in the file; I just removed the entries).

acl "com.apple.ServerAdmin.DNS.public" {192.168.1.254;192.168.5.254;192.168.10.254;192.168.15.254;192.168.20.254;192.168.25.254;192.168.30.254;192.168.35.254;192.168.40.254;192.168.45.254;192.168.55.254;192.168.75.254;192.168.70.254;192.168.80.254;localnets;192.168.65.251;192.168.65.185;192.168.80.0;192.168.65.253;};

//
// This is the view that is shown in Server Admin
// This is an automatically generated file.
// PLEASE DO NOT MANUALLY MODIFY THIS FILE!
// Please make your changes in the named.conf file
//

view "com.apple.ServerAdmin.DNS.public" {
//GUID=3EA358EF-5C55-4619-98D0-5004B310D1B0;

    allow-recursion {"com.apple.ServerAdmin.DNS.public";};

    // -------------------------------------------------------------
    // THERE WERE SEVERAL ZONES HERE IN THE FILE THAT WE HAD CREATED
    // I DELETED THEM ALL.
    // THE FOLLOWING ZONES DID NOT LOOK LIKE ONES WE CREATED, SO I LEFT
    // THEM IN TACT
    // -------------------------------------------------------------

    zone "." {
        type hint;
        file "named.ca";
    };
    zone "localhost" IN {
        type master;
        file "localhost.zone";
        allow-update { none; };
    };

    zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "named.local";
        allow-update { none; };
    };

};

Having done that, and restarted DNS, Server Admin still was not happy. Turning off DNS again, I went into the /var/named and the /var/named/zones folders and deleted all the files created by us. A list before (and after) of /var/named looks like this:

db.100.168.192.in-addr.arpa.
db.15.168.192.in-addr.arpa.
db.20.168.192.in-addr.arpa.
db.203.244.66.in-addr.arpa.
db.34.168.192.in-addr.arpa.
db.40.168.192.in-addr.arpa.
db.5.168.192.in-addr.arpa.
db.55.168.192.in-addr.arpa.
db.65.168.192.in-addr.arpa.
db.75.168.192.in-addr.arpa.
db.somedomain.ab.ca.
db.anotherdomain.net.
localhost.zone
named.ca
named.local
zones/

I left the localhost.zone, named.ca, named.local and the zones folder, and deleted everything else. (sudo rm db*).

The /var/named/zones folder looked very similar, but does not (appear to) contain any files that were not created by server admin, so sudo rm db* deleted everything.

At this point, I restarted DNS (and likely rebooted) and could work with Server Admin again.


Now I had to repopulate all of our DNS entries. Fortunately, the backups of /var/named/db.{$DOMAIN}. (one file for each domain) made it really clear what needed to be done to recreate the domains, being simply a list of the name of a host, the type of record, and the IP address, such as this:

...
silo IN  A 192.168.100.254 
old IN  A 192.168.100.116 
psmain IN  A 192.168.100.121 
mail IN  CNAME ghs.google.com. 
...

I was two-thirds of the way through recreating both of our domains when, suddenly, Server Admin exhibited the same problem I started with -- namely, one could no longer use it to display or edit zones. Oh, man!

The last host entry I had put in was ftp. I decided to see if it showed up in any of the files:

$ cd /private/var/named/zones
$ grep -R --include "*" ftp .
./db.somedomain.ab.ca.zone.apple:ftp IN  A 192.168.100.254 
./db.somedomain.ab.ca.zone.apple:ftp IN TXT "Was pointing to webserver (192.168.100.116), now pointing to silo (192.168.100.254)."

I removed those two lines and Server Admin was happy again. (Thank goodness).

The problem appears to be the comment for the ftp server. (We use very few comments; there were only two, and I didn't see any reason not to create them. I believe I shall exercise more care in the future.) Perhaps it is because the comment contained IP addresses.

(There is also an outside chance that the ftp server, being an A record to a machine that already had an A record, caused the problem, but that strikes me as rather unlikely.)

I recreated the ftp entry as a CNAME and did not put in a comment.

Thinking on it later, changing the ftp-server entry was most likely the last change we made to DNS, several weeks ago.

I finished up re-instating all the hosts, and checked my work:

mkdir DNSDiff && cd DNSDiff
# repeat for each domain
cat /path/to/backup/var/named/zones/db.somedomain.ab.ca.zone.apple | sort > old.somedomain.txt
cat /var/named/zones/db.somedomain.ab.ca.zone.apple | sort new.somedomain.txt

diff --side-by-side {old,new}.somedomain.txt
# or, with TextWrangler,
twdiff *.somedomain*
# (or, use the diff tool of your choice.)

DNS appears to be running fine now.

2
  • I'd guess it's because there's only a single space in IN TXT (as opposed to the two spaces in IN A). I don't have a 10.5 server to test with, but I tried essentially this on 10.6 and it didn't have any trouble (it only put one space in the file, but wasn't confused when reading the file back). Jun 23, 2010 at 18:24
  • Really? Thanks for testing that for me. It rather sounds like the issue has been resolved in 10.6 then. Jun 23, 2010 at 19:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .