TS 6.7.1 - Unix groups/TS Groups

You can *try* to see threads started by Adam. There were only 100. However I was not able to see the thread you were talking about.

I certainly did find the dead link.

me

TestReport.rptdesign

Thanks for checking. Not that I'm surprised that the documentation IW creates themselves is so poor. You'd think older threads would be preserved somewhere. Maybe Adam will save the day...

not sure if this URL helps http://devnet.interwoven.com/forums_vb/showthread.php?t=10216&forumid=11

check this out by ghoti

That post was found easily, however the last post references another thread with a link that is no longer valid.

Thanks - that's sort of useful. But it's not the thread I was hoping for. There was a thread that went through all sorts of combinations of groups, owners, and permissions if I recall correctly. Because we weren't upgrading at the time, I was only half interested. Now I'm much more interested. Hopefully Adam will stop working and look at DevNet soon. Smiley Very Happy

Thanks - that's sort of useful. But it's not the thread I was hoping for. There was a thread that went through all sorts of combinations of groups, owners, and permissions if I recall correctly. Because we weren't upgrading at the time, I was only half interested. Now I'm much more interested. Hopefully Adam will stop working and look at DevNet soon.

Are you talking about this thread and/or this thread?

Are you talking about this thread and/or this thread?

No - neither of those. I may be mistaken about the content of the thread. I just recall that when they first came up with the concept of TS Groups, I and perhaps some others, were concerned how the TS groups would interact with the filesystem groups/permissions. There was a big discussion on the members of each type of group and why you need one or the other or both. I have a terrible memoery, so I don't recall much more than that.

Our main concern is because we have all of our users using Samba to push files into TeamSite from their own development areas, would we still need to have individual Unix groups for each TS workarea to prevent people from being able to Samba files over to an area of TS we don't want them writing into? We think the answer is "yes". TS groups don't have much weight when you are dealing with the filesystem outside of the TS GUI, correct? You can't use TS Groups to manage the filesystem outside of the TS GUI it appears...

Yea I remember a nice dissertation from Adam on the tsgroups. I assumed that was the post refered to in this link:

http://devnet.interwoven.com/forums/cgi-bin/showthreaded.pl?Cat=&Board=PRODUCTS_TEAMSITE&Number=56464&Search=true&Forum=PRODUCTS_TEAMSITE&Words=iwgroup%20bug%20feature%20request&Match=And&Searchpage=0&Limit=25&Old=allposts&Main=56059

But since the old #'s are not valid anymore, finding thread 56059 or post 56464 may be difficult.

Andy

report_error.txt

jed

No - neither of those. I may be mistaken about the content of the thread. I just recall that when they first came up with the concept of TS Groups, I and perhaps some others, were concerned how the TS groups would interact with the filesystem groups/permissions. There was a big discussion on the members of each type of group and why you need one or the other or both. I have a terrible memoery, so I don't recall much more than that.

Our main concern is because we have all of our users using Samba to push files into TeamSite from their own development areas, would we still need to have individual Unix groups for each TS workarea to prevent people from being able to Samba files over to an area of TS we don't want them writing into? We think the answer is "yes". TS groups don't have much weight when you are dealing with the filesystem outside of the TS GUI, correct? You can't use TS Groups to manage the filesystem outside of the TS GUI it appears...

TS groups did work for me when doing things on the filesystem. Since samba is a middleman between the client and the filesystem, I assume samba would work as expected. We never went live with it, so this is all based upon an afternoon of testing.

~jed

So when you are in a Unix shell and you do an "ls" of a TeamSite workarea, what do you see as the group owner of the files? Is it a TS Group name or a Unix group name?

It *should* be the TS group, since that is returned from the device driver, TS should easily sub the TS group.

If that's true, and it utilizes the TS group in every way, then that would actually work out pretty good. We'd no longer have to manage dozens and dozens of Unix groups. I hope it works that way. Guess we'll find out.

The reason I'm skeptical is because my coworker is deploying some of our content from our current production setup to the new IW server and when you look at a file in the Properties link in TS, it appears to display a Unix group, not a TS group for the file. That would tend to contradict what you said...

jed

So when you are in a Unix shell and you do an "ls" of a TeamSite workarea, what do you see as the group owner of the files? Is it a TS Group name or a Unix group name?

It shows the iwglobal or something generic along that line. As far as access control, it will do the proper things, but it sure is confusing if you go off of visual perms.

If you have logic that does a stat() to get the group information, you would have to convert that to a TeamSite CLT.

basically how it works is TS creates a Unix group iwglobal on your Unix\ Solaris box above which it sets up TS groups as defined by you.

when you do a ls from the unix shell, the group you will see next to the file\ directory would be iwglobal and not your tsgroup.

You would only be able to see your tsgroup on the TS GUi.

In your case since you have deployed content from one box to another, make sure you apply the permission rules in your deployment and you can assign the group and permissions accordingly there. I am not very sure if you can deploy with permission rules pointing to a TS Group but you should be able to do that. I did not try yet.

Doubt for one more field.doc

