On Friday 30 November 2007, Max Vozeler wrote:
> I've spent some time thinking about possible solutions
> for #414638 which all essentially worked around the fact
> that partman offers file systems (via valid_filesystems)
> that are not actually valid for certain crypto setups.

Could you elaborate a bit? The report talks about "the 'tmp' setting 
in /etc/crypttab". Is that equivalent to using random keys?
Why is use of random keys so restricted?

Also, isn't swap also allowed with random keys?

> I've pondered different ways of implementing this, and
> ended up with the attached patch. There are two things
> I don't like about it: Since we are piping the list of
> filesystems through the veto scripts, any error in them
> can cause the list to end up empty. The scripts have to
> be extra careful not to consume stdin by accident.

Why pipe them and not just pass them as a parameter?
Call the script as '$i $dev $id "$filesystems"' and in the script have
'filesystems="$3"'.

> The second thing I don't like but couldn't come up with
> anything better is the name 'valid_filesystems_veto'. If
> the basic idea is sound, and anyone has suggestions for
> a better name of the directory, I'm all ears :-)

{test,check}_valid_filesystems ?

> If we can, we should IMO try prevent invalid choices in the first place.

Agreed.

> +                     for fs in $(cat); do
> +                             case fs in
> +                             ext2)
> +                                     echo $fs
> +                                     ;;
> +                             esac
> +                     done

The preferred indentation for case statements is:
                                case fs in
                                    ext2)
                                        echo $fs
                                        ;;
                                esac

In this case I'd just use:
                                case fs in
                                    ext2) echo $fs ;;
                                esac

Cheers,
FJP

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to