Hi,

On Wed, 13 Nov 2019 19:37:04 +0100 Benjamin Drung 
<benjamin.dr...@cloud.ionos.com> wrote:
> Am Mittwoch, den 13.11.2019, 19:22 +0100 schrieb Johannes Schauer:
> > Quoting Benjamin Drung (2019-11-13 19:03:31)
> > > One hook is missing: A clean hook that is run after the cleanup, which
> > > would be run at last step of the setup function.
> > What kind of stuff would you run there instead of putting it into the
> > customize hook?
> My cleanup script contains two things:
> 
> 1) Removal of different stuff like /etc/resolv.conf,
> /etc/udev/rules.d/70-persistent-net.rules,

why can these two things not go into the customize hook?

> and /var/lib/apt/lists/"* (removing the apt lists in the customize hook is
> too early, see #944684)

Please reply to #944684 and remove the moreinfo tag once you do. If you find a
situation in which mmdebstrap does not remove /var/lib/apt/lists/*, then you
found a bug that I cannot yet reproduce.

> 2) Adjusting the timestamp of files/directories, e.g.:
> 
> find "$0/etc/" "$0/var/" -newermt "@${SOURCE_DATE_EPOCH}" \
>     \( -type f -o -type l \) -print0 | \
>     xargs -0r touch -hm -d "@${SOURCE_DATE_EPOCH}"

Why is the customize hook too late for this snippet?

I assume you are not creating a tarball then, because tar would take care of
clamping the mtime for you?

> > > I have only one issue related to the hooks: There is no easy, safe, and
> > > reliable way to copy stuff out of the image to an existing directory.
> > > Use case: copy the kernel+initrd out of the image for PXE booting.
> > I agree and I have needed this myself several times already. I'm still
> > thinking of a good way to implement this because it does not only involve
> > copying the data itself but also assuring right permission and ownership
> > information.  Furthermore, it should be possible to copy files in and out
> > of the chroot at any point where hook are currently run.
> > 
> > Currently I'm doing a lot of this in my own scripts:
> > 
> > --customize-hook='cp -a tmpfile "$1/target/directory"'
> > --customize-hook='echo foobar > "$1/target/file"'
> > 
> > I have been considering adding another option that allows extracting

As you know from my private mail, there are now some basic special hooks to
copy stuff in and out of the chroot. Just like with guestfish hooks, globbing
is not (yet) supported. This could be fixed but would require implementing a
full shell quoting parser as well as a symlink resolver which the current
solution is working around by utilizing /bin/sh inside the chroot. If you want
globbing, then create one hook that utilizes globbing in sh to create a tarball
of the files you want and a second hook to move that tarball out of the chroot.
Like this:

--customize-hook='chroot "$1" sh -c "cd /boot && tar -cf /tmp/boot.tar vmlinuz* 
initrd.img*"'
--customize-hook='copy-out /tmp/boot.tar .'
--customize-hook='rm "$1"/tmp/boot.tar'

Or like this:

--customize-hook='chroot "$1" sh -c "mkdir /tmp/boot && cp /boot/vmlinuz* 
/boot/initrd.img* /tmp/boot"'
--customize-hook='copy-out /tmp/boot .'
--customize-hook='rm -r "$1"/tmp/boot'

As you can see, both examples utilize globbing and possible symlink resolution
of /bin/sh running inside the chroot. You are right that mmdebstrap could
re-implement that functionality but this is more complicated than it might seem
at first. It not only needs a full parser of common shell quoting, but also
needs to resolve symlinks inside the chroot differently depending on which mode
was chosen.  Doing both shell parsing and symlink resolution safely is way
beyond the sparetime I have left right now.

Already implementing the copy-in/copy-out/... special hooks required a 1000
line large commit (git commit 86808172) because I had to invent a protocol with
which the process running the hook would communicate with the process that was
initially stared by the user over a AF_UNIX socket. Did I manage to put bugs
into the state machine that sends messages forth and back? Who knows... But
re-implementing a shell parser and symlink resolver would be yet another mega
project that is much out of scope right now. But patches welcome!

cheers, josch

Attachment: signature.asc
Description: signature

Reply via email to