make sure that you have the TS Group created on the target server

No - neither of those. I may be mistaken about the content of the thread. I just recall that when they first came up with the concept of TS Groups, I and perhaps some others, were concerned how the TS groups would interact with the filesystem groups/permissions. There was a big discussion on the members of each type of group and why you need one or the other or both. I have a terrible memoery, so I don't recall much more than that.

Our main concern is because we have all of our users using Samba to push files into TeamSite from their own development areas, would we still need to have individual Unix groups for each TS workarea to prevent people from being able to Samba files over to an area of TS we don't want them writing into? We think the answer is "yes". TS groups don't have much weight when you are dealing with the filesystem outside of the TS GUI, correct? You can't use TS Groups to manage the filesystem outside of the TS GUI it appears...

Ah - I think I know what you're talking about - I found this but I don't think its what you were thinking about either.
I think the post was probably in a TS65 beta forum and thus may no longer be visible on the system (perhaps the devnet folks can resurrect it?)

If it was what I'm thinking it was - it was about how one would see the information about the groups from the file system interface.

So when you are in a Unix shell and you do an "ls" of a TeamSite workarea, what do you see as the group owner of the files? Is it a TS Group name or a Unix group name?

No - you'll see the unix group 'iwglobal' (or something like that).
iwattrib can be used to decode the group and provide the TS Group name.

I believe - but its been some time since I've worked with them - that if you have a TSGroup "foo" with members user1, user2, and user3 - and you're logged into the shell as user4 and you try to access a file or directory that is protected so that only members of the TSGroup "foo" have access - that even though the filesystem shows "iwglobal", the IFS will do "the right thing" and prevent access to that file or directory unless you're a member of the actual TSGroup associated with it.

Thanks for the refresher. Yes you have a much better memory than me - it was something about groups/permissions from the filesystem. It's good news if we don't need to create a couple hundred Unix groups. We'll play around with it a bit and see if it's foolproof.

Thanks Adam!

basically how it works is TS creates a Unix group iwglobal on your Unix\ Solaris box above which it sets up TS groups as defined by you.

when you do a ls from the unix shell, the group you will see next to the file\ directory would be iwglobal and not your tsgroup.

You would only be able to see your tsgroup on the TS GUi.

In your case since you have deployed content from one box to another, make sure you apply the permission rules in your deployment and you can assign the group and permissions accordingly there. I am not very sure if you can deploy with permission rules pointing to a TS Group but you should be able to do that. I did not try yet.

When attempting to use OpenDeploy to move our content from our 6.1 version of TeamSite to 6.7.1, if we specify the group in the permission rules as a TS group, the deployment fails with this error:

ERROR: Unknown group

That sucks royally. If we leave the group empty in the deployment config, it forces a Unix group to be the group-owner of the files. In other words, it doesn't do the right thing. That sort of takes the usefulness of the TS Groups out of the equation for migrating files. I would consider this a bug.

:mad:

When attempting to use OpenDeploy to move our content from our 6.1 version of TeamSite to 6.7.1, if we specify the group in the permission rules as a TS group, the deployment fails with this error:

ERROR: Unknown group

That sucks royally. If we leave the group empty in the deployment config, it forces a Unix group to be the group-owner of the files. In other words, it doesn't do the right thing. That sort of takes the usefulness of the TS Groups out of the equation for migrating files. I would consider this a bug.

:mad:

Are you using targetFilesystem or targetTeamsite? I'm not sure, but its less-likely to work with targetFilesystem -- however in either case, this is OD and not DD and so unless it is working explicitly with the IFS it is unlikely to be able to know about the TS groups (perhaps this is a feature-failure that should be addressed?)

From past experience though - you know about using chmod g+s and the submit.cfg file - so if you're deploying to a TS workarea - why not keep the permissions on the files as generic as possible during the deployment and let them get taken care of on the receiving side and/or when you submit the files?

Fish, Smitty,

I tried the deployment to TS Area with chmod g+s. that does not work as required. Also, you are right TS Groups will not work with target filesystem.

What i basically ended up doing was to set the permission rules group to iwglobal and use chmod g+s on the target workarea. This helped to solve my problem at that time. I think, if you are using Target teamsite, this will work for you as well.

Are you using targetFilesystem or targetTeamsite? I'm not sure, but its less-likely to work with targetFilesystem -- however in either case, this is OD and not DD and so unless it is working explicitly with the IFS it is unlikely to be able to know about the TS groups (perhaps this is a feature-failure that should be addressed?)

From past experience though - you know about using chmod g+s and the submit.cfg file - so if you're deploying to a TS workarea - why not keep the permissions on the files as generic as possible during the deployment and let them get taken care of on the receiving side and/or when you submit the files?

We need the group to be set properly to make sure only the people who have access to each workarea can overwrite files in that workarea. Remember everyone uses Samba to push files into TeamSite, so if the group was generic, everyone would have access to everyone else's areas.

We opened a support ticket, for whatever that's worth. Also left a message with Todd Scallan who is usually very responsive.