Restore 10.2 network.nidb to 10.4 network.nidb – wishful thinking?

[papastanley]

Hi guys, sorry for the essay, but here it is – we have upgraded 10.2.8 to 10.4.2 on our solo Xserve and everything was more or less running fine.

I had one Windoze client (most of my clients are) whose login wasn’t being recognised by SMB (or more likely netinfo). While troubleshooting this I rebooted the server, which came up without the NIC working. After punching the button on my Xserve, it rebooted ok again and I found no users in Netinfo/network setup could auth via AFP, SMB or FTP even. However, local users could login, of which there was only the admin user.

After trying the nidb backup restore options in single user mode for the netinfo network.nibd restore process as outlined in…
http://docs.info.apple.com/article.html?artnum=107210
…the server would hang at the Sectoin 4 command sh /etc/rc – ie when you try and get the system running still in single user mode, before you try and reload the nidump backup. When I say hang, I mean blue prelogin screen, with only a mouse cursor and no disk activity and going nowhere fast.

Realising we may have chewed the local.nidb in the process, we’ve rebuilt this and again have local root and admin access. Baxk to square one, or maybe -1?

So I believe I now have a blank network.nidb as created by the script in that article, and no easy way to try and import the nidump? Add to this the possibility that the nidump updated itself overnight again, most likely with the new blank network.nidb. cuts the options a bit shorter.

We do have our previous 10.2.8 system on another ADM which will boot and work fine. I am seriously condiering a clean install and migrate as “The Final Solution” 😉

I’ve also got a feeling we’ve somehow ended up with a crossed over reference for our local and remote netinfo domains, mainly due to these error messages from the boot in system.log… note DrectoryService looking for 127.0.0.1/local and and netinfod local binding to 137.219.118.14/network – is this right?

<< Aug 12 12:29:28 localhost /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow: Login Window Application Started
Aug 12 12:29:28 localhost loginwindow[100]: Login Window Started Security Agent
Aug 12 12:29:29 localhost DirectoryService[45]: NetInfo connection failed for server 137.219.118.14/network
Aug 12 12:29:34 localhost configd[38]: AppleTalk startup
Aug 12 12:29:34 Tesla configd[38]: setting hostname to “Tesla”
Aug 12 12:29:43 Tesla kernel[0]: UniNEnet::monitorLinkStatus – Link is up at 100 Mbps – Full Duplex
Aug 12 12:29:45 Tesla /usr/sbin/serialnumberd[170]: serialnumberd: Firewall rule #1 added to allow port 626.
Aug 12 12:29:45 Tesla configd[38]: executing /System/Library/SystemConfiguration/Kicker.bundle/Contents/Resources/enable-network
Aug 12 12:29:45 Tesla configd[38]: posting notification com.apple.system.config.network_change
Aug 12 12:29:45 Tesla nibindd[50]: Shutting down NetInfo servers
Aug 12 12:29:45 Tesla nibindd[50]: Restarting NetInfo
Aug 12 12:29:45 Tesla lookupd[239]: lookupd (version 365) starting – Fri Aug 12 12:29:45 2005
Aug 12 12:29:45 Tesla lookupd[239]: NetInfo connection failed for server 127.0.0.1/local
Aug 12 12:29:46 Tesla lookupd[239]: NetInfo connection failed for server 127.0.0.1/local
Aug 12 12:29:48 Tesla netinfod local[241]: bound to 137.219.118.14/network
Aug 12 12:29:50 Tesla DirectoryService[45]: NetInfo connection failed for server 127.0.0.1/local
Aug 12 12:29:56 Tesla configd[38]: AppleTalk startup failed, status = 92 (retrying)
Aug 12 12:29:56 Tesla DirectoryService[45]: NetInfo connection failed for server 127.0.0.1/local
Aug 12 12:29:56 Tesla netinfod local[241]: rebound to 137.219.118.14/network (was to 137.219.118.14/network)
Aug 12 12:29:57 Tesla configd[38]: AppleTalk startup
Aug 12 12:29:57 Tesla /usr/sbin/serveradmin: servermgr_ipfilter:ipfw config:Noticeisabled firewall
Aug 12 12:29:58 Tesla configd[38]: target=enable-network: disabled
Aug 12 12:30:03 Tesla configd[38]: AppleTalk startup complete
Aug 12 12:30:13 Tesla /usr/sbin/AppleFileServer: TIME-CHECK: NSLXStandardRegisterService took 1.660377 seconds!

>>>end snip

.. and this in the netinfo log…
<<< snip Aug 12 12:29:45 Tesla nibindd[50]: Shutting down NetInfo servers
Aug 12 12:29:45 Tesla nibindd[50]: Restarting NetInfo
Aug 12 12:29:45 Tesla lookupd[239]: NetInfo connection failed for server 127.0.0.1/local
Aug 12 12:29:46 Tesla lookupd[239]: NetInfo connection failed for server 127.0.0.1/local

>>> end snip

SO, I think I have two questions

1. Is the Netinfo domain setup somehow ass about with network and local?

2. If yes, how can we fix it given we can’t auth into the network netinfo to edit it in Netinfo manager (maybe with NICL in raw mode to reset the blank network.nidb root password? The System Administrator account is there I can see it but not auth to edit it.)

3 (ok three questions) Can we somehow import our 10.2.8 nidb into our 10.4.2 setup, either via nidump or dsimport? (and expect it to work)

4.(ok four questions) Can I simply chuck the network netinfo db away, activate LDAP for Directory Services and import our 10.2.8 WGManager users export into it, and take the hit on asking everyone to reconfirm their password…

Yes I know Apple have moved to LDAP for the main auth, and I was intending to convert from Netinfo to it, but it’s first week of semester and I wanted to get through that first before doing anything major with the new Tiger features. The authentication has been running fine for over a week after the UIP until this one user problem (prob indicative of the impending disaster), then these other issues.

Apologie in advance iof this is something obvious, I wear many hats at work and my sysadmin one is a bit tight, ie I don’t have enough time to devote to it.

Any assistance greatly appreciated – love your work

Steven Stanley

[papastanley]

OK, update on the essay – got it going again after some dicking around (pardon my Australianism) as I tried restoring the network.nidb I’d backed up in the script process. By rights this should have got us back to square one – ie no users could log in, but at least they are still there.

However I also stripped back what the SMB server was doing, turning off the Workgroup Master Browser feature – and bingo! it’s working?

This makes me think that enabling the Workgroup Master Browser feature somehow started blocking authentication to Netinfo and network.nidb – does that make any sense? Bug? Feature? Anybody seen something like this?

One final niggling question – in WGM my Network domain path shows “Netinfo/root” but my Local domain now shows the path “Netinfo/root/Tesla” – this is what I meant when I said the local.nidb might be nested inside the network.nidb – is this ok, or will this cause probs if I migrate to LDAP?

thanks in advance for any perspective

Steven G Stanley

[Author]

Posts