If you attempt to access your application running inside a Vagrant VM using app_dev.php you’ll receive the following error:
You are not allowed to access this file. Check app_dev.php for more information.
If you look into your app_dev.php file you’ll see a line that looks like the following:
// This check prevents access to debug front controllers that are deployed by accident to production servers.
// Feel free to remove this, extend it, or make something more sophisticated.
if (isset($_SERVER['HTTP_CLIENT_IP'])
|| isset($_SERVER['HTTP_X_FORWARDED_FOR'])
|| !(in_array(@$_SERVER['REMOTE_ADDR'], ['127.0.0.1', 'fe80::1', '::1']) || php_sapi_name() === 'cli-server')
) {
header('HTTP/1.0 403 Forbidden');
exit('You are not allowed to access this file. Check '.basename(__FILE__).' for more information.');
}
The important part is this line:
|| !(in_array(@$_SERVER['REMOTE_ADDR'], ['127.0.0.1', 'fe80::1', '::1']) || php_sapi_name() === 'cli-server')
This line looks at the IP address you’re using to access the system and makes sure it’s referring to the “local” computer. There are a couple options to fix this. This first is that you can just remove this line and then delete the app_dev.php file when you deploy. This could create a potential security problem because if you forget to remove it someone could access it and use the dev tools.
The better option is to add your local computers IP address to the list. To do this we’re going to change the exit function so it outputs you’re IP address.
exit('You are not allowed to access this file. Check '.basename(__FILE__).' for more information. You're IP: . $_SERVER['REMOTE_ADDR']);
Now if you try to access the site you’ll get your IP address:
You are not allowed to access this file. Check app_dev.php for more information. Your IP: 192.168.56.1
Then you just need to add your IP to the list:
if (isset($_SERVER['HTTP_CLIENT_IP'])
|| isset($_SERVER['HTTP_X_FORWARDED_FOR'])
|| !(in_array(@$_SERVER['REMOTE_ADDR'], ['127.0.0.1', 'fe80::1', '::1', '192.168.56.1']) || php_sapi_name() === 'cli-server')
) {
header('HTTP/1.0 403 Forbidden');
exit('You are not allowed to access this file. Check '.basename(__FILE__).' for more information. Your IP: ' . $_SERVER['REMOTE_ADDR']);
}
I was setting up a virtual server that’s using resque to perform background jobs and when I ran into the following error:
$ resque-web
/var/lib/gems/1.8/gems/rack-1.6.4/lib/rack/handler.rb:22:in `const_get': wrong number of arguments (2 for 1) (ArgumentError)
from /var/lib/gems/1.8/gems/rack-1.6.4/lib/rack/handler.rb:22:in `get'
from /var/lib/gems/1.8/gems/vegas-0.1.11/lib/vegas/runner.rb:280:in `setup_rack_handler'
from /var/lib/gems/1.8/gems/vegas-0.1.11/lib/vegas/runner.rb:278:in `each'
from /var/lib/gems/1.8/gems/vegas-0.1.11/lib/vegas/runner.rb:278:in `setup_rack_handler'
from /var/lib/gems/1.8/gems/vegas-0.1.11/lib/vegas/runner.rb:36:in `initialize'
from /var/lib/gems/1.8/gems/resque-1.26.0/bin/resque-web:13:in `new'
from /var/lib/gems/1.8/gems/resque-1.26.0/bin/resque-web:13
from /usr/local/bin/resque-web:19:in `load'
from /usr/local/bin/resque-web:19
After a lot of fighting I learned that Sinatra wasn’t compatible with rack 1.6.x so the only way to fix the problem was to downgrade to a version that worked. After much testing it appears that 1.5.5 was the last version that worked.
Read MoreToday when I tried to boot a VM I got a scary message:
> vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
default: Adapter 2: hostonly
==> default: Forwarding ports...
default: 22 (guest) => 2223 (host) (adapter 1)
default: 80 (guest) => 8080 (host) (adapter 1)
default: 4444 (guest) => 4444 (host) (adapter 1)
default: 3306 (guest) => 3306 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 127.0.0.1:2223
default: SSH username: vagrant
default: SSH auth method: private key
default: Warning: Remote connection disconnect. Retrying...
default: Warning: Authentication failure. Retrying...
<snip>
default: Warning: Authentication failure. Retrying...
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.
If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.
If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.
If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.
The odd part was if I tried to manually SSH into the VM I received a password prompt which isn’t supposed to happen.
> vagrant ssh default
vagrant@127.0.0.1's password:
Welcome to Ubuntu 12.04 LTS (GNU/Linux 3.2.0-23-generic x86_64)
* Documentation: https://help.ubuntu.com/
New release '14.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.
Welcome to your Vagrant-built virtual machine.
Last login: Mon Mar 21 20:28:37 2016 from 127.0.0.1
To fix this problem I needed to “reset” the authorized_keys file to the default:
wget https://raw.githubusercontent.com/mitchellh/vagrant/master/keys/vagrant.pub -O ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R vagrant:vagrant ~/.ssh
After another vagrant command Vagrant automatically replace the default file with one specific to my computer and we were back off to the races.
> vagrant halt
==> default: Attempting graceful shutdown of VM...
default:
default: Vagrant insecure key detected. Vagrant will automatically replace
default: this with a newly generated keypair for better security.
default:
default: Inserting generated public key within guest...
default: Removing insecure key from the guest if it's present...
default: Key inserted! Disconnecting and reconnecting using new SSH key...
I recently read Modern PHP: New Features and Good Practices and I thought I would pass along several things that I learned while reading the book.
Today marks the one month mark of my move to Jekyll so I thought I would recount some issues I’ve run into.
On my Wordpress installation I installed a plugin that redirected RSS subscribers from the feed hosted on the site to Feedburner so I could get statistics about all of you who are subscribing. I checked my statistics and my subscribers went to zero:
The problem was that the link on my Wordpress install pointed to /feed/ and the plugin redirected the folder to the correct Feedburner URL. The fix was to add a redirect to the site’s configuration:
# redirect /feed/ to feedburner
Redirect 301 /feed http://feeds.feedburner.com/ThisProgrammingThing
On the 15th, I received the following error in my email:
I check the errors and it was mostly /category/ and /tag/ pages that Wordpress creates automatically. Normally people don’t usually use these so I’m not too worried.
I only post some images but I noticed that the following happened when I looked at my RSS feed:
The fix to this is to prepend all image links with {{site.url}}.
{{site.url}}/assets/2016/brokenimages.png
The horrible downside to this is that {{site.url}} is www.thisprogrammingthing.com and not dependent on what’s being served (which makes sense). So I have to upload all my images to the live server when I’m checking my post because it looks like this otherwise:
Today I was trying to figure out the total amount of space a type of file was taking up on one of our servers so I could free up some space. The result below will give you the total number of bytes.
ls -FaGl "mysql-bin" | awk '{ total += $4; print }; END { print total }';
If you’re going to do something crazy like edit your Apache config on your production server without testing it in a test environment it’s important to at least make sure you’re configuration files are formatted correctly.
Apache provides a command line switch to apachectl
to do just that:
$ sudo apachectl configtest
Syntax error on line 4 of /etc/apache2/sites-enabled/000-default:
Invalid command 'DaocumentRoot', perhaps misspelled or defined by a module not included in the server configuration
Action 'configtest' failed.
The Apache error log may have more information.
This way you can make sure you won’t mess stuff up when you reload the service.
$ sudo service apache2 restart
Syntax error on line 4 of /etc/apache2/sites-enabled/000-default:
Invalid command 'DaocumentRoot', perhaps misspelled or defined by a module not included in the server configuration
Action 'configtest' failed.
The Apache error log may have more information.
...fail!
In case you’ve missed it, Apple released a note about their stance on unlocking a terrorist’s work phone. Much has been said about how this makes them unAmerican and I think we really need to applaud them for drawing a line in the sand and saying “No”. This seems like a case where it would be really easy for them to make us less secure as a nation and instead their spending time and money fighting for what they know is right. Over the last couple weeks I’ve heard all kinds of arguments on both sides but I think the take away is that if we give away the ability to have secure phones the only ones losing are the American people.
It’s also going to be hilarious what I can only assume is millions of dollars spent on fighting this the phone contains zero actionable material. :-)
subscribe via RSS