This title is very specific and may not be everyone’s exact scenario, however, there was plenty of beneficial items in my latest exercise with Wiki data on OS X; specifically taking old 10.6 Wiki data and putting it on a new server in which the Directory information was lost.
I happened to have Wiki data from a 10.6.8 server that was saved by a simple backup routine instead of using Time Machine backups. “No Time Machine backup?” you ask. This was because this was 10.6 Server! Remember, Time Machine couldn’t stop Open Directory, so back then backups were “on the ODM, use this ‘export’ script”, and “rsync or use some other backup tool to save your data”. In 10.6 the Wiki data was saved in /Library/Collaboration so it made backup of the data very simple.
The environment that I stepped into was:
So there are two things to remember when migrating Wiki data:
- The Directory is critical (and even more so w/ Mt Lion)
- If you are doing a migration that needs to “upgrade” data, be sure to have a system that can still run the old OS.
What do I have to work with for this migration task? File backup of /Library/Collaboration with the original Directory system lost targeted for a machine that cannot run 10.6 to update. Not a problem, right. Apple’s kbase article on how to migrate Wiki data from a 10.6 server to Mt Lion should work… right? Not really. Depending on how you have your Wiki setup and it’s permissions (who owns the data vs. who has read and/or write capabilities) some of the Wiki groups will not come over.
What I have done several times is migrate 10.6 Wiki to a new 10.6 Wiki server because I can always strip the permissions data by doing the following steps.
10.6 Server Wiki to 10.6 server
# Wiki Migrate https://discussions.apple.com/message/10479747#10479747 Source Article sudo serveradmin stop web sudo mv /tmp/Collaboration/Groups/ /Library/Collaboration/Groups/ sudo chown -R 94:94 /Library/Collaboration/Groups/ sudo rm /Library/Collaboration/dataVersion.plist sudo rm /Library/Collaboration/globalIndex.db sudo rm /Library/Application Support/Apple/WikiServer/directoryIndex.db sudo serveradmin start web
The end result is a working 10.6 Wiki server. So what about the the new hardware that cannot run 10.6.8 Server… VMware to the rescue! You can install 10.6.8 Server in VMware Fusion as it’s a Server OS (thus is compliant to Apple’s EULA). Now we can upgrade to 10.8 and move the Wiki content from the VM to the real server by following Apple’s kbase article. You would think that wouldn’t you.
Let’s review what we have and where we will go:
- You have a VM w/ 10.6.8 Server running Wiki (which includes Open Directory Service for Authentication).
- Downloaded and install OS X Mountain Lion
- Software Updates for Mt Lion
- Download and install Server.app for OS X
End result is a full functioning Wiki service… that is running on your local VM. Now I could just install VMWare on the new hardware and just be done, but Fusion is not really production worthy for this environment so that was not an option. When I tried to migrate the data following Apple’s kbase article the end result was several Wiki groups that could not be administered. What happened? The “Directory Admin” that was running in your VM has a different UUID than the “Directory Admin” running on your new Mac hardware that may either:
- Be running as an ODM
- May be joined to a ODM via Directory Utility.
Final solution? Thank goodness Apple updated their Kerberos to Heimdal (as discussed last year at MacTech and MacIT), because I can now connect to multiple Directories! I joined my VM of 10.8.2 running Server.app v2.2.1 to the future Directory system (AD or OD), adjusted the Wiki settings for each group, then followed Apple’s kbase step by step which can be shortly described as:
- export wiki postgres db with the
- copy /Library/Server/Wiki/FileData from the old server to the new server
- change permissions on the new Server for FileData
sudo chown -R _teamsserver:_teamsserver&
sudo chmod -R +a "www allow search"
- On the new server
dropdbthe the existing db (thus loosing ALL content previously there),
createdbto have a bare but ready db and then
pg_restoreyour info from your collab.pgdump.
Wiki uses authentication, but simple usernames and passwords are not the limit to how Wiki is tied to the directory system. Wiki is now using UUID’s to identify who has read/write/owner of Wiki data. You know, this one:
# dscl command to find the GeneratedUID of diradmin sadmin@osxs1 ~> dscl /Search -read /Users/diradmin GeneratedUID GeneratedUID: 27D18844-70C6-4BDD-BE3A-5B26A6FDEA1B # not my real UUID. Generated via command 'uuidgen'