Till's blog

In order to connect to firewall and DRACs of our new Rackspace cluster, I had to setup a VPN connection. Rackspace gave us a Cisco ASA device which is firewall and vpn in one. In order to connect to the VPN the client needs to do 2-factor authentication.

At first I tried to install the necessary add-ons for Ubuntu's network-manager, but after I spent an hour or so trying to make it work, I took an alternate route.

Requirements

Here's all you need to get started:

$ sudo aptitude install vpnc
...

Configuration

Create a configuration file — I called mine rackspace.conf:

$ gksudo gedit /etc/vpnc/rackspace.conf

I put in the following:

IPSec gateway X.X.X.X
IPSec ID GROUPNAME
IPSec secret GROUPPASSWORD
Xauth username USERNAME
Xauth password PASSWORD

Obviously, the capitalized values need to be replaced:

• IPSec gateway: the VPN's gateway/address
• IPSec ID: the group's name
• IPSec secret: the group's password
• Xauth username: the username
• Xauth password: the password associated with the username

If you're with Rackspace, they'll tell you those exact things when the firewall is provisioned. I gather other ISPs call them similar.

Using your VPN

Once the file is saved, just start the vpn connection:

$ sudo vpnc rackspace
VPNC started in background (pid: 2691)...

Note: Just rackspace is plenty, not rackspace.conf or similar.

Testing:

$ ping 172.30.0.144
PING 172.30.0.144 (172.30.0.144) 56(84) bytes of data.
64 bytes from 172.30.0.144: icmp_seq=1 ttl=64 time=114 ms
64 bytes from 172.30.0.144: icmp_seq=2 ttl=64 time=113 ms
64 bytes from 172.30.0.144: icmp_seq=3 ttl=64 time=113 ms
^C
--- 172.30.0.144 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 113.766/114.199/114.866/0.552 ms

To disconnect it:

$ sudo vpnc-disconnect 
Terminating vpnc daemon (pid: 2691)

Fin

That's all.

Some people have this misconception that there is a plot to kill of the original mysql extension (aka ext/mysql) in PHP.

So first off, I know that bloggers are not journalist. So apprently fact-checking is not required for a rant blog post. ;-) But if a blog post is a rant, it should be labeled as such.

Improved

ext/mysqli (hint: "i" as in improved) has been the goto extension for years. If anyone writes code in 2011 which uses ext/mysql, then they should be fired or demoted to trainee. MySQL's 4.1.3 beta was released in 2004 and ever since its release, it's been "strongly" suggested to use ext/mysqli.

PHP's fault in this case is that it didn't drop ext/mysql sooner.

Legacy code

The problem with legacy code is that it's usually not a legacy with the good meaning of the word.

It's indeed a legacy of the past which often exhibits all things that can go wrong on a PHP project.

In a situation where a project requires an older version of PHP to run, there are two kind of improvements developers (and essentially the companies employing them) miss out on: active and passive.

Passive improvements

… generally happen and don't require anyone to re-write any code, examples include:

• PHP's runtime became more efficient
• improvements such as garbage collection
• most importantly: bugs were fixed

Active improvements

… may require updates to the code base — they mostly include new features (e.g. through a new extension) or extensions of the language itself — namespaces, traits, etc..

Ecosystem

In addition to missing out on the improvements of the language another major problem is that since the code base requires an out-dated (maybe vulnerable) version of PHP to run, companies are often stuck in an entirely outdated ecosystem.

From top to bottom: it starts from the OS (Security updates?) — Linux, but also includes the services you run — MySQL and Apache. But there you go, the entire LAMP stack is fubar'd.

Anyone could argue that it's possible to e.g. run PHP4 on a recent Linux with semi-recent components, but let alone compiling PHP and/or backporting patches for security issues and crucial bugfixes don't make maintainance exactly trivial.