| 1 |
A. Khattri wrote: |
| 2 |
> On Thu, 11 Aug 2005, kashani wrote: |
| 3 |
> |
| 4 |
>>And that isn't option #1 aka, stuff everything in a db and do central |
| 5 |
>>auth from there" how? See I'm even loosing sleep just talking about |
| 6 |
>>option #1. The rest of you have been warned. :) |
| 7 |
> |
| 8 |
> Well, firstly, there are NO local accounts for users. And second, PAM |
| 9 |
> isn't involved in all of it. So yeah #3 is alive ;-) |
| 10 |
> |
| 11 |
|
| 12 |
That's it? That's the big explanation? Come on it's six of one and half |
| 13 |
a dozen of the other. You can use PAM, NIS+, libnss, Radius, etc and you |
| 14 |
can auth against a flat file, Mysql, Postgres, Oracle, LDAP, hell even |
| 15 |
Active Directory if you want as well as twenty other things I'm sure. |
| 16 |
|
| 17 |
To the original poster you can go fully virtual by combining X auth |
| 18 |
method with Y backend with no local accounts. I'd go this route if the |
| 19 |
users that need local access to machine aren't likely to reside in a |
| 20 |
single email domain. In my case users that need access to the box work |
| 21 |
here so I made our domain local, gave ourselves local accounts, and our |
| 22 |
customers get to be virtual. The pros here that it's easy and you can |
| 23 |
leave your sshd, ftpd, etc configs alone. Messing with a virtual mail |
| 24 |
system is sometimes hard enough the first time around for a lot of |
| 25 |
people and doing everything at once can be painful and most importantly |
| 26 |
cause sleep loss. |
| 27 |
Cons of course are that if you need to add local users from any other |
| 28 |
domain at some point in the future you're likely to need to re-engineer |
| 29 |
things a bit... or a lot. And also make the old local users start using |
| 30 |
their email as the login instead of their old username which is always a |
| 31 |
fun transition. |
| 32 |
|
| 33 |
kashani |
| 34 |
|
| 35 |
-- |
| 36 |
gentoo-server@g.o mailing list |
Archives