For years we’ve used bash scripting to ensure that all of our server configurations are standardized, so that we can expect servers with the same role to have the exact same configuration profile and exhibit the exact same behavior. We’re in the process of moving to Puppet but we’re not quite there yet. Recently we decided to redesign our network architecture with a higher level of focus around High Availability. This new design introduces Percona XtraDB Cluster and we’re writing our installation and configuration scripts to ensure that our new cluster boxes are both tuned and standardized.

We have base template linux VM’s in both VMWare and Oracle VirtualBox, and also templates that are specific to server roles such as web servers, HAproxy servers or MySQL Cluster servers. If we need to test a new configuration, or add a new node to the cluster, we just clone the appropriate template add some minor configuration and we’re good.

However if you clone a VMWare or Oracle VirtualBox VM, you’ll notice that it kills your network interfaces throwing errors like the one listed below:

#ifup eth0

Device eth0 does not seem to be present, delaying initialisation

What’s happening here is that when you clone your VM, VirtualBox and VMWare apply a new MAC Address to your network interfaces but they don’t update the linux configuration files to mirror these changes and so the kernel doesn’t firstly can’t find or start the interface that matches it’s configuration (with the old MAC Address) and it finds a new interface (the new MAC Address) that it has no configuration information for. The result is that only your networking service can only start the loopback networking interface and eth0 is dead.

So here’s how we fix it:

Remove the kernel’s networking interface rules file so that it can be regenerated

# rm -f /etc/udev/rules.d/70-persistent-net.rules

Restart the VM

# reboot

UPDATE your interface configuration file

# vim /etc/sysconfig/networking/devices/ifcfg-eth0

Remove the MACADDR entry or update it to the new MACADDR for the interface (listed in this file: /etc/udev/rules.d/70-persistent-net.rules).

2011 was meant to be “the year of NFC” so was 2012 and 2013.
However, it seems that earlier this year NFC ran out of steam as far as “mind share” is concerned.

When Google Wallet decided to drop support for loyalty cards — one of the key components of any m-wallet (and one of the core functions of ISIS wallet, via SmartTap) — it became clear that Google lost its interest in NFC and started looking at the alternatives: Google bought Bump – the technology that enables P2P interaction via accelerometers and cloud; Google finally opened up Android to BLE (Bluetooth Low Energy – aka Bluetooth Smart).

Apple didn’t include NFC in their latest iPhone models. Again, instead, Apple is currently betting heavily on BLE technology.

Tons of smartwatches are coming out soon, all with BLE, and potentially payment applications. Only a few smartwatches are expected to include passive contactless interfaces.

Projections for NFC-enabled phones vary widely (and are being revised downwards by most analysts) at the same time, almost every new smartphone model out there has BLE.

BLE, BLE, BLE… Does all that mean the end of NFC (in retail)? Well, that depends…

Before we get too excited about BLE, let’s consider the following. One of the key problems of NFC is lack of infrastructure in retail. Guess what: BLE infrastructure is… zero. Moreover, such forthcoming solutions as PayPal Beacon are not simple “plug and play” you still need some “add-on” to identify the customer who wants to make the payment, among the dozen of others in the BLE range. That’s where NFC seems to actually shine.

NFC is great for instant ad hoc proximity-based “peer to peer” communication.
Other alternatives come nowhere near in that respect. (For now…) There are many areas where NFC is a star: transit, access control, authentication, device pairing, device configuration.

So, what could make it or break it for NFC? EMV push in the US will lead to further gradual introduction of NFC payment terminals. NFC will come of age, but don’t expect miracles it could be too little too late.

On the other hand, if several major players unite to push (a) open, (b) low-cost (think $10-20), and (c) true “plug-n-play” alternative to NFC, based on BLE, that could seriously tip the scales and much faster than anyone can imagine.