Qubes - wheezy vs jessie - sysvinit vs systemd - 10 vs 11

Qubes-Whonix
1

⚓ T273 control-port-filter-python.service exits pre-maturely made me think. I am not sure it’s worth trying to get a Whonix 10 based qubes-whonix ready. Because Whonix 10 is wheezy / sysvinit based and Whonix 11 will be jessie / systemd based.

Whonix 10:
https://phabricator.whonix.org/maniphest/?statuses=open&allProjects=PHID-PROJ-azftsdqyk3mbrlzazoc6#R

And…

Whonix 11:
https://phabricator.whonix.org/maniphest/query/FAHipiL19o_a/#R

Have a very small task list.

Wheezy / systemd just doesn’t work well together. Shipping the systemd unit files in the qubes-whonix package would likely lead to issues, when these unit files are later removed and moved to the appropriate specific packages (such as control-port-filter-python). Namely, the package manager would refuse upgrading, because the file is already owned by another package, unless we figure out using some complex - easy to get wrong - ‘replaces’ (Debian packaging terminology) magic.

So options are, we maintain Whonix 9 with all it’s issues (Tor Browser starter, updater broken and more) a little more and skip Whonix 10 [although non-Qubes versions are in RC and quite releaseable, looks like] or skip Whonix 10, get quickly Whonix 11 with full jessie / systemd support ready.

I guess if you want to get Whonix 10, originally wheezy / sysvinit to work for qubes-whonix (due to requirement on systemd) you’ll be going in circles and there will still be weird [upgrading] issues.

2

i can not wait to see the futur of the Whonix Qubes :slight_smile:

keep up the good work!

3

could Devuan become an option?

4

For the purpose of this thread, no. Well, it’s not that bad. This isn’t systemd bashing. I might have forgotten to be clear that this is a qubes-whonix specific issue - that only happens because they want to use systemd on wheezy - before all Whonix work on jessie / systemd, i.e. Whonix 11 has been finished. I don’t think any of us hates systemd as much or at all as the work to switch to a new base distribution would be justified. There is probably no unsolvable issues for Whonix 11 that would justify that.

5

This issue is not a current expertise of mine, so I’ll let @nrgaway decide on this one, since he is still the primary coder of the “qubes-whonix” module.

It looks like the latest is that @nrgaway has a Whonix 10 compatible “qubes-whonix” package ready, and we have proposed a potential Whonix 10 release in the next few days. [1]

At least with Qubes, if something like this breaks, we have the ability to release an upgrade through a new RPM template package that overwrites a previous broken version through the Qubes YUM update interface, and people’s userland data/settings don’t get affected in their VMs, thanks to the Qubes TemplateVM partitioning scheme.

[1] ⚓ T275 Qubes Whonix 9.6.9 and 10.0.5 is ready

6

[quote=“Patrick, post:1, topic:1038”]https://phabricator.whonix.org/T273 made me think. I am not sure it’s worth trying to get a Whonix 10 based qubes-whonix ready. Because Whonix 10 is wheezy / sysvinit based and Whonix 11 will be jessie / systemd based.

Whonix 10:
https://phabricator.whonix.org/maniphest/?statuses=open&allProjects=PHID-PROJ-azftsdqyk3mbrlzazoc6#R

And…

Whonix 11:
https://phabricator.whonix.org/maniphest/query/FAHipiL19o_a/#R

Have a very small task list.

Wheezy / systemd just doesn’t work well together. Shipping the systemd unit files in the qubes-whonix package would likely lead to issues, when these unit files are later removed and moved to the appropriate specific packages (such as control-port-filter-python). Namely, the package manager would refuse upgrading, because the file is already owned by another package, unless we figure out using some complex - easy to get wrong - ‘replaces’ (Debian packaging terminology) magic.[/quote]

What ya mean Wheezy / systemd doesn’t work well together? It pretty much works as expected. As the ‘distributor’ of a package, you will be expected to place those unit files in ‘/lib/systemd/system’ for files such as ‘control-port-filter-python’. Now, Tor on the other hand is not distributed by you, so you would then place the Whonix overriding unit file in ‘/etc/systemd/system’ as that is meant for local unit files.

Therefore qubes-whonix can create a ‘/etc/systemd/system/control-port-filter-python’ and ‘/etc/systemd/system/qubes-whonix-tor’ (which will can set a requires / conflict so as not to run when whonix provides its own). This is pretty simple and standard and really only needs a bit of planing, which I think we just did :slight_smile:

So options are, we maintain Whonix 9 with all it's issues (Tor Browser starter, updater broken and more) a little more and skip Whonix 10 [although non-Qubes versions are in RC and quite releaseable, looks like] or skip Whonix 10, get quickly Whonix 11 with full jessie / systemd support ready.

I guess if you want to get Whonix 10, originally wheezy / sysvinit to work for qubes-whonix (due to requirement on systemd) you’ll be going in circles and there will still be weird [upgrading] issues.


So, given that there is an easy solution to this issue, and that I have Whonix 10 ready to go, I would suggest I make the suggested changes and let it roll.

I also suggest you add a ‘–testing-current-sources’ option to your current builder so I can start building Whonix in Jessie :slight_smile:

7

Yes, put any necessary systemd files required by the qubes-whonix package into /etc. Much better. Less chance for later conflicts.

Ok, let’s do it.

If I understand this right, you should be able to do this already.

git master and 11.0.0.0.1 and above:

  • are totally jessie only. That is done. (https://phabricator.whonix.org/T270)
  • although using frozen sources
  • you should be able to use ‘–freshness current’ that would have the same effect (untested)
  • ‘–testing-frozen-sources’ is currently broken, because Debian has not created the stretch repository yet, since jessie has not been released yet, but that does not matter and will fix itself when jessie has been released / Debian starts providing the stretch repository
  • please post a feature phabricator request if you want ‘–testing-current-sources’ (that option names are also somewhat non-ideal, and I am looking for something better)
  • for Whonix 11, I hope we can keep the default frozen sources, as per separate discussion: Whonix Forum
  • I guess (somewhat hope) you don’t need ‘–testing-current-sources’ for Whonix 10.

Does this answer it?

8

[quote=“Patrick, post:7, topic:1038”]Yes, put any necessary systemd files required by the qubes-whonix package into /etc. Much better. Less chance for later conflicts.

Ok, let’s do it.

If I understand this right, you should be able to do this already.

git master and 11.0.0.0.1 and above:

  • are totally jessie only. That is done. (https://phabricator.whonix.org/T270)
  • although using frozen sources
  • you should be able to use ‘–freshness current’ that would have the same effect (untested)
  • ‘–testing-frozen-sources’ is currently broken, because Debian has not created the stretch repository yet, since jessie has not been released yet, but that does not matter and will fix itself when jessie has been released / Debian starts providing the stretch repository
  • please post a feature phabricator request if you want ‘–testing-current-sources’ (that option names are also somewhat non-ideal, and I am looking for something better)
  • for Whonix 11, I hope we can keep the default frozen sources, as per separate discussion: Whonix Forum
  • I guess (somewhat hope) you don’t need ‘–testing-current-sources’ for Whonix 10.

Does this answer it?[/quote]

Yes, I think it does, thank you.

I think I was confused between current-sources and testing-current-sources, which I understand to be Jessie, and stretch respectively for a Jessie Whonix 11 build.