|
I used to take information from the customer database and store
shadow/passwd/groups/httpd.conf/aliases/virtusertable/etc in two
high-availability MySQL-databases (on the same machines that run LVS) then
every 30 minutes or apropriate generate the files on the real servers. The
"source of all information" for us whas the customer database (also
MySQL), that we can modify in our own customized python/GTK-clients or the
customers (indirect) via a webinterface.
One of the ideas with this was to move the focus from what is stored on
the servers to what is in the customer database. In that way it is easy to
inactivate accounts if customers doesn't pay their fees etc. If the
real-servers go down, they can all be reinstalled with a
kickstartinstallation including the scripts that generate the
configuration files. I found it easier with "pull" instead of a "push" for
the configuration files.
Local files (with databases "db" instead of linear files in
/etc/nsswitch.conf - this began to make a difference with more than 10k
users) in my experience always seemed to be faster than any networked
nameservices (LDAP, NIS etc) even if you use nscd to cache as much as you
can.
However, I do not work with that any more, I am now a student again.
Regards,
Jerker Nyberg.
On Fri, 6 Sep 2002, Doug Schasteen wrote:
> Sorry if I'm getting off topic here, but I figure most of you are in the
> same boat as me when it comes to the fact that you don't want to have to
> set up user accounts on EVERY real server in your farm. When somebody
> needs a password reset, I can't imagine having to log in to 5 different
> servers to change the password on each of them.
>
> I've done a little bit of research on this, and it seems there are 2
> ways of using centralized authentication. They are LDAP and NIS. I don't
> personally like either of these, because my main reason for having
> multiple servers is actually for redundancy (if one server goes down, I
> have others). So what good is it to me if no one can log into the
> servers because the central authentication server is down? NIS seems to
> have one plausible solution, which is to run 1 master server and every
> other server be a slave server, but have each server set as a client to
> itself. That way the user accounts are propagating from the master to
> all of the slaves, but none of the slaves are relying on any other
> server for authentication. They are actually using themselves as their
> own authentication server.
>
> Does that sound right? Does anyone have any experience with doing that
> kind of a setup with NIS?
>
> My other idea would be simply to rsync all of the necessary files. I'm
> running FreeBSD on my real servers so I would just rsync /etc/group,
> /etc/passwd, /etc/master.passwd, and /etc/aliases. This way, all of my
> machines are using their normal authentication, but they all receive the
> newest set of user accounts and password files every minute (if I put
> the rsync commands in cron).
>
> What do you guys think? Let me know what you are doing to solve this
> problem.
>
> - Doug
>
>
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>
|
