Migrating from Solaris to Linux

Has anyone migrated teamsite from Solaris to Linux? I see people have asked questions about the migration but has anyone actually completed the migration.

Thanks,
Winston

Find more posts tagged with

Comments

Migrateduser

Yes we have done it - it was a long and tedious process (we had 6 TS servers), but we got it done. Hired a consulting firm to do it, but we monitored their process. Of course, installing a fresh version of TS on the Linux boxes was pretty straightforward. Configuring and setting permissions properly on everything was a PITA. Migrating the backing store was not bad. Prepare for some hurdles, but it's doable.

Winston

We only have 1 server with 675g to migrate.

I'm guessing you used Open Deploy. If yes, do you have an example that you would share.

Thanks,
Winston

Migrateduser

We did not use OD to migrate the backing store - and yours is way bigger than ours. We had our Storage folks copy the backing store snapshot to the new filer. Then we ran the standard migration CLTs on the store.

Winston

Thanks.

We're also upgrading from 6.7 to 7.3 at the same time.

Adam Stoller

We did not use OD to migrate the backing store - and yours is way bigger than ours. We had our Storage folks copy the backing store snapshot to the new filer. Then we ran the standard migration CLTs on the store.

For those not familiar with your environment, which I'm assuming did not change (in this respect) since I was there - the backing stores were located on NetApp servers / "filers" such that they could be utilized easily for failover of the primary TeamSite servers and/or disaster recovery (filer-to-filer copies performed periodically) in the case of data center failures.

The NetApp servers take full advantage of NetApp's snapshot functionality.

If Winston's environment is different (most likely) then the amount of effort and processes for performing such copies will also be different.

nipper

One potentially big issue is the iw-home location. Legacy servers, people used something like /usr/interwoven/iw-home, now new installs for the directory to be TeamSite.

Of course symbolic links can be used, but you may want to clean that up as well.

The backingstore on Solaris can be mounted directly on Linux, you may still want to run iwmigrate, fsshrink and/or iwfsck (the latter 2 are certainly best practices), you also may have user access issues depending on the authentication of Solaris and Linux. iwaccessmigrate will help

HurricanesFan

Hello,
oh I remember the changed iwhome path to now include a 'teamsite' directory - caused me a lot of angst at a previous assignment...

I'm interested about mounting the backing-store from Solaris on to a new Linux TS implementation. The HP-Aut webinar stated for a 'fresh install' migration to 7.3.2: "Migrating content store cross platforms (Sol v linux) will not retain version history and will require a custom OpenDeploy script".

Did you lose the old versions doing this?

Also, I've been reading conflicting specs for the linux server required for 7.3.2. Can it be a VM or does it need to be a physical server? Try to get the definitive specs so we can order it.

Cheers
PJ

nipper

I'm interested about mounting the backing-store from Solaris on to a new Linux TS implementation. The HP-Aut webinar stated for a 'fresh install' migration to 7.3.2: "Migrating content store cross platforms (Sol v linux) will not retain version history and will require a custom OpenDeploy script".

You believe them ? Smiley Very Happy

I have mounted a Solaris backingstore on a Linux server and used it, now problem. 6.7.2 Solaris to a new install on RHEL running 721.

Try it yourself, if you have access to both flavors. Create a new store on 672, add a branch and a few files then move it to the new server and mount it.

You cannot mount a DOS store on a Unix server (or vice versa).

Rick Poulin

I have mounted a Solaris backingstore on a Linux server and used it, now problem. 6.7.2 Solaris to a new install on RHEL running 721.
[...]
You cannot mount a DOS store on a Unix server (or vice versa).

Adding the technicals, because why not...

IWOV won't guarantee that the move between Solaris and RHEL will work because of differences in the kernel, especially if you're going from an ancient version of Solaris to a very recent version of RHEL. What helps here is that they both use UVFS as the driver for the content store, so the internal format is the same (assuming you have the same endianness on both sides).

The reason that the Windows content stores are incompatible with Unix is that it uses a different driver entirely (iwfsd.sys and related), so you can't make the assumption that the OS will treat the proprietary format in the same way (and it doesn't).

HurricanesFan

You believe them ?

I have mounted a Solaris backingstore on a Linux server and used it, now problem. 6.7.2 Solaris to a new install on RHEL running 721.

Try it yourself, if you have access to both flavors. Create a new store on 672, add a branch and a few files then move it to the new server and mount it.

You cannot mount a DOS store on a Unix server (or vice versa).

Well it looked official, so I believed it...

Brainstorming, I guess if I install TS7.3.2 on a Linux server, there is no harm in loading the old 6.7.2 SP2 content store from solaris and seeing if it works. If it doesn't then I get rid of it, and start writing some 'TS Comparison' deployment scripts...

nipper

Well it looked official, so I believed it...

Brainstorming, I guess if I install TS7.3.2 on a Linux server, there is no harm in loading the old 6.7.2 SP2 content store from solaris and seeing if it works. If it doesn't then I get rid of it, and start writing some 'TS Comparison' deployment scripts...

Yep, and if it works, then you should consider running iwmigrate anyway to make certain you do not hit any unforeseen issues.

HurricanesFan

Yep, and if it works, then you should consider running iwmigrate anyway to make certain you do not hit any unforeseen issues.

Actually I have a follow-up question to this now.

I've just been informed by our Unix team that they can't migrate the users & groups from our old TS solaris server to our intended new Linux server, and that we will have to recreate the users and groups - about 100 users.

So, even if we can load the old content store on to the new TeamSite on Linux, I'm guessing the file owner/groups will be a mess and very hard to rectify. I was reading about iwidmap, but I'm not confident that will fix the issue.

