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)
Backing Store Issue after TS 6.1 Solaris Install
System
G'day All -
I've got a support case going on this also, but I thought I'd cover all bases by posting here.
I was running 6.0 TS on Solaris on my dev server and attempted the 6.1 upgrade. It didn't work correctly for me. I tried fixing the issue unsuccesssfully and things got worse from there. At some point, I decided it would be better to do a fresh install of TS rather than attempt to fix the upgrade.
In preparation for this, I saved off the Backing Store that I'd been working with in 6.0. I did this by executing the following command:
> mv iw-store iw-store_bak
Then, I successfully performed the fresh install of 6.1. It created a new backing store at /iw-store. I stopped TeamSite and all associated processes then tried to swap in the backed up Backing Store:
> mv iw-store iw-store_new (move the freshly created backing store to another directory)
> mv iw-store_bak iw_store (move the previously backed up backing store back into production)
and then restarted TeamSite.
TeamSite came up fine, but now it doesn't recognize the contents within the 'old' backing store. It only shows the initial branch as if it were a brand new backing store. None of the content is showing up. In the TS Admin interface, the server status shows the correct disk space usage as if all of the content and branches exist, but TS isn't seeing them.
I've attempted to use the Admin CLTs: They recognize the store as in production. I've deactivated and readded the store successfully (according to the CLT feedback). Still no content.
Permissions all seem OK at the file level.
Here's one issue I see as a possible clue:
When I run the diagnostics tool against TS with the 'old' backing store in place, I get the message during execution:
It appears as though Teamsite is not running
or the mount point is unavailable. This means
some values will not be present in the output
so it appears that the diagnostic tool can't correctly find the content either. I've sent the truss output associated with the running of this portion of the diagnostics tool and they're taking a look.
One thing I'm hesitant to do is to add a new branch to the 'old' backing store, as I don't want to introduce any corruption.
Ideas? Suggestions? All are appreciated!
Thanks,
Wally Box
Nike, Inc.
Find more posts tagged with
Comments
Migrateduser
Wally,
As I understand it, there is no conversion that takes place on the B.S. between 6.0 and 6.1. So, I would think that a B.S. from 6.0 should work on a 6.1 installation. Perhaps IWOVDAVE could confirm this? I think I already know the answer to this, but do you still have a 6.0 installation that you can test the backing store in (to make sure that no corruption occurred at any point)? Also, have you run iwfsck?
Let me know what you find out from iwfsck.
Thanks,
Jason
Migrateduser
Hey Jason -
I just ran iwfsck with each level of verbosity. No errors found and it also doesn't find any of the 'old' content within the /iw-store area.. it looks like it's running against a brand new backing store.
I have a nagging suspicion there's a symlink or something of that low level Solaris nature involved?..
Wally
Migrateduser
Wally,
Can you run
iwstoreadm
and post the output?
Also an
ls -l -a
of the <IW-STORE> directory would be nice.
I'm wondering if you're running into an issue of multistores or something like that.
- Jason
Migrateduser
Several things:
cambob$ sudo iwstoreadm -l
Password:
Name Store Directory ID Comment
---- --------------- -- -------
default /iw-store/default 0x65
cambob$ sudo ls -l -a /iw-store
Password:
total 18
drwxr-xr-x 5 root other 512 May 13 10:14 .
drwxr-xr-x 43 root root 1536 May 13 10:14 ..
-rw------- 1 root other 4 May 12 11:48 STOREID
-rw------- 1 root other 4 May 12 12:04 STOREID_
-rw------- 1 root other 15 May 13 10:14 StoreRegistry
-rw-r--r-- 1 root other 0 May 13 10:14 TSRunning
drw------- 5 root other 512 May 12 11:48 default
drw------- 5 root other 512 May 12 11:48 events
drw------- 4 root other 512 May 12 11:48 workflow
and finally, I ran into the same issue as another person posted a while ago at
http://devnet.interwoven.com/forums/cgi-bin/showthreaded.pl?Cat=&Board=PRODUCTS_TEAMSITE&Number=27848&Search=true&Forum=PRODUCTS_TEAMSITE&Words=iwfsck%20-b&Match=And&Searchpage=0&Limit=25&Old=allposts&Main=27848
where, if I run the iwfsck with the -b option and point at the location of the iw-store, I get different results than if I run it without the -b option:
cambob$ sudo ./iwfsck -**** -b /local/iw-store
Password:
Command line: ./iwfsck -**** -b /local/iw-store
iwfsck: 6.1.0 Build 33333 Interwoven 20040311
[Thu May 13 10:00:34 2004] Error...TMetaFile::Read, file=</local/iw-store/FORMAT/PointTypes>, open() failed.
No such file or directory
Cannot open backing store: No such file or directory
[Thu May 13 10:00:34 2004] Error...TMetaFile::Read, file=</local/iw-store/FORMAT/AttributeTypes>, open() failed.
No such file or directory
Error, unable to open backing store: /local/iw-store
The FORMAT directory contents are invalid, or your backing store path may be wrong.
Migrateduser
Wally,
One thing I noticed is that with the iwfsck -b command you were running against /local/iw-store. Shouldn't it just be /iw-store?
Wondering if this could be a permission problem. I'm not sure what the permissions are supposed to be on the iw-store, but it looks like they're pretty tight so that only root can read most of the info in your B.S. Don't see any multistore stuff going on, so permissions is really my only thought. Might want to look at the permissions on your production iw-store and see if they line up with cambob.
If it's not permissions, I think I'm tapped for ideas.
- Jason