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

Perl wrapper

System

I am very new to the concept of perl wrapper. I need to know more about it, and i also need to understand how can i include a perl wrapper in a tpl to run some CLTs.

Can someone please give me links to site/docs which can help me learn and write/use wrapper functionality.

Thanks
Dixit
TS 6.5 SP3 Win 2000

Find more posts tagged with

Comments

cute_guy

I am very new to the concept of perl wrapper. I need to know more about it, and i also need to understand how can i include a perl wrapper in a tpl to run some CLTs.

Can someone please give me links to site/docs which can help me learn and write/use wrapper functionality.

Thanks
Dixit
TS 6.5 SP3 Win 2000

To run clts in tpl
you can do it within the iw_perl tag of tpl, run the command within backticks(`)

Migrateduser

To run clts in tpl
you can do it within the iw_perl tag of tpl, run the command within backticks(`)

Thanks, I know that we can run the CLTs from iw-perl tag, but there is certain requirement/scenario/permission issues, which i need to tackle.

I need to read certain external attributes of files from another branch where the user does not have any kind of access. So i was thinking if this can be achieved using a wrapper. Just contemplating an option.

Thanks
Amit

MAK

Thanks, I know that we can run the CLTs from iw-perl tag, but there is certain requirement/scenario/permission issues, which i need to tackle.

I need to read certain external attributes of files from another branch where the user does not have any kind of access. So i was thinking if this can be achieved using a wrapper. Just contemplating an option.

Thanks
Amit

Hi Amit,

I am not sure if i understand your requirement.
But if you want to execute a Perl script to perform some actions (like reading ext attr) within your tpl, you can iw_system to execute perl script or
execute pm function within your iw_perl tag.

Migrateduser

Hi Amit,

I am not sure if i understand your requirement.
But if you want to execute a Perl script to perform some actions (like reading ext attr) within your tpl, you can iw_system to execute perl script or
execute pm function within your iw_perl tag.

Hi,

Whats happening is, when user regenerates a page in branch1, the tpl tries to read some external attribute stored on a file in branch2.
The user who regenerates/generates the page does not have any access in branch2. So when the tpl fires the iwextattr command it is not able to read the external attribute as this process is run with the user as its owner.
I need a way so that the iwetattr comand is executed with SYSTEM as the owner. I hope the requirement is clear now.

-Amit

Migrateduser

Can you please give me a reference for iw_system , which u mentioned in the previous post.

Thanks
Amit

Adam Stoller

Can you please give me a reference for iw_system , which u mentioned in the previous post.

Thanks
Amit

You can either look at

http://your-ts-server/iw/help/tst

- and from there look at the various directives that are available - or from the command line run iwperldoc TeamSite:T::iw_system.

However, I'm not sure if iw_system will force the script to be run as SYSTEM (please report back your findings) - if you're unsure - make a simple Perl script that creates a temporary log file and dumps the complete contents of %ENV into it. The owner of the file should either be the logged in user or a system account, the contents of the file should also help to determine "who" is running the script.

Adam Stoller

You can either look at
http://your-ts-server/iw/help/tst
- and from there look at the various directives that are available - or from the command line run iwperldoc TeamSite:T::iw_system.

However, I'm not sure if iw_system will force the script to be run as SYSTEM (please report back your findings) - if you're unsure - make a simple Perl script that creates a temporary log file and dumps the complete contents of %ENV into it. The owner of the file should either be the logged in user or a system account, the contents of the file should also help to determine "who" is running the script.

The other "solution" is to adjust the access on this other file (either directly or by moving it to a more general location if possible) such that all users would have READ access to it.

Migrateduser

The other "solution" is to adjust the access on this other file (either directly or by moving it to a more general location if possible) such that all users would have READ access to it.

Adam,
This solution wont fit into the business rules, the ownership of this branch lies with an external group, and access to this cannot be altered.

However, writing the external attributes to another readable area was possible, but business, due to some "un explainable/quaotable reason", is not ready to go ahead with that. Smiley Happy

-Amit

Adam Stoller

Adam,
This solution wont fit into the business rules, the ownership of this branch lies with an external group, and access to this cannot be altered.

