read bash?

[Auke Kok]

Jan Eidtmann wrote:
> On Tue, Jan 30, 2007 at 17:57:26 -0800
> Auke Kok <sofar at foo-projects.org> wrote:
>> Moritz Heiber wrote:
>>> On Tue, 30 Jan 2007 12:36:01 +0100
>>> Jan Eidtmann <cmak at lunar-linux.org> wrote:
>>>
>>>> i just want to make lunar better and all i get is your 
>>>> BS...of course ive heard what you say...but im not 
>>>> satisfied with that. i want this support.  you didnt say 
>>>> that you dont ever want to support such things.  all you 
>>>> said is i _could_ stop. but why? because you failed? you 
>>>> even tried to implement the same thing...  and failed, is 
>>>> that my fault?  no. is it bash's fault?  no.
>>> Man, you're really going for it now.
>>>
>>> I'm not going to get stuck in this. You aren't worth it.
>>>
>>> Good luck duplicating work that has been done already.
>> this is completely irrelevant to Jan wanting to get something to work for 
>> himself. You're completely bullying him here. There is no need to get personal, 
>> and frankly I'm disturbed by that a bit.
>>
>> Jan, I really thought that only apps from shadow could prompt from a password. 
>> It turns out that that's wrong and I would discourage from using 'read' in 
>> startup scripts at all myself due to obvious security concerns.
>>
>> Otherwise, show me the script that fails and perhaps run it with -x so we can 
>> take a look at the code you're trying.
>>
> 
> thx to wodkahexe it works now. adding <&1 after the command 
> let the command get the std input back, even in a while 
> read.
> 
> anyway, this is pretty simple, but its a start. i think its 
> bad because its not very generic. it works for the new 
> dm-crypt target only (no loopback). also encrypted root is 
> not supported.
> 
> on the other hand, its just a small change to our mount 
> script that doesnt get in your way but adds support for 
> state-of-the-art filesystem encryption. :)
> 
> what this patch does:
> 
> * unlock dm-crypt devices before we parse fstab. this way 
> one can use fstab for encrypted volumes. devices which are 
> to unlock at boottime are kept in the new /etc/crypttab:
>     # device    mapping
>     /dev/sda6   sda6-c
> 
> to mount the unlocked filesystem you add it to your fstab 
> as normal but with just a slightly different device path:
> /dev/mapper/sda6-c  /root  xfs defaults 0 2
> 
> * if the user has a lvm package installed it scans discs 
> for volume groups and activates them


I'm OK with the general idea, however I would like to see a separate LVM init.d 
script (installed through the LVM2 module) that handles the lvm code before 
mount does. That way we have a pluggable system and offload some logic to a new 
script in a safe place. It would be a lot cleaner as well.

Do you think that might be feasable? Can you give it a try to make such a thing? 
It should be very simple of course...


Auke