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

16-Group Unix Limit

edrud

Wondering if anyone has this situation: We are running Teamsite 6.5 on a Solaris box running Unix. Unix supports a user being in only up to 16 groups. So, let's say we have 30 branches and each branch is owned by a different group. As a system administrator, my userid "Ed01" can only get into 16 branches (at the most) for troubleshooting, etc. Meaning if user "Bob" calls and says, "Hey, I can log in to Teamsite, but I am having trouble submitting this workflow", and Bob's branch happens to be owned by a group that I don't have in my profile, I cannot log in an troubleshoot things by seeing them the way Bob would.

Our Unix admins will NOT support ACLs in our system.

My solution thus far has been to request several "shared" userids- "Teamsite 01", "Teamiste 02", etc., and assign the first 16 of our groups to the first id, the next 16 to the 02 id, and so on. Then, if we need to log on looking like a specific user, we just use the proper id and log in. However, our corporate auditors also frown on "shared" userids, even between the two people who troubleshoot and maintain our Teamsite stuff.

Does anyone have any story like this, and how do you handle the situation?

Thanks,
Ed R.
Aetna
rudmane@aetna.com

Find more posts tagged with

Comments

Adam Stoller

Consider switching to TeamSite Groups rather than OS Groups - if you do so - the limitation is removed.
RTFM for more details.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

gzevin

have you ever switched to TS groups from an existing model on Solaris?

I am not picking, really curious....

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Adam Stoller

Yes - I did it on a previous project - most of my notes on the initial confusion I had while doing it was posted in the forums - but at the end-of-the-day it seemed to work well (as far as I know it still is).

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Frederik

I think pretty much everybody must have that experience.

"Teamsite Groups" were added in a recent TS version (6.5 or was it 6.1 ?) to help on that, but they can only be used to protect branches and workareas. Not directories / files.

A much older workaround (present at least since 5.5.2, maybe earlier) is the iw.cfg setting

[iwserver]
map_secondary_to_primary_gid=yes

read the manual for details. There's also probably tons of comments to read when searching for map_secondary_to_primary_gid on the forum

THE SINGLE MOST IMPORTANT THING to remember, when using this, it to NEVER, ever, use the mount point /iwmnt, but ALWAYS use /.iwmnt (non-caching mount). In all your scripts, etc.

--Fred

Adam Stoller

"Teamsite Groups" were added in a recent TS version (6.5 or was it 6.1 ?) to help on that, but they can only be used to protect branches and workareas. Not directories / files.

TeamSite Groups were introduced in 6.5.
Although they are documented for use for branch and workarea sharing - there is nothing in the documentation that indicates that TeamSite groups cannot be used for file and/or directory group ownership (within TeamSite) - and, in fact, the customer where I used them does this and I believe without any problems.

A much older workaround (present at least since 5.5.2, maybe earlier) is the iw.cfg setting

[iwserver]
map_secondary_to_primary_gid=yes

read the manual for details. There's also probably tons of comments to read when searching for map_secondary_to_primary_gid on the forum

map_secondary_to_primary_gid existed as far back as 4.2, possibly earlier (I don't have copies of the earlier manuals anymore).
There is, I believe, a significant performance hit for using this option - I'm pretty sure TeamSite groups perform better and provide greater flexibility and functionality.

The biggest problem with TeamSite Groups is that the administration and querying of information about them is explicitly limited to 'root' (administration makes sense, but querying shouldn't have been) - I think they may have improved some of this in 6.7 but I haven't had time to try anything out in my beta copy thus far.

THE SINGLE MOST IMPORTANT THING to remember, when using this, it to NEVER, ever, use the mount point /iwmnt, but ALWAYS use /.iwmnt (non-caching mount). In all your scripts, etc.

If you're script is dealing with submitting / publishing files and then interacting with the submitted / published files - this generally makes sense.
If you're script is dealing with files within a workarea or previously submitted / published files - performance will be better if you go through the cached mount point.
I tend to use the cached mountpoint until / unless I find timing problems with the functioning of the script.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Frederik

Although they are documented for use for branch and workarea sharing - there is nothing in the documentation that indicates that TeamSite groups cannot be used for file and/or directory group ownership (within TeamSite) - and, in fact, the customer where I used them does this and I believe without any problems.

There was a lengthy discussion here, prior to the release of TS 6.5, about how the TS groups would work out on files... Sunil Menon from IWOV was involved there. It's interesting that they chose not to include any of that into the product documentation. Anyway, the discussion pointed at several "side-effects" of using tsgroups for files, so whether it works for you will depend on what you wish to do.
http://devnet.interwoven.com/forums/cgi-bin/showflat.pl?Cat=&Board=PRODUCTS_TEAMSITE&Number=32733&page=0&view=collapsed&sb=5&o=0&part=all&vc=1

significant performance hit for using this option
Maybe. We're satisfied with this setting. We have about 70 groups or so at the moment.

if you're script is dealing with files within a workarea or previously submitted / published files - performance will be better if you go through the cached mount point.
We've learned the hard way to ALWAYS use the non-caching mount i.s.o. the caching mount.

Scenario with map_secondary_to_primary_gid=yes
user X, primary group A, member of group C
user Y, primary group B, member of group C; member of group A, but that is his 30th group, and not seen by unix.
file Z, owned by root, group C, permission 660

let user X access file Z via cached mount, even just doing "ls -l" on it. Then Teamsite will present file Z as : owner root, group A (!), permissions 660 -> mapping the group on file Z to the primary group of the actor.

if user Y accesses file Z _soon_ after that via the cached mount, he will get the CACHED attributes. (= root, A, 660). Unix will determine that user Y can not read or write file Z, because Unix doesn't see that user Y is in group A.

If user Y accesses file Z via the non-cached mount, TS will give him new attributes, and will map the group C (of the file) to group B (the primary group of user Y). As a result, user Y has access to file Z.

I've reproduced this many times in 5.5.2, because our external developer refused to change /iwmnt to /.iwmnt as we asked him. So we demonstrated the bug in his scripts.

Only if you know beyond doubt who runs the script (ours were custom menu items, which are run as the acting user), and what group membership that user has, etc, you might be able to stay out of trouble with /iwmnt

greets,
Fred.