1 | # $Id$ |
---|
2 | |
---|
3 | =head1 DESCRIPTION |
---|
4 | |
---|
5 | =head1 SPECIFIC SETUP PARAMTERS |
---|
6 | |
---|
7 | =head2 db_conn |
---|
8 | |
---|
9 | The C<libpq> connection parameters, eg a semin colon separated paramaters |
---|
10 | containing the server, the database name, user and password, etc... |
---|
11 | |
---|
12 | =head1 FEATURES |
---|
13 | |
---|
14 | =head2 Network managment |
---|
15 | |
---|
16 | Link::Accounts can build automatically some part of your DNS or DHCP |
---|
17 | configuration. |
---|
18 | |
---|
19 | To do this you have to create a C<netzone> object. Such object need a type: |
---|
20 | |
---|
21 | =over 4 |
---|
22 | |
---|
23 | =item dns: to build a DNS zone for classic domain |
---|
24 | |
---|
25 | =item reverse: for reverse IP address (168.192.in-addr.arpa) |
---|
26 | |
---|
27 | =item dhcp: ISC dscpd configuration for fixed address |
---|
28 | |
---|
29 | =item puppet: puppet configuration |
---|
30 | |
---|
31 | =back |
---|
32 | |
---|
33 | The way it works is quite simple, each zone will make the code to write a file |
---|
34 | you can include in your server configuration. The match is done by looking the |
---|
35 | zone IP address masks and the host IPs. |
---|
36 | |
---|
37 | For example someone having a zone named C<private.mydomain.com> having masks |
---|
38 | C<192.168.5.0/24>, and having an host named C<foo> with IP C<192.168.5.3> and |
---|
39 | another host C<bar> with IP C<192.168.13.78>. The zone built will look likes: |
---|
40 | |
---|
41 | foo IN A 192.168.5.3 |
---|
42 | |
---|
43 | As you can see this DNS zone is not valid: the goal of such feature is to make |
---|
44 | the repetive work for us, not to manage the full zone (even such feature could |
---|
45 | be possible). The repetitive work is declaring the hundred computers our users |
---|
46 | have. |
---|
47 | |
---|
48 | The output will be happend to a template have the name of the zone suffixed by |
---|
49 | C<.in>. You can put in this template evering about the zone declaration (SOA, |
---|
50 | NS, TXT...). |
---|
51 | |
---|
52 | =head2 User endcircuit |
---|
53 | |
---|
54 | The C<endcircuit> attribute contain the deadline for people to make |
---|
55 | admnistrative task when starting to work. |
---|
56 | If set this attribute take precedence to C<expire> attribute for computed |
---|
57 | attributes (C<accountExpires> for Active Directory). |
---|
58 | |
---|
59 | =head2 Group AutoMemberFilter |
---|
60 | |
---|
61 | Group objects contains users members by setting either C<members> or |
---|
62 | C<memberUID> attributes. |
---|
63 | |
---|
64 | Sometimes it can be usefull to have group automatically populated by arbitrary |
---|
65 | rules. |
---|
66 | |
---|
67 | This is possible by setting a filter in the C<autoMemberFilter> attribute, |
---|
68 | The filter format is the same the one used by L<la-search>, the attribute is |
---|
69 | multivaluable. |
---|
70 | |
---|
71 | So for example one can create an account automatically a group containing people |
---|
72 | having "Olivier" as first name: |
---|
73 | |
---|
74 | autoMemberFilter: givenBame=Olivier |
---|
75 | |
---|
76 | A probably more usefull example is a group containing people from two others |
---|
77 | groups: |
---|
78 | |
---|
79 | autoMemberFilter: memberOf=group1 |
---|
80 | autoMemberFilter: memberOf=group2 |
---|
81 | |
---|
82 | The C<members> or C<memberUID> attribute becomes read-only attribute once |
---|
83 | C<autoMemberFilter> attribute is set. |
---|