[systemd-devel] Errors using machinectl pull-tar and machinectl pull-dkr

[Lennart Poettering]

On Mon, 02.03.15 11:00, Peter Paule (systemd-devel at fedux.org) wrote:

> 
> Quoting Lennart Poettering <lennart at poettering.net>:
> >>Thanks for clarifying this. :-) Any ETA for this? I'm looking for better
> >>integrated solution "into" systemd than docker and I really like the
> >>idea of having a systemd-daemon managing the containers.
> >
> >This is actually in place now in git. The first time you invoke one of
> >the "machinectl pull-xyz" commands we create /var/lib/machines.raw as
> >loop back file with btrfs inside which is then mounted to
> >/var/lib/machines. With the "machinectl set-limit" command you can
> >then set the size of this file dynamically, which resizes the btrfs
> >and the loopback file, as well as the btrfs quota settings
> >inside. It's really nice to use.
> >
> >Next step: make the file grow automatically during pull, if a certain
> >fill level of the file system is reached.
> 
> Great. Thanks for that. Do you always create that loop back file or only if
> on non-btrfs-filesystems?

Only on non-btrfs.

> Do you have a solution for the trustdb-stuff already? I only found this in
> the manual for gnupg2:
> 
> --trustdb-name file
>   Use file instead of the default trustdb. If file begins with a tilde and a
> slash, these are replaced by the $HOME directory. If the filename does not
> contain
>   a slash, it is assumed to be in the GnuPG home directory (‘~/.gnupg’ if
> --homedir or $GNUPGHOME is not used).

I wonder if we can use --trustdb-name /dev/null

> Maybe you should just create your own trustdb-file and ship it as well or
> create it on the first run of machined. There was no other obvious option
> for that I found. But I'm not really a gpg-pro. Maybe some other guy has a
> better idea about solving this thing.
> 
> BTW:
> Even RHEL 6.6 ships with gpg2 already. Do you really need to support
> gpg1? :-)

Well, gpg1 is kinda the default on FEdora at least since it is
installed as /usr/bin/gpg... We can of course switch to gpg2 instead,
but that's a package that is not as frequently installed I
think. Hence maybe a scheme where we use /usr/bin/gpg with a fallback
to /usr/bin/gpg2 might work.

Lennart

-- 
Lennart Poettering, Red Hat