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.5 Catalina Errors on Solaris

mike_jaixen

In preparation for a migration from 5.5.2 to 6.5, we have installed 6.5 on a new box under Solaris 9. The server installed and we were able to get the login screen but unable to move forward. Since our sysadmins guard "root" access with their life, we needed to change the ownership and permissions on iw-home from iwui to our Interwoven account. (We have it installed as /software/interwoven/teamsite)

I then went in and edited the roles files, and tried to log in again. But now we receive 500 Internal Errors from TeamSite. We've looked at the permissions several times and can't understand why it is failing now.

The logs/iwui/servletd.log file reports several errors that indicate that the servlet engine can't access files:
SEVERE: The scratchDir you specified: /software/interwoven/teamsite/servletd/work/Catalina/localhost/iw-cc is unusable.
java.io.FileNotFoundException: /software/interwoven/teamsite/servletd/conf/Catalina/localhost/iw-cc.xml (Permission denied)
SEVERE: The scratchDir you specified: /software/interwoven/teamsite/servletd/work/Catalina/localhost/iw_eventsubsystem is unusable.
log4j:ERROR setFile(null,true) call failed.
java.io.FileNotFoundException: /software/interwoven/teamsite/servletd/logs/iweventproxy.log (Permission denied)
java.io.FileNotFoundException: /software/interwoven/teamsite/servletd/conf/Catalina/localhost/iw#eventsubsystem.xml (Permission denied)

But all of the files have the same ownership and permissions:
drwxrwxr-x 3 iwov_acct webgrp 96 Dec 30 14:09 iw-cc
-rwxrwxr-x 1 iwov_acct webgrp 143 Dec 30 14:09 iw-cc.xml
-rwxrwxr-x 1 iwov_acct webgrp 579445 Jan 5 13:28 iweventproxy.log
-rwxrwxr-x 1 iwov_acct webgrp 155 Dec 30 14:09 iw#eventsubsystem.xml
(775, owned by our Interwoven account)

Interwoven Support suggests uninstalling and starting over fresh with a clean install, but that doesn't explain this problem. If these files are okay to be owned by a non-existant account (iwui) and group nobody, then why won't it work here. Any thoughts?

Find more posts tagged with

Comments

Migrateduser

Mike,

The work directory under $IWHOME/servletd serves as a "scratch" directory for servletd. This is where jsp's are converted to Java code; from there, the code is compiled into class files. The error you list indicates that servletd does not have write permission to those directories. Is it possible that servletd is being run as a user other than iwov_acct and not part of webgrp?

--Daniel

Migrateduser

TeamSite has start-up scripts that refer to user iwui, so your
servletd is probably running as the wrong user.

There are also binaries that are setuid root, and if you changed them
things will break. This is used as various spots for impersonation,
so they should not be changed. If the goal is to lock down the
system by changing file permissions that's generally not going to
work, unfortunately. There may be some places it won't break,
but generally it's going to cause problems. You also may run
afowl during installation of patches or service packs.

I would suggest either reinstalling (which you didn't want to do) or
getting a recursive file listing from someone with a fresh 6.5 install
and changing the file attributes back. My own installs are rather
non-standard (internal images) but maybe someone in the devnet
community can help.

You might ask your IT department if they will let you use "sudo" for
some maintenance tasks (resetting the server, etc), if you're not
already using that tool.

Hope that helps,

Jason Heirtzler
Interwoven Engineering

mike_jaixen

We ended up restoring the old permissions and ownerships from a backup. We'll just make the file ownership changes to only the files that we need to; that seemed to solve this issue.