Make it possible to use Debian VM as UpdateVM for downloading dom0 updates

[marmarek]

No description provided.

[marmarek]

Improvements made here: QubesOS/qubes-core-agent-linux@3fdb67a
Needs more testing.

[marmarek]

Improvements made here: QubesOS/qubes-core-agent-linux@3fdb67a
Needs more testing.

[mig5]

I updated by Debian template to use the new version of the script as per above commit, and ensured yum-utils was installed.

But my qubes-dom0-update fails with attached errors: https://gist.github.com/mig5/3ad90f15b8189eb333fd

This actually happens prior to execution of the script in question: it seems to be at the step where the yum repo stuff is tar'ed up on the dom0 and extracted in the guest via pipe to qvm-run. It looks like it missing a / slash in the extraction, maybe a distro-specific issue in use of tar on Debian compared to Fedora.

Maybe I am missing a corresponding update to the qubes-dom0-update script for dom0?

[mig5]

I updated by Debian template to use the new version of the script as per above commit, and ensured yum-utils was installed.

But my qubes-dom0-update fails with attached errors: https://gist.github.com/mig5/3ad90f15b8189eb333fd

This actually happens prior to execution of the script in question: it seems to be at the step where the yum repo stuff is tar'ed up on the dom0 and extracted in the guest via pipe to qvm-run. It looks like it missing a / slash in the extraction, maybe a distro-specific issue in use of tar on Debian compared to Fedora.

Maybe I am missing a corresponding update to the qubes-dom0-update script for dom0?

[mig5]

I found the issue: /var/lib/qubes/dom0-updates is chown root:root and chmod 755 on the Debian template image.

In the Fedora template, it is chown user:user and chmod 775.

I had to make it chown user:user and chmod 775 in the Debian VM/template before the tar command (and qubes-dom0-update in general) would work successfully (with chmod 755, which I tried first, I still had tar errors on the /var/lib/qubes/dom0-updates/etc subdirectory).

Have you already accounted for this perm fix in the Debian template/qubes-core-agent package? Or perhaps the script could force the perms before the tar execution, after starting the UpdateVM, just to be on the safe side. Happy to supply a patch if I know the right place!

Thanks

[mig5]

I found the issue: /var/lib/qubes/dom0-updates is chown root:root and chmod 755 on the Debian template image.

In the Fedora template, it is chown user:user and chmod 775.

I had to make it chown user:user and chmod 775 in the Debian VM/template before the tar command (and qubes-dom0-update in general) would work successfully (with chmod 755, which I tried first, I still had tar errors on the /var/lib/qubes/dom0-updates/etc subdirectory).

Have you already accounted for this perm fix in the Debian template/qubes-core-agent package? Or perhaps the script could force the perms before the tar execution, after starting the UpdateVM, just to be on the safe side. Happy to supply a patch if I know the right place!

Thanks

[marmarek]

Apparently file permissions set in "install" stage of package build are
not preserved. According to debian policy
manual
this should be done in postinst script.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

Apparently file permissions set in "install" stage of package build are
not preserved. According to debian policy
manual
this should be done in postinst script.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[adrelanos]

Is it ensured, that user user and group user exists at the time of run of qubes-core-agent-linux's postinst script? Otherwise the postinst script could fail.

For reference/comparison you could look how /var/lib/dpkg/info/tor.postinst handles user account creation and folder permissions.

[adrelanos]

Is it ensured, that user user and group user exists at the time of run of qubes-core-agent-linux's postinst script? Otherwise the postinst script could fail.

For reference/comparison you could look how /var/lib/dpkg/info/tor.postinst handles user account creation and folder permissions.

[marmarek]

On Sun, Jul 19, 2015 at 05:00:14AM -0700, Patrick Schleizer wrote:

Is it ensured, that user user and group user exists at the time of run of qubes-core-agent-linux's postinst script? Otherwise the postinst script could fail.

Yes, it is created by qubes-core-agent-linux's preinst script.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Sun, Jul 19, 2015 at 05:00:14AM -0700, Patrick Schleizer wrote:

Is it ensured, that user user and group user exists at the time of run of qubes-core-agent-linux's postinst script? Otherwise the postinst script could fail.

Yes, it is created by qubes-core-agent-linux's preinst script.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[rootkovska]

It's too late for adding any new features to 3.0, moving to 3.1 for further considerations.

[rootkovska]

It's too late for adding any new features to 3.0, moving to 3.1 for further considerations.

[marmarek]

Actually it's not about adding - its already implemented for some time. It's about testing and deciding whether we want to include it in release notes and documentation as supported option.

[marmarek]

Actually it's not about adding - its already implemented for some time. It's about testing and deciding whether we want to include it in release notes and documentation as supported option.

[mig5]

It's been working well for me since July.

[mig5]

It's been working well for me since July.