Backing store migration from 6.1 to 6.7.1 failing

TeamSite 6.1 SP1 solaris 2.9 (I know 6.1 SP1 isn't supported but decided to give it a try anyway)
TeamSite 6.7.1 Beta - RHEL 4

I am trying migrate my 6.1 backing store across platforms and versions and am getting an error. I am not sure if it is my misunderstanding of how this works, but here is what I did:

1. Mounted the 6.1 backing store on the 6.7.1 server in /mnt/teamsited02

2. Attempt to run the iwmigrate command into the current 6.7.1 /default store:


Command line: /apps/intrwvn/iw-home/bin/iwmigrate -m /mnt/teamsited02 -o /apps/intrwvn/iw-store
No locale specified, using native locale for this system
Converted backing store location is /apps/intrwvn/iw-store
Configured backing store on system is /apps/intrwvn/iw-store
Error, output directory /apps/intrwvn/iw-store is the configured backing store
for your system.  You must specify a different location for the
output directory.
iwmigrate quits

3. So I created another store called d02 and ran the command again:


Command line: /apps/intrwvn/iw-home/bin/iwmigrate -m /mnt/teamsited02 -o /apps/intrwvn/d02
No locale specified, using native locale for this system
Converted backing store location is /apps/intrwvn/d02
Configured backing store on system is /apps/intrwvn/iw-store
Starting backing store environment
ERROR: no valid submit config file found in the current configuration (/apps/intrwvn/iw-home/conf/events/submit.conf, /apps/intrwvn/iw-home/local/config/submit.cfg, /apps/intrwvn/iw-home/config/submit.cfg, /apps/intrwvn/iw-home/local/config/submit.cfg) (2)
ERROR: no valid autoprivate file found in the current configuration (/apps/intrwvn/iw-home/conf/events/autoprv.txt, /apps/intrwvn/iw-home/local/config/autoprivate.cfg, /apps/intrwvn/iw-home/config/autoprivate.cfg, /apps/intrwvn/iw-home/local/config/autoprivate.cfg) (2)
[Tue Oct 10 14:45:10 2006] Reading users and groups...
[Tue Oct 10 14:45:10 2006] Loading disk cache from Tue Oct 10 14:41:05 2006, revision = 1.
[Tue Oct 10 14:45:10 2006] done. 4 users and 12 groups read.
[Tue Oct 10 14:45:10 2006] [iwserver] branch_default_perm=775
[Tue Oct 10 14:45:10 2006] [iwserver] directory_default_perm=775
[Tue Oct 10 14:45:10 2006] [iwserver] file_default_perm=664
[Tue Oct 10 14:45:10 2006] [iwserver] workarea_default_perm=775
[Tue Oct 10 14:45:10 2006] New webserver_uid nobody (99)
[Tue Oct 10 14:45:10 2006] New vannotate_uid iwui (500)
[Tue Oct 10 14:45:10 2006] Log Permissions Disabled
[Tue Oct 10 14:45:10 2006] Login Daemon Enabled
[Tue Oct 10 14:45:10 2006] :ORT ME:: _get_vm_total
[Tue Oct 10 14:45:10 2006] :ORT ME:: _get_vm_total
[Tue Oct 10 14:45:10 2006] :ORT ME:: _get_vm_total
[Tue Oct 10 14:45:10 2006] Memory monitor is disabled
[Tue Oct 10 14:45:10 2006] IW Global Group = iwglobal and ID = 502
[Tue Oct 10 14:45:10 2006] Reading userops file /apps/intrwvn/iw-home/private/etc/userops.xml ...
[Tue Oct 10 14:45:10 2006] Done reading userops file /apps/intrwvn/iw-home/private/etc/userops.xml
[Tue Oct 10 14:45:10 2006] Reading userops file /apps/intrwvn/iw-home/private/etc/userops_ui.xml ...
[Tue Oct 10 14:45:10 2006] Done reading userops file /apps/intrwvn/iw-home/private/etc/userops_ui.xml
[Tue Oct 10 14:45:10 2006] TEnvironment: fd limit 1024 max 1024
[Tue Oct 10 14:45:10 2006] Initialized store 0x64 at "/apps/intrwvn/d02" (version=300007, next id=0x200).
[Tue Oct 10 14:45:10 2006] TFSEnvironment: inode cache 30000
[Tue Oct 10 14:45:10 2006] Creating new inode tables.
[Tue Oct 10 14:45:10 2006] Batch Jobs Thread started
Remote server version string is iwserver: 6.7.1 Build 58202 Interwoven 20060804
Opened SCI session with iwserver
Internal error, vpath  does not begin with '/'
Error parsing vpath

Total files/directories/symlinks copied: 0

Total bytes of data copied: 0

Total EA's copied: 0
Shutting down backing store environment...
(This may take a while because the cache must be flushed)
Please wait...
[Tue Oct 10 14:45:11 2006] TEnvironment::Flush flushed 0, unlinked 0
[Tue Oct 10 14:45:11 2006] TEnvironment::Freeze freeze until Wed Oct 10 14:45:11 2007
[Tue Oct 10 14:45:11 2006] Shut down store 0x64 at "/apps/intrwvn/d02" (next id = 0x200).
Shutdown of backing store environment complete.
Backing store environment is shut down
iwmigrate failed
iwmigrate can be restarted by running
"iwmigrate -o /apps/intrwvn/d02/"

What strikes me as odd is that my remote server is listed as 6.7.1, instead of 6.1, which makes me think I have somehow inverted the command. Or quite possibly it is not possible to move from solaris to linux, although both are using the same nfs protocol, so I am inclined to believe that is not the issue.

Assume it is something dumb.

Find more posts tagged with

Comments

Adam Stoller

TeamSite 6.1 SP1 solaris 2.9 (I know 6.1 SP1 isn't supported but decided to give it a try anyway)
TeamSite 6.7.1 Beta - RHEL 4

I am trying migrate my 6.1 backing store across platforms and versions and am getting an error. I am not sure if it is my misunderstanding of how this works, but here is what I did:

1. Mounted the 6.1 backing store on the 6.7.1 server in /mnt/teamsited02

2. Attempt to run the iwmigrate command into the current 6.7.1 /default store:
Command line: /apps/intrwvn/iw-home/bin/iwmigrate -m /mnt/teamsited02 -o /apps/intrwvn/iw-store
No locale specified, using native locale for this system
Converted backing store location is /apps/intrwvn/iw-store
Configured backing store on system is /apps/intrwvn/iw-store
3. So I created another store called d02 and ran the command again:
Command line: /apps/intrwvn/iw-home/bin/iwmigrate -m /mnt/teamsited02 -o /apps/intrwvn/d02
No locale specified, using native locale for this system
Converted backing store location is /apps/intrwvn/d02
Configured backing store on system is /apps/intrwvn/iw-store

In the first example you have:

And iwmigrate sees /apps/intrwvn/iw-store for the configured backing store and /apps/intrwvn/d02 for the converted backing store. This seems to indicate to me that /mnt/teamsited02 might be referencing the wrong store - i.e. it might be referencing the store configured for 'default' on your Linux server rather than the store configured on your Solaris server.

Bill Klish

Running mount on our linux 6.7.1 server:


[root@teamsited03 main]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
none on /proc type proc (rw)
none on /sys type sysfs (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda1 on /boot type ext3 (rw)
none on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
none on /apps/intrwvn/iwmnt/default type pmfs (rw,store=/iwserver/default)
none on /apps/intrwvn/iwmnt/iwadmin type pmfs (rw,store=/iwserver/iwadmin)
nfsd on /proc/fs/nfsd type nfsd (rw)
teamsited02:iwserver on /mnt/teamsited02 type nfs (rw,rsize=8192,wsize=8192,nfsvers=2,intr,tcp,addr=X.X.X.X)

I switched the 2 runs because I thought it meant I couldn't migrate from my 6.1 default store directly to my 6.7.1 default store, which I didn't think made sense, so I tried to run against a newly created 6.7.1 store.

msrinivas

From 6.7 Release Notes:

Upgrade Paths

You can install TeamSite 6.7 from TeamSite 6.1 SP2 or TeamSite 6.5 SP2.

So lack of SP2 might be one of the reasons.

The other reason that I think is more plausible is this is considered a cross-platform upgrade. So you might have to do custom scripts or use OD to do the upgrade.

P.S. Its not a good idea to directly mount an older version on a newer version server and run iwmigrate. I know of people who messed up the existing backing store and had to restore from back ups. I would HIGHLY recommend working with a copy.

HTH.

Bill Klish

Thanks. I heard back from Interwoven and there are some steps that need to be performed for this to work. The full documentation will be included in the GA release of 6.7.1.

tgerber

Well be careful upgrading if you use Active Directory or LDAP. At least in 6.7.0 and beta of 6.7.1 domain local groups are broken. We've had a case open for 3 months with no real progress.

Bill Klish

Thanks for the tip. We are actually going in the other direction. We are migrating from local group to LDAP, so that will be just as fun.....