nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

6.7.2 sp1

bturns

Solaris 10
6.7.2 sp1

I've experienced Java errors in the GUI when installing 6.7.2 sp1. It appears with every install the permissions on the directories $iw-home/servletd/conf, $iw-home/servletd/work and $iw-home/servletd/webapps have been set recursively to be owned by root. I resolved this by:

1) recursively setting the owner of these directories to be iwui
2) restarting TS

Find more posts tagged with

Comments

nipper

Funny, I ran this yesterday on 2 Linux servers. Worked great. I was actually pleased that the installer did not ask for a lot of parameters that TS knows already (DB connectivity, etc)

Andy

Migrateduser

Even I faced some permission issues and some Java components were missing after SP1 upgrade in Solaris 10.

tanguyr

Even I faced some permission issues and some Java components were missing after SP1 upgrade in Solaris 10.

Could you give some more details on this? We've just installed SP1 (+ a patch on SP1) on a Solaris machine and we've had problems with groups disappearing on files and folders in certain branches.

/t

Migrateduser

We had two main issues after TS 672 SP1 upgrade:

1. Some of the SitePublisher GUI items like File --> New Page, SitePublisher --> Manage segments, New node (under SiteMap) were giving HTTP 500 Java exceptions. We raised a case with Interwoven and got a LS black patch.

2. When we migrated content store from TS 671 SP1 to 672 SP1 along with tsgroups and tsusers files, we observed Groups were missing in the branches and the workarea sharing was changed from Groups to Induviduals. We used iwaccess CLT to add missing groups and set permission for the workareas.

And in your case, do you see the issue with all the branches under default and iwadmin content stores, or only with few branches?

You can either use iwaccess CLT to set the missing groups OR if you've migrated content store to 672 SP1 from different server, you can make use of iwidmap CLT for mapping users, groups.

Antharix

was there any response/suggestions from support site. Is this issue specific to Solaris environment?

tanguyr

We had two main issues after TS 672 SP1 upgrade:

1. Some of the SitePublisher GUI items like File --> New Page, SitePublisher --> Manage segments, New node (under SiteMap) were giving HTTP 500 Java exceptions. We raised a case with Interwoven and got a LS black patch.

We also got the "LS black patch" to fix the issues with creating/editing sitepublisher files. We also had problems when editing components, or adding components to existing pages. As far as i can tell, it had to do with the version of the site as originally created: we had more recent sites (created under 3.1 or later) that had less problems and older sites (created under 3.0) that had waaaaay more.

2. When we migrated content store from TS 671 SP1 to 672 SP1 along with tsgroups and tsusers files, we observed Groups were missing in the branches and the workarea sharing was changed from Groups to Induviduals. We used iwaccess CLT to add missing groups and set permission for the workareas.

And in your case, do you see the issue with all the branches under default and iwadmin content stores, or only with few branches?

Yup, this second one sounds a lot like what happened to us: groups disappearing from files/folders in some branches - braches under default with a sitepublisher site in them ("normal" branches under default were not affected). In our case, we were going from 6.7.2 to 6.7.2 SPI, which is pretty much the shortest upgrade path possible, so it's strange that we've had so many problems.

You can either use iwaccess CLT to set the missing groups OR if you've migrated content store to 672 SP1 from different server, you can make use of iwidmap CLT for mapping users, groups.

We restored the groups on our dev server by copying them over from our integration server (they have 99% the same content/structure, but we can't take this approach in live because of all the differences. We could "record" the groups-to-folders mapping in a datafile before applying the SP and restore it afterwards, but right now we've decided not to go forward with SP1: given how many problems we've had we're a little scared of what else might be lurking out there...

In any case, thanks for taking the time to answer my post, i appreciate knowing that we're not the only people to have these issues.

regs,
/t