1 |
Aron Griffis said: |
2 |
> I really like this idea for the following reasons: |
3 |
> |
4 |
> 1. Information about devs should be sourced from the devs home |
5 |
> directory. It means each dev can maintain their own data, and it |
6 |
> avoids the problem of having a separate area of which devs need to be |
7 |
> aware. Using fingerd automatically meets this "requirement". |
8 |
> |
9 |
|
10 |
There are advantages and disadvantages. For pgp keys I personally believe |
11 |
that this is not the way to go. In case a dev box gets rooted it is very |
12 |
easy for a hacker to update a .gpgkey file, but if we would have an |
13 |
authenticated and automated process changing the key in the ldap database |
14 |
(through an easy to use script) that would increase security a lot while |
15 |
still getting all the data at one place. I think the plan file can indeed |
16 |
be sourced from a .plan file in the homedir. But a gpg in general hardly |
17 |
gets updated, so a bit more formal access is waranted in this case. |
18 |
|
19 |
I believe the choice has been made to centralize the developer database on |
20 |
ldap. As such I believe that if we want to provide a finger service it |
21 |
will need to be ldap aware and pull most information from ldap, and/or |
22 |
other sources. For example for projects the current plan is to create |
23 |
project.xml files containing information about the project. Including who |
24 |
is part of the project. There is no final structure yet, but once we do |
25 |
have it, it will be the definite authority on who works on which project. |
26 |
I believe having people maintain seperate information in their homedirs is |
27 |
not the way to go as it will lead to incomplete and inaccurate data, and |
28 |
also diminishes the need for developers to keep the definite information |
29 |
up to date. (Yes that means that I think the next version of the developer |
30 |
list will be autogenerated) |
31 |
|
32 |
> 2. If we want to make dev information available on the web as well, it |
33 |
> can easily be harvested (once per hour, as somebody mentioned the |
34 |
> website is updated) from the dev's home dirs. |
35 |
> |
36 |
> 3. I agree with Tavis regarding the ease of using finger to lookup |
37 |
> per-developer information such as gpg keys. Using the web is not |
38 |
> quick. |
39 |
> |
40 |
I don't mind the use of finger as the retrieval protocol, but in this case |
41 |
the server probably needs to be updated to get its information from other |
42 |
sources. |
43 |
|
44 |
> |
45 |
> It seems like a good (usable/maintainable/secure) solution to me, and as |
46 |
> Tavis has mentioned, it's already in use by a number of major open |
47 |
> source projects. |
48 |
|
49 |
Well, I see the use of finger as a protocol for information retrieval, but |
50 |
I don't think that a standard fingerd will do the job. One way to do |
51 |
things is to have a configuration file somewhere that specifies plugin |
52 |
programs that supply the fingerd with information. What I mean is for |
53 |
example the following: |
54 |
|
55 |
/etc/fingerd/plugins: |
56 |
getplan=/usr/gentoo/bin/getplan |
57 |
|
58 |
and |
59 |
"getplan pauldv" would then return my plan (by catting .plan from my homedir) |
60 |
"getkey pauldv" though would get my key from the ldap server and would |
61 |
output it to fingerd |
62 |
|
63 |
Paul |
64 |
|
65 |
-- |
66 |
Paul de Vrieze |
67 |
Researcher |
68 |
Mail: pauldv@××××××.nl |
69 |
Homepage: http://www.devrieze.net |
70 |
|
71 |
|
72 |
|
73 |
|
74 |
-- |
75 |
gentoo-dev@g.o mailing list |