Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upbind-dirs.sh legacy function broken #2191
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Also need to keep or restore file permissions. |
andrewdavidwong
added
bug
P: critical
C: Whonix
labels
Jul 21, 2016
andrewdavidwong
added this to the Release 3.2 milestone
Jul 21, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Jul 21, 2016
Member
As for merging - you can use cp + rm. Or an overkill like rsync --remove-source-files...
|
As for merging - you can use cp + rm. Or an overkill like |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Jul 21, 2016
Member
That means a qubes-core-agent dependency on rsync would be permissible?
|
That means a qubes-core-agent dependency on rsync would be permissible? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Jul 21, 2016
Member
On full template it is installed anyway. On whonix-gw too (probably whonix-ws too).
On minimal template it's easy - rsync do not pull any other packages, it's about 800kb.
So, if that would make solution much easier - yes, it's ok to add rsync dependency.
|
On full template it is installed anyway. On whonix-gw too (probably whonix-ws too). |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Jul 21, 2016
Member
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?
|
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? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Jul 22, 2016
Member
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?
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? |
added a commit
to adrelanos/qubes-whonix
that referenced
this issue
Jul 22, 2016
added a commit
to adrelanos/qubes-whonix
that referenced
this issue
Jul 22, 2016
added a commit
to adrelanos/qubes-whonix
that referenced
this issue
Jul 22, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Jul 23, 2016
Member
I am worries about any update combinations Whonix 12/13 vs Qubes R3.1/R3.2.
Ok, so leave it where it is.
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.)
Yes.
There is an even bigger issue. The path change of Qubes bind-dirs broke legacy Whonix bind-directories disabling itself.
That file was always installed into /usr/lib/qubes/init, not /usr/lib/qubes. Some references to it were broken. I assume the same applies to legacy Whonix bind-directories disabling itself.
Since it isn't easy possible to change old Whonix packages (possibly already installed somewhere), better add a compatibility symlink (/usr/lib/qubes/bind-dirs.sh -> /usr/lib/qubes/init/bind-dirs.sh).
And perhaps a better check that does not rely on file names?
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.
Which qubes-core-agent version first shipped bind-dirs.sh?
3.2.0. But as noted above, IMO this is bad idea.
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Jul 23, 2016
Member
Marek Marczykowski-Górecki:
I am worries about any update combinations Whonix 12/13 vs Qubes R3.1/R3.2.
Ok, so leave it where it is.
Thank you!
But actually, I made good progress on an updated qubes-whonix package.
Testing it currently. It fixes that bind-dirs.sh legacy function.
Related:
#2194
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.)
Yes.
Good! And good to know.
There is an even bigger issue. The path change of Qubes bind-dirs broke legacy Whonix bind-directories disabling itself.
That file was always installed into
/usr/lib/qubes/init, not/usr/lib/qubes. Some references to it were broken. I assume the same applies to legacy Whonix bind-directories disabling itself.
Since it isn't easy possible to change old Whonix packages (possibly already installed somewhere), better add a compatibility symlink (/usr/lib/qubes/bind-dirs.sh->/usr/lib/qubes/init/bind-dirs.sh).And perhaps a better check that does not rely on file names?
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.
Which qubes-core-agent version first shipped bind-dirs.sh?
3.2.0. But as noted above, IMO this is bad idea.
Whonix legacy bind-directories disables itself on both file names and
qubes-core-agent version equal or higher than '3.2.8-1+deb8u1' now.
Generally you are right, but I doubt we will or should be backporting
bind-dirs.sh to R3.1. So I guess in this case it is good enough.
I want to totally wipe Whonix legacy bind-directories at some point. It
depends on when old Qubes releases can be considered deprecated and when
Qubes-Whonix versions start to depend on some minimum Qubes version.
Since that goes off-topic here, I will ask on qubes-devel.
Once testing is done and the updated qubes-core-agent package is in
Whonix stable repository, there should be a functional Qubes R3.1 Whonix
12 to Qubes R3.2 Whonix 13 upgrade path.
Users upgrading to Qubes R3.2 but staying with Whonix 12, not sure if
that happens, could still benefit from the compatibility symlink.
[Users starting with fresh Qubes R3.2 / Whonix 13 images are currently
affected by "bind-dirs plus bind-directories at the same time" bug. So
after the upgrades, a new template build would be good.]
|
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 was referenced Jul 23, 2016
added a commit
to Whonix/qubes-whonix
that referenced
this issue
Jul 24, 2016
added a commit
to adrelanos/qubes-whonix
that referenced
this issue
Jul 24, 2016
added a commit
to adrelanos/qubes-whonix
that referenced
this issue
Jul 24, 2016
added a commit
to adrelanos/qubes-whonix
that referenced
this issue
Jul 24, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Jul 27, 2016
Member
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.
|
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Aug 1, 2016
Member
An updated package is in Whonix jessie-proposed-fixes as well as testers repository.
|
An updated package is in Whonix jessie-proposed-fixes as well as testers repository. |
adrelanos commentedJul 21, 2016
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.shin thelegacyfunction.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.?