On Mon, Apr 22, 2002 at 10:03:14AM -0400, Scott Murphy wrote:

From: Adrian Chung
Reply-To: ovsage@yahoogroups.com
To: Ottawa Valley SAGE
Subject: [ovsage] Centralized password databases.
Date: Sun, 21 Apr 2002 21:19:07 -0400

…

I’m tending towards an rsync of the shadow/password files, or a
custom script that merges password change differences for entries
in the password database.

You can rsync across an ssh tunnel, so that would protect your
data. You still have the problem as to how to manage updates
though… If the password is changed on the co-lo and the local in
the same day and you only sync once a day, which takes precedence?

Although not the most convenient, I’d make the rule that most recently
updated wins. So if both local and co-lo change, then whichever was
changed most recently wins. This is also pretty easy to determine,
since the shadow file stores this information (assuming that the
clocks on the machines are accurate).

Although it wouldn’t be a realtime replication, it could happen every
minute, or maybe more like every 10 minutes since the user base is
small, and don’t change their passwords often.

The possibility of competing updates could also be mitigated by having
a CGI script that users have to use to change their password (which
would reside on the co-lo, most likely), and have the local servers
all have a ‘passwd’ wrapper that point to the URL above.

Since the user base don’t tend to use shell-level access, this
shouldn’t be a big deal…

I could also do something like move to MySQL, or LDAP and replicate
the databases every so often.

You still have the issue of which takes precedence, unless you decide
to declare one as master and it overwrites the other. As you do not
have realtime updates, you need a mechanism as how to arbitrate
differences in the databases.

Definitely. I think the one point of access to set your password is
the important aspect. That way, I’m already implicitly defining one
database as the “master”.

…

I’m sure that this is addressed in some of the tools out there, but
if you want to roll from scratch, this might be the easiest way to
start. I’m not sure how you manage synchronization in LDAP, but I’m
sure it can be done.

I’ve never had the patience to learn enough about LDAP to know. In
this case, however, I feel like moving to another authentication
backend database is overkill just to solve replication issues.

I’ve never had to do this before, so it is an interesting
question. Most systems I have dealt with have either had a yellow
pages master, or had Active Directory, which manages this for
you. Maybe this could be a topic for the next ovSAGE meeting -
Directory replication across intermittently networked machines.

I figured there were probably some good ideas kicking around people’s
heads.

It’d be nice to just setup a VPN and use NIS, but I don’t have that
much faith in broadband connectivity, yet…

–
Adrian Chung (adrian at enfusion-group dot com)
http://www.enfusion-group.com/~adrian
GPG Fingerprint: C620 C8EA 86BA 79CC 384C E7BE A10C 353B 919D 1A17
[toad.enfusion-group.com] up 29 days, 22:33, 17 users