Nixon -
By default the filer updates the NIS group cache once a day. To verify the option switch enter the following at the console:
filer> options nis.group_update_schedule nis.group_update_schedule 24
To manually force an update run the following:
filer> options nis.group_update_schedule now
To automate the process you can add a command to your NIS servers Makefile as such :
rsh <filer> options nis.group_update_schedule now
The NIS cache option began with ONTAP release 5.3
Hope this is helpful,
Regards,
audryp
X-Authentication-Warning: freddie.softlab.se: leif set sender to
nixon@softlab.ericsson.se using -f
To: toasters@mathworks.com Subject: NIS group trouble From: Leif Nixon nixon@softlab.se Date: 23 Nov 2001 14:32:23 +0100 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0
It seems my filer (F720, ONTAP 5.3.6R2) caches NIS group lookups even if nis.group_update.enable is set to off.
This is what happens when I add the user "testuser" to the group "rally":
Initially both a Unix NIS client and the filer agree that the user isn't in the group:
UNIX: % ypmatch rally group UNIX: rally:*:31042:jfrid,leif
FILER: jar> ypgroup testuser FILER: User "testuser" belongs to the following group(s): FILER: name: testproj gid: 31038 FILER: name: testprod gid: 31039
Then I add the user to the group and do a ypmake. The Unix client immediately picks up the change:
UNIX: % ypmatch rally group UNIX: rally:*:31042:jfrid,leif,testuser
But the filer doesn't:
FILER: jar> ypgroup testuser FILER: User "testuser" belongs to the following group(s): FILER: name: testproj gid: 31038 FILER: name: testprod gid: 31039
The filer is supposed to not cache group lookups:
FILER: jar> options nis.group_update.enable FILER: nis.group_update.enable off
In this state, the user can access the group's files just fine from an NFS Unix client, but gets "permission denied" when attempting the same from a CIFS client.
Clearing the WCC cache with "wcc -x" doesn't help. Trying to manually force a group cache update doesn't work:
FILER: jar> options nis.group_update_schedule now FILER: Local NIS group update failed now. NIS group caching is not enabled.
The only way out of this state I've found is to enable group caching and then disabling it again. This forces a group update.
FILER: jar> options nis.group_update.enable on FILER: Fri Nov 23 14:24:21 MET [rc]: NIS: Group Caching has been enabled FILER: Fri Nov 23 14:24:21 MET [nis_grp_updater]: Local NIS group update
successful.
FILER: jar> options nis.group_update.enable off FILER: Fri Nov 23 14:24:27 MET [rc]: NIS: Group Caching has been disabled
Now the ypgroup command stops working:
FILER: jar> ypgroup testuser FILER: NIS Group cache not yet updated.
But at least the credential mapping is correct:
FILER: jar> wcc -u testuser FILER: (NT - UNIX) account name(s): (SOFTLAB.LIN\testuser - testuser) FILER: *************** FILER: UNIX uid = 31028 FILER: user is a member of group softlab (30100) FILER: user is a member of group rally (31042) FILER: user is a member of group testproj (31038) FILER: user is a member of group testprod (31039) FILER: FILER: NT membership FILER: SOFTLAB.LIN\testuser FILER: SOFTLAB.LIN\Domain Users FILER: SOFTLAB.LIN\Gemini FILER: BUILTIN\Users FILER: User is also a member of Everyone, Network Users, FILER: Authenticated Users FILER: ***************
Now the user can access the group's files over both NFS and CIFS. Can anyone make head or tail of this?
/Leif Nixon
--
Audry Peterson mailto:audry.peterson@fnc.fujitsu.com Fujitsu Network Communications, Inc. Phone : (972) 479-2137 2801 Telecom Parkway FAX : (972) 479-6989 Richardson, TX 75082
--
Audry Peterson audry.peterson@tx.fnc.fujitsu.com writes:
By default the filer updates the NIS group cache once a day.
Does it? My impression was that this behaviour was controlled by nis.group_update.enable, which is set to "off" in my filer.
To manually force an update run the following:
filer> options nis.group_update_schedule now
Not to be rude, but did you read all of my problem description? I have tried that:
FILER: jar> options nis.group_update_schedule now FILER: Local NIS group update failed now. NIS group caching is not enabled.
Out of band correspondence with a NetApp engineer indicates that I've run into an ONTAP bug, which is fixed in 6.0.2 and later.
/Leif Nixon
i thought this issue was already ok.
if u want to run group_update , nis and update.enable has set to on
with update_schedule, u tell ontap how often the update should apply (every hour, now); default 24 (once a day)
nis.enable on nis.group_update.enable on nis.group_update_schedule 1
k?
Leif Nixon wrote:
Audry Peterson audry.peterson@tx.fnc.fujitsu.com writes:
By default the filer updates the NIS group cache once a day.
Does it? My impression was that this behaviour was controlled by nis.group_update.enable, which is set to "off" in my filer.
To manually force an update run the following:
filer> options nis.group_update_schedule now
Not to be rude, but did you read all of my problem description? I have tried that:
FILER: jar> options nis.group_update_schedule now FILER: Local NIS group update failed now. NIS group caching is not enabled.
Out of band correspondence with a NetApp engineer indicates that I've run into an ONTAP bug, which is fixed in 6.0.2 and later.
/Leif Nixon
-- ------------------------------------------------------------------- Hannes Herret IT-Service / Storage phone : +43 (1) 60 126-34 Bacher Systems EDV GmbH fax : +43 (1) 60 126-555 Wienerbergstr. 11B mailto:hh@bacher.at A-1101 Wien, Austria www : http://www.bacher.at/ Europe
Hannes Herret - Bacher Systems EDV GmbH hh@bacher.at writes:
i thought this issue was already ok.
if u want to run group_update , nis and update.enable has set to on
My problem has already been solved, but to lessen the confusion on the list:
- "nis.group_update.enable on" means "turn on caching of NIS group lookups".
- "nis.group_update.enable off" means "always make a NIS lookup for group information, don't cache anything".
With me so far? OK, I had group_update turned *off* since I wanted the filer to pick up changes to the group map immediately, but it still didn't.
I suspect these options have a less-than-optimal naming.
/Leif Nixon