Part 5: Setting-up a Linux Development Machine: Virtual Hosts in Apache2

When I am working on code project, I isolate that project within it's own directory/repository.  Further, it matters not if I'm starting a completely new project, or if I'm branching off the trunk of an existing project.  As a means of imposing order over chaos, I isolate the existing project within it's own sandbox both on the filesystem and via Apache2.

To do so requires an understanding, somewhat, of the mechanics of Apache2, DNS, and your localhost.  A minimal understanding, trust me.

What it, in return, gives you is an isolated view of your code project from the web-server perspective.  Cookies are isolated by domain, your document root is isolated to a single directory/repository, and you not only put your log files, just for that domain, where ever you want but you can also name them anything you want as well.

What I'll provide you with in this installment is a rudimentary understanding of the mechanics behind virtual hosting using Apache2, a template configuration file to get you going, and the basic steps necessary to get the whole mess working.  Let's get started...

When you start a new project, if you're checking it out from a source-code repository, you'll typically assign it to a directory somewhere common.  For example, within your home directory, you may have a folder named "code" and beneath that folder, other folders that describe either the project or the programming language you're working in.  Doesn't really matter as the point is this:  you've isolated your code repository from everything else on your filesystem, right?

It really doesn't matter, to Apache2, where you create your filesystem repository.  As long as the webserver pseudo-user has access permissions to the directory, then you can access the files within that directory via a web browser.  The webserver has to be configured to be told that, for a given domain name, where is the documentRoot for that domain.

Some of you, at this point, may be asking: what's a domain name and why is it important?  Well, a domain name is simply a name you've assigned to the project to keep it separate, at least in your own head, from the other projects you may, or may not, have running on your development machine.  For example, I create a new project called newWidget and it's currently in the 1.4 revision.  I'm ready to branch and write some new features for the product so, using whatever sccs tool, I branch off the trunk and create the 1.5 branch.

I check that branch out to a directory in /lampdev/php/newWidget115.  I now need to do two basic things:

  1. invent some domain name that will be used exclusively for this project and resolve the domain to my localhost
  2. create a virtual host in apache so that apache knows that http://newW115 points to my localhost

