-
-
Notifications
You must be signed in to change notification settings - Fork 46
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
bind-dirs.sh legacy function broken #2191
Comments
Also need to keep or restore file permissions. |
As for merging - you can use cp + rm. Or an overkill like |
That means a qubes-core-agent dependency on rsync would be permissible? |
On full template it is installed anyway. On whonix-gw too (probably whonix-ws too). |
Hmm, what about putting legacy function (that long list you've just made) into separate file? Or even better - move it to qubes-whonix package, as it is whonix-specific? |
I am worries about any update combinations Whonix 12/13 vs Qubes R3.1/R3.2. When I am using Qubes R.3.2 and install Whonix from Qubes repository, do I get Whonix 13 updated with Qubes R3.2? (It seems like or I messed up yesterday.) There is an even bigger issue. The path change of Qubes bind-dirs broke legacy Whonix bind-directories disabling itself. We can either ship a dummy file /usr/lib/qubes/bind-dirs.sh for legacy purposes or I update the qubes-whonix package bind-directories script to the new path. And perhaps a better check that does not rely on file names? Which qubes-core-agent version first shipped bind-dirs.sh? |
…igher than 3.2.8-1+deb8u1 QubesOS/qubes-issues#2191
Ok, so leave it where it is.
Yes.
That file was always installed into
I'm not sure if it worth it. The best would be some feature discovery protocol (just package version isn't the best as the same feature may be backported to older branches, or dropped in the future). But just checking for path existence is IMO good enough feature discovery.
3.2.0. But as noted above, IMO this is bad idea. |
Marek Marczykowski-Górecki:
Thank you! But actually, I made good progress on an updated qubes-whonix package. Related:
Good! And good to know.
Whonix legacy bind-directories disables itself on both file names and I want to totally wipe Whonix legacy bind-directories at some point. It Once testing is done and the updated qubes-core-agent package is in Users upgrading to Qubes R3.2 but staying with Whonix 12, not sure if [Users starting with fresh Qubes R3.2 / Whonix 13 images are currently |
This is fixed in qubes-whonix git. Updated package will be uploaded [and called for public testing] once another blocking task https://phabricator.whonix.org/T528 is done. |
An updated package is in Whonix jessie-proposed-fixes as well as testers repository. |
R3.2 with testing repository
There is a problem with the whonix-gw template. Perhaps a release critical bug.
The symptom is starting with a fresh Tor data dir and Whonix Setup Wizard popping up again since /etc/tor/torrc settings get lost. Perhaps more.
The cause is a bug in
bind-dirs.sh
in thelegacy
function.Both, legacy folders
/rw/srv/qubes-whonix/
and/rw/srv/qubes/
contained a foldervar
.Do you know how to properly merge/move these folders?
Perhaps I should just abandon the generic approach and do it manually for the 8 legacy folders? I.e.
etc.?
The text was updated successfully, but these errors were encountered: