[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACuV5sCKgV=_g74Y8B=P+8bK8-cCKAwh=0PrhjQJ6zNvzb6G6A@mail.gmail.com>
Date: Mon, 26 Mar 2012 10:55:33 +0000
From: Zenny <garbytrash@...il.com>
To: owl-users@...ts.openwall.com
Subject: Re: Customizing Owl to fit in a small sized USB Stick or CF
On 3/26/12, Solar Designer <solar@...nwall.com> wrote:
> On Mon, Mar 26, 2012 at 07:39:27AM +0000, Zenny wrote:
>> On 3/26/12, Solar Designer <solar@...nwall.com> wrote:
>> > Gremlin had patches to add a new make target that would generate flash
>> > images instead of ISOs. I think those were primarily intended for
>> > installing systems from, and they were for larger flash devices (1 GB
>> > being considered the minimum anyone would likely happen to have handy
>> > anyway).
>>
>> Great info. Do you mean this one:
>> ftp://ftp.gremlin.people.openwall.com/pub/linux/Owl/INSTALL/?
>
> Almost. IIRC, Gremlin also produced a patch to our Owl/build/ tree to
> automatically generate flash images like that. Gremlin, please post
> that patch to owl-dev now such that we could refer to it at least.
Appreciate if Gremlin post the patch somewhere and post a link here.
@Gremlin: Thanks in advance!
>
>> With ZFS on Linux (ZoL) and BTRFS in the horizon, it seemed as such a
>> script would be nice to separate OS from the data. With ro CF/USB with
>> an encrypted data volume implemented in Owl would indeed be awesome!
>
> Owl already supports encryption for loopback devices, so you can use
> an encrypted ext4 filesystem with it currently (with our pre-built
> kernels and tools). As to keeping the OS read-only, this also can be
> done e.g. like it's done on our live CDs. We could add some scripts to
> make setting this up easier, but I think folks should start actually
> setting up systems like that first, so that we know what's actually in
> demand and what is not.
>
>> Thanks that you appreciate interest in new features. Have you ever
>> though to HAMMER filestystem from DragonflyBSD to port? I am
>> optimistic that Owl team could port HAMMER to Owl (as you already have
>> ported several of the BSD utilities).
>
> That would be an ambitious project of its own, and porting of kernel
> code is quite different from porting of userspace code - including in
> terms of subsequent maintenance as the Linux kernel interfaces change.
>
> One of the reasons why Owl evolves a lot slower than we'd like it to is
> that it's not the only project we're working on. While certain other
> projects of ours like John the Ripper are technically part of Owl,
> they're not essential to Owl and they have an overall negative effect on
> Owl development in particular (they take more time than they're worth as
> it relates to Owl, even though they're very valuable on their own). In
> this context, adding yet another project that is not essential to Owl
> would have negative overall effect on Owl development. Thus, no, let's
> not port HAMMER to Linux on our own. If someone else does it and
> maintains it, then that would bring it within consideration for Owl.
Just found that there was an effort made over github, but could not
say whether it is of Owl-standard:
§1 http://dlorch.github.com/hammer-linux/
§2 http://dlorch.github.com/hammer-linux/files/hammer-lorch.pdf
>
> Meanwhile, we support DRBD in our kernel builds (and we need to add the
> corresponding userspace tools to Owl), and we may add support for some
> additional filesystems that are already supported on Linux. BTW, of the
> less common ones, I'd consider POHMELFS.
Thanks for pointing to POHMELFS. Interesting one, studying now but it
has transformed a lot since it was conceived as evident from the post
here: https://lkml.org/lkml/2012/2/8/293
POHMELFS seems to become just the wrapper for the new network,
elliptis, but for me it is early to comment. ;-)
>
> Alexander
>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