The reasons, apart from what we've already discussed, is to keep your local DNS services on your local machine.  If you, before entering any configuration information, entered: http://newW115 into a browser url bar, chances are very good you're going to end-up on a search page (I'm using Chrome) or get some sort of browser error.

So the first step is to define the new domain name (again, given that we're already checked the code out into the aforementioned directory) to the local system so that all requests to that domain are resolved locally through our name services.  To do this, we're going to sudo edit the /etc/hosts file.

This file, /etc/hosts, is the first thing checked whenever your local name services is trying to resolve a host name.  If it finds a host-to-IP alias in this file, all further attempts at resolution are halted as it has successfully resolved the host name.  Edit /etc/hosts to resolve your new domain.  It should look something like this:

[cc lang='bash' line_numbers='false']    localhost codemonkey codemonkey.shallop.com codeMonkey.shallop.com newW115


The way /etc/hosts works is that you first list an IP address for the domain to resolve to - in this case, we're using which is TCP/IP speak for your local host.  Next we list all of the domain names that are going to resolve to this IP address.  In the example above, we're resolving localhost, codemonkey, codemonkey.shallop.com, codeMonkey.shallop.com, and the new domain: newW115 all to

Whenever I type one of these domains, for example, in to a web browser URL bar, my local host domain services won't go out to my network name servers to resolve the domain name -- it's telling the requesting service that it's  Note, too, that you can alias multiple domain names to the same machine.

Side Note -- this is how you can blacklist certain domains from your browsing experience.  Simple resolve that domain to that's an article for another day...

You can also have multiple entries resolving to the same IP address.  It would have been just as correct for me to have listed by /etc/hosts file as:

[cc lang='bash' line_numbers='false']     localhost     codemonkey     codeMonkey     codemonkey.shallop.com     codeMonkey.shallop.com     newW115


Finally, also note that a domain extension isn't really required.  We can name our domain pretty much anything we want and as long as you universally use that spelling (and case), then it will resolve locally.

Now that the domain is resolving locally, the next step is to tell Apache2 how to handle the request.  When you type: http://newW115 at the browser, the browser will query local services and receive a response that the domain is handled locally.  Apache2 will then say: "Oh, if it's local, then were do I go to get the files and stuff?"

The configuration for Apache2 is done with virtual hosting.  Technically, you can do this without virtual hosting -- but you can only do it for one domain.  If you want to locally-host multiple domains, you have to use virtual hosting.

The Apache2 configuration file lives in: /etc/httpd/conf and is named: httpd.conf.  This is the main configuration file for Apache2.  Some installations use a sub-directory, usually called something like: vhostsd.conf, and stores the vhosts.conf file within that directory.  That's ok, too.  Apache2 is versatile that way but, for our purposes, we're going to maintain the virtual host configuration(s) within the main conf file.

However, if you wanted to use a separate file for Virtual Hosting, all you need in your httpd.conf file is the directive:

[cc lang='apache' line_numbers='false']

# Virtual hosts Include conf/extra/httpd-vhosts.conf


At the very end of httpd.conf, there's a section called: Name-Based Virtual hosting.  We're going to append this virtual host configuration to the end of this file.

Allow me to side-step for a quick second.  Consider if we were to install phpMyAdmin locally on our server because this is how we want to administer our mySQL database.  We can install the program files anywhere as phpMyAdmin is just another LAMP application, right?  Were we to do that, then we would need a <Directory> directive to Apache2 telling Apache2 where to look for phpMyAdmin.  The domain for phpMyAdmin would still be localhost, or or whatever else you'd defined in /etc/hosts.  The location of the application can live anywhere and we're using the conf file to tell Apache2 how to find and serve it to us when requested.

[cc lang='apache' line_numbers='false']

Alias /phpMyAdmin "/opt/local/www/phpmyadmin" <Directory "/opt/local/www/phpmyadmin"> Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all </Directory>


What this <Directory> directive simply does is tell Apache2 where to look for phpMyAdmin if I enter something like: http://localhost/phpMyAdmin in the URL bar of my browser.  It's not the same thing as giving phpMyAdmin it's own domain at all.

I do this with a lot of my web applications: phpMyAdmin, mcmon, ajaxmytop, nagios, etc., simply because I don't want to remember where the fill path name is of the applications.  It's easier to type: http://localhost/phpMyAdmin that it is to type: http://localhost/webapps/database/phpMyAdmin.

Ok, so back to domains.  Here's the template for the virtual host we've created in /etc/hosts: newW115:

[cc lang='apache' line_numbers='false']

<VirtualHost *:80> ServerName  newW115 ServerAdmin mshallop@gmail.com DocumentRoot /code/webapps/LAMP/newWidget/1-15

DirectoryIndex  index.php

<Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /code/webapps/LAMP/newWidget/1-15> Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny allow from all </Directory>

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ <Directory "/usr/lib/cgi-bin"> AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory>

ErrorLog /var/logs/115_error.log

LogFormat       "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined LogFormat       "%h %l %u %t \"%r\" %>s %b" common LogFormat       "%{Referer}i -> %U" referer LogFormat       "%{User-agent}i" agent        CustomLog       /var/logs/115_log common        ErrorLog        /var/logs/115_error_log

# Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn

CustomLog /var/logs/115_access.log combined ServerSignature On



This is a pretty minimal configuration -- but it's the boilerplate template I use for all new domains and it works.  The lines that in boldface are the lines you should change to match your environment.  Note that you can pretty much put files, such as the log files, where ever you wish.  I changed the names from my normal location but, as a rule, I maintain the entire environment outside of the root filesystem.

Once you've made your changes and saved the file, you'll need to restart Apache2 so that it will read the new configuration.  If there are errors in your configuration file, Apache2 will let you know and will refuse to start.  Make sure you've corrected all errors and, once the server successfully restarts, you should be able to type: http://newW115 into your browser URL bar and have that domain resolve locally, and serve files from the directory you specified in the httpd.conf file.

Over time, as you add additional projects and create new code-domains, you can simply add the new <VirtualHost> directives, appending them, to the httpd.conf file as needed.  When you expire and remove hosts and files, don't forget to remove them from the Apache configuration as well.

And that's pretty much it.  This is a simple thing to set-up as we didn't delve into anything that wasn't plain-vanilla.  For example: SSL configurations, .htacces, or the re-write engine.  That's for another day, another article.

Hope this helps...

Part 3: Creating Linux Development Environment (PHPStorm and the JDK)

I stopped working yesterday on the installation because I hit a pothole installing PHPStorm by JetBrains.

As I mentioned in the previous article, and in case you're just tuning in, I am first working towards a LAMP development environment on an older PC running 64-bit Linux.  We've decided on CentOS 6 as the base distribution and installed the LAMP stack yesterday.  I installed the PHPStorm package but hit a snag when I received an error message telling me that it required the JDK runtime ... thingys.  (Whatever - I assiduously avoid Java.)

I installed the openjdk packages with yum and got PHPStorm to start-up, albeit with many dire warnings and threats to the graphics system.  Apparently PHPStorm is comfortable running only with the jdk from SUN/Oracle.

I then downloaded and RPMd the SUN/Oracle version of the jdk and restarted.  What happened next were error messages telling me that I need to set-up the java (dk) environment correctly as, now, the two were conflicting with each other.

[cc lang='bash' ]

ERROR: Cannot start WebIde. No JDK found to run WebIde.  Please validate either WEBIDE_JDK, JDK_HOME or JAVA_HOME environment variable points to valid JDK installation.


See, in the linux world, the PHPStorm is launched from a shell script.  It checks your environment for the JDK through these variables and, if correctly defined, launches the IDE.

There's a java-sdk configuration file located as /etc/java/java.conf -- don't make the same mistake I made and edit this file to re-direct/create environment  variables so they point to the SUN/Oracle version of the JDK.

The SUN/Oracle version of the Java SDK installed in: /usr/java/jdk1.7.0/ which will change for your system depending, I'd assume, on your distribution and version of the SDK.

To reconcile the conflicts, I used the yum installer to remove any traces of the openjdk -- all packages were removed and then I did a yum clean all to reset the environment.

Since I'm the only user on this system, I next cd'd into my home directory and pulled up the .bashrc file - this will modify the bash shell environment for every terminal session I start.  I added the following two lines to the .bashrc:

[cc lang='bash' line_numbers='true']

JDK_HOME=/usr/java/jdk1.7.0 export JDK_HOME


I exited the editor and reloaded my bash environment: [cc lang='bash' line_numbers='false']

# . ./.bashrc


From there, all I need to do is start the PHPStorm shell script which launches the application and I'm good to go!

You can install the PHPStorm folder anywhere.  Using your bashrc file, you can make an alias to the start-up shell script so that you can launch the IDE anywhere from the CLI environment.

[cc lang='bash' line_numbers='false']

alias phpstorm='nohup /home/user/folder/PhpStorm/bin/PhpStorm.sh &'


The nohup allows the program to ignore SIGHUP -- in other words, if you close the terminal from where you launched PHPStorm, you will not close PHPStorm as well.  The ampersand (&) at the end of the command tells the shell interpreter to launch the application as a "background" task which frees up your terminal session so that you can continue to use the shell while PHPStorm is running.

At this stage, I'm pretty much good to go for basic LAMP development.  I've got a running mySQL server, Apache2 is good to go, and PHP5 is installed.  I will enhance my environment by adding a few packages such as:

I also want to give some thought to virtual hosts -- I'll cover this topic in a future post -- within my local Apache2 environment, I'm going to want to establish several different virtual host environments, each of which point to a different documentRoot location (or code repository) depending on which application/environment I'm currently working on.
I'll also have to plan my filesystem repositories carefully -- for the most part, I'll be working as a subversion server for home-projects, while also working as a subversion client for work projects.
Which reminds me - in the first article in this series, I reported on the filesystem utilization following a clean Fedora 15 install.  Here's the state of the current filesystem (CentOS 6) following the LAMP stack install, and the install of the PHPStorm IDE and the SUN/Oracle JDK:
/ (root):   50gb, used 6%, 47gb available
/boot:      485mb, used 11%, 409mb available
/home:    864gb, used 1%, 820gb available
I'm looking pretty good for user filesystems but I'll want to check my mySQL configuration and ensure that databases are being created in the /home filesystem and not in the /root filesystem also.
Ok - done for this weekend and off to play some Rift!  Hope this helps someone!
PS: If you want some detailed tutorials on installing any of the supplemental packages I listed at the end of this article, please leave a comment!

Setting-up a Linux Development Client - Part 2 - CentOS 6 Install

In the last install, I wrote about how I decided to try Fedora Linux after a nearly 10-year hiatus from the product.  Unfortunately, as it turned out, my fears were not groundless and I am going to scrap the install in favor of CentOS before I get in so deep that making the switch-out becomes prohibitive.

I am going to continue to try Gnome as my desktop, however, as I did like what I saw for Gnome under Fedora.  While I have always used KDE in the past, it was always accompanied by a wistful bit of: "I'll bet the grass is greener over there..." kind of thinking.  Anyone that's ever spent anytime looking over the Gnome application offerings vs. the KDE application offerings will agree.

Time to stop wondering and start trying.  I've downloaded the CentOS 6 x86_64 CD ISO and have booted into the desktop.  It's not nearly as polished, pretty, as the Fedora desktop -- it looks more like a traditional windows set-up with the desktop icons falling down the left-side of the screen and the top-bottom menu bars.  While simpler in appearance, it's also intuitive and easier to use.  Less eye-candy also means less CPU/GPU crunching resulting in improved responsiveness.  (Dragging a window around in the Fedora desktop on my hardware platform was like a bit like being on a strong hallucinogenic.  Or so I've been told.)

Anyway, I locate the "Install to Hard Drive" icon and click it...

The CentOS 6 installer opens a window in the middle of desktop (as opposed to Fedora taking over the entire desktop) and presents you with the same two start-up options: installation language and installation destination.  (As I mentioned in the previous article, CentOS is a child of Fedora.  I expect things to be similar.  Stuff working is one such expectation.)

CentOS gives me the same options as the Fedora installer - except with less eye-candy.  For example: when asking to input the root password, I'm not shown a bar indicating password strength.  I just type in my password and that's pretty much it.  Also, like the previous install, I'm not going to choose the encrypted filesystem, and I'm going to go with the defaults for filesystem partitioning.

While this is installing, I'll yak about why I've chosen these two distributions as my first-two choices.  Ubuntu offers a great installation and configuration experience.  However, after messing around with Linux distributions for 30 years, I can't quite shake the feeling that Ubuntu in the Granimal of linux installs.

Don't get me wrong - it's a great install in that everything works, is highly automated, and requires little, if any, user intervention from the machine's administrator.  And that's probably what bugs me the most about Ubuntu.  As a Linux guy, I want (need) more interaction with my OS.  If I was content to let me OS run off and make all the most-important decisions without asking me, I'd use Windows.  Ubuntu fulfills a great niche - it introduces Windows users to Linux.  I'd install Ubuntu on my Dad's PC.

I've also bypassed SuSE Linux -- which is surprising considering that, for nearly a decade-and-a-half, all I would consider running and installing was SuSE.  This flavor of Linux, like most things German, is precise, exacting and mechanically sound.  Correct, even.  It's also overbearing, heavy-handed and leaves deep footprints.  The other problems that I have with SuSE is that it can be difficult to find packages tailored for it's installation base.  While SuSE enjoys a wide-variety of software, there always seems to be those few-dozen packages you want to install but can't locate the ports to the SuSE distribution.  In that, it's like the Dewey (Malcolm in the Middle reference) of Linux installs: unprepossessing and brilliant but relatively scarce when it comes to applicable resourcing.

I've never been a big fan of Debian simply because they move in geological-timeframes when it comes to engineering releases.  Oh, look, kernel 2.26.9999 is out!  (Debian: happy with 2.123, thank you.)  Geh.  What it lacks in contemporary packaging, it more than makes up with in stability.  I, on the other hand, tend to blow through distributions like the end is near so Debian isn't really for me.

I tried Mandriva once and, as a result, got sucked into this weird mail hell back when I was running my own DNS and MX servers.  I really tried to make it work but it just got too ... weird for me.  It may have improved in recent years but I've never had enough of it catch my eye to really care enough to revisit it.

Rebooting the CentOS 6 Live CD was better than the Fedora Live CD as CentOS actually gave me a 'reboot' option whereas Fedora would only let me 'suspend'...whatever that means...

I configured the user and the network time and then was presented with an alert: "Insufficient Memory to Start kdump" ... which made me think I had crashed the install...turns out, it was just telling me I couldn't start the monitor itself.

On to the login...

Well, CentOS 6 is definitely a derivative of Fedora 15.  Although the desktop is radically different, the first thing I try is FireFox -- and am immediately told that I can't access any off-site web page.  Although I can ping and resolve hosts from terminal, FireFox cannot do so from the browser.  So the same crappy DNS issue which plagues Fedora was inherited by CentOS.  Great.  Starting to get an idea of where all this is eventually going to end up...

The network configuration applet in CentOS allows me to edit and add google's nameserver and things start to work in the browser immediately thereafter. For some reason, I wasn't able to get this to work in Fedora so, bonus.  Also, my screen resolution is at the highest at 1280 x 1024 and that gives me a happy, too.

I start the software update and am informed that all my software is currently up-to-date and I do not need to additional software.  That strikes me more as a software fail...so I run yum update from the command line as root (side note: either I didn't see the option to create my new user as an admin, or it didn't exist, but regardless, I can't sudo...) and I'm suddenly off-and-installing 237 total packages... so, clearly something in the GUI version of the software update failed and now I'm thinking that, because I didn't have sudo privileges, it was my account exec'ing the command.

CentOS 6 will allow you to login graphically as root.  And thereafter puts so many scare-ware pops on the screen that you eventually, submissively, quietly and quickly edit the sudousers file and logout.  Now that my main account has sudo access, I never need to hit root again.

Quick download and now Chrome is my default browser...time to try to install some development tools...

The first package I'm going to install, from the Add/Remove Software package manager, is the MySQL server and related files package which is an 8.1mb download...I have to also install dependent packages for perl support and client programs and shared libs, which is ok...PHP 5.3.2 is the next item to be installed and I install all packages except for postgres.

At this point, I have a LAMP stack installed, but it's not running...  starting off with mysql:

[cc lang='bash' line_numbers='false']

# sudo chkconfig --level 2345 mysqld on

# sudo /etc/init.d/mysqld start

# mysql -uroot

mysql> use mysql;

mysql> update mysql set password=password('yourPasswordHere') where user='root';

mysql> exit;


This set of commands sets-up mysql to run at start time (run levels 2, 3, 4, and 5) and then starts the mysql server.  Next, you invoke mysql as root and reset the root password to something other than the default, which is nothing.

--> mySQL is now running.

For Apache, we're going to leave virtual hosts alone for a future article, and just make sure that the webserver will execute at boot, and that we can serve system information...

[cc lang='bash' line_numbers='false']

# sudo chkconfig --level 2345 httpd on

# sudo /usr/sbin/apachectl start


If you ps -ef | grep httpd you'll see a list of the running apache servers...you can also open up http://localhost in a browser window and you should see the CentOS Apache 2 Test Page.  Now we have to confirm that we have PHP installed and running, along with a few other modules.  By default, your web server DocumentRoot is in /var/www/html.  Using the terminal, cd into this directory and type the following:

[cc lang='bash' line_numbers='false']

# sudo vi snitch.php






This creates a little snitch file in your DocumentRoot which you can load in a browser -- it then dumps your LAMP configuration to your browser window.  At the very top of the display, it should tell you what version of PHP you're running.  (Mine reports version 5.3.2.)  Important to me, at this stage, is that I have memcache, soap, mysql, and ODBC drivers installed.

The last stage for me is to install my IDE.  I own a license for JetBrains PHPStorm which I personally prefer.  It's not freeware but if you can afford the license costs, it's probably the best IDE you can get for the price.  I use it on all environments (Mac, Windows and Linux).  I also noticed that you can install the Eclipse IDE using the software installer -- this is very similar to PHPStorm.

To get PHPStorm up and running, I need the SUN/Oracle version of the JDK -- not the openJDK.  I did get it running, but not without DIRE and URGENT messages prophesying  the END OF THE WORLD, or at least my video display, should I continue.  Point is, I did get it installed, configured, licensed.  Then I de-installed the openJDK and went hunting for the SUN/Oracle JDK.

Which will be covered in the next installment...