Done.
Added some more minor improvements and refactoring.
New version was uploaded.
Thanks to @grass now also only VirtualBox can be installed without installing Kicksecure or Whonix:
New version was uploaded.
1 Like
related:
The Whonix Linux Installer is now capable to install VirtualBox on Debian bookworm.
New version was uploaded just now.
1 Like
Merged your repository adding refactoring.
Fixed a syntax error.
CI success.
Uploaded new version just now.
bug: a few extraneous messages.
whonix-installer-xfce --reimport --testers --destroy-existing-guest -n
whonix-installer-xfce: [NOTICE]: If you would like to redownload the image, read about --redownload (safe).
whonix-installer-xfce: [NOTICE]: If you would like to reimport the image, read about --reimport (danger).
Just some minor things, perfections… I am wondering if we can standardize or at least improve the output format.
One thing I am pretty sure about.
kicksecure-installer-xfce: [NOTICE]: Detected architecture: x86_64.
kicksecure-installer-xfce: [NOTICE]: Detected system: Linux.
The trailing dot seems unnecessary in a format:
Test name: test result
Other useful improvements? Test results always within single quotes (')? Example:
kicksecure-installer-xfce: [NOTICE]: Detected system: ‘Linux’
When to use underline?
When to use bold?
Maybe consistent use isn’t warranted as some things are to be specifically highlighted because specifically important.
kicksecure-installer-xfce: [NOTICE]: Detecting guest version…
kicksecure-installer-xfce: [NOTICE]: User defined, dry_run or dev version already configured. Autodetection form API not required.
These are a bit inconsistent because these don’t use the format:
Test or action name name: details
Commited with the format test: 'result'
1 Like
Debian 12 with apt-get 2.6.1 wraps the line wrongly when output if not a terminal (pipe, file).
This has to do with log_term_and_file redirecting stdout and stderr to file and then tail -f file.log &, this way we don’t have to write redirection for every command like echo something >&3.
This bug is new and introduced on between apt 2.2.4 and 2.6.1.
I believe it was fixed without downsides in this commit.
1 Like
Further improved wording.
Please check and feel free to revert any nonsensical changes, if any.
Should we change [WARN] to [WARNING]?
Then it would have a similar length as [NOTICE].
I followed tor’s log levels. I don’t think warning is correct, because it is a an action/verb, not a level. Else the levels would need to be debugging, noticing, informing.
We could however change notice to note? Or that changes the meaning…
1 Like
From your commits I get that tests should have the explanation underlined. Read the commits, they made the phrases clearer.
1 Like
Not necessarily?
I did now underline:
A) All failure cases (when function die is used). I.e…
${underline}Package List Update:${nounderline} 'FAIL' - Could not update package lists.
B) Specifically important test results. But it’s questionable if that makes sense in all cases. For example, Existing VM Check, while only an “NOTICE”, seems exceptionally interesting for the user.
On the other hand, I might tend to overuse some elements such as underline, bold. If “everything is important” then nothing is. I mean, if too much is highlighted, then the actually important stuff might get unnoticed. So please stop me if I am overusing some stylistic thing. Usability design naturally needs several revisions. So no worries, no offense taken.
Not sure if you meant that: But underlining the full explanation text in case of errors would probably be too much. Stylistic elements need to be focused and sparingly used to have a positive effect.
1 Like
True but we might have different views of what is most important…
Yeah, I agree we shouldn’t emphasize all the tests considering how much they are.
I think the log levels already help a lot in that case to hide extraneous info, so we should consider how much more visualization can the user get from bold and highlight.
1 Like
If you think I am using something too much, please revert, because I guess I tend to overuse stylistic elements. Useful if you can slow down overuse.
Just reverting stylistic elements seems easier than discussing each one?
If I feel an important one was removed, I’ll mention that here.
installer-dist: [NOTICE]: Performing integrity checks…
installer-dist: [NOTICE]: Signify key:
untrusted comment: Patrick Schleizer adrelanos@whonix.org signify public key
RWQ6KRormNEETq+M8IysxRe/HAWlqZRlO8u7ACIiv5poAW0ztsirOjCQ
installer-dist: [NOTICE]: Verifying file: ‘/home/user/installer-dist-download/Whonix-Xfce-17.0.3.4.sha512sums’
Signature Verified
installer-dist: [NOTICE]: Signify Signature Verification: ‘success’
installer-dist: [NOTICE]: Checking SHA512 checksum: ‘/home/user/installer-dist-download/Whonix-Xfce-17.0.3.4.ova’
6fcebf8c0b48e5432a0c5e764b09bcc1ff46e9cc92066e8ef21695f4c059522ed1efe671e2705e7b91ab6480a741643ee0beca2dc162e5bae8d20eb1f474ba33 /home/user/installer-dist-download/Whonix-Xfce-17.0.3.4.sha512sums
installer-dist: [NOTICE]: SHA512 Hash Verification: ‘success’
This seems too chatty now for loglevel notice. Going through it line by line.
installer-dist: [NOTICE]: Performing integrity checks…
Useful because that could take a while and user shouldn’t think something is hanging.
installer-dist: [NOTICE]: Signify key:
untrusted comment: Patrick Schleizer adrelanos@whonix.org signify public key
RWQ6KRormNEETq+M8IysxRe/HAWlqZRlO8u7ACIiv5poAW0ztsirOjCQ
I can see how that is useful in case the signify key is ever updated and the script still has the old version. Might rarely happen.
So let’s make that loglevel info?
installer-dist: [NOTICE]: Verifying file: ‘/home/user/installer-dist-download/Whonix-Xfce-17.0.3.4.sha512sums’
More useful for loglevel info?
This seems a bit confusing even for me since it doesn’t really say which file is used to verify what other file.
Instead when loglevel is info, show the full command instead such as:
Running: $ ...
Signature Verified
This is the output by signify.
Ideally hidden when loglevel is notice but shown when loglevel is info.
If difficult to implement and making the code too complex, also not a big deal.
installer-dist: [NOTICE]: Signify Signature Verification: ‘success’
Loglevel info.
installer-dist: [NOTICE]: Checking SHA512 checksum: ‘/home/user/installer-dist-download/Whonix-Xfce-17.0.3.4.ova’
Similar to above.
6fcebf8c0b48e5432a0c5e764b09bcc1ff46e9cc92066e8ef21695f4c059522ed1efe671e2705e7b91ab6480a741643ee0beca2dc162e5bae8d20eb1f474ba33 /home/user/installer-dist-download/Whonix-Xfce-17.0.3.4.sha512sums
Similar to above.
installer-dist: [NOTICE]: SHA512 Hash Verification: ‘success’
Loglevel info.
But then would be useful to add:
installer-dist: [NOTICE]: Integrity Check Result: ‘success’
For now I think it is ok.
Maybe log error or die don’t need the - FAIL, as it already is a red color with log level [ERROR]?
Maybe it needs in some cases?
I think the underline is ok, but the FAIL is redundant?
1 Like
Good point.
First of all, how I got that idea… I thought writing 'success' is an easy and unambiguous way to communicate to the user that it’s “OK”. No need to ask if the detailed message is OK not not. (Avoiding support requests.)
But then for consistency, if a test failed that should be ‘fail’ or more easily visible ‘FAIL’ or perhaps that is already overuse of stylistic items.
Indeed, so if it’s already [ERROR] which is already a strong word and even in red color, then the additional FAIL might be superfluous.
If consistency doesn’t seem needed, please revert the FAIL -.
Ok, but from previous talks it was your decision to show on notice. The argument was that the user would see which key is being used. My contra-argument was that the user only needs to see success or failed verification.
Info is good.
Not easy because the key is piped and received via signify -p -, as the key is not a file, but a variable.
The log stops before the pipe and after the pipe would make the signify not receive from stdin.
We could save the key to a file on every run.
With the rest, I agree, INFO.
1 Like