Yes, it will be. But should it? I am unsure about that.
Perhaps some users would get annoyed by having it pop up every time? On the other hand, without enabled Tor, the gateway is pretty useless anyhow.[/quote]
Yes. So the user would have to run whonix-setup-wizard, anyhow (or try to correct the problem manually, for advanced users). So, it’s may be better to start it at boot, as a reminder that Whonix-Gateway is useless.
I think for consistency it would be best to create whonixsetup.done on gateway and workstation?
Yes, makes it easier for future re-reading.
https://github.com/troubadoour/whonix-setup-wizard/commit/7c8deda88b911987c497050914b23dbc3f082d98
This one I find potentially problematic. I guess either it’s a duplicate or it misses the usual making sure, that folder /var/cache/whonix-setup-wizard/status-files exists.
if Common.is_complete:
f = open('/var/cache/whonix-setup-wizard/status-files/whonixsetup.done', 'w')
f.close()
What about putting
if not os.path.exists('/var/cache/whonix-setup-wizard/status-files'):
os.mkdir('/var/cache/whonix-setup-wizard/status-files')
at the beginning of the script? So we could be sure that folder will exist either way and only need to run it once and for all.
Put the folder check in class “common” (the first one interpreted) and added “whonixsetup.done” check before writing it (2 commits).
In workstation, when running whonix-setup-wizard (after first boot), it was dispaying a blank page (the disclaimer pages text is not loaded). In the last commit, the wizard exits if “show_disclaimer” is false. The setup option no longer available, the user can run the repository wizard though.
The setup option no longer available, the user can run the repository wizard though.
This is problematic, see:
[code]kdesudo whonix-setup-wizard[/code]
[code]usage: whonix-setup-wizard [-h] {setup,repository,locale_settings}
whonix-setup-wizard: error: too few arguments[/code]
But if they run “setup”, then nothing happens.
There is also a bug, because when file /var/cache/whonix-setup-wizard/status-files/disclaimer.skip exists, repository wizard will not be started. Also whonixcheck would not be run at the end. Maybe rather than eliminating “setup” as long we don’t have much content, let’s use the whonixcheck page in meanwhile?
[quote=“Patrick, post:184, topic:650”]This is problematic, see:
kdesudo whonix-setup-wizard
usage: whonix-setup-wizard [-h] {setup,repository,locale_settings}
whonix-setup-wizard: error: too few arguments
But if they run “setup”, then nothing happens.[/quote]
Agreed, it’s not very consistent. In finish page only if all status files exist · troubadoour/whonix-setup-wizard@e59e6ee · GitHub, if all the status files exist, the wizard shows only the finish page, and whonixcheck is run. We could display a new page (“Whonix Setup was completed, you can run Whonix Repository …”) without running whonixcheck.
There is also a bug, because when file /var/cache/whonix-setup-wizard/status-files/disclaimer.skip exists, repository wizard will not be started. Also whonixcheck would not be run at the end. Maybe rather than eliminating "setup" as long we don't have much content, let's use the whonixcheck page in meanwhile?
I cannot reproduce that, whatever the combination of status files.
implemented 'whonix-setup-wizard quick', which instantly exits 0 if Tor has been enabled [not already been enabled] so the number of Whonix Setup Wizard pages in Qubes can be reduced to 1
I don’t have a strong opinion about that. I don’t mind either way.
In this case, I was just cross posting it. To notify the public that something is going on. I thought if someone cares strongly enough for it, they’d join phabricator.
Forum:
more people reading
more people sharing thoughts
threads fall down getting ignored
threads get long
stuff can be forgotten if no ticket exists
Phabricator:
nothing gets forgotten if properly tagged (by release milestone for next release or just by application “for some day some contribution”
not so much feedback
less wasting time on debating to no avail (aka “I am an expert user, I need the bikeshed to be blue, I need this extra debug info” and so forth but not contributing any actual research or code)
In an ideal world, everything would share the same data base and just provide different interfaces into it. (I wrote a bit about that dream here News - Whonix Forum)
In this case, after talking to an actual UI designer (Brennan Novak), I was quite sure that it’s best to re-implement exactly how tor-launcher is looking. Therefore continued on phabricator. Better than having all the advanced users try to reinvent something that mortals understand.
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)