1 |
I've recently been busying myself setting up Kerberos/LDAP directory to |
2 |
provide a NIS like authentication system for my small LAN (hopefully |
3 |
allowing single sign on at some point in the near future). |
4 |
|
5 |
What I have found is that it is currently quite a big job to get all of |
6 |
this sorted on a Gentoo server, and even when it's all running, it doesn't |
7 |
play nicely with portage (or rather, there are some ebuilds that don't |
8 |
play nicely with NIS like systems). |
9 |
|
10 |
The main problems I've found are that some ebuilds grep /etc/passwd to see |
11 |
if a specific user exists on the system, and then go and add the |
12 |
user/group with the useradd/groupadd commands. Obviously, this doesn't |
13 |
work for users whose credentials are stored somewhere other than |
14 |
/etc/passwd. |
15 |
|
16 |
What I would like to propose is some sort of virtual package, maybe |
17 |
virtual/auth. The standard /etc/{passwd,group,shadow} authentication |
18 |
mechanism should be retained as the default (maybe call it auth-files or |
19 |
auth-shadow). The key thing here though, is that each package that |
20 |
provides virtual/auth must provide a user{add,del} and group{add,del} |
21 |
command (maybe useradd.packagename, etc. with symlinks to /sbin/useradd). |
22 |
|
23 |
I am quite prepared to put some effort in to putting together a |
24 |
sys-auth/krb5-ldap ebuild, but there will need to be some coordination. It |
25 |
would be nice to be able to offer some sort of tool to switch between |
26 |
authentication mechanisms, a la RedHat authconfig. |
27 |
|
28 |
Can anybody see any problems, advantages, disadvantages, glaring issues in |
29 |
what I'm suggesting? |
30 |
|
31 |
Cheers, |
32 |
|
33 |
Gareth. |
34 |
|
35 |
|
36 |
|
37 |
|
38 |
-- |
39 |
gentoo-dev@g.o mailing list |