this one is disco and ready to go @Patrick
It builds VMs now with the GUI setting and launches the VM
Next step I will have tag pushes automatically run WATS. This PR sets the stage for that to happen
1 Like
Excellent! Thank you, merged.
1 Like
This was done. Could you check please?
1 Like
I have access. Will hopefully get WATS running after this weekend
1 Like
Okay so WATS is almost running, a few changes left. I had to create a huge VPS in order for all the VMs to run with GUI (8gb of RAM).
So once I get WATS running, I will create new functionality to automatically provision servers.
Here is the design plan for 2 scenarios
Developer pushes a commit
- trigger CI job to build commit VMs with
--remote-derivative-packages - check for existing VMs in account
- if VMs do not exist, create 2 very small headless VMs (1gb ram or 2 at most) from template with virtualbox and ssh keys installed
- On each VM, build headless workstation and gateway. Do not run WATS
- Destroy VPS servers
Doing this in a parrallel manner will speed things up, and hopefully get CI jobs for commits to under 30 minutes.
Developer pushes a tag
- check for existing largefootprint VM. If does not exist, create it. 8gb of RAM, XFCE GUI, Virtualbox, etc.
- Build both Workstation and Gateway VMs with GUI, and NO remote packages
- Run WATS on VMs.
- Destroy VPS
This will be a much slower process, probably almost 2 hours to fully test a VM tag with GUI. But this is shorter than manually testing it, and can happen in the background
1 Like
Running in to problems with the GUI stuff.
I can successfully VNC in, open a terminal, and run WATS. But when I do it remotely via VBoxManage it isnt working because the shell (on the host) is not within the Workstation XFCE display.
Been a huge headache, took a LOT of hours. I am thinking my new strategy is going to be creating a .desktop file and transferring it to Workstation and set it to run WATS on boot. Then after X amount of seconds (I will average how long it takes to run wats and add maybe an extra minute for good luck), have the host grab the WATS logfile, parse, and throw an error if WATS does not pass.
It’s hacky and I am not proud of the strategy, but I am at a loss what to do otherwise. It has been quite a lift getting this running 
1 Like
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