Currently Being ModeratedSep 9, 2012 5:17 PM (in response to phillw)
The fix appears to be rather simple but odd. For each page that contains linked files, you simply need to press the edit button and then press the save button. You do not need to modify anything on the page. The process of saving the page will correct the links.
Currently Being ModeratedSep 9, 2012 7:13 PM (in response to Strontium90)
Wow, doing that almost brings it back to life! Instead of getting broken images I get pictures of the files alok with the quicklook button for suport files.... however when clicking on those links it takes me to a URL which results in a blank page silimar to this - "htts://myserver.com//cc-sandbox/file?entity_guid=78bb57fd-7f37-4043-b8f0-1d55c 12281be&auth_token=7B8B97B5-DE84-46BB-A8E8-C93BE4AFE2A5
Also on documents which have the quicklook icon when I press the button it displays a popup saying "This file has no preview. Try uploading it again."
Currently Being ModeratedSep 10, 2012 7:13 AM (in response to phillw)
Hmm. You are getting different results than I've seen on about 7 migrations. However, you also did far more than I did in the migration process. I did not attempt the:
I have also ran "wikiadmin fixPermissions", "wikiadmin rebuildSearchIndex" and "wikiadmin resetQuicklooks" afterwards but all the attachments are still broken,
Looking in the Collabration folder I brought over from 10.6 Server I can see inside the wiki folders all the attachment data, so I don't know why this hasn't worked as part of the migration.
I simply followed the migration document, reviewed all permissions on each wiki and then did the edit/save (or instructed users to do the same). I can only recall one link that never worked and it ended up that it was nested inside 4 or 5 tables. I actually had to recreate that entire page.
Any chance you can remove everything and restore again. This time without running the extra commands? Are you still testing on a non-production system?
Currently Being ModeratedSep 10, 2012 3:14 PM (in response to Strontium90)
As the migration to 10.7 did not work I have got the client still working off the 10.6 Wiki for the moment, this allows me to continue testing the content I have migrated onto 10.7.
From here I am getting a copy of Collabration folder sent to me from my client (as I am doing this remotly) so that I can create a new 10.7 test server here and see what the results are like migrating from scratch again.
To confirm it will be a blank 10.7.4 Lion Server Install, I will copy the Collabration folder onto the desktop of the 10.7 Server, set the permissions on the folder using "sudo chown -R _teamsserver:_teamsserver /tmp/Collaboration" and then run "sudo wikiadmin migrate -r /tmp/Collaboration"... Any other suggestions or is this all you have done?
Fingers crossed this was just a one off migration issue, but I will let you know in the next few days what the results are like with the test server I build.
Thanks again for your advice so far
Currently Being ModeratedSep 11, 2012 4:25 AM (in response to phillw)
So far, that has been exactly what I've done. The only other step was to log in to the individual Wiki pages and correct the permissions of the wiki. This will be vital for you since you will not have matching GUID values on the test server. Then once imported, go to a page with attachments and then edit... save...
Good luck. Let me know how the testing works.
Currently Being ModeratedSep 14, 2012 6:09 PM (in response to Strontium90)
Ok so after getting a copy of the collabration data from the 10.6 wiki server I created a virtual machine for testing on my machine, brand new 10.7 Server with all updates applied. I then set permissiosn on my existing collabration folder to "_teamserver" and ran "wikadmin migrate -r" this ran through and imported all 207 pages for me again without any errors... however the results are exactly the same, broken images to links until I then edit the page and save again, then the icon will show up for the attachments but the quickview doesn't find anything and clicking on the link to download just takes me to a blank page like before...
So what I did was rollback to a pre-imported snapshot of my test server and decided to migrate just one wiki into the clean server, this worked perfectly except I still had to click on edit and save again for the attachment links to finally work! I imported a few more wikis just as a test and they also worked fine.
So this is great apart from the fact I have 207 wiki groups and a total of 1222 pages which need to be moved to this new 10.7 server, I really only have two days over the weekend to perform the import so am hoping there might be an easier way. Based on my findings do you have any other suggestions? Would you like a log output of the migration or any other callabd logs at all? Obviously there are some client names in there which I'd rather not post up on the web. Perhaps I can send you a message through your contact page on your website and you can contact me back to get these?
While I'm waiting I am going to build a 10.8 server and perform the same just to see if this is an issue with 10.7.4 perhaps, I'll let you know how this goes as well.
Thanks for everything so far!
Currently Being ModeratedSep 15, 2012 3:56 AM (in response to phillw)
I guess I've been lucky enough not to have run into this. I moved one environment with over 100 wikis and everything work (meaning that pages with attachments needed to be edited/saved for them to appear).
This sounds like a needle in the haystack. One of those wikis might be messing everything else up. During the bulk import, you are not seeing anything in the console to suggest and issue?
You can post the logs but I would suggest doing the following. Import one wiki and isolate the log file for that import action. Assumming you are successful with this one wiki, then we should be able to assume that the logging information is an example of a "successful" import. If so, then import the entire (or half) of the wikis and compare each block of logging to see if there is a difference on one or more of the wiki imports.
Currently Being ModeratedSep 15, 2012 9:48 PM (in response to Strontium90)
Ok so it was a long night waiting for a few different tests to run but this is what I have found:
Under Mac OS 10.7.4 Lion Server:
- If my services storage is set to a location other than the default then when I perform a complete migration of all my wikis in one go I get broken links and nothing works as per my original issue.
- If my services storage is set to a location other than the default when when I import a single wiki at a time the links are fine, I just need to click on edit and resave the page for everything to link up as it should.
- If my services storage is set to the same volume as my server OS then when I perform a complete migration of all my wikis in one go then it imports successfully and I only need to edit and resave the page for everything to start working as expected.
Under Mac OS 10.8.1 Mountain Lion Server:
- If my services storage is set to a location other than the default, then I perform a complete migration of all my wikis in one go everything imports successfully AND I don't even have to go through every wiki page to edit and re-save!
At least I now have two options to provide my client.
- If they choose to stay with OS X Lion Server then what I am going to do is move the services storage back to the default location, perform the migration, confirm everything is working fine and then move the services storage after the migration. Given the amount of wiki data is over 300GB having it on the internal volume on a Mac mini server really isn't ideal which is why I chose external storage in the first place.
- Alternativly we could just update the server to OS Mountain Lion Server and this would work fine with the current setup and eliminate the need for my client to go through and re-save around 1200 pages.
There appear to be a few import improvements with Mountain Lion Server as there was a lot more information logged while performing the migration and I noticed it also took significantly long than Lion Server.
So I would be very interested to know if you've kept the storage location for services at the default for your deployments or have had success with alternative locations?
Also my next question is going to be, given I have a failed migration currently, I want to reverse the migration on the server currently running (as it's currently taking up 300GB of storage - effectivly so I get a fresh start with postgres and everything to do with collabration. I found this article - http://www.rowlandblogs.org/users/robertquiroz/weblog/80b5a/ - and followed it, but surprisingly everything remained even after running those commands, I notice the commands don't actually touch on deleting the wiki data and attachements from the storage location I have set (the 300GB of data). Do you have any suggestions on this at all?
Currently Being ModeratedSep 22, 2012 9:29 PM (in response to phillw)
Well this weekend I reloaded the server with OS X Mountain Lion Server and performed the migration. So far everything looks fine, had the client have a look around and they seem happy. Just got to get email notifications working now and work out how to remove users from showing up in the People page.
Big thanks to Strontium90 for your help and suggestions along the way! Appreciate it