Hammer feature suggestion

[Sdävtaker]

Hey,
I was using Hammer for a while (10 months) and i found it extremly
usefull (and stable now).
The PFSs are very handfull for administration and backup.
I manage 3 servers with DFBSD right now and 0 makes mirror-copy in 1,
1 in 2 and 2 in 0 so i can ever have a backup of everything just in
case.
I was wondering if there is the possibility to make the PFSs crypt-able.
You pass them the RSA/DSA pair key at mount (mount -key pathToKey
/pfs/cryptedPFS ), the key could be stored in a removable device, like
a usb stick, CDROM or anything else (get it from a server in local
network, i dont know).
I found it usefull for notebooks, you can crypt /home and /var, have a
usb with the key pair, so if someone stole the PC, at least you dont
have to worry about the data.
I was thinking use the keys for crypt at  8MB chunks basis (i had read
hammer has a 8MB chunks allocation in the tree) and code/decode at
use.
I wondering if it is possible to add this feature without big
collaterals, if you think it can be added smoothly and someone can
guide me a little i can try to code it.
Sdav

BSDday Argentina 2009

[Sdävtaker]

As i posted last month, there will be a BSD event in Argentina May 29 and 30
I got a spot for a Hammer administration introduction.
I will talk about, setup, basic use, config files, mirroring, and some
introduction to DFBSD's basics (pkg_src where to find some basic
config files, etc...)
Link to talks schedule :
http://www.bsdday.org/index.php?p=cronograma
Sdav

Re: Hammer feature suggestion

[Matthew Dillon]

:I was wondering if there is the possibility to make the PFSs crypt-able.
:You pass them the RSA/DSA pair key at mount (mount -key pathToKey
:/pfs/cryptedPFS ), the key could be stored in a removable device, like

Not that we would build into HAMMER itself.  That sort of crypto needs
to be its own block device of sorts.

I think it will become easier to build those sorts of layers once
the devfs project is done.  Then we could add a shadow block device
topology that provides encrypted access to the disk block devices.

-Matt

Re: mail/mailx question

[Matthew Dillon]

:
:I was trying to write a mail script and couldn't find a way to set the
:"from" field to an arbitrary address. =A0Is there a way to do this with
:the base mail client? =A0I ended up installing mutt to solve the
:problem.
:
:Tim

Normally you do it by running sendmail directly with numerous options.
Typically -f ... and -oi.  I'm not sure what the options should be,
exactly.

-Matt
Matthew Dillon 

Re: mail/mailx question

[Tim Darby]

Thanks, Matt and Bill.  It didn't occur to me that sendmail could be
used for this.  Am I correct in thinking that dma would handle this
too?

Tim


On Tue, May 26, 2009 at 12:01 PM, Matthew Dillon
 wrote:
>
> :
> :I was trying to write a mail script and couldn't find a way to set the
> :"from" field to an arbitrary address. =A0Is there a way to do this with
> :the base mail client? =A0I ended up installing mutt to solve the
> :problem.
> :
> :Tim
>
>    Normally you do it by running sendmail directly with numerous options.
>    Typically -f ... and -oi.  I'm not sure what the options should be,
>    exactly.
>
>                                        -Matt
>                                        Matthew Dillon
>                                        

Re: mail/mailx question

[Matthew Dillon]

:Thanks, Matt and Bill.  It didn't occur to me that sendmail could be
:used for this.  Am I correct in thinking that dma would handle this
:too?
:
:Tim

It should though I don't know how much of the option set DMA
supports.  'man dma'.  It does seem to support -f and -oi.

-Matt

Re: [issue1357] A cloned tap device patch (for a person to test KQEMU 1.4.0pre1 for QEMU 0.10.1)

[Naoya Sugioka]

Hi Sephe,

Sorry for the slow res too.
The response mail to sub...@... failed some reasons, also it took me a
few days to realize  :-)

I'll test your 3 patches for a while and your patches (including
'closed-out' flag operation)
work well with qemu/kqemu environment.

BTW, I guess we need a small patch for qemu to open correct tap device
node (ex /dev/tap*0*),
as I attached, but it is another story. I'm appreciate if someone can
take care of the patch, if need.

thanks a lot for your assistance.
-Naoya

On Mon, May 18, 2009 at 7:40 AM, Sepherosa Ziehau (via DragonFly issue
tracker)  wrote:
>
> Sepherosa Ziehau  added the comment:
>
> On Sun, May 17, 2009 at 12:06 PM, Sepherosa Ziehau  
> wrote:
>> On Thu, May 14, 2009 at 1:11 PM, Naoya Sugioka  
>> wrote:
>>> Hi Sephe,
>>>
>>> Thank you for your comment. Here I made a patch which includes you pointed.
>>> I hope you will review this patch too.
>>> - Naoya
>>
>> Sorry for the delay, I will review it today.
>
> Could you test following three patches:
> http://leaf.dragonflybsd.org/~sephe/0001-tap-4-Add-ifclone-support.patch
> http://leaf.dragonflybsd.org/~sephe/0002-tap-4-Correct-reversed-logic.patch
> http://leaf.dragonflybsd.org/~sephe/0003-tap-4-More-fixes-to-tapuponopen.patch
>
> The first one is an adjusted version of your submitted patch.
>
> Best Regards,
> sephe
>
> _
> DragonFly issue tracker 
> 
> _
>


net.c.diff
Description: Binary data

Re: Hammer feature suggestion

[Sdävtaker]

Sounds nice, didnt know devfs was getting implemented.
Thanks for the reply.
Sdav

On Tue, May 26, 2009 at 15:51, Matthew Dillon
 wrote:
> :I was wondering if there is the possibility to make the PFSs crypt-able.
> :You pass them the RSA/DSA pair key at mount (mount -key pathToKey
> :/pfs/cryptedPFS ), the key could be stored in a removable device, like
>
>    Not that we would build into HAMMER itself.  That sort of crypto needs
>    to be its own block device of sorts.
>
>    I think it will become easier to build those sorts of layers once
>    the devfs project is done.  Then we could add a shadow block device
>    topology that provides encrypted access to the disk block devices.
>
>                                                -Matt
>



-- 
Sdävtaker prays to Rikku goddess for a good treasure.