However, writing the external attributes to another readable area was possible, but business, due to some "un explainable/quaotable reason", is not ready to go ahead with that.

-Amit

The test output of the script (to dump %ENV info) is to verify the owner of the process that is invoked from iw_system. If it turns out to be the logged in user - you're still stuck with the same problem. If it turns out not to be the logged in user - then it provides a likely way to get around the issue without having to move the file or change the access on it.

A convoluted method would be to kick off a no-op deployment with a DNR script (which I believe runs by default as SYSTEM - or can be set explicitly to do so?) and have that script retrieve the information into a temporary files (passed in on the command line as a parameter) and then after the deployment is done retrieve those values from that temporary file -- definitely a kludge - but if it's the only way to achieve what you need - do it and document the **** out of it.

Migrateduser

The test output of the script (to dump %ENV info) is to verify the owner of the process that is invoked from iw_system. If it turns out to be the logged in user - you're still stuck with the same problem. If it turns out not to be the logged in user - then it provides a likely way to get around the issue without having to move the file or change the access on it.

A convoluted method would be to kick off a no-op deployment with a DNR script (which I believe runs by default as SYSTEM - or can be set explicitly to do so?) and have that script retrieve the information into a temporary files (passed in on the command line as a parameter) and then after the deployment is done retrieve those values from that temporary file -- definitely a kludge - but if it's the only way to achieve what you need - do it and document the **** out of it.

Thanks Adam,

Will be on it. However if I come back to the concept of perl wrapper, which i mentioned in my first step, I want to understand can a wrapper be used somehow to solve the issue. But before that i need to understand what exactly a wrapper can do. I read in the manuals that iw_cgi_wrapper.cgi is used for impersonization of TEamsite. Can you throw little more light on a perl wrapper(not cgi wrapper), or it would be great if U could provide me some links on it.

Thanks
Amit

Attendance.rptdesign

Adam Stoller

Thanks Adam,

Will be on it. However if I come back to the concept of perl wrapper, which i mentioned in my first step, I want to understand can a wrapper be used somehow to solve the issue. But before that i need to understand what exactly a wrapper can do. I read in the manuals that iw_cgi_wrapper.cgi is used for impersonization of TEamsite. Can you throw little more light on a perl wrapper(not cgi wrapper), or it would be great if U could provide me some links on it.

Thanks
Amit

iw_cgi_wrapper.cgi is a binary setuid root (on Unix) program that is used to coerce the server into running the script referenced after it as if it were executed by the logged in user.

It used to be (and perhaps still is, but I recently ran into a case where it wasn't) the case that if you did not use iw_cgi_wrapper.cgi that TeamSite would run the URI as the owner of the TeamSite (or iwwebd) process - which on Unix used to be root. I think that changed somewhere within the 6.x timeframe - which then makes the usage of the wrapper somewhat questionable.

The other form of 'wrapper' that used to be used for externaltask scripts on Windows was creating a copy of show_env.cgi and naming it to be the same as the perl script (but with a .cgi instead of .ipl extension) - that binary was simply a mechanism for getting past some IIS issues with trying to run non-binary .cgi programs and/or non-binary .ipl programs. This, I believe became largely obsolete in 5.5.2 when iwwebd took over for the "customer webserver" for everything except preview - now you can use .ipl files directly and just make sure the #! line is correct (even though it isn't "used" by Windows, it is looked at and makes a difference for iwwebd).

None of the above really helps you for running CLTs from a PT - because I'm pretty sure that the PT engine is set to run as the logged in user so anything that is run by the PT is also run as the logged in user.

For that - if you handle the page generation via workflow - the option is to make sure that the externaltask (or cgitask) script is "owned" by some user who has access to read the file you want to reference and write the file you need to output. This, however, won't help if you need to do this for Preview.

Migrateduser

Thanks Adam,

For the reply, it really helped me to see things clearer!

Closing the Thread now.

As far as the issue is concerned, the business didn't want to spend money on creating workflows or other things, so we made some changes to the submit.cfg to allow users to see only certain folder.

This solution worked and business was quite happy ---- Smiley Happy

-Dixit

stacktrace.jboss.log.txt