| 1 |
Lindsay Haisley wrote: |
| 2 |
> My main issue here is the question of how such a condition can occur. I have |
| 3 |
> USE=ldap set, and a Gentoo ebuild at some point put ldap into the |
| 4 |
> authentication methods for passwd, shadow and group, probably because this flag |
| 5 |
> was set when glibc was last emerged. |
| 6 |
|
| 7 |
I checked the ebuilds and none of 'em actually touch nsswitch.conf It's |
| 8 |
a purely manual setup. |
| 9 |
|
| 10 |
> Whatever happened, I ended up with udevd |
| 11 |
> trying to find an ldap server before either the network or the local ldap |
| 12 |
> server were up and running. This shouldn't ever be allowed to happen. |
| 13 |
|
| 14 |
Agreed :) |
| 15 |
|
| 16 |
> Here are a couple of thoughts. There's a single ldap USE flag spec'd for |
| 17 |
> Gentoo. There are, however, several widely different ways in which ldap can be |
| 18 |
> used. For instance, although I have ldap in my USE flags for my desktop |
| 19 |
> system, I don't want to use ldap authentication, nor do I want the system to |
| 20 |
> even try to use it. I do want ldap capabilities in applications such as |
| 21 |
> evolution, and ldap clients, and proper schemas installed by various such |
| 22 |
> applilcations which can take advantage of them. Perhaps rather than a single |
| 23 |
> "ldap" USE flag, there need to be at least a couple - "ldap-auth", |
| 24 |
> "ldap-client", etc. |
| 25 |
|
| 26 |
I'd mostly would like to have ldap-lib and ldap-server with the USE=ldap |
| 27 |
only pulling the ldap-lib stuff, leaving the server stuff as an exercise |
| 28 |
to the reader. Kind of like the xorg split. |
| 29 |
|
| 30 |
> One of the disadvantages of Gentoo is that it follows the open source maxim |
| 31 |
> "release early, release often" pretty literally. The choices are either to |
| 32 |
> keep an identical non-production server around as a test bed or to not try to |
| 33 |
> keep up2date on stuff once the system is stable. I do live dangerously, and |
| 34 |
> reserve the right to whine about it when I get my butt bitten ;-) One of the |
| 35 |
> advantages of Gentoo is that the dev community and forums are generally very |
| 36 |
> helpful in solving stuff when things break. bugs.gentoo.org is a great |
| 37 |
> resource to which I successfully turn more often than I would wish. |
| 38 |
|
| 39 |
I'll second Donnie here, VMWare is a great tool for that, I used it in |
| 40 |
several occasions and it saved me a bundle, both in terms of time and |
| 41 |
money (one server with plenty of RAM running 2 win2k and 2 linuxes at |
| 42 |
the same time). It's definitely worth its price tag in the long run. |
| 43 |
|
| 44 |
Xen seems to be the cool new thing, and it seems to be well tested to be |
| 45 |
put into production use. Definitely worth a look if you're on a tight |
| 46 |
budget, or if your servers are not used to their max capacity. |
| 47 |
|
| 48 |
>> I read someplace this was going to be fixed in later versions of nss_ldap. |
| 49 |
> |
| 50 |
> Yeah, this bug has been outstanding for many months. I put a version cap in |
| 51 |
> packages.mask on nss_ldap and a comment referencing the bug report. It looks |
| 52 |
> as if Greg KH and other devs can't quite agree on where the responsibility lies |
| 53 |
> for this one. |
| 54 |
|
| 55 |
Since this bug has been bothering me for quite a while too, I'll try and |
| 56 |
see if I can fix it. I started looking through udev this morning, and it |
| 57 |
seems really clean code-wise. I'm not really sure how to test udev |
| 58 |
though, besides rebooting the box. I'll figure this out this weekend. |
| 59 |
|
| 60 |
Cheers, |
| 61 |
|
| 62 |
Rémi |
| 63 |
-- |
| 64 |
gentoo-desktop@g.o mailing list |
Archives