Another problem, is there a way to programmatically (via CLI) get rid of all the “Understood” boxes and set the gateway VM to connect without bridges? A new VM build stalls because of this.
1 Like
Other Ideas:
Maybe I could figure out how to give VNC control to CI, and use Dogtail to write more scripts that click through and run everything. I have no idea if this is possible, but seems less hacky. High effort.
Another possibility is setting up X11 forwarding SSH from host to workstation through gateway, using VBoxManage to configure it. I worry this will lead me to the same GUI issues that I am experiencing currently where the shells are not actually and XFCE shell in the GUI
Possible Fix for GUI problems
Is there a way to run a command INSIDE a GUI XFCE shell from an SSH connection? It would be really nice to just skip the bullshit
1 Like
TL;DR-Headaches, frustration, struggling
1 Like
I have X11 forwarding set up from CLI via SSH, so I have a new idea. It will probably take a bit of time but I think the best idea is to run WATS from the host instead of the VM
So basically I will have to rework the Dogtail stuff to run from the host, click inside of the workstation, and run the GUI testing like that.
This is going to be a pain in the ass but at least there is a path to move forward. I also imagine these tests are going to be pretty flakey with a manually configured host (which is how I set up GUI/vncserver/etc). I will have to add scripts in to ansible to set up everything from a brand new VM to ensure it behaves exactly the same every time.
1 Like
thank u 4 attending my ted talk
1 Like
The build itself stalls? You mean WATS? If so…
There is easo which is an abbreviation for easyorca. Was developed for a different context but might be handy here.
easo
[1] But that command has to be run inside the VM.
Does this still work? Does this help? If broken, that I could certainly fix and/or adjust for the CI purpose.
On the other hand, the setup-dist-wizard (understood boxes) and anon-connection-wizard could be considered part of stuff that should be CI tested. But if difficult, headache, then also a solution which skips that part (by grammatically accepting it).
[1] Do you need a command to programatically accept disclaimers (setup-wizard-dist), connect to public Tor network (anon-connection-wizard) that can be run from outside the VM? That might be possible too.
Would probably be based on configuration an extra VirtualBox setting on the host operating system VBoxManage getextradata / setextradata and then inside the VM reacting to it accordingly such as starting an inside VM shell script or program.
Not sure needed. VBoxManage can already be used way to execute shell commands inside VM. So that could be used to run easo.
It’s possible to SSH into Whonix-Workstation. Not tested for a long time, not sure how easy/reliable it is. See also:
- File Transfer - Whonix chapter SSH into Whonix-Gateway in Whonix wiki
- File Transfer - Whonix chapter SSH into Whonix-Workstation in Whonix wiki
- SSHFS into Whonix-Workstation
I don’t understand.
You mean inside a Whonix-Gateway Xfce or Whonix-Workstation Xfce. You mean…
-
ssh into Whonix-Gateway Xfce
-
VNC from host into Whonix-Gateway Xfce
?
1 Like
Yes. Sorry some of the above posts were rubberducking at midnight, and a good nights sleep gave me a lot of much needed clarity. I was very frustrated but see a solution now.
I like the idea of having the WATS test everything, so having it click through the user agreements and setup makes a lot of sense.
I am going to try to avoid SSH-ing in to the Whonix VMs for now, too much config to automate if i can just run dogtail on the host and make it point & click.
For now I am changing my strategy and prioritization, because it makes more sense.
New Strategy
Automated Host Setup and Teardown
I am going to focus on using the digitalocean API to build the host ENTIRELY from scratch, and tear down at end of build. I will also have it create a snapshot automatically so for subsequent runs to be faster.
This step is important because the GUI setup and everything must be the exact same and automated to avoid flakiness. We need it to be reproducible anywhere so in the event something happens to me, the suite doesn’t end up abandoned.
Also will save lots of money using a big server. I will write logic to prevent duplicating instances too, and do it all on my account so no risk of crazy accidental cost to whonix.
Create Lightweight VPS setup for Commits
When a developer pushes a commit, create 2 VPS machines that are much smaller, 2gb of ram or so without GUI, have one build the workstation and one build the gateway in parallel. No WATS
When a tag gets pushed, do it on the single beefed up VPS with GUI, run WATS
WATS rework
Rework WATS to run inside of the host using dogtail to control the GUIs, instead of the workstation. This is the easiest way to solve the issue of running WATS for now, and much easier than using VBoxManage which is clunky and not working with XFCE in the guest machines.
Document
Document everything very well with diagrams and specific layout of how it works, for future maintainability.
Setup for collaboration (stretch goal)
Figure out how to make all of it run locally in a single environment so people can collaborate more easily on test cases. God only knows how much of a challenge this could be. Maybe not so bad if it is possible to run whonix VMs inside of a debian virtualbox VM (like the movie Inception… dream in a dream). Or perhaps build it to a single debian ISO that ran on a USB or something.
Either way, not worth worrying about until the thing works
1 Like
And before i do too much, i need to play with dogtail and ensure it can control the VM guis from the host. Proof of concept required in order for any of this GUI testing to work.
But i am going to figure out the auto generation of VMs because it will save me some money in the meanwhile.
Im sorry this is taking so long @Patrick , it ended up being much more complicated than anticipated
But for now at least we have CI to ensure the builds dont break.
1 Like
Lastly, in the event I am not a good enough engineer to make the GUI testing work, I can definitely spin up some shell testing to check Tor network connectivity, proper system functionality, etc.
But i am going to fight hard to avoid that outcome
1 Like
No worries at all! No expectations here on my side. I am just patiently waiting and happy if there’s any positive surprises. Thank you for all your work!
1 Like
Test suite running programmatically 
This is very good news ! It will work!
1 Like
@Patrick I deleted the VPS because I am working on automating the entire process and creating/deleting inventory dynamically. A large VPS makes WATS run much better with the GUI (16gb ram with 4g allocated to each VM).
The cost of this to run full time would be very high, plus things need to be dynamically configured for long term reusability and automation,
It shouldnt be too long until I have builds working again with dynamically generated inventory, but I wanted you to know the situation since builds will be failing for a little while. Calling it for the evening
1 Like
Also @Patrick I added you to a DigitalOcean team where the cloudservers will live. Check your email for an invite, you can oauth with github.
I’d like if you joined it, that way in the event something happens where I am not around you have access to the cloud servers. Eventually once everything is working I’d like to transfer the billing to the project itself instead of paying out of pocket 
For now I am happy to continue paying and considering it donation
1 Like
Not going to switch to Linode for now. Minimal cost savings for large time overhead. Automated resource creation/deletion will keep costs low enough. If costs become a burden long term, we can discuss switching to Linode long term.
DigitalOcean has a very nice Ansible Collection that interfaces with the API for programatic resource provisioning. I think this Automated resource provisioning justifies the roughly 10% cost savings of Linode
Save $100 a year for 30 hours of very focused dev time doesnt make sense for now, especially given the potential development speed increases of Whonix from automated GUI testing.
1 Like
red → green → refactor
1 Like
Sounds all good!
Regarding the invite, I’ve sent an e-mail just now.
Alright, invite accepted.
@Patrick I have a branch that is very near complete, that should fix CI builds for commits. I have made a lot of progress.
Currently seeing a failure when trying to build with remote packages
last_failed_bash_command: "$source_code_folder_dist/packages/kicksecure/genmkfile/usr/bin/genmkfile" deb-pkg
############################################################
'
++ unset error_reason
++ '[' ERR = INT ']'
++ '[' ERR = TERM ']'
++ '[' ERR = ERR ']'
++ '[' '!' 0 = 0 ']'
++ true 'INFO: dist_build_auto_retry set to 0 (--retry-max). No auto retry.'
++ unset dist_build_auto_retry_counter
++ true
++ ignore_error=false
++ answer=
++ '[' ERR = ERR ']'
++ '[' true = true ']'
++ true 'INFO: using non-interactive error handler.'
++ break
++ errorhandlermaybeexit ERR
I will link full logs shortly.
1 Like
The new branch is now programmatically creating and destroying VPS for builds. These VPS are larger so things are moving faster.
A large refactor to ensure best practices and maintainability was also included in the changes
Next steps:
- Parallelize builds of Workstation and Gateway for pipeline speed. Hoping that this will result in a huge cutdown in pipeline build times, especially since the pipeline creates a VPS is very large
- Install GUI programatiically and run WATS (getting very close to this step. Proof of concept works, it will run)
- Fix WATS race condition and User agreement issues (perhaps with orca, perhaps with wats test)
1 Like