Posts from ‘Uncategorized’


new-__bash__-software-bug-mayUnless you’ve been under a rock for the last few days you’ve probably heard about the new Bash exploit (CVE-2014-6271) ‘ShellShock’ that allows remote code execution through bash, because of the amount of servers and applications using the bash service it’s a fairly big deal in the security world.

Here’s a few simple commands to get your CentOS servers patched, please for your sake do this ASAP.

# Check if vulnerable
env x='() { :;}; echo Vulnerable system'  bash -c "echo Testing..."
 Vulnerable system
# If you need to access the web via a proxy, add that here.
nano ~/.bash_profile
export http_proxy=
# Apply the patch
yum update bash -y
# Remove proxy (if used
nano ~/.bash_profile
# export http_proxy=
# Check if vulnerable
env x='() { :;}; echo Vulnerable system'  bash -c "echo Testing..."

Any problems or questions, please leave a comment.

24 has a new look coming soon, the old design was getting a bit cumbersome, also it didn’t render too great in a few browsers because of all the CSS hacks.

Probably one of the biggest reasons for changing was some search engines were getting really confused by the old designs coding/layout which was effecting people actually finding the information they wanted.

Anyway good new a new design with some cool new features is on it’s way, a over there>>>


Most of us check the normal thinks like traceroute or arp on a web server, but actually checking recent routing table lookup’s can be a great tool. Doing this you can see if your actually using the right interface or if the application is even requesting the traffic to be routed by your OS.

When debugging a networking issue it can be invaluable to see your linux servers current routes to get an idea of what’s going on, also you can view the number of hits these routes have recently gotten, just look in the use column of the output table.

route -neeC

You should see something like the following output:

root@:/# route -neeC
Kernel IP routing cache
Source          Destination     Gateway         Flags Metric Ref    Use Iface    MSS   Window irtt  TOS HHRef HHUptod     SpecDst             0      0        2 venet0   1500  0      800   0   -1    0    l     0      0       23 lo       0     0      0     0   -1    0             0      0        1 venet0   1500  0      875   0   -1    0    l     0      0       23 lo       0     0      0     0   -1    0             0      0        1 venet0   1500  0      735   0   -1    0

From the above we can see some very interesting stats such as the interface used, source and destination IP’s, metric, number of ‘uses’ and even the interface MTU


Apologies I haven’t posted in a while, I am actually planning on setting a minimum of 4 posts a week so there is always some fresh content on here.

The good news is I haven’t just been sitting around doing nothing (some of the time), so there are some quite big updates for the project site – Go there to have a play around, please leave any comments about it on this post


The New Look for


Almost every day at work I see people horizontally scaling their infrastructure to support their applications, such as adding CPU, Memory, HDD even whole servers. For the hosting company this is generally great news, as there is an increase in revenue per client.

However about 9 out of 10 times this is not actually required as generally there are some clear coding optimizations that would reduce load on the servers, and therefore remove the need for scaling out the infrastructure. Usually the issue is that your coders don’t really communicate that well with the hardware guys or don’t understand the implications of their coding structure. Hopefully this will make you more aware and therefore build more optimized and scalable applications.

1. Redundant Variables

This is probably one of the most common issues that I see in coding, generally you have some output returned from a function and the coder instantly creates a new variable to contain this information which is then processed straight away. See the example here:

$SomeVar = Function('hi');

The faster and better way:


The most common reason for this is coders claiming that they might need to recall the output later in their code, and returning from the variable should be faster than running the function again. Yes this is a valid point some times, however you should never put it in because you might need it, leave it out and come back to add it if you do. Basically your probably just going to be wasting the servers memory, remember every little helps. Continue reading “5 ways to speed up your PHP code” »

Our Sponsors