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

Incorrectly set OS groups to "nobody"

rude_ravn

Good morning!

I did a rather loose branch migration from one server (production) to another (dev), simply by copying the STAGING area's contents of this branch using TAR (with option p to preserve groups/users/fileperms).

When copying the TAR's content into a new workarea on the target server, most of the files (not all) that formerly had the UNIX group "iwglobal" set, now got the group "nobody" (thus, Teamsite can't really handle those files). Trying to fix this using chgrp on the shell, I had to find out that it was not possible, even as root, to change the files' group attribute to "iwglobal" - they would be set to "nobody" instead. Setting the group to any other UNIX group worked finely.

Both servers are on TS 6.7.1 on Solaris and, as far as I can see, have the same UNIX groups and users, the same TS groups and users, and the same relevant iw.cfg configurations.

Does anybody have an idea how I can fix this issue, or what I am doing wrong?

Cheers,

Rude

Find more posts tagged with

Comments

Adam Stoller

Does the iwglobal group have the same GID on both servers?
My guess is "no" - which is probably at the root of your problem.
Then of course there's the fact that Unix / tar, doesn't know anything about TeamSite groups - and if the TeamSite groups themselves don't have the same ID on both servers - you're going to have problems there too (you could try copying the tsgroups.xml file from the source to target server and then run an iwreset on the target server to make sure they take effect)

rude_ravn

Thanks for your reply, ghoti.

Yes, the iwglobal group has the same GID on both servers. In fact, the /etc/group files are identical.

But even if the iwglobal groups had different IDs, how could that explain that a "chgrp iwglobal " of a file on the target server does not have any effect?

I have deliberately ignored TeamSite groups when copying, as there are no user mentionable access requirements on the dev environment.

Funny thing is, the groups inside the TAR on the target system are still correct after copying, and if I unpack that tar somewhere other than the iwmnt (e.g. in /tmp), the iwglobal group is correctly set, and changeable. It's just inside the TS filesystem where this strange behaviour occurs.

Good ideas still appreciated. :-)

Adam Stoller

Hmm - well that's definitely a puzzler. Since I don't have an environment similar to yours on which to try things out - that's about the limit of what I can suggest at this time. Perhaps someone else, who is working in a Unix environment can offer some additional insight and/or suggestions.

LooseCannon

My guess is that not having the Teamsite Groups on the dev server is the issue. The iwglobal group is applied indirectly when an asset is secured with a TS Group. I've never attempted to chgrp iwglobal because the group by itself is worthless - it's not supposed to contain members.

What happens when you apply a TS Group to an asset? Does the sharing group show as iwglobal on the file system level?

rude_ravn

Thanks again, ghoti, and LooseCannon, for your replies.

Applying a TS group works (as it does apply this group on the TS level - at least the file properties say so), but the OS group is not changed. The files still have nobody as a group, and that, of course, does still mean that e.g. generating files does not work.

As a workaround I have changed the OS group to another group instead of iwglobal, and now everything seems to work. But, as I mentioned, we don't do a lot of access restriction on the dev server, so I can't tell for sure that the TS groups really apply. I will check that.

But, as my way of copying a workarea from one server to another obviously does not work very well, could you tell me: What is the best way to perform such a branch migration from one server to another? (It's really just one branch, and we want to do this regularly to always have some sort of productive content on the dev server.)

Migrateduser

You shouldn't be messing with the Unix groups. To migrate content between servers, use your submit.cfg to define your security model. Tar up the content on the source server, untar it on the target server, then submit to Staging, and if you set up submit.cfg properly, everything should be golden.

rude_ravn

Yes, Smitty77, you are right, and that is exactly what I was doing in the first place: I unTARed to a workarea and then submitted to STAGING, expecting that the submit.cfg would keep order. The problem was that it didn't.

Obviously the submit.cfg itself was unable to apply the correct group. (To be honest, I have no idea if, with the new security model, a SUBMIT is setting any OS users/groups at all).

In a way, I'm glad to hear that what I am experiencing on that server this is not expected behaviour. Although I have really no idea how to solve that problem at the moment.