On Aug 22, 12:01*pm, "Mark"
wrote:
> "dunx" wrote in message
>
> news:9838df5a-c769-48c1-b0dd-04c4c7152e35@25g2000hsx.googlegroups.com...
>
>
>
> > We have 8 AIX Escalla servers in a cluster using GPFS to share files.
> > All the necessary "passwd" files are stored on GPFS. We have over 9000
> > users.
>
> > How resilient is the file level locking for the passwd function? Does
> > this locking work over GPFS?
>
> > It's a tricky one to test because of the user interaction required.
>
> > We currently have our own file level locking in place, but because
> > this is around the whole passwd function it results in users being
> > unable to change their password because one user is taking their time
> > in coming up with a new password. This restriction is making the
> > lovely users unhappy.
>
> > We have at least one instance of /etc/security/passwd becoming
> > corrupt, but we don't know the cause of this.
>
> > My concern is that the passwd function being called at login when a
> > passwd has expired is causing this issue because it is not performing
> > its own internal locking correctly over GPFS - we don't have our own
> > file locking around password expiry changes. On the other hand it
> > might just be an Admin editing the file.
>
> > Thanks in advance for your wisdom.
>
> How did you get this working as GPFS is not supported for rootvg?
> Did you link the files needed (/etc/passwd etc.) to a GPFS file system?
>
> Anyway, my suggestion would be to migrate your user authentication to LDAP.
> It can be used on different platforms and easily synchronized with various
> other security products.
All the files are linked to GPFS and this solution works fine. I just
have this one concern over file level locking for passwd over GPFS.
BTW we're on AIX5.3.
We do know that opening GPFS hosted files with O_NSHARE without
lockf() is not supported (I think), we just don't know whether this is
what the passwd function is doing. A truss on passwd indicates what we
think is a Kernel lock on /etc/security/passwd "kfcntl(8, F_SETLK,
0x[snip]) = 0", but we don't know whether this is correctly locking
the linked file on GPFS.
Moving to LDAP is not an option today.
My two options are to remove all locking around passwd and risk
corruption or put our own locking around passwd and have users
complain it's taken an our to change their password.