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; } } }

strange iwat trigger issue

Adam Stoller

Environment[indent]TS 6.7.2 SP2 + P1
W2K3
WFM[/indent]Scenario[indent]I have an iwat script:

\Interwoven\TeamSite\local\bin>iwperl -w -c iwat_grouptask.ipl
iwat_grouptask.ipl syntax OK

I have that script registered on my server:

\Interwoven\TeamSite\local\bin>iwlsat
ID: 8380 "TaskGroupTaken" /Interwoven/TeamSite/iw-perl/bin/iwperl /Interwoven/TeamSite/local/bin/iwat_grouptask.ipl

The script sends output to a log file when run:

2010/04/30 14:28:55 DEBUG > iwat_grouptask.ipl:28 - In iwat_grouptask: company\userid, iwat_test, GROUP
...
2010/04/30 14:29:00 INFO > iwat_grouptask.ipl:74 - [48585:IWAT] Set owner of EMAIL to: 'company\userid'

[/indent]
Issue[indent]The problem we're having is that while the script works just fine when some of us take ownership of the grouptask, it fails to run when others take ownership of the grouptask (no errors in any of the log files I've looked at, no output anywhere - other than the expected event showing up in the iwevents.log, and no change of task ownership)

suggestions for how to further debug / diagnose it?

Find more posts tagged with

Comments

Migrateduser

It's a bit of a reach, but is it possibly an impersonation issue? If it was, I would have thought you would see something in iwutild.log, but I'm sure you checked there. What does your iwutild.cfg look like?

Adam Stoller

It's a bit of a reach, but is it possibly an impersonation issue? If it was, I would have thought you would see something in iwutild.log, but I'm sure you checked there. What does your iwutild.cfg look like?

I thought about that - when there was an error in my script I did see some output in iwutild_cmdout.log - but after fixing that - when it runs for me or runs for someone for which it doesn't work - there's nothing in either iwutild_cmdout.log nor iwutild.log.

I also didn't do anything to configure it for iwutild (and again, it works for some of us, but not others).

Interestingly - and quite possibly related - in another part of our customizations (not the iwat trigger) we were using iw_cgi_wrapper.cgi to run some scripts -- and it worked just fine for some of us, but caused 500 errors for others ... and with the limited number of users we have right now in our development environment... it was the same users who had problems with the iw_cgi_wrapper.cgi that have problems with the iwat trigger script.

I suppose we could try adding something to the iwutild.cfg for this, but it doesn't explain why it worked just fine for some of us without having done so. (100% failure or 100% success I can deal with - 60%/40% success/failure is maddeningly frustrating)

ISCBorisB

we were using iw_cgi_wrapper.cgi to run some scripts -- and it worked just fine for some of us...

By chance, did your Admins play with the .../teamsite/bin Folder Security settings like for example Permission Inheritance?
What's your Authentication mechanism? Is it local? If it is, do users that iwat works for are members of some privileged OS
Group like Administrators?

Adam Stoller

By chance, did your Admins play with the .../teamsite/bin Folder Security settings like for example Permission Inheritance?
What's your Authentication mechanism? Is it local? If it is, do users that iwat works for are members of some privileged OS
Group like Administrators?

No - I don't think the Admins played with any folder security stuff.
However, we did notice (just before leaving for the day) that the people for whom the trigger and iw_cgi_wrapper.cgi worked - were all members of domain groups that were members of the local server's Administrators group - and the users for whom it didn't work were not members therein.

This would seem to imply some local-policy setting that users would need to be a part of in order for this stuff to work (yes?) though it still seems strange to me with regard to the iwat trigger at least, since I didn't think that ran 'as' anyone other than the service process owner.

sampleRpt.rptdesign

ISCBorisB

This would seem to imply some local-policy setting...

I certainly hope not...

We have very similar settings in 3 CMS Environments (Windows, 6.7 SP2, no Patch). Authentication is through ADS, all users are Domain OS Users.
With the exception of 3-4 Administrators nobody has local Servers' account nor belongs to the Administrators Group. We have no problems whatever
running iw_cgi_wrapper to impersonate anybody. To the best of my knowledge, no problem with the Utility Daemon either.

It *seems* that in your TS Configuration Services have problems issuing some privileged commands like "Run As", etc. So...
What is the "Log On As" Attribute of IW Services, especially iwteamsite and iwutild? Is it "Local System Account" (default, and our case) or have you
changed it to something else?

Adam Stoller

...
It *seems* that in your TS Configuration Services have problems issuing some privileged commands like "Run As", etc. So...
What is the "Log On As" Attribute of IW Services, especially iwteamsite and iwutild? Is it "Local System Account" (default, and our case) or have you
changed it to something else?

