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

Teamsite running as non-root

System

Hello everyone,

Here are the system configurations, on the environment I work.
OS - Solaris10
TS - 7.2.1
OD - 7.2.1

I am opening this thread to understand more if we run Teamsite to run as non-root user on solaris or linux machine.

Few of the pointers, I already have based on TS admin guide and from the KB articles provided by Autonomy.

We are already converting our TPLs to XSLs and also are in process to convert external tasks to URL based tasks. But we have almost 5000 external tasks (executable perl scripts behind the scene) and converting all to URL based tasks (java classes) is a big challenge as we need to run make-toolkit everytime we need to test the changes with the application.

I just wanted to check if someone has already converted running TS as non-root and can share the issues/exerience then it would be great help.
At our end the most challenging task we have is to convert external tasks to URL based task. Any help or suggestions are most welcome.

Thanks in advance!
Rajesh

Find more posts tagged with

Comments

interDev

Hello everyone,

At our end the most challenging task we have is to convert external tasks to URL based task. Any help or suggestions are most welcome.

Why do you need to convert them from external task to URL task? Converting 500 tasks from perl based to Java based classes will not be easy job and I would not make this change unless until there is real need as External tasks are supported without any problems.

Adam Stoller

Why do you need to convert them from external task to URL task? Converting 500 tasks from perl based to Java based classes will not be easy job and I would not make this change unless until there is real need as External tasks are supported without any problems.

Because they're attempting to run TeamSite as non-root, it would tend to follow that the "normal" impersonation performed by external tasks will not work in that context.

FYI: a URL External Task (and Email Task, and Deploy Task) is the same thing as an External Task - the only difference, once you get down to the job specification file level, is that URL External Tasks provide a URL for the 'command' element (the other such tasks are just [partially] pre-configured External Tasks)

Migrateduser

5000 unique scripts? Yikes. That seems a tad extreme. Is that normal?

sample_javascript.rptdesign

Migrateduser

5000 unique scripts? Yikes. That seems a tad extreme. Is that normal?

Yes, there are multiple applications hosted on a single TS server and hundreds of workflows are there to support various apps data.

nipper

Yes, there are multiple applications hosted on a single TS server and hundreds of workflows are there to support various apps data.

Just the testing required for the 5000 different scripts will takes months. Then add what happens when something needs to be changed. This will be a huge undertaking.

Migrateduser

Hundreds of workflows? 5000 unique scripts? Someone didn't design this very well. How many people support all that? And where the **** is Noida?

Migrateduser

Hello Guys,

I think we are distracting from the topic. I can explain why but I want to more stick to the discussion and don't want to this discussion to be highjacked. BTW Noida is not ****, you can always search it on the web. I think you all can help me and others (in future) to have answers for these queries.

Let me narrow down my discussion point. There are 3 processes (iwwebd, iwauth and iwutild) which need to run as root and we can convert one or possibly 2 to non root

1) Conversion of iwutild to non-root- it is documented by Autonomy and I am looking for a better way to convert external tasks to URL external tasks and easy way to handle this as we need to run multiple time make-toolkit in a day and make the UI down.

I also realise that we have cgi wrapper used in the cgi tasks and it can also cause problems for impersonations. Please provideyour thoughts on it.

2) If we use SSO and don't authenticate users via OS then we can can try changing iwauthen to run as no-root as iwuthen will be sitting idle. Please let me know your thoughts on this.

3) iwwebd - As far as I know this cann't be converted to a non-root user as it needs to handle the port below 1024. Please let me know if anyone have ideas if this can be handled as a non-root user.

Thanks
Rajesh

Migrateduser

With all due respect, if you're not happy with the responses you're getting here (from people you are not paying to help you, it should be noted), then by all means open a support ticket with Interwoven and get the help you do actually pay for. You are not entitled to anything here - it's a place where people help you out of the goodness of their little hearts.

The fact that you have so many workflows and scripts *should* be a cause of concern for someone over there and a great opportunity now to refactor them into something more reusable. But good luck with rewriting all of them in Java since you don't seem to care about that.

Migrateduser

With all due respect, if you're not happy with the responses you're getting here (from people you are not paying to help you, it should be noted), then by all means open a support ticket with Interwoven and get the help you do actually pay for. You are not entitled to anything here - it's a place where people help you out of the goodness of their little hearts.

The fact that you have so many workflows and scripts *should* be a cause of concern for someone over there and a great opportunity now to refactor them into something more reusable. But good luck with rewriting all of them in Java since you don't seem to care about that.

Hi Dave,

I don't want people to hurt in anyway. I just didn't want to distract to and to move to new discussion but I respect you all and learnt so many thing from the post you put here on this forum.

