This question came to me from Steve:
“…I am looking to migrate my data from an NSS/NCP volume to an ext3/NCP volume (temporarily) and then back to a ext3/NCP volume. Should I do it? I have a vendor software that needs me to run on an EXT3 partition.”
The important part is that by “NCP”, he means *with trustees*. Steve and I now know that this is not possible with the tools that Novell provides for you.
Oh sure, you can use the OES2 built-in “Migrate NetWare Files” tool (in Yast) to migrate the data and trustees *from* the NSS-based source server *to* the NCP-only (non-NSS) server. You just can’t get the data & trustees off the NCP-only (non-NSS) server. Nope. No tools. No dice.
So imagine this scenario: you migrated the data off the NSS/NCP volume to a temp OES2 server’s ext3/NCP (non-NSS) volume, using the “Migrate NetWare Files” (migfiles) tool, and all went well. You test all trustee assignments, data, etc., and everything is fine. Now, you destroy the original source NSS volume and build the new destination ext3/NCP volume, and you are ready to migrate back.
First, you try the same “Migrate NetWare Files” tool, and you just get errors. Hmm. You dig deep and find that it seems to be looking for elments of NSS… but there was no mention that NSS was mandatory… Hmm…
You then try nbackup, but guess what? It makes calls to NSS elements too. Nbackup *might* have worked if we had used it in the first place to make a blob from the NSS/NCP volume and restore to the ext3/NCP volume (import of trustees is not the problem, export is), but that doesn’t matter now…
You find a dude out on the ‘net who wrote a modern equivalent of the old “tbackup” utility, but for OES Linux — and it is very nice — but it uses NSS calls as well…
Even the “rights” package and commands are part of the NSS sub-system, which you can’t use since you don’t have the NSS elements installed anymore on your production server (since they aren’t needed without NSS in an ext3/NCP situation). They wouldn’t work against an non-NSS volume anyway, even if they were there.
Okay, data you can copy. That’s not the problem. You hastily configure an rsync daemon on one side, a client on the other, and start the data copy going right away, just to get that done with.
You still need those pesky trustee assignments. So, what are you left with? You have a trustee database file (._NETWARE/.trustee_database.xml at the root of your volume), and ncpcon. You can: (A1.) visually inspect the xml database file and (A2a.) start clicking like mad in Windows Explorer to re-add all the trustee assignments back or (A2b.) type in a zillion “ncpcon rights add” commands. Or… you can: (B.) script it.
Okay, end of scenario. What would you do? Really? Well, what if you don’t have enough time to script it (because it is kinda’ complex), and it’s almost morning and the users are going to want to log in a few hours?? I’m not going to say what we ended up doing, but I can tell you this: I have now written a script to solve this problem so that I will never be faced with that crap again.
On a side note, I felt quite let down by Novell support when we called in on this too. I won’t go into specifics about this in public, but it sure wasn’t like the old days… and it hurts…
Anyway, here’s the deal: If you have arrived at this blog page because you *are* in such a scenario and did a search, or because you might be in the near future… or even if you are a regular reader… consider yourself warned. The benefit of this post is really the warning of these shortcomings, since it is a very real situation that many people may find themselves in.
And if you are interested in having someone like… oh, say… ME… parse your trustee database and instantly turn it into a import script to restore all your trustee assignments, please contact me and I would love to offer you my consulting services! Sorry to be so cheesy about it folks, but I could always use the work… š
Actually, if you send me your trustee database file, I might just parse it and return the results for free… if you’re nice…Ā šĀ The result file is VERY handy for Disaster Recovery. Or, if you happen to be using a non-SMS-aware backup like RSync, and you aren’t backing up your trustee assignments, but do get the database as part of the backup, this would be handy for you as well. Or if you’re migrating to another server… or if you just want a nice file for an audit trail… bla bla bla….
I just hope that my telling this story helps somebody else avoid the pain I went through…
š
** Note: The script handles IRMs, too…And right now a cgi-based version of this tool is in the works for your convenience… stay tuned…
POST-PUBLISH UPDATE: I have turned the tool into a cgi interface that anyone can try. So please notice the link to “Trustee DB Export (alpha)” under the “Pages” section to the right (on the main front page). Give it a try!!
Pingback: Your Linux Guy .com » Blog Archive » How do I add NCP trustee assignments at a command prompt?
Here is an odd little data point. I was in a somewhat similar situation a few weeks ago with an OES1 server. We were getting low on space on an NSS-based volume. The expansion process went horribly wrong, and ended up toasting the volume entirely. At this point I went “screw NSS” anyway (I’d been less than happy with it performance wise, and it had been fragile for me in other ways in the past too).
So I restored all my data to an xfs file system, mounted that at the same mount point as the old NSS volume, and used ncpcon to export it as a volume of the same name as the old one (all that was just to ensure UNC paths didn’t break from the client’s point of view. *At this point, NSS was still running on the server, with its prior configuration intact. I also forgot to move the mount line from fstab*. I was happy to see everything seemed to be working fine, including rights. I thought that was how it was supposed to work, and went happily on my way, making a mental note to turn off NSS on the server when I got a chance.
Fast forward to yesterday night. I disabled NSS, and rebooted the server. Everything seemed to work in terms of mounting and exporting, but… no rights, which it turns out should not have been a surprise. Huh. I used ncpcon to dismount the volume, started NSS (and remember, its configuration had never been cleaned up), remounted the volume with ncpcon, and… rights were back :V
So probably not something you should plan around(!), but it seems you can do this weird Frankenstein’s monster thing with NSS and a linux native file system in a pinch.
Wow Alan, thanks.
That’s a cool insight into some peculiar application behavior, for sure…
Maybe it will help someone out in a pinch!