Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
NFS mount to convert backing store ?
tjayaprasad
We are in the planning stages of upgrading from TeamSite 5.0.1 to 5.5.2. I am sure there are many experts out there with first-hand experience doing this conversion.
As per Interwoven's upgrade/conversion documentation, we need
- two servers to convert the backing store, one running 5.0.1 and the other running 5.5.2.
- NFS mount of 5.0.1 backing store and /iwserver on the server running 5.5.2
My question is, can I do this conversion (without using NFS mount) with a local copy of 5.0.1 backing store and /iwserver (let's say the location will be /old_version/iwserver) on the the server running 5.5.2 version.
My gut feeling is, it will not work.
I am really looking forward to hearing that it's possible - because NFS mounts are strictly prohibited at our firm and I need go through many approvals for an exception. If so, could you please enlighten me with more details ?
Your feedback/input greatly appreciated. Thanks in advance.
Find more posts tagged with
Comments
gzevin
maybe a bit offtopic. Think whether you need to convert the whole backing store. You might end up with cutting a limited number of editions (and/or workareas) and transferring them as .tar.gz files to the 5.5.2 server, and capturing and reattaching EAs on the way
Greg Zevin
Independent Interwoven Consultant/Architect
Sydney, AU
Adam Stoller
(still a bit off-topic, since this is assuming you *can* use iwconvert)
iwconvert allows you to specify a range of editions to transfer - and this is probably a bit better than trying to do it manually.
The advantages of using iwconvert include:
- preservation of history between the editions
- preservation of date / timestamp information
- preservation of metadata / extended attributes
If you don't want this, then yes, you could to .tgz files and record/play-back the EA information.
--fish
(Interwoven Senior Technical Consultant)
Edited by ghoti on 02/14/03 07:58 AM (server time).
tjayaprasad
I intend to use iwconvent only and I do want to preserve the history, timestamp and metadata.
I would like to know if any one was successful in using iwconvert with local copies of 5.0.1's /iwserver and backing store (without NFS !!) ?
Thanks
Adam Stoller
I believe the old backing store needs to be on a system where the old TeamSite is running. The new backing store generally is on a machine where the new TeamSite is installed but *not* running.
You could *try* running the [new] iwconvert tool on your existing server and having it write the new backing store to a different location. I don't believe this is supported (QA'd) and I have absolutely no idea if it will even work - my guess is "no", but sometimes these things do actually work.
NOTE: I am *not* recommending this process - merely stating a possible, hypothetical work-around for the limitations of your environment.
A better solution would be to have your IT folks allow the NFS mounts for the duration of the conversion - between those two machines only - and not try to hack around it.
However - I will ping some of our engineering type folk who might have some more insight into this (as well as being able to say whether my suggestion above for trying to do it on one machine is completely bonkers)
--fish
(Interwoven Senior Technical Consultant)
Adam Stoller
Okay - here's what I've managed to collect from one of my engineering colleagues... slightly paraphrased
Yes, it should be possible to do this. It's mostly an installation issue.
They will have to install iwconvert by hand to do this, since installing TS5.5.2 would overwrite the previous server. The iwconvert binary can be placed anywhere. Then they will need to at least copy the I18N library into their 5.0.X IWHOME. The good news here is that the iwconvert program will tell you what libraries are missing (if any) when you go an run it.
I take that to mean that it will complain with error messages about missing libraries that you'll then have to go and find on the 5.5.2 machine and transfer over to your 5.0.x machine in the appropriate place (or set environment variables like LD_LIBRARY_PATH to point to them in some non-standard path?)
Also, they'll want to be careful not to get confused between the old and new backing stores.
It's possible that there are other shared libs that have crept into iwconvert as dependencies. But again they will be pretty obvious once you run iwconvert.
So - it sounds like you should be able to do this, but you will need to go slowly and carefully through the process to make sure you bring over the right parts of the 5.5.2 system onto your 5.0.x server and that you make sure you clearly
distinguish
between your
old
and
new
backing stores.
I'd also recommend that you make sure a good, clean, full backup is performed on your 5.0x server before you attempt to do this (standard practice anyway, but even more important in this case I think).
Good luck, and if you keep good notes and are willing to share your experience, I'll be happy to transcribe them into a KB for others to reference.
--fish
(Interwoven Senior Technical Consultant)
tjayaprasad
Fish, I greatly appreciate your valuable input.
I got approvals for NFS mount in the development environment. Though it's painful to get approval for NFS mount, with the information I got so far, I am now inclined to go the NFS way.
I may experiment converting on the same server in development and if I do, I will certainly share my experiences.
Thanks again.
Migrateduser
I kind of understood the discussion on this thread. However I'm not able to understand what you guys meant by "capturing and reattaching EAs on the way with tar.gz files". Can any one of you please explain that?
If we decide not to take the iwconvert route and instead take say only most of the branches and workareas (due to cleanup) how do we still retains the EA's? Are you guys saying that it's possible? Is it by means of some scripting?
Thanks
Saravanan
Adam Stoller
The manual method for migrating content is:
Create a tar (or zip) file of the content to be migrated (one per branch)
Create a text file that contains a list of all the EA's associated with each of the files to be migrated
Create the same branch structure on the remote server
Create a workarea there
Unload the tar (or zip) file into the workarea
Set the extended attributes based on the information in the text file
Submit
(repeat for each branch)
If you want multiple versions' worth of data - you have to repeat the process several times - starting with the oldest versions (from an edition) that you want to bring over and subsequently replacing them with newer versions.
You lose all history trail information, you lose all date/time-stamp information, you'll spend a fair amount of time doing it, and the process is not without it's possibility of human error.
The only part that I think is reasonably well scripted is the transferrence of the EA's - I'm not sure if the script exists on DevNet or the Support site - but if you cannot find it there, someone can probably provide one (or you can write it your self - it's not that difficult - traverse files, run iwextattr -l on them. Traverse files, run iwextattr -s on them - with suitable quoting, etc.)
You're generally better off going through the conversion process.
--fish
(Interwoven Senior Technical Consultant)
Migrateduser
Thanks fish for the detailed information.
We are still weighing/testing both options (Of course we're in touch with Interwoven Support). And I did find the script that you mentioned.
>>You lose all history trail information, you lose all date/time-stamp information, you'll spend a fair amount of time doing it, and the process is not without it's possibility of human error.
I agree with everything you said except the one about the time factor. One complicating factor for us is we're moving from 4.2 to 5.5 which is why have to consider both options.
Saravanan
