Making DragonFly compatible with NSS/ldap

[Alex Hornung]

On 23/03/2014 10:57, Francois Tigeot wrote:
> On Sun, Mar 23, 2014 at 11:44:30AM +0100, Sascha Wildner wrote:
>> On Sun, 23 Mar 2014 10:51:45 +0100, Francois Tigeot <ftigeot at wolfpond.org>  
>> wrote:
>>
>>> This rescue thing is the most problematic part, not because of some
>>> technical challenges but due to general disagreement among developers.
>>> Discussions in the IRC channel are going nowhere.
>> My perception was that there was a general agreement about not wanting a  
>> /rescue with you being the only one who's in favor of it (correct me if  
>> I'm wrong).
> I'm not in favor of it.
> If it was just me, I would only use the ISO images to rescue broken systems.
>
> But since there is a feeling some sort of rescue system is needed, /rescue is
> a start.
>
Just to recap the IRC discussions (both now and a few days ago). No, we
do not want /rescue, not even as a start. Nobody wants it, so there is
no point in doing that.

There is a general agreement that extending the initrd framework to
encompass this is the right thing to do.

What I think we agreed we'd want from the initrd/md image framework is:

 - Integrating it with installworld, so that there's always an initrd image

 - Making it a default mechanism to mount the root file system. Matt
argued that things like hammer2 are too complex to mount in the kernel
in the first place. And we already have things like luks, truecrypt
(tcplay), lvm, etc that we handle the mounting in the initrd framework.

 - Extending the initrd system with static rescue binaries and, in
general, network setup sort of things.

 - nice to have: cleanup/streamline/<insert buzzword here> the initrd
generation script

 - nice to have: crunching binaries to reduce size

 - nice to have: possibly look into compressed md images (if the
crunching is not good enough)

Most of this involves mostly infrastructure sort of things (build
system/Makefile integration) and shell scripting. Any takers?


Cheers,
Alex