Hmm - well, I hadn't thought about that, but we do have a domain account being used to run the iwserver process (configured as per KB 49040) because the backing store is on a NAS device.

However, this still doesn't (to me) explain why these things (iwat trigger, iw_cgi_wrapper.cgi) work for some of us but not all of us - and thus far the only thing we've been able to identify (as of EOB Friday) was that the ones for whom it works for are members (directly or indirectly) of the local Administrators group and the ones for whom it doesn't work aren't.

I'm hoping to go through policy settings for the Administrators group to see if anything stands out (like maybe they need log-on-locally privileges?).
At the same time, I've opened a case with Support to see if they can shed any light on this - we're heading into "crunch-time" with respect to the development effort on this project and it's kind of a pain when something that works the way one expects for the developers fails for the users...

ISCBorisB

However, this still doesn't (to me) explain why these things (iwat trigger, iw_cgi_wrapper.cgi) work for some of us but not all of us - and thus far the only thing we've been able to identify (as of EOB Friday) was that the ones for whom it works for are members (directly or indirectly) of the local Administrators group and the ones for whom it doesn't work aren't.

I can only speculate on that either... Be it as it may, is services "Log On" domain account itself a member od Administrators Group?
If not, what happens if you add it?

Adam Stoller

I can only speculate on that either... Be it as it may, is services "Log On" domain account itself a member od Administrators Group?
If not, what happens if you add it?

Assuming you mean "of" not "od" (as in OpenDeploy) - then yes, the domain account used to run the TeamSite service is a member of the local Administrators group (and has been since it was set up)

Again though, I don't see why this would affect the iwat trigger script such that it runs for 3 of 5 users and not 5 of 5 (there are soon to be more people testing and I have a feeling that the percentage of users for whom the trigger fires is going to go down sharply)

ISCBorisB

Assuming you mean "of" not "od" (as in OpenDeploy) - then yes, the domain account used to run the TeamSite service is a member of the local Administrators group (and has been since it was set up)

Again though, I don't see why this would affect the iwat trigger script such that it runs for 3 of 5 users and not 5 of 5 (there are soon to be more people testing and I have a feeling that the percentage of users for whom the trigger fires is going to go down sharply)

That was certainly supposed to be "of" - Fat Fingers typo.

Adam Stoller

FYI

)

Migrateduser

Hi Fish -
Did you ever hear back from Support on this issue? We're running into it also:

On our 6.7.1 machine (Solaris), we've got an iwat trigger that, whenever a new group-shared workarea is created, performs a chmod -R g+s (shared group) on the workarea so that all of the directories in the workarea belong to the 'shared with' group. It's been working well for some years now.

However, on our 7.1 machine, we get inconsistent results with this trigger - much as you describe for your trigger.

The difference seems to be whether or not the person logged into ContentCenter is an OS-level user (someone actually with an account on the Solaris machine) vs. an LDAP user. It's working for the OS user, but doesn't even trigger for the LDAP user. On our 6.7.1 machine, all of the users are OS users.

And, for the OS folks it does trigger for, the file-system permissions appear to be those of the OS user and not of the owner of the persistent iwat process. Even if I ps -ef and see the trigger process owned by root, it appears to be passing through the permissions of the TeamSite user. Not sure if this is as intended or not.

Wally

Migrateduser

I just found this in the 7.2 Release Notes, under the 'Notes' appendix. It wasn't in the 7.1 version of the Release Notes:

iwat script permissions. iwat scripts create files or inherit permissions from
the user invoking the iwatscript.

I'm going to look into what this means in terms of LDAP users....

Cheers,
Wally

Adam Stoller

I just found this in the 7.2 Release Notes, under the 'Notes' appendix. It wasn't in the 7.1 version of the Release Notes:

iwat script permissions. iwat scripts create files or inherit permissions from
the user invoking the iwatscript.

I'm going to look into what this means in terms of LDAP users....

Cheers,
Wally

I never did get a resolution on that - I think the case is still open, however since my involvement with the project ended at the end of June, I don't think I have access to the case notes anymore (had it transferred to the customer)

I'd be curious to know what (if any) resolution you find though.

boriskerzner

We ran into the same issue on TeamSite 6.7.2, Service Pack 2, and we solved it by adding the following to iw.cfg:

[authentication]
disable_ext_task_impersonation=true

This directive is described on page 58 of the TeamSite Administration Guide for Windows in the "External Task Impersonation" section. Nothing in the section appears to indicate that this directive would solve the above-mentioned problem, but the name of the directive was a leading sign so we tried it, and voila(!) it worked!