In our current TS 6.7.2 SP2 we just use old-fashioned Unix groups and users to control access to workareas.

Has anyone been through this?

I'm starting to form the opinion that maybe it will be better to do as HP-Aut recommend and just use TS Comparison deployments to migrate branch-by-branch and live with the loss of the old versions...

Opinions will be gratefully received.
Thanks
PJ

nipper

Hope you have plenty of time to test. If you did not know by now, a best practice is to, using submit.cfg, set the permissions and ownership the same (I always like to assign tsadmin as the owner). Would not have fixed everything but get you a lot closer to your goal.

I assume that means they cannot recreate the users and groups with the same id, if they could it would make your life easier. ID Map should cover it, but it is a pain.

Deploying editions from one server to another is another solid approach, set the owner to tsadmin, and submit each release.

ISCBorisB

Actually I have a follow-up question to this now.

I've just been informed by our Unix team that they can't migrate the users & groups from our old TS solaris server to our intended new Linux server, and that we will have to recreate the users and groups - about 100 users.

So, even if we can load the old content store on to the new TeamSite on Linux, I'm guessing the file owner/groups will be a mess and very hard to rectify. I was reading about iwidmap, but I'm not confident that will fix the issue.

In our current TS 6.7.2 SP2 we just use old-fashioned Unix groups and users to control access to workareas.

Has anyone been through this?

I'm starting to form the opinion that maybe it will be better to do as HP-Aut recommend and just use TS Comparison deployments to migrate branch-by-branch and live with the loss of the old versions...

Opinions will be gratefully received.
Thanks
PJ

If you can mount old content and the problem is just (re)mapping, you may want to consider utility's extract ( -x ) Flag.

This old KB Article helped me before, you may want to take a look. Note that XML Format may differ, the approach is still sound.
Basically, you get XML, modify it (manually, using Editor's Macro or custom code and whatnot) and re-apply in new Environment

HurricanesFan

Hope you have plenty of time to test. If you did not know by now, a best practice is to, using submit.cfg, set the permissions and ownership the same (I always like to assign tsadmin as the owner). Would not have fixed everything but get you a lot closer to your goal.

I assume that means they cannot recreate the users and groups with the same id, if they could it would make your life easier. ID Map should cover it, but it is a pain.

Deploying editions from one server to another is another solid approach, set the owner to tsadmin, and submit each release.

Thanks Nipper.

They didn't elaborate but I would assume it is ID mapping. Yes, we use submit.cfg. Hmmm it sets group/owner in workareas retroactively on submitting and we have a 1 branch / multiple workareas system so that's a lot of submits to get meaningful owners & groups for the workareas. Then there's the group on the branch and workarea itself.

So in terms of migration tools we would need to run on our 600G content store, we have iwmigrate, iwidmap, maybe iwfsck... And we would have to have at least 2 iterations of load store, run migration tools, fix stuff, until we are ready to switch over without downtime. I'm thinking aloud, but eisch.

With the deploy method we could switch over 1 branch at a time without running any tools I think - just deploy in latest content. All theory, but favouring this option more and more.

Good to talk it out.
Cheers
PJ

HurricanesFan

If you can mount old content and the problem is just (re)mapping, you may want to consider utility's extract ( -x ) Flag.

This old KB Article helped me before, you may want to take a look. Note that XML Format may differ, the approach is still sound.
Basically, you get XML, modify it (manually, using Editor's Macro or custom code and whatnot) and re-apply in new Environment

Thanks ISCBorisB, I'm checking that out.

If I can mount the store and the problem is just mapping, then I would go for that. I think I will be quite happy. Over the moon in fact.

Cheers
PJ

Winston

“Can you tell me which ‘standard migration CLTs’ you ran? There seems to be so many, and some seem mandatory and others not. I’m wondering which ones we really need to run because we have a large store to run on and we will probably have to do several iterations – it would be good if we didn’t have to run them all each time.”

nipper

iwfsck and iwfsshrink are required.

iwmigrate and iwidmap are optional. iwmigrate is a good idea. ID map is if you have access issues.

HurricanesFan

I thought I would update this, with my findings in case anyone else in upgrading TS672 on Solaris to TS732 on Linux and is interested.

I was able to bring in the TS672 store (Solaris) to our new TeamSite732 installation this:
- Stop TS
- put in store from 672
- take out the 672 'workflow' sub-component, and replace it with a saved 732 version 'workflow' sub-comp
- start TS

And it worked.

At first it wasn't and I was getting errors in iwtrace.log like:
[Wed Nov 13 15:02:50 2013] TTaskTimeoutCB: Smiley Tongue

rocess: bad workflow (21425006)
...so that's when I figured I needed a 732 workflow component.

This means we can't bring over workflow Jobs, but that's no big deal.

Prior to replacing the store we had set up groups and users with the same IDs as on our old TS672 Solaris server, and they worked fine. So no need to run any sort of ID mapping utility.

We were also lucky that an iwfsck run revealed no errors, so no need to run iwfsfix.

Also I should note that I was advised by HP-Autonomy support that there are problems with iwfsshrink, so that was enough to dissuade me from running that.

All in all a surprisingly good result.

Thanks people for your help and advice, and I hope this helps any others who have to go through this.

Cheers
Peter J

Adam Stoller

Note - you should also make sure to pull in the /iwadmin store from 7.3.2
You will have to migrate any WFM's, Components, and/or Templates separately from your old to your new system (spars or tar-files should work). There are things that HP provides in the /iwadmin store that need to be kept in sync with the installed version of TeamSite.