Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
marmarek opened this issue Jun 15, 2015 · 9 comments
Closed
Labels
C: core P: major Priority: major. Between "default" and "critical" in severity.
Milestone

Comments

@marmarek
Copy link
Member

No description provided.

@marmarek marmarek added enhancement C: core P: major Priority: major. Between "default" and "critical" in severity. labels Jun 15, 2015
@marmarek
Copy link
Member Author

marmarek commented Jul 8, 2015

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

@mig5
Copy link

mig5 commented Jul 18, 2015

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
Copy link

mig5 commented Jul 18, 2015

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
Copy link
Member Author

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 added a commit to marmarek/old-qubes-core-agent-linux that referenced this issue Jul 18, 2015
@adrelanos
Copy link
Member

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
Copy link
Member Author

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 marmarek added this to the Release 3.0 milestone Aug 6, 2015
@rootkovska rootkovska modified the milestones: Release 3.1, Release 3.0 Sep 2, 2015
@rootkovska
Copy link
Member

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

@rootkovska rootkovska reopened this Sep 2, 2015
@marmarek
Copy link
Member Author

marmarek commented Sep 2, 2015

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
Copy link

mig5 commented Sep 2, 2015

It's been working well for me since July.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: core P: major Priority: major. Between "default" and "critical" in severity.
Projects
None yet
Development

No branches or pull requests

4 participants