Ready to rock PHP 7.3 Docker LAMP Stack

I have built a full LAMP stack that comes with the following:

• Apache
• PHP 7.3.3
• Mariadb
• MailHog
• XDebug
• HTTPS Virtualhost with holding page

Here’s how you get a full LAMP stack up and running in no time at all, which will be identical on any platform.

Firstly, install Docker and Virtualbox if you don’t have them. Then create a default base VM.

https://www.docker.com/community-edition

https://www.virtualbox.org/

docker-machine create --driver virtualbox default

OK. So, first thing you need to do is start your VM:

docker-machine start
docker-machine env
eval $(docker-machine env)

You should run eval $(docker-machine env) in any other terminal tabs you open too, this sets up environment vars for setting up docker. Take a note of that IP address, and edit your /etc/hosts file

192.168.99.100 awesome.scot

Ok, lets clone the LAMP stack:

git clone https://github.com/delboy1978uk/lamp
cd lamp

This is another one off, build the image.

docker-compose build

That’s it! Now start your docker image like this

docker-compose up

and you can finally open your browser to

https://awesome.scot

Advertisements

Bypass HSTS on local dev sites

HTTP Strict Transport Security will BLOCK your dev site if it is using a self signed certificate. And once the browser has given you that, it remembers it, so fixing it doesn’t help until you fix Firefox/Chrome.

Firefox

• Close any tabs
• Ctrl + Shift + H (Cmd + Shift + H on Mac)
• Find the site in question
• Right click, forget about this site
• Close and reopen browser
• Add certificate exception this time 😎

Chrome

• chrome://net-internals/#hsts
• type the hostname into the Query Domain
• If found, enter the domain in the Delete domain section 😎

 

Stop git committing chmod changes

Pretty self explanatory. Just do this:

git config core.fileMode false

The documentation says this about it:

core.fileMode 
If false, the executable bit differences between the index and the 
working copy are ignored; useful on broken filesystems like FAT. 
See git-update-index(1). True by default.

Here’s a warning from a guy on StackOverflow:

core.fileMode is not the best practice and should be used carefully. This setting only covers the executable bit of mode and never the read/write bits. In many cases you think you need this setting because you did something like chmod -R 777, making all your files executable. But in most projects most files don’t need and should not be executable for security reasons.

The proper way to solve this kind of situation is to handle folder and file permission separately, with something like:

find . -type d -exec chmod a+rwx {} \; # Make folders traversable and read/write
find . -type f -exec chmod a+rw {} \; # Make files read/write

If you do that, you’ll never need to use core.fileMode, except in very rare environment.

Fixing missing Authorization Headers

It’s something to do with using PHP FPM / Fast CGI, and auth headers being disable for that.

So we add this to the directory entry of the .htaccess:

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

You now have your missing header back!

Line Endings in Git with Windows

Devving on Windows is a PITA.

Anyway, ever seen a message like this?

warning: LF will be replaced by CRLF in tests/unit/Del/Console/CommandTest.php.
The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in tests/unit/Del/Console/CommandTest.php.
The file will have its original line endings in your working directory.

We only want LF. To squelch this crap, run the following:

git config core.autocrlf false

Yay.

Use Git bisect to find dodgy commits

Today I had the mammoth task of checking through 512 git commits to find a piece of code that broke something.

Usually i would git log, look back however many commits, and then do a git reset –hard COMMIT_NUMBER, then check if it worked. If it did, I would git pull back to the HEAD again, and try a resetting back to a more recent commit, until I found the bad code.

Never again! Git bisect to the rescue!

Find any good commit in the past, and note the commit number. Find any bad commit where the code is broken, and note the commit number.

Now, do the following:

git bisect start
git bisect good 514d83c
git bisect bad b27f38e

Git checks out the middle commit between the good and bad ones. At this point I reloaded my page to see if the code was working or not. The code was working, so I then told git that it was good:

git bisect good

Again the code was working, so as you can see I ran it again. Each time, git bisect jumps half way, iterating and narrowing down the options. Keep doing this and checking your code until it breaks, then say:

git bisect bad

Here’s the rest of the output:

Now we have the exact commit number, and can do a git diff to find out what you did wrong! 🙂

Once you have the commit in question, tell git bisect that you are finished:

git bisect reset

I am amazed that I’m only just finding out about this awesome feature of Git! I’m sure you’ll love it too, try it!

Have fun!

Automate everything! – The power of puPHPet

As you readers probably know, I can’t stand XAMPP and MAMP, being two steaming piles of crap, and have long advocated that you set up VirtualBox & Vagrant, then head over to http://www.puphpet.com, fill in the forms to configure your VM,  generate the config.yaml, and then unzip it and run ‘vagrant up’ to install it. Brilliant so far.

Yesterday I had a total downer of a day, trying to run an old legacy PHP 5.3 app. PuPHPet doesn’t have the EOL PHP 5.3, so at first I settled as a one off for MAMP, but it was slow and horrible.

Then I thought, wait! If I don’t configure Apache or PHP in puphpet, I could get a box up and install 5.3 myself. That’s when I discovered the awesomeness of the puphpet/files folder.

The only thing I used in there was the ssh keys. But there are empty folders waiting for .sh files (shell scripts) to be dropped in.

So for this box, I created exec-once/install-stuff.sh which contained the following:

#!/bin/bash
yum -y install httpd php
yum -y install php-mysql php-devel php-gd php-pecl-memcache php-pspell php-snmp php-xmlrpc php-xml

Then upon running vagrant provision, it not only looked for changes in config.yaml, but it checks for changes in these files too!

I then made set-vhosts.sh, and import-database.sh, which look like these:

#!/bin/bash
echo "
===========================================
Adding vhosts to /etc/httpd/conf/httpd.conf
===========================================
"
echo "
<VirtualHost *:80>

   DocumentRoot /var/www/fife/web
   ServerName fife
   ErrorLog /var/www/fife/log/error.log

   <Directory "/var/www/fife">
      Options -Indexes +FollowSymLinks
      Order allow,deny
      Allow from all
      AllowOverride All
  </Directory>

</VirtualHost>
" >> /etc/httpd/conf/httpd.conf

And …

#!/bin/bash
mysql -u root --password=123 --database=fortdev < /var/www/fife/data/sql_scripts/symf_fortdev.sql

I take it by now you get the idea! So now you can totally destroy your VM, and put any customisations in these shell scripts, so your full setup can be back up in 5 minutes flat with a vagrant up and vagrant provision!!!

You can then also start thinking about using puPHPet for deploying your setup to your production server 🙂 There’s a vagrant plugin called Vagrant Managed Servers, which will take care of that for you. https://github.com/tknerr/vagrant-managed-servers . I haven’t looked at it yet, but of course you can expect a blog post on it here when I figure it all out!!