passwd locking over GPFS

This is a discussion on passwd locking over GPFS within the aix forums in Operating Systems category; 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 ...

Go Back   Database Forum > Operating Systems > aix

Database Forums

Register FAQ Calendar Search Today's Posts Mark Forums Read
  #1  
Old 08-22-2008, 07:28 AM
Default 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.
Reply With Quote
  #2  
Old 08-22-2008, 08:01 AM
Default Re: passwd locking over GPFS



"dunx" wrote in message
news:9838df5a-c769-48c1-b0dd-04c4c7152e35-at-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.

Reply With Quote
  #3  
Old 08-22-2008, 09:04 AM
Default Re: passwd locking over GPFS

On Aug 22, 12:01*pm, "Mark" wrote:
> "dunx" wrote in message
>
> news:9838df5a-c769-48c1-b0dd-04c4c7152e35-at-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 With Quote
Reply


Thread Tools
Display Modes



All times are GMT -4. The time now is 08:26 AM.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Integrated by bbpixel2008 :: jvbPlugin R1013.368.1

Search Engine Friendly URLs by vBSEO 3.1.0
vB Ad Management by =RedTyger=
In an effort to better serve ads to our visitors, cookies are used on Mydatabasesupport.com. For more information, check out our Privacy Policy.