Let me explain it if this helps everyone in anyway. The TS env where I work is hosting content to more than 25000 web page and almost 500 mobile pages. It hosts data for almost 20 different applications on the website. There are 4 different TS production servers which host all this data.

There are several legacy workflows and we are discussing with clients over its frequency of uses and any way to get rid of those or if something can be managed with an existing workflow. So that we can reduce our overheads of working on those.

Let me know if you think I can provide anything else which can help here.

Rajesh

Migrateduser

Adding to it to explain why we are moving to TS non-root conversion. As there is security compliance which we need to abide by and that requires all applications to run as non-root user.

-Rajesh

nipper

Adding to it to explain why we are moving to TS non-root conversion. As there is security compliance which we need to abide by and that requires all applications to run as non-root user.

-Rajesh

Someone has to push back on this requirement. Is it possible, *maybe*, but the new development cost and the testing for all of your workflows and scripts will be extremely time consuming.

Just changing all of your external tasks to URL tasks will be quite time consuming, they will not all work immediately so you need to add a couple hours each for test/debug.

Make toolkit changes, there is no way around it. So you need to have a SLA from the admin group so that they will run maketoolkit on demand within a reasonable amount of time. That will be another deal breaker.

There are way too many unknowns here, get a dev server and start experimenting. You will only find answers with a great deal of work because this is something no one with a lot of TS experience would attempt.

Migrateduser

Andy, I concur with you on this. We were avoiding this for last 3 years or so and we got exception from security folks as this conversion requires lots of effort and we could do better things for the new business in the same time and the amount of money we spend here. But this year client got funding just for this security compliance.

Now security folks are pushing us to do this non-root conversion as we have funding available just to make TS run as root. Although it will not be 100% running as non-root as iwwebd has to run as root (Not sure if there is anyway to avoid this process to run as non-root).

Now it seems, it's inevitable to avoid this. So looking for the best possible option we can have to achiev this task.

-Rajesh

ISCBorisB

Not sure if there is anyway to avoid this process to run as [...]root

According to TS, no. It must be root, see here

Adam Stoller

Andy, I concur with you on this. We were avoiding this for last 3 years or so and we got exception from security folks as this conversion requires lots of effort and we could do better things for the new business in the same time and the amount of money we spend here. But this year client got funding just for this security compliance.

Now security folks are pushing us to do this non-root conversion as we have funding available just to make TS run as root. Although it will not be 100% running as non-root as iwwebd has to run as root (Not sure if there is anyway to avoid this process to run as non-root).

Now it seems, it's inevitable to avoid this. So looking for the best possible option we can have to achiev this task.

-Rajesh

You got funding - good. Here's what you do. Buy every developer their own TeamSite Developer Server license and install it on each of their desktops / laptops (provided their desktops / laptops are running a supporter server-version of the OS)

Once you have that done, copy all the code and backing store from your existing server to all of their individual servers.

They can then start working (hopefully in an organized manner) to re-write Perl code in Java for their own concentrated scope of the overall project (you need someone to orchestrate from the top) - they should be striving for as much code-reuse as possible, building libraries as much as possible so that the individual scripts are mostly thin "wrappers" around calls to library routines.

Each developer can then restart the services on their own server as many times as they want without disrupting anyone else.

Periodically (TBD) you coordinate the promotion of various code from the individual development servers to your central development server and do a build there (followed by lots of testing). On success, you refresh all the individual development servers code so that everyone is working off the same baseline.

Then "rinse, lather, repeat" as often as you need to until you've finally got a solution that works.

Based on the specs that you've already provided - I'd say you easily have another year's worth of time to work through this - possibly as much as another decade. Though if you do a good job of top-level design aimed at re-use and configurability, you should be able to pare down the total number of scripts into a much smaller number of classes.

Good luck. If you're still working on this in August I might be available for hire ;-)

Migrateduser

Good luck. If you're still working on this in August I might be available for hire ;-)

The Fish spending the next 10 years in India. I don't think they could afford you. Smiley Wink

Snap 2016-07-05 at 10.33.24.png

Snap 2016-07-05 at 10.32.50.png

Snap 2016-07-05 at 10.33.54.png

DisplayGrowth.rptdesign

nipper

The Fish spending the next 10 years in India. I don't think they could afford you.

DevNet needs a *like* button. But then Smitty might think I *like* him....... Smiley Very Happy

Migrateduser

Oh I don't think I'll ever think that. No worries there. Smiley Tongue

Wonder if that client knows what a cluster they are about to face with their great team of TeamSite experts over there...

nipper

Oh I don't think I'll ever think that. No worries there.

Wonder if that client knows what a cluster they are about to face with their great team of TeamSite experts over there...

I think Ghoti articulated the LOI quite well. As a consultant I could sit there & bill for years. Smiley Very Happy

Still I give this a 50/50 chance of working.