Skip to content
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

Allow setting sdwdate gateway via qvm-features/qvm-prefs #9601

Closed
mzpqnxow opened this issue Nov 24, 2024 · 2 comments
Closed

Allow setting sdwdate gateway via qvm-features/qvm-prefs #9601

mzpqnxow opened this issue Nov 24, 2024 · 2 comments
Labels
C: core C: Whonix This issue impacts Qubes-Whonix P: minor Priority: minor. The lowest priority, below "default." R: duplicate Resolution: Another issue exists that is very similar to or subsumes this one.

Comments

@mzpqnxow
Copy link

mzpqnxow commented Nov 24, 2024

I'm not sure if this should be seriously considered as it's a pretty niche use-case

However, there is a documented manual process for this so maybe it should be considered as something users need more hand holding on

The problem you're addressing (if any)

When a user renames the sys-whonix qube or has multiple Whonix Gateways - basically, any time a user uses a Whomix Gateway that is not named sys-whonix - they must manually update sdwdate settings as described here

The steps aren't hard once it's clear that they're necessary

The file /usr/local/etc/sdwdate-gui.d/50_user.conf must be created like so:

sudo mkdir -p /usr/local/etc/sdwdate-gui.d && echo "gateway=<whonix gateway vm name>" | sudo tee /usr/local/etc/sdwdate-gui.d/50_user.conf

If I understand correctly this (at least) allows the sdwdate GUI in the dom0 taskbar to work properly. It may have a more substantial impact as well, I'm not too knowledgeable about Whonix Gateway/Workstation so I'm not certain

This step is easy to automate and impossible to forget if it's being built using salt, but otherwise it's both clunky, obscure and easy to forget. It's not obvious that it's even "a thing" unless you explicitly look into Qubes forums or the linked Whonix docs for this specific configuration

The solution you'd like

To make it easier, it would be nice if there was a way to set this value without manually editing the AppVM. Perhaps this could be done via qvm-prefs?

It would also be nice to have some mechanism to notify the user that they need to take this step. This could be some sort of blocking behavior when the gateway starts or (at least) some warning. I don't know a way to do either of these so I can't propose an elegant or reliable way

The value to a user, and who that user might be

It would save users who experiment with multiple whonix gateways or rename sys-whonix time trying to diagnose "weird" or broken behavior

Completion criteria checklist

@mzpqnxow mzpqnxow added P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: enhancement labels Nov 24, 2024
@andrewdavidwong andrewdavidwong added C: core P: minor Priority: minor. The lowest priority, below "default." C: Whonix This issue impacts Qubes-Whonix and removed P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. labels Nov 29, 2024
@mzpqnxow
Copy link
Author

mzpqnxow commented Jan 21, 2025

This may overlap a bit with (or be a duplicate of) #4117

If so, my mistake, I didn’t realize until now

Please feel free to merge them by closing this, if it’s appropriate to do so

@andrewdavidwong andrewdavidwong added the R: duplicate Resolution: Another issue exists that is very similar to or subsumes this one. label Jan 21, 2025
Copy link

This issue has been closed as a "duplicate." This means that another issue exists that is very similar to or subsumes this one. If any useful information on this issue is not already present on the other issue, please add it in a comment on the other issue. Here are some common cases of duplicate issues:

  • The other issue is closed. The other issue being closed does not prevent this issue from duplicating it. We will examine the closed issue and, if appropriate, reopen it.
  • The other issue is for a different Qubes release. We usually maintain only one issue for all affected Qubes releases.
  • The other issue is very old. The mere age of an issue is not, by itself, a relevant factor when determining duplicates.

By default, the newer issue will be closed in favor of the older issue. However, we make exceptions when we determine that it would be significantly more useful to keep the newer issue open instead of the older one.

We respect the time and effort you have taken to file this issue, and we understand that this outcome may be unsatisfying. Please accept our sincere apologies and know that we greatly value your participation and membership in the Qubes community.

If anyone reading this believes that this issue was closed in error or that the resolution of "duplicate" is not accurate, please leave a comment below saying so, and we will review this issue again. For more information, see How issues get closed.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jan 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: core C: Whonix This issue impacts Qubes-Whonix P: minor Priority: minor. The lowest priority, below "default." R: duplicate Resolution: Another issue exists that is very similar to or subsumes this one.
Projects
None yet
Development

No branches or pull requests

2 participants