passwd locking over GPFS - Aix

This is a discussion on passwd locking over GPFS - Aix ; 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 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: passwd locking over GPFS

  1. passwd locking over GPFS

    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.

  2. Re: passwd locking over GPFS



    "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.


  3. Re: passwd locking over GPFS

    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.

+ Reply to Thread