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
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
Excellent! Thank you, merged.
Important to not give me access to master though, and set up rules that PR must be merged by an admin (you).
This was done. Could you check please?
I have access. Will hopefully get WATS running after this weekend
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
--remote-derivative-packages
Doing this in a parrallel manner will speed things up, and hopefully get CI jobs for commits to under 30 minutes.
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
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
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.
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
TL;DR-Headaches, frustration, struggling
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.
thank u 4 attending my ted talk
A new VM build stalls because of this.
The build itself stalls? You mean WATS? If so…
is there a way to programmatically (via CLI) get rid of all the “Understood” boxes and set the gateway VM to connect without bridges?
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.
Using the Orca Screen Reader in Kicksecure Virtual Machines
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
.
Another possibility is setting up X11 forwarding SSH from host to workstation through gateway, using VBoxManage to configure it.
It’s possible to SSH into Whonix-Workstation. Not tested for a long time, not sure how easy/reliable it is. See also:
Is there a way to run a command INSIDE a GUI XFCE shell from an SSH connection?
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
?
You mean WATS? If so…
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.
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.
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
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 everything very well with diagrams and specific layout of how it works, for future maintainability.
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
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.
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
Im sorry this is taking so long @Patrick , it ended up being much more complicated than anticipated
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!
Test suite running programmatically
This is very good news ! It will work!
@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
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