Troubleshooting your local environment - DoSomethingArchive/legacy-website GitHub Wiki

Add your questions here.

It's probably your Vagrant version. Use version 1.5.4. We've seen no problems from downgrading over an existing version.

After you install version 1.5.4, do a vagrant plugin update to ensure that Vagrant and the plugins are happy with each other.

You may have borked permissions. Did you run something as root?

If you get "Operation not permitted" on a particular file, e.g., /var/www/path/to/file.php, look at the permissions:

ls -l /var/www/path/to

ls -l /var/www/path

Does root own any of those?

Pull the latest upstream and run vagrant provision.

You have to build the app first. Drush won't be able to define @self unless it can identify a functioning Drupal installation, which needs to be at /var/www/dev.dosomething.org/html. Just remember to run ds build before you try any ds pull commands.

• You may need to have your public ssh key added to the staging server. Check with Morgan / devops about this.

• You may need to add your SSH keys to you local system again even if you did it before and followed all these steps. See Vagrant setup above, step 3 regarding SSH.

umount(/Users/aschachter/Development/dosomething-mount): Resource busy -- try 'diskutil unmount'
==> default: Mounting SSHFS for `/var/www/dev.dosomething.org` to `../dosomething-mount`
/Users/aschachter/.vagrant.d/gems/gems/vagrant-sshfs-0.0.5/lib/vagrant-sshfs/builders/host.rb:34:in `port': undefined method `[]' for nil:NilClass (NoMethodError)
	from /Users/aschachter/.vagrant.d/gems/gems/vagrant-sshfs-0.0.5/lib/vagrant-sshfs/builders/host.rb:18:in `mount'

Try this:

diskutil unmount force ../dosomething-mount
vagrant up

The errors look like this:

rm: cannot remove `/var/www/dev.dosomething.org/html/sites/default/settings.php': Permission denied
rm: cannot remove `/var/www/dev.dosomething.org/html/sites/default/files': Permission denied
rm: cannot remove `/var/www/dev.dosomething.org/html/sites/default/settings.local.php': Permission denied
rm: cannot remove `/var/www/dev.dosomething.org/html/sites/default/settings.stage.php': Permission denied
rm: cannot remove `/var/www/dev.dosomething.org/html/sites/default/default.settings.php': Permission denied

This happens because Drupal automatically secures setting files by forcing read-only mode, even for its rightful owner.

You can fix it by running:

sudo chmod -R u+rw /var/www/dev.dosomething.org/html/sites/default

You might need delete it from your OS X host rm -rf html/sites/default outside of vagrant

This error is just a terrible way of saying that Vagrant can't reach SSH server on its virtual machine. You can connect to it manually and check actual SSH connection error: ssh -p2222 [email protected].

Most often the error will look like this:

The authenticity of host '[127.0.0.1]:2222 ([127.0.0.1]:2222)' can't be established.
ECDSA key fingerprint is 11:5d:55:29:8a:77:d8:08:b4:00:9b:a3:61:93:fe:e5.

It means that your SSH client has wrong record of the server signature. Sometimes it's caused by other Vagrant box that got this signature overridden with its own. To fix it, just open ~/.ssh/known_hosts file and remove a line which starts with '[127.0.0.1]:2222'. After that you will be able to connect Vagrant SSH server as usual.

You can also disable key checking for your local machine by adding the following lines to your ~/.ssh/config file. This will disable these errors if you are switching between multiple Vagrant boxes on the same machine:

Host 127.0.0.1
   StrictHostKeyChecking no
   UserKnownHostsFile=/dev/null

If you're not working with Solr, you can safely ignore these errors.

Sometimes during first vagrant up or when dosomething/drupal box removed manually it takes up to 5-8 hours to download. It such cases just stop the vagrant by hitting ctrl+c and run vagrant up again. Normal download time is 15-30 minutes.

May happen upon a new build of your Vagrant box. If your SSH tunnel fails, with an error like so:

debug1: Server host key: RSA 06:58:fa:6d:4c:d7:2c:80:25:9a:d9:0f:ad:f7:b9:9f
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
06:58:fa:6d:4c:d7:2c:80:25:9a:d9:0f:ad:f7:b9:9f.
Please contact your system administrator.
Add correct host key in /Users/aschachter/.ssh/known_hosts to get rid of this message.
Offending RSA key in /Users/aschachter/.ssh/known_hosts:28
RSA host key for [dev.dosomething.org]:2222 has changed and you have requested strict checking.
Host key verification failed.

Try the following steps:

• On your local machine, edit your .ssh/known_hosts file
• Remove the line for dev.dosomething.org
• If the above doesn't work, remove the line that starts with [127.0.0.1]

If those steps don't work and you get a "The SSH Tunnel could not authenticate with the remote host. Please check your password and ensure you still have access." error message:

• On your local machine, run ssh-add -L
• Run vagrant haltand then vagrant up and make note of the port. We've seen issues where the port was 2200 instead of 2222
• In Sequel Pro the settings should be as follows:
  SSH Host: dev.dosomething.org
  SSH User: dosomething
  SSH Key: ~/.ssh/id_rsa
  SSH Port: 2222 (or possibly 2200) - Check to make sure you've got the right port

Dropping local DB
Do you really want to drop all tables in the database dosomething? (y/n): y
Pulling down db from staging
The external command could not be executed due to an application error.                                                                                            [error]
Illegal string offset 'site' backend.inc:1030                                                                                                                      [warning]
                                                                          [error]ickey).
, code: 255)
Error: no database record could be found for source @ds.staging                                                                                                    [error]
Enabling Stage File Proxy...
<h1>Additional uncaught exception thrown while handling exception.</h1><h2>Original</h2><p>PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table &amp;#039;dosomething.blocked_ips&amp;#039; doesn&amp;#039;t exist: SELECT 1 FROM {blocked_ips} WHERE ip = :ip; Array
(

Run ssh-add on your host

This happens if you installed libsass from your virtual machine or host machine, but then try to run it from the other. Why? Libsass is written in C++, so it must be compiled for your machine. Since the virtual machine and your local are (likely!) different platforms, the compiled code isn't portable between them.

To fix it, either run your build from the same "machine" that you installed your NPM dependencies from or rm -rf node_modules and re-install from the same box you're trying to build assets on.

The cause if this is still more or less unknown (though this issue may have some clues), but there is a workaround.

1. Comment out the 3 lines of Vagrantfile that start with config.ssh.
2. Confirm that the permissions of your ~/.ssh directory are OK (see here).
3. Run vagrant up and it should succeed this time
4. After running vagrant ssh, note that you'll have to run sudo su dosomething to switch to the dosomething user, so things like the ds command and drush all work.

Note! If you are starting to setup this environment after May 14, 2016, you will get this error AND the above lines listed are not the solution to your woes!

Ok, how do I solve this?

1. Checkout the tower repository: git clone [email protected]:DoSomething/tower.git
2. In /files/app_user/ssh in the tower repo, there is an authorized_keys file.
3. Add your public key to this file and create a PR with your changes so that one of our devops team can merge it in and deploy the change.
4. Once your public key gets deployed, follow the steps 1 - 3 above to temporarily comment out the config.ssh lines (we will undo this step later).
5. vagrant up and vagrant ssh
6. sudo su dosomething
7. vi ~/.ssh/authorized_keys
8. Add your public key to the bottom of this file and save it
9. Uncommenting the lines in the Vagrant file (the config.ssh lines)
10. Your private key must be available to the local ssh-agent. You can check with ssh-add -L, and if it's not listed add it with ssh-add ~/.ssh/id_rsa.
11. Run vagrant up --provision
12. You should be all set now! There should be no need to switch to the dosomething user in order to access ds and you should have no problem pulling the stage db and files! 👍

Why do I have to do this? See our versions for the vagrant boxes @ https://atlas.hashicorp.com/dosomething/boxes/phoenix. Our current version is 2.0.0.beta1. It's a bit out of date. This means that the ~/.ssh/authorized_keys on the vagrant box is not updated with your public key!

Yes, it would be great to update the box with an up to date config; unfortunately it's an arduous process and we're in the process of coming up with a better way of dealing with this.

Pending documentation