Add Vagrantfile for testing

[ocdtrekkie]

Fixes #90

Note: I was inspired to finally get back to you on this because of Hacktoberfest. However, this PR only counts if you're willing to apply a label of hacktoberfest-accepted to the PR before you merge it. I offer it up either way though.

This is now probably the fastest way for someone to test Dropserver on their PC. It does build from source instead of using releases, so it is probably useful for people hacking on Dropserver as well.

This is pretty similar to my attempt last year, except:

• I updated the way Node is installed to their new preferred method.
• I am now using the new paths recommended for the data and socket directories now.
• I am also using the local.dropserver.org DNS name.

I think it would probably be worthwhile to:

• Comment my setup script into clear sections.
• Implement cgroups and bubblewrap support.
• Probably configure the service method so that the vagrant up command doesn't effectively hang.

When you run vagrant up, this will build the VM, build Dropserver, start dropserver, and the final line it logs is the URL to register the admin account.

[teleclimber]

Thanks for this Jacob!

I think the comments are good enough but feel free to improve them.

cgroups and bwrap support is not really necessary in this context unless someone is working on those aspects of ds-host.

Probably configure the service method so that the vagrant up command doesn't effectively hang.

You mean use systemd to start ds-host? That would be one way to go. We would just have to tell the user to check the logs to get the admin login link.

I am going to go ahead and merge this as-is for now because it's already helpful in its current state. Please feel free to improve on it.

[ocdtrekkie]

My thought is re: cgroups and bwrap, that if someone might test apps with this, it should be as strict as possible to ensure it doesn't just "work on my machine". vagrant-spk uses sandboxing that's actually stricter than Sandstorm's default to ensure developers build apps that will work in both modes.

I am unsure how much it matters though when the stack is more predefined.

[ocdtrekkie]

I do agree it is perfectly serviceable as-submitted though, I just figured I'd also note the areas I already recognize are ripe for improvement. ;) It will possibly only matter if a bunch of people start using the Vagrantfile as part of a workflow.

[teleclimber]

Yes those are good thoughts. Ideally the app is equally constrained regardless of configuration. Bubblewrap just adds a backup layer to the sandbox. But it's not obvious that it will work out that way in practice.

One thing I wanted to ask you: could we use a different base box in the Vagrantfile? the one you are using doesn't work under Parallels. I wrestled with Virtualbox today and failed to get it working on the mac (possibly because Parallels is already running on there). So I wanted to use Parallels as a provider but that failed because the box doesn't support it. Since you know more about this world, is there any harm in using generic/debian12? It's bigger, but it supports multiple providers. Thoughts?

[ocdtrekkie]

I suspect if it's Debian, it'll be fine. I know I use a lot of Debian-based commands (all I know!) but I doubt anything here is tied to a specific Vagrant box.

I have gone with some similar problems over the years with my desire to play with WSL while Hyper-V is very allergic to Virtualbox. (I actually just recently got WSL2 and Virtualbox set up on the same machine for the first time.)

[ocdtrekkie]

Ah, I know what (was) Virtualbox specific: vagrant-spk relies on a folder sharing setup that I think uses the vbox driver so you can develop an app entirely in the VM while having the files on the Git repo on your host machine.

That might be a nice-to-have if we added building ds-dev into this. But I don't think it needs it currently.

[teleclimber]

I think for now we can leave the box as-is. Someone who has to use a different box can make the change locally if needed. I'll make a note of it in the docs.

One thing I'm not clear on is how this becomes a nice development environment for Dropserver. Like if I make a change to the DS code, do I have to SSH into the VM and manually launch the build command then restart ds-host? Or does vagrant do that for me? What about frontend development? I imagine I'd run yarn run dev in the VM, but then I'd need to expose the port, though I suppose that's fine.

[ocdtrekkie]

I am unsure if that approach would make a ton of sense for Dropserver's case or not. vagrant-spk is a whole separate wrapper that also passes build commands into the VM to automate those things. It's important to Sandstorm development because apps can have various different dependencies which have to be installed somewhere and are pretty platform-specific i. a lot of cases.

Because everything in a Dropserver app is a single platform stack (and I believe Deno is cross-platform?), it's a lot less problematic to handle that outside a VM.

[teleclimber]

But vagrant-spk is for packaging Sandstorm apps, right? My impression was that this Vagrant file was for working on Dropserver itself?

For developing Dropserver apps there is ds-dev which is a standalone binary. The only requirement is to also install Deno. It can create the packaged app too. So there is no need to get Vagrant involved for this. (Although there is no ds-dev build for Windows, I guess that could be a problem though I have run it on WSL2 without issues.)

[ocdtrekkie]

@teleclimber Yeah, vagrant-spk is for app dev, but I started with more or less the same boilerplate used for it and then stripped things out and changed things over. This Vagrantfile was ostensibly so I could "try Dropserver", but it could also be potentially useful for platform or app dev if someone doesn't want to install things on a local machine.

I think it's probably safe to say you could use a different Debian box without much issue, I was just explaining why we had a specific Virtualbox dependency in our usage.