1 |
Kerin Millar wrote: |
2 |
|
3 |
>On Mon, 2003-11-17 at 16:44, aechols@××××××××××××.edu wrote: |
4 |
> |
5 |
> |
6 |
>>>Any insights or additional advice will be gratefully received as I would |
7 |
>>>like to get this just so before fully populating the directory and |
8 |
>>>attempting to configure nss_ldap and such :) |
9 |
>>> |
10 |
>>> |
11 |
>>In my experience, migrating user data was one of the worst parts of the whole |
12 |
>>thing. The smbldap-migration tools really didn't do the job right, and in the |
13 |
>> |
14 |
>> |
15 |
>Yes, the tools were useful in so far as gaining some insights into how |
16 |
>the data should manifest itself, but I would probably enter most of the |
17 |
>data from scratch in any case. |
18 |
> |
19 |
Have you had a look at "migrationtools"? These tools allowed me to |
20 |
easily move all of my system accounts into LDAP. You simply run the |
21 |
script to export your account data (users, groups, shadow, and hosts) to |
22 |
LDIF files and import the LDIF files into LDAP. Simply "emerge |
23 |
migrationtools". |
24 |
|
25 |
(I haven't dealt with moving SMB accounts (yet) as I'm just starting to |
26 |
get into LDAP but there may also be similar from this package.) |
27 |
|
28 |
>>Finally, there's the management issue. For a while I was doing it by hand using |
29 |
>>LDIF files, and then we got LDAP Administrator. It's simplified the process, |
30 |
>>but on the down side it's a Windows program. Currently we're developing a new |
31 |
>>website as a front end to the LDAP, with user administration for us, and |
32 |
>>personal information entry amond other things for the users. |
33 |
>> |
34 |
>I've been using a combination of phpldapadmin (now in portage) and gq to |
35 |
>do the trick. I find gq to be very nice as a general LDAP management |
36 |
>tool, and phpldapadmin is looking quite promising also - might be worth |
37 |
>investigating the templates that it provides. I believe it is quite |
38 |
>trivial to adapt them or create new ones. There is also something called |
39 |
>gosa (haven't tried, but the screenshots look nice). |
40 |
> |
41 |
Yes, this package does look promising--I hadn't heard of it before. The |
42 |
one I've been looking at is Directory Administrator. I believe it's |
43 |
written in GTK--the authors have Gnome as a prerequisite for installation. |
44 |
|
45 |
I have plans to evaluate Webmin, too, as I've heard it has a pretty nice |
46 |
LDAP interface--plus you get the added bonus of the other administration |
47 |
tools that are built into it. |
48 |
|
49 |
>>As bad as I've made it sound by now, I do think it has been worth the trouble. |
50 |
>>I still like it better than NIS. If you have any other questions or I left |
51 |
>>something out, let me know, I'll try to answer. |
52 |
>> |
53 |
>> |
54 |
>Much obliged, I will certainly take you up on that offer should I have |
55 |
>any further queries. To be honest, NIS isn't a huge issue here as the |
56 |
>clients consist mostely of Windows boxen but that doesn't deter me from |
57 |
>wanting to master the method :) The most important thing for me |
58 |
>initially is making it play with qmail (might move to postfix), samba, |
59 |
>courier-imap and several others. In any case, I shall see how I get on |
60 |
>over this week. |
61 |
> |
62 |
This is a bit off-topic but I was using qmail for production servers |
63 |
(hosting many virtuals) and it works quite well. Problems arose when |
64 |
some of our domains started receives *huge* amounts of spam. With qmail, |
65 |
you're stuck aplying several patches to implement different types of |
66 |
functionality--some creating more restrictive policies in and of |
67 |
themselves (goodrcptto, for example, allows you to protect against |
68 |
joe-job attacks but now you have to know /exactly/ which email address |
69 |
to receive mail for--this doesn't work well for TMDA). |
70 |
|
71 |
In either case, qmail was becoming more of a management nightmare in our |
72 |
environment. We push a lot of email and deal with large numbers of |
73 |
spammers. qmail has effectively limited our functionality and |
74 |
effectiveness for stopping spam whereas Postfix has provided us with |
75 |
/all/ the features (so far, anyway) to implement flexible spam stopping |
76 |
policies with the lowest amount of administration. |
77 |
|
78 |
Both qmail and Postfix support LDAP, though. I've not seen any howtos |
79 |
for qmail but there's one for Postfix in their Documentation |
80 |
section--this is intended, though, to support virtual domains. If you're |
81 |
not doing virtual, you should simply be able to point Postfix at the |
82 |
LDAP server and give it the context within which to search for email |
83 |
accounts--this is my understanding from reading thePostfix READMEs. I'll |
84 |
be setting this up in the next week or two and will have a much better |
85 |
idea of the process afterwards. |