Scott Horsley

I actually disagree with this wholeheartedly. Naming machines based on a theme is fun for a small subset (or your home network) but realistically it's a nightmare. Here are a few scenarios.

My current network contains over 500 nodes and they are named based on role and location.

eg. www01.dc1, www02.dc1, www01.dc2, etc.

This makes it extremely easy to train a new staff member on what these machines purpose is and which datacentre that machine lives in. As for renaming a server. How hard is it to change the entry in /etc/{hostname,hosts,mailname} and reboot (just for good measure). We used to name every machine after weather phenomena (storm, glacier, wind, tornado, hurricane, etc) but at about 200 nodes it became apparent that 1) We were scraping the bottom of the barrel to get new cool names and 2) New staff members were so confused it took months to work out the basics from scratch.

As for the whole multifunction server, once again, it works if your network is small, however when you start growing you really want to move to a separation of concern model where a single node does a single task, and does it well (Unix philosophy). As a side note, I use OpenVZ for a whole heap of infrastructure. This means that a single node takes about 4G of disk space (service data is on NAS services) and as such, it's cheap to spin up guests to perform another single task well.

eg. Database, Web, Monitoring, Reverse Proxies, Syslog.

This of course means I NEVER "re-purpose" a server for another task any time, EVER. Seriously, this just leads to absolute server/disk bloat and leads to a huge amount of unknown when it comes to software (version and upgrades) auditing.

Another point (as also mentioned by @pincoded for a similar method) is the following.

I use saltstack for server management and targeting hosts using commands similar to the following;

$ salt 'www*.dc1.mydomain' cmd.run X</pre></code>

This works great for dealing with all web servers in datacentre1. Of course, I can use grains for this but the host dictates it's role pretty well.

Overall, an interesting article, just scoped very much to a smaller network structure.

@andyfleming,
Your right on both accounts.

1) date() with time() and without "should" produce the same result, however I prefer to use time() as date() accepts a timestamp to allow different result points in time. By leaving it in place, makes that very clear when reading the code.
2) MySQL will accept the : or . as valid.

Example:
mysql> create table foo (bar datetime);
mysql> insert into foo values ('2012-10-10 13:45.32');
mysql> select * from foo;
| 2012-10-01 13:45:32 |

Truncated for reading pleasure.