On Thu, 2009-01-01 at 09:01 -0700, Joe wrote:
> That is a great question. First, let me say I don't have an answer. The
> reason I'm responding is that Postgres scares me. The reason it scares
> me is that I have had a number of times when upgrading postgres, the DB
> files were not compatible with the older version and it wasn't till
> after the upgrade that I found out. Make sure that if you do use
> postgres, that you plan to export the DB's to load files so that if you
> do hit the upgrade issue you have a way to reload the DB.
----
Usage of any sql db should incorporate a plan to back up on a regular
basis which in postgres should incorporate some form of a pg_dump.
Upgrades that seem to work seamlessly suggest the ability to ignore
corruption.
----
> I have tried using ldap a number of times for what you are asking and
> have not been successful. I tried Fedora Directory Server and it still
> is a complex setup. I still think ldap would be the way to go, but the
> management tools for ldap leave a bit to be desired. Also the initial
> setup has a steep learning curve.
----
FDS is a decent enough system and it seems that they are working hard to
integrate into freeIPA and provide a fairly robust authentication
system.
http://freeipa.org/page/Main_Page
It is possible to use an SQL database with OpenLDAP but if you aren't
familiar with LDAP usage, it adds another layer of complexity that would
make the process more daunting.
----
> My other issue with a central auth mechanism is that I want the user
> id's and passwords to be secure going to the backend. I didn't want
> wireshark to be able to pick up the credentials. Also, what happens when
> the DB goes down? No one will be able to auth.
>
> Another problem I ran up against was having the DB admin ID/password
> located on each client. At least the shadow file protected the passwords
> from normal user access. I do think ldap solves this issue, but
> configuring the ACL's is not a trivial task.
>
> Again, a great question and I look forward to hear what others have done.
>
> kitepilot@kitepilot.com wrote:
> > OK, I've reached that (long postponed) point of my life where I *HAVE* to
> > ditch /etc/passwd and /etc/group in favor of storing my users in a database.
> > Any database...
> >
> > Unless there is a *COMPELLING* reason not to, I will store my users in
> > Postgres, but I don't see why generic concepts should not be applied to
> > *ANY* database.
> >
> > All I find in the howto's is how to install (laundry list here), but what I
> > need is a fairly general cookbook about how-to-configure-what to allow my
> > machine to validate users contained in my database.
> > Most of this howto's are useless to my because I run LFS and it right there
> > voids any reference to apt-get/yum/rpm/etc.
> >
> > Furthermore, I want to login with my trusted /etc/passwd - /etc/group
> > combination when I SSH into (or console) into my machine and I want the
> > "other" users (people hosting WEB sites and/or receiving e-mail) be
> > authenticated against the Postgres table.
> >
> > So the final question is:
> > What do I need?
> > specifically, do I need PAM? (Probably...)
> > What do I configure?
> >
> > I don't need too many details, I just need something along the lines of:
> > You need this list of packages and you need to edit this configuration files
> > to accomplish (fill in the blanks)
> > Lisa? :)
> > HAPPY NEW YEAR!!!
> > Enrique
----
at this stage, if I wanted to start implementing a robust, multi-system
authentication package, I would give freeIPA a serious look - I don't
know how difficult it would be to implement on LFS though.
As for needing PAM - I would think so - that is the point of PAM
(Pluggable Authentication Module I think is the acronym)
Craig
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)