Category: DevOps

apt-add-repository failing in Ubuntu 14.04 because of threading.py

Posted on May 5, 2018 by - DevOps, Life of a Web Developer

Ran into an interesting one today:

# sudo add-apt-repository ppa:ondrej/apache2

[omitted]

Press [ENTER] to continue or ctrl-c to cancel adding it

gpg: keyring `/tmp/tmpnv_gva8h/secring.gpg' created
gpg: keyring `/tmp/tmpnv_gva8h/pubring.gpg' created
gpg: requesting key E5267A6C from hkp server keyserver.ubuntu.com
gpg: /tmp/tmpnv_gva8h/trustdb.gpg: trustdb created
gpg: key E5267A6C: public key "Launchpad PPA for Ond\xc5\x99ej Sur�" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python3.4/threading.py", line 920, in _bootstrap_inner
self.run()
File "/usr/lib/python3.4/threading.py", line 868, in run
self._target(*self._args, **self._kwargs)
File "/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 687, in addkey_func
func(**kwargs)
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 370, in add_key
return apsk.add_ppa_signing_key()
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 261, in add_ppa_signing_key
tmp_export_keyring, signing_key_fingerprint, tmp_keyring_dir):
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 210, in _verify_fingerprint
got_fingerprints = self._get_fingerprints(keyring, keyring_dir)
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 202, in _get_fingerprints
output = subprocess.check_output(cmd, universal_newlines=True)
File "/usr/lib/python3.4/subprocess.py", line 609, in check_output
output, unused_err = process.communicate(inputdata, timeout=timeout)
File "/usr/lib/python3.4/subprocess.py", line 947, in communicate
stdout = _eintr_retry_call(self.stdout.read)
File "/usr/lib/python3.4/subprocess.py", line 491, in _eintr_retry_call
return func(*args)
File "/usr/lib/python3.4/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position 92: ordinal not in range(128)

Long story short, turns out it was due to my locale settings not being configured properly.

I applied the first suggestion of regenerating locales, and then the second one of setting default locales in /etc/default/locale, closing the SSH session, and opening it again. That fixed things.

Hello from WordCamp Vienna, and ddev in fish

Posted on April 8, 2018 by - DevOps, Toolbox

I’m…kind of late mentioning that I’m at WordCamp Vienna. The day of sessions was fun and the people were great.

I’m at the Contributor Day now setting up my site in ddev.  I use the Fish Shell, so sometimes I have to run commands a bit differently.

After I imported my database, ddev reminded me to properly search-replace the WordPress URL, as one does. It told me:

WordPress sites require a search/replace of the database when the URL is changed. You can run “ddev exec ‘wp search-replace [http://www.myproductionsite.example] http://wizonesolutions.com.ddev.local'” to update the URLs across your database. For more information, see http://wp-cli.org/commands/search-replace/

However, I got errors when trying to do that:

Failed to execute command [wp search-replace http://local.wizonesolutions.com http://wizonesolutions.com.ddev.local]: Failed to run docker-compose [-f /Users/kevin/vhosts/ws/wizonesolutions.com/.ddev/docker-compose.yaml exec -T web wp search-replace http://local.wizonesolutions.com http://wizonesolutions.com.ddev.local], err='exit status 126', stdout='OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused "exec: \"wp search-replace http://local.wizonesolutions.com http://wizonesolutions.com.ddev.local\": stat wp search-replace http://local.wizonesolutions.com http://wizonesolutions.com.ddev.local: no such file or directory": unknown
', stderr=''

This was weird. I could see that it was misinterpreting my command and trying to use it as a working directory or something. That made sense.

I started to think: is Fish processing my command inside the single quotes before it sends to ddev, maybe? I’m not sure if that was the exact cause, but it lead me to running the command this way:

ddev exec ''wp search-replace http://local.wizonesolutions.com http://wizonesolutions.com.ddev.local''

It worked after that!

How to fix nokogiri errors caused by Vagrant 2.0.3 plugins

Posted on March 25, 2018 by - DevOps, Technology, Vagrant

The short version: vagrant plugin expunge --reinstall

The long version:

Vagrant 2.0.3 seems to have changed something from 2.0.2 in terms of its embedded version of nokogiri. This causes errors when running commands such as vagrant status.

Here’s an example of the kind of error you may see:

/opt/vagrant/embedded/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require': incompatible library version - /Users/kevin/.vagrant.d/gems/2.4.3/gems/nokogiri-1.8.2/lib/nokogiri/nokogiri.bundle (LoadError)
from /opt/vagrant/embedded/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /Users/kevin/.vagrant.d/gems/2.4.3/gems/nokogiri-1.8.2/lib/nokogiri.rb:32:in `rescue in <top (required)>'
from /Users/kevin/.vagrant.d/gems/2.4.3/gems/nokogiri-1.8.2/lib/nokogiri.rb:28:in `<top (required)>'
from /opt/vagrant/embedded/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /opt/vagrant/embedded/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /Users/kevin/.vagrant.d/gems/2.4.3/gems/vagrant-parallels-1.7.8/lib/vagrant-parallels/driver/base.rb:2:in `<top (required)>'
from /Users/kevin/.vagrant.d/gems/2.4.3/gems/vagrant-parallels-1.7.8/lib/vagrant-parallels/driver/meta.rb:4:in `require_relative'
from /Users/kevin/.vagrant.d/gems/2.4.3/gems/vagrant-parallels-1.7.8/lib/vagrant-parallels/driver/meta.rb:4:in `<top (required)>'
from /opt/vagrant/embedded/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /opt/vagrant/embedded/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /Users/kevin/.vagrant.d/gems/2.4.3/gems/vagrant-parallels-1.7.8/lib/vagrant-parallels/provider.rb:16:in `usable?'
from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/vagrantfile.rb:138:in `machine_config'
from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/vagrantfile.rb:45:in `machine'
from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/environment.rb:694:in `machine'
from /Users/kevin/.vagrant.d/gems/2.4.3/gems/vagrant-auto_network-1.0.2/lib/auto_network/action/filter_networks.rb:38:in `block in machines_for_env'
from /Users/kevin/.vagrant.d/gems/2.4.3/gems/vagrant-auto_network-1.0.2/lib/auto_network/action/filter_networks.rb:36:in `map'
from /Users/kevin/.vagrant.d/gems/2.4.3/gems/vagrant-auto_network-1.0.2/lib/auto_network/action/filter_networks.rb:36:in `machines_for_env'
from /Users/kevin/.vagrant.d/gems/2.4.3/gems/vagrant-auto_network-1.0.2/lib/auto_network/action/filter_networks.rb:30:in `filter'
from /Users/kevin/.vagrant.d/gems/2.4.3/gems/vagrant-auto_network-1.0.2/lib/auto_network/action/filter_networks.rb:18:in `call'
from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
from /Users/kevin/.vagrant.d/gems/2.4.3/gems/vagrant-auto_network-1.0.2/lib/auto_network/action/load_pool.rb:19:in `call'
from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
from /Users/kevin/.vagrant.d/gems/2.4.3/gems/vagrant-triggers-0.5.3/lib/vagrant-triggers/action/trigger.rb:17:in `call'
from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
from /Users/kevin/.vagrant.d/gems/2.4.3/gems/vagrant-triggers-0.5.3/lib/vagrant-triggers/action/trigger.rb:17:in `call'
from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
from /Users/kevin/.vagrant.d/gems/2.4.3/gems/vagrant-triggers-0.5.3/lib/vagrant-triggers/action/trigger.rb:17:in `call'
from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builder.rb:116:in `call'
from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/runner.rb:66:in `block in run'
from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/util/busy.rb:19:in `busy'
from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/runner.rb:66:in `run'
from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/environment.rb:504:in `hook'
from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/environment.rb:165:in `initialize'
from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/bin/vagrant:131:in `new'
from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/bin/vagrant:131:in `<main>'

 

The most likely reason this happens is that plugins using Nokogiri have to build what are called native extensions each time. That means that the end result of that building is specific to your computer and various things on it. If those things change (e.g. Vagrant changes its version of Nokogiri), then the build becomes invalid and has to be redone.

In this case, it has to be redone across the board, and the easiest way is just to reinstall all plugins.

For that, you can use the vagrant plugin expunge --reinstall command.

You can then get back to developing!

 

(It’s worth noting that the command didn’t work on my older macOS computer, but it did work on my newer one. I’m not really sure why, since they have the same version of Vagrant. I just left the old computer as-was since I didn’t really need to fix it at the time.)

 

Source: https://github.com/hashicorp/vagrant/issues/9599

Disabling default rsync of the Vagrant Docker provider

Posted on May 8, 2014 by - DevOps, Life of a Web Developer, Technology, Vagrant

Discovered today that Vagrant automatically rsyncs files to the Host VM when the Docker provider is used on a system that doesn’t natively support Docker.

Sometimes, though, one wants to sync the files to a custom location, and might get errors when trying to sync them to two locations on the Host VM (as I was).

To turn off Vagrant’s default sync, use the same syntax you would to turn off the /vagrant shared folder otherwise:

config.vm.synced_folder ".", "/vagrant", disabled: true

Thanks to @adamjt on GitHub for the tip: https://github.com/mitchellh/vagrant/issues/3680#issuecomment-42482434

Fixing “The box … could not be found” in the new Vagrant (1.1+)

Posted on April 18, 2013 by - DevOps

Visual people: Watch this screencast

Anti-video readers: Keep reading.

This morning I ran into an issue with my Vagrant upgrade (I went from 1.0.7 to 1.2.1) that took me a few hours to figure out. I did, however, solve it in the end and thought it’d be useful to share how. It’s an easy fix.

First, the error I was getting was:

The box ‘boxname’ could not be found.

(where boxname was the actual name of the box, e.g. precise32)

The box did show up when I ran vagrant box list, so I knew that it should have been working.

After trying an assortment of things, including converting my Vagrantfile configuration to the version 2 format and trying to use the box in a fresh directory and with a fresh Vagrantfile, I decided to try re-adding the precise32 box that Vagrant provides. I did that, and then typed vagrant init precise32d. (I had called it precise32d.) This worked fine. I deduced that there must have been some change in the box itself. So I fired up DiffMerge.

DiffMerge told me that there weren’t any files it could compare. This, I discovered, was because everything in the new box I had downloaded was under a virtualbox directory. A-ha! I was on to something. I looked in that directory and saw these files:

Vagrantfile box.ovf box-disk1.vmdk metadata.json

Wait, metadata.json? That wasn’t in my existing box’s folder at all! What could be in there, I wondered?

$ cat virtualbox/metadata.json

{“provider”:”virtualbox”}

Ah. So it’s relying on this to figure out the provider, since Vagrant 1.1+ has the concept of providers other than VirtualBox. That explained a lot. The simplest fix is just as you may suppose:

To eliminate the potential for human error, we’ll use an existing metadata.json file. Run:

$ vagrant box add precise32 http://files.vagrantup.com/precise32.box

Wait for it to download and be added.

Then,

$ cd ~/.vagrant.d/boxes/yourbox

$ mkdir virtualbox

$ mv * virtualbox (or you can specify all the filenames manually)

$ cp ../precise32d/virtualbox/metadata.json virtualbox

You should now be able to vagrant up any projects that are relying on your pre-upgrade box. And they should work just as well as they did before!

Some notes:

  • I assume your boxes are VirtualBox VMs. If they’re not, then you probably wouldn’t have this issue anyway.
  • Don’t type the $ marks. That’s just to show you type the command in a terminal.

VirtualBox 4.1.18: How to solve “Failed to load unit ‘HGCM’ (VERR_SSM_UNEXPECTED_DATA)”

Posted on July 16, 2012 by - DevOps

(Update 7/18/2012: My theme cuts off the title. The full title is, “VirtualBox 4.1.18: How to solve “Failed to load unit ‘HGCM’ (VERR_SSM_UNEXPECTED_DATA)”.)

So, this is a bit of a departure from my usual type of post, but it’s still DevOps-related (an area I’m increasingly getting into), and people are probably searching for this.

My experience with this error

I had to send in my Windows laptop for warranty repair, and I was running a couple work-critical VirtualBox virtual machines (“VMs”) on it. I use Vagrant to run them without a GUI, and moving them was easy. I used vagrant package, copied over the project files, and ran vagrant up on the destination machine. This was not the issue.

I got this error when I suspended the virtual machines, then tried to resume them

So for some reason the VMs started up without issue. However, upon suspend and resume, I started getting the titular error. I searched for it on the Internet and found a VirtualBox forum which linked to a bug report which suggested editing the .vbox file. This is in <home directory>/VirtualBox VMs/<name of VM> and is named after the VM as well. It ends in .vbox.

Now, before you edit it, make sure you:

  1. Suspend or shut down all running VMs
  2. Close VirtualBox

If you don’t, this won’t work because VirtualBox will use the previous configuration anyway.

OK, so open up the .vbox file. Search for SharedFolders. You will see something like:

<SharedFolders>
<SharedFolder blah blah blah />
</SharedFolders>

Anywhere in the file you see that, change it simply to:

<SharedFolders/>

and save the file.

Now open VirtualBox and try resuming the afflicted VM again.  It should work. If it doesn’t, go check the .vbox file and make sure VirtualBox didn’t change it back. If it did…then make sure you followed the two preparatory steps above. I’m speaking from experience here. You can’t skip those.

And you’ll be good!

Update (7/17/2012): If you have several VMs that you run together, sometimes one of them will resume while the others fail with this error. If you resume that one, you may be able to subsequently resume the others. Not sure why this happens since the VM in question didn’t have any VirtualBox shared folders (not even in the XML), though some were using NFS. Perhaps it was internal-network related. Just noting this here since it happened.

Last-ditch Solution to Non-Working PHP-FPM + Apache Configuration

Posted on November 3, 2011 by - DevOps, Life of a Web Developer, Tips

I had a surreal experience yesterday. I was following online tutorials about setting up Apache + PHP-FPM (for example, this ServerFault question: http://serverfault.com/questions/326919/how-to-set-the-httpd-conf-when-using-php-fpm-with-php5-3-8-and-apache2). I’ll let you read that rather than re-hash it.

My goal here is only to share quickly how I actually got this working.

Alright, so you know the part where it says to add the directives:

AddHandler php5-fcgi .php
Action php5-fcgi /fcgi-bin/php5.external

This didn’t work for me no matter what I did. No errors were produced, so I knew that it simply wasn’t executing the Action directive for whatever reason. In checking the Apache 2.2 documentation for Action, I noticed that a MIME type could be given in lieu of an action-type (the php5-fcgi thing). Having exhausted all other options, and knowing that the PHP file was being sent to the browser unprocessed with the MIME type application/x-httpd-php, I decided to add:

Action application/x-httpd-php /fcgi-bin/php5.external

to my configuration. And, much to my shock, it actually worked!

So, if you find yourself as frustrated with setting up Apache + PHP-FPM as I was, I hope this tip may ease your suffering.