15
votes
Struggle setting up Tildes development environment
I'm interested in possibly developing a tildes client. In order to experiment with the currently disabled API, as well as to become more familiar with how Tildes works internally, I've been trying to set up a Tildes development environment on my machine following the instructions on the docs site. I've run into a problem with the 'vagrant up' stage of the setup.
...
==> default: Running provisioner: salt...
Copying salt minion config to vm.
Checking if salt-minion is installed
salt-minion was not found.
Checking if salt-call is installed
salt-call was not found.
Using Bootstrap Options: -F -c /tmp
Bootstrapping Salt... (this may take a while)
bash: /tmp/bootstrap_salt.sh: /usr/bin/sh: bad interpreter: No such file or directory
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
/tmp/bootstrap_salt.sh -F -c /tmp
Stdout from the command:
Stderr from the command:
bash: /tmp/bootstrap_salt.sh: /usr/bin/sh: bad interpreter: No such file or directory
So the Salt provisioning is failing, and it seems like it just has the wrong path to the shell it needs, but while I could probably just tweak this script, it seems like that goes against the concept of using Vagrant in the first place. I was wondering if anyone else ran into this problem, or if the bug lies between the seat and the keyboard.
On attempting this myself just a moment ago, I haven't run into any issues. I would recommend that before you take any further action, you attempt a reinstall of VirtualBox, Vagrant, and/or the VM box itself (look at
vagrant box removefor the last one). It's possible that you're running into a case where some part of your setup is corrupt. Another possible consideration would be possible version incompatibilities in these tools (I've had a case where Vagrant and VirtualBox would fail to work together with certain versions installed).I suspect that the problem is the box itself, and not VirtualBox or Vagrant, due to
/usr/bin/shnot being accessible, but any of the above could potentially be problematic. Please validate your setup and, failing that, we can take a deeper look into this problem :)After wiping away all traces of the box, several times I can't figure out for the life of me why the original script is failing to run in its shell. I ssh'ed into the box, and sure enough,
which shreturns/usr/bin/sh.None the less, I did some RTFMing and discovered that I can supply a custom bootstrap_salt.sh to the Salt provisioner, so I copied the bootstrap script, and made it a bit more portable by telling it to use
/usr/bin/env sh.This is still a bit messy, but I can reprovision the machine without doing any manual screwing around. The box now provisions, and everything seems to be working. I suppose I'm happy with this hack for now :)
Edit: It is worth mentioning, that the host system is running Fedora 29, and they have made at least a few adjustments to upstream Vagrant. Most notably, the default VM provider is switched to libvirt, and this needs to be overridden in order to use the box "ubuntu/xenial64" which is specified by Tildes.
Your edit seems like it describes the most likely source of the problem. Unfortunately I don't have a spare machine or drive lying around to test with, though.
I'll be sure to look into this issue nonetheless. This is valuable information to be aware of since I use vagrant for my own development work.
I would like to ask you to try something: Please take a look at the documentation and try one of the steps provided to switch your VM provider to VirtualBox, then perform a
vagrant upwithout the use of the custombootstrap_salt.sh. If this works, then we can verify that the provider is the problem.If this is indeed the case, then we'll want to ping Deimos regarding this problem, as Vagrant's entire purpose is to provide an identical environment and ease of environment setup. If a faulty VM provider is getting in the way of this, then either the Tildes
Vagrantfilewill need to be updated to enforce a priority order of providers (option #3 in the documentation), or instructions will need to be added to the docs detailing how to manually select a provider in the event of errors.One of the first things I did was override the default VM provider to VirtualBox, since the box specified in the Tildes VagrantFile does not support libvirt. I added an
export VAGRANT_DEFAULT_PROVIDER=virtualboxto my .bashrc to make this stick. Everything I posted above was done using the VirtualBox provider.As far as explicitly setting the default VM in the VagrantFile, that is probably not a bad idea. I assume Fedora is a little unique in changing the default provider, but being explicit in the VagrantFile would make the setup a bit more robust and portable.
Man, then it's not the provider, huh? Could just be an issue with Fedora's version of either Vagrant or VirtualBox, then. This is a tricky one. It seems like no matter what the answer is, it boils down to a user-end workaround being needed, not a simple configuration or procedural change.
Thanks for bearing with me and updating me on what you've tried. I could see this potentially causing me some major headaches in the future trying to help someone configure their own dev environment.