Interoperability backing store between unix/linux & Windows

Hi there,

I recently changed company ,and am working now on systems that run both on windows and linux.

I previously did a migration from a Solaris to a Linux system ,and that went flawless. (although I needed to updated the user entity db here and there).

I 'm wondering if someone already figured out some trick to move a backing store from a windows system to a linux/unix system.

I know officially that's not supported ,but I'm pretty convinced there's gotta be a way around that. It's only a matter of using uid's/gid's in linux and sid's in windows.

It comes down to know where and how to alter this in the store db ,basically turning a windows store into a linux/unix store with the combination of a user entity db update. Eventsubsystem db is either way fully resetted.

Would be nice if HP came with a solution for this out of the box.

So if anyone out there that found a trick ,feel free to speak up :-)

The alternative would be to copy over the lot with opendeploy,and script the lot using the deploy'n run stuff to cover the editions. But given the amount of editions would be long long task.

Thanks for any reply (even negative ones).

Kind regards,

Koen

Find more posts tagged with

Comments

nipper

Not possible. I have tried a number of ways.

OD is you best bet, or stay on Linux. :-)

DeSmetKoen

Hi Andy,

Thanks for your reply. I was kind of expecting this answer.

So you did already some migrations then. In my case the purpose is going from windows to linux.

I'll write the tool based on OD and sell it off to HP :-) :-) ...

Kind regards,

Koen

nipper

Make certain you do edition different deployments. I had one guy basically push everything in an edition a d submit. The backingstore grew dramatically because of all the redundant data. It will be much faster as well.

Adam Stoller

Why would you do an edition-difference deployment?

Or do you mean to do a difference from staging between STAGING and EDITION/INITIAL? (that would make sense)

The alternative would be to generate the list of files in staging and just do a filelist-based deployment from staging

In either of the above cases, you would want to have the transfer of EAs enabled.

After setting up the baseline (and submitting it on the target side) - then create the workareas you want on the target side and do a differential deployment from the workareas on the source side (workarea comparison against staging) again with EA transfer enabled.

All history will be lost, the modified-by and modified-dates will all be wrong - but the assets will be transferred and you should end up with the same list of modified files on the target system that you have on the source system (unless you don't care about bringing over modified files, in which case you can skip that step)

(Topic_40163)OS_BIRT_2.6.2_JavascriptLikeFilterUsingRegex.rptdesign

DeSmetKoen

Correct Ghoti. You'll be loosing this info indeed. I've seen it before on previous copies between servers.

You'd need to create your own db with this info to set this kind of info manually each time.

Complex ,but do-able.

Thanks for your assists here ..

Koen

nipper

My point was if you want the history then deploy each edition and submit and publish. However if you do that you need to be efficient with OD either pushing only the differences between each edition or use date different deployments.