NFS? TeamSite? Solaris?

Can anyone explain this. If I create a new workarea, and a user who does not have permission on that workarea performs an ls that uses properties other than file name on the parent (WORKAREA) directory, sometimes it works and sometimes it doesn't (ls with no parameters always works). I haven't determined the exact conditions where it works and doesn't - it seems a little random. Is this an NFS issue, a TeamSite issue or something else? The output looks something like this (executed by the same user moments apart).

sncdevgms1:/default/main/branch/WORKAREA>ls -ltr
drwxrwx--- 4 user group 512 Sep 15 11:38 wa1
drwxrwx--- 2 root nobody 512 Sep 17 17:51 foo

sncdevgms1:/default/main/branch/WORKAREA>ls -ltr
./foo: Permission denied
drwxrwx--- 4 user group 512 Sep 15 11:38 wa1

Find more posts tagged with

Comments

james1

Have you tried the same things on the no-attribute-cachine mount point (usually /.iwmnt)? I'm just guessing here, but I'd guess that the NFS client is caching attributes and deciding that you're not allowed to see 'foo', but if you ask iwserver, it will give you the details. If that's true (big if -- I'm 100% speculating at this point), maybe that's a bug against iwserver? You could look at it either way, probably.

Is this causing you any problems? Or is just a minor annoyance?

-- James

--
James H Koh
Interwoven Engineering

Migrateduser

Sorry I am just returning to Solaris and haven't looked at this in a long time. Can you give a description of the differences between /iwmnt, /.iwmnt, /default and /iwserver (and the corresponding things on Windows where I never saw anything like this - there was only the Y: drive), or point me to the documentation on this?

I never want caching - are you saying I should always use /.iwmnt (I prefer /default)?

This is actually a major problem for the Idiom WorldServer integration here - that application is running on another machine, and when it comes across one of these workareas the whole application breaks in strange ways. But WorldServer is running on another machine using a mount that looks something like this:

gms:/tmp>df -k /iwmnt
Filesystem kbytes used avail capacity Mounted on
cms:/iwserver 174923387 16121583 157052571 10% /iwmnt

If attribute caching really is the problem, is there any way I can configure this mount to use the non-attribute caching moint?

Thanks,

-John

Migrateduser

Just checked, /.iwmnt seems to behave the same way.

Migrateduser

>>Can you give a description of the differences between /iwmnt, /.iwmnt, /default and /iwserver (and the corresponding things on Windows where I never saw anything like this - there was only the Y: drive), or point me to the documentation on this?<<

The different paths do take some getting used to, here is my take on it...

These are related to nfs, iwserver and cache
https://support.interwoven.com/kb/kb_show_article2.asp?ArticleID=2088
https://support.interwoven.com/kb/kb_show_article2.asp?ArticleID=1285
https://support.interwoven.com/kb/kb_show_article2.asp?ArticleID=2087
https://support.interwoven.com/kb/kb_show_article2.asp?ArticleID=1669

As for the different paths, TeamSite has both a filesystem path and a virtual path.

/default/main/foo/WORKAREA/draft/bar.txt:
This is vpath to the asset. This should be used for the majority of TeamSite CLT's and not much else. This is how TS internally sees the asset.

/iwmnt/default/main/foo/WORKAREA/draft/bar.txt:
This is the cached mount point. This is where the asset resides on the virtual nfs file system. This is cached, so the following can happen depending on a number of factors (size of branch, cache size, etc):

%ls
foo bar

%rm bar

%ls
foo bar

TeamSite CLT's should not be passed the file system mount. Yes, you can do this:

iwsubmit /iwmnt/default/main/foo...

It will work, but it may not work for every TeamSite CLT and every store.

/.iwmnt/default/main/foo/WORKAREA/draft/bar.txt:
This is the non-cached mount point also called the CGI mount. This is where the asset resides on the virtual non-cached nfs file system. Filesystem operation should be performed within here, i.e. rm, ls, etc

When TeamSite is installed, the following symbolic link is created (for better or worse):
default -> /iwmnt/default

This is why the vpath maps to the actual asset on the filesystem. You could delete the symlink and no core TeamSite functionality will break. Although, chances are custom code will break since many are confused about the various paths and when to use them.

Where this really gets messy is when you start to use multi-store. That will create a vpath such as:
/store2/main/foo/WORKAREA/draft/bar.txt

When a new store is created, no symlink is created, so the following will not work:
ls -l /store2/main/foo/WORKAREA/draft/bar.txt

Except for the case where you are running a TS CLT, anyone that uses a vpath instead of a true filesystem path will run into problems. Of course you could create a symlink like this, but this would perpetuate incorrect path problem:

store2 -> /iwmnt/store2

--
Jed Michnowicz
Interwoven Technical Consultant

Migrateduser

Thanks for the explanations.

So /default is caching? Would it be recommended to delete this symbolic link and create one pointing to /.iwmnt? What about /iwserver? If it is cached can I modify it to use the non-caching? What types of attributes are cached? How significant are the benefits of caching? It seems to just cause me problems - we don't have performance issues, we have these other issues like zero byte files getting deployed, this weird NFS stuff, etc. I don't like the idea of using one path when calling Interwoven CLTs and another everywhere else - that seems to introduce great potential for error. I would like to use /default for everything.

Edited by john on 09/18/03 09:48 AM (server time).

james1

/iwserver is known as "the shadow directory". It just contains a bunch of empty directories. For no reason should this directory or anything under it ever be messed with!

(FYI: NFS requires directories to exist, if a client is going to *mount* it. The directory does not have to exist to be accessed. So, we replicate the branch and workarea/edition structure (but do not go into areas, where your content is), so that individual areas can be NFS-mounted by NFS clients.)

FYI: NFS attribute caching only caches attributes, not the actual file contents. Dunno if it caches directory contents (my guess is no). Sometimes the NFS client cache misrepresents the contents of TeamSite, and so the no-attribute-caching mount point exists. If you want, you can redirect /default to /.iwmnt/default, but there will be a slight performance degradation in file system activity. And I think there are scenarios where the /.iwmnt mount point shows bogus owners (like nobody:nobody). I don't recall when that happens, or if it was intentional or a bug, or, if it was a bug, what release it was fixed in.

Good luck.
-- James

--
James H Koh
Interwoven Engineering

Migrateduser

So /default is caching?

Depends. If you use /default for file system access, and default happens to be a symbolic link to /iwmnt/default, then yes, it is cached.

However, if you use /default as a vpath and pass a vpath to a CLT such as iwsubmit, iwcmp, iwcp, etc, then my educated guess is that there is no caching going on. (An engineer would have to clarify this one.)

Would it be recommended to delete this symbolic link and create one pointing to /.iwmnt?

It would be best to have developers know what to use and when to use it for portable code. Since I have never done this before, I do not know the full ramifications, but it sounds like this might work in your use case. But, that could get a little wacky if multi-store is used.

Personally, I would say delete the /default symlink and people will learn real quick about the different paths and when to use them.

What about /iwserver?
This is used internally by TeamSite, solaris and NFS to create /(.iwmnt|iwmnt). for all intents and purpose--ignore it.

If it is cached can I modify it to use the non-caching?
There might be a flag to force /iwmnt to turn of caching. If not, file a feature request with support. A KB/documentation search might revel something.

What types of attributes are cached? How significant are the benefits of caching?
Not sure, but every case will be different depending on hardware, number of branches, amount of memory, and usage.

--
Jed Michnowicz
Interwoven Technical Consultant

Migrateduser

OK, if it's not caching the content then I don't really care - if I ever need to get updated attributes such as datestamp, permissions, etc. I can add the /.iwmnt in those specific cases and use /default otherwise. But back to my original problem...what the heck is going on there?

nipper

It appears that you are trying the same command & it produces different results. Much more of a Windows behavior than Unix. However IF your command was slightly different (ls -lrt * as opposed to ls -lrt ) then the behavior is expected.

If I do an ls of a dir I do not have read or execute permissions to then ls will fail with permission denied:

--> ls -lrt
total 4
d--------- 2 andy other 512 Sep 18 13:17 hi
drwxrwx--- 2 andy other 512 Sep 18 13:17 there

--> ls hi
hi: Permission denied

Andy

Migrateduser

Is your Teamsite running with "map_secondary_to_primary_gid=yes" in iw.cfg?

Regards,
Rajiv

Migrateduser

No but we have been thinking about implementing this. Do you think this would be a problem or might it help with this specific condition?

Thanks,

-John

Output.txt

james1

When you turn on map_secondary_to_primary_gid, all files and directories in the TeamSite file system appear to have group ownership by your primary group. So you might see a different group than another user. When you try to access a file or directory, then TeamSite checks the actual group owner against all of the groups that you belong to and then decides if you have permission of not. Gotta love NFS and its arbitrary limits! :-)

-- James

--
James H Koh
Interwoven Engineering

Migrateduser

We have been thinking about doing this in configuration but are not sure of all ramifications, so I have an idea of how it works. I don't understand how it might help me with my current problem though.

Adam Stoller

Note that map_secondary_to_primary also imposes a bit of a performance hit on TeamSite. From a recent internal thread...

The map_secondary_to_primary_gid flag causes TeamSite to do its own access checking on each file operation instead of letting Solaris and NFS do it. This slows down most common TS operations, especially for users that are members of a lot of groups. If there are a lot of users that are in a lot of secondary groups, and those groups are used to share workareas, then overall server performance will also deteriorate. [We] don't have any exact performance numbers, but it [may be] practical to have a few individual users that are members of a very large number of groups - say 100 groups each. However, those users would probably find the system slow to use.

Hope that helps a bit.

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

Just to confirm, because /default does not point to /iwmnt it is non-caching?