Ronny Lam


Applying Spigen GLAS.tR Slim

Last week I finally upgraded my old iPhone 3Gs to a brand new 5S. The first thing I wanted is protect the phone a bit but still keeping the great original look and feel. My eye fell on the Spigen GLAS.tR which is effectivally a gorilla glass on top of the original gorilla glass. Why would you do that? Because gorilla glass is still not entirely unscratchable and when it scratches it weakens the glass.

The GLAS.tR arrived when I was in two days of very intensive meetings. When I finally arrived at my colleagues house for a short night I did not take enough time and patience to apply the glass, but of course I still tried. All went well, but just like the enclosed warning I got all kinds of dust particles in between. That’s when I started abusing the silicon layer in between to try and get it clean, but of course I failed and gave up on the glass.

Two days later, with a lot more patience I took the glass again and started cleaning it under cold water with a little soap. The silicon layer could handle it well. To dry the glass I used a hairdryer, because I didn’t want to touch the silicon again. But after applying it I saw some lime and still a dust particle in between. I took it off again and applied scotch tape on the silicon to clean it from rest particles. Cleaned the iPhone again and peeled the tape off right before applying. The GLAS.tR is attached to the iPhone like it was still new.

My conclusion is that the GLAS.tR can handle a lot, even my abuse of cleaning the silicon with a cloth. When using water and scotch tape the glass can applied like new, without wearing off the adhesive effect of the silicon. If you want to see how the GLAS.tR can be abused from the outside, just search for it at YouTube and you will understand why I chose it.

Protect SSH With Two-Factor Authentication

I finally took some time to secure my internet facing systems a bit more, which are currently all Raspberry Pi’s by the way. Since I have been working with the Google authenticator app on iOS for a while now it was a logical decision to also apply that to my “servers”. I was delighted to see that the first hit when searching for “ssh 2 factor” was indeed the Google PAM-module.

Configuring the systems was a breeze with the result that now my internet facing systems are protected by something I know (my password) and something I have (my phone).

I would like to encourage everyone to enable such a system whenever possible. Currently lots of systems like Google, Dropbox, Twitter, Amazon AWS and others have implemented 2 factor authentication. It is still up to the user to use it.

One warning though. With the above mentioned systems it is impossible to reuse the shared secret (file). With the Linux-PAM setup you can, but I really advise against it. If scalability is becoming an issue you might consider TOTP-cgi which shares secrets AND state of the secret accross systems, so that a hacker cannot reuse a key more than once.

The State of SDN

Besides yesterdays definition the SDNcentral presentation also holds the current state of SDN:

Similar to the typical enterprise or service provider software market, SDN currently requires a lot of experimentation and customization.

I talk to a lot of engineers and decision makers in both of those markets and none of them is experimenting with SDN. They try to follow it and put it on their future roadmap. Besides myself the only people I know personally that have been experimenting with SDN are scientists.

Should we therefore ignore it? Certainly not, networking has not changed for the last 15 years and is currently at a tipping point. However, it is still uncertain where it will be tipping towards. If you ask me, SDN has a future, but overall standardisation is still needed. Not only on the protocol side, but also on the interface side.

I’d love to close with how you could start with SDN:

  1. Learn and read-up as much as you can on SDN;
  2. understand your own networking problems to identify a business use-case where SDN can bring value;
  3. work with the SDN-community, trusted vendors and advisors to design a Proof of Concept (PoC);
  4. use what you learn from PoC to determine appropriate next steps.

So yeah, this is the state of SDN. Still fragmented and experimental, but with a lot of promise.

The Definition of SDN

Yesterday I read a great post by Ivan Pepelnjak:

As I’ve been thinking about controllers, central visibility and network device programmability, it struck me: we already had SDN in 1993 … and didn’t know it.

This resulted in a couple of tweets back and forth in which I also claimed that the definition of SDN is still unclear and that every vendor is skewing it to their own use. Today, SDNCentral published a presentation on Slideshare about the primer of SDN. It contains a definition which uses the same words as Ivan is using:


  1. Separates the network’s control and forwarding planes;
  2. provides a centralized view of the overall network;
  3. utilizes programmatic application interfaces (API’s);
  4. enables efficient orchestration and automation of network services.

I expect these to be AND operators and not OR, but there are still vendors that miss one or two items.

I like that the presentation is including some of the predecessors of SDN, including Ivan’s example. Tomorrow I’ll write about the status of SDN.

Linux Desktop in the Enterprise: Ubuntu vs. Windows

This post on NetworkComputing intreaged me. The time has finally come that Linux is a viable alternative to Windows on the desktop. In my opinion not only because the (Ubuntu) Linux desktop has been improved over the last couple of years, but also because of Windows getting worse. The differences are not that big anymore; people with Windows experience can find their way on the Ubuntu desktop.

About two years ago I installed Ubuntu on a friend’s laptop. Just because I denied to support Windows environments and the person really wanted/needed my support. A couple of weeks ago this same person bought a new laptop and really tried to master Windows 8 on the thing. In the end he asked me to install Ubuntu on it again. Not only because of my support, but mostly because he couldn’t find his way in Windows 8.

The most annoying thing in the article is:

Companies under stringent compliance requirements may have difficulties switching over to Linux. For example, HIPAA requires encryption that meets FIPS-140-2 requirements.

But if more and more enterprises and government(agencie)s are moving towards Linux this too will be solved.

Bye bye Windows.

LinkedIn Setting the Record Straight on False Accusations

As you may have read recently, a class action lawsuit was filed against LinkedIn last week. The lawsuit alleges that we “break into” the email accounts of our members who choose to upload their email address books to LinkedIn. Quite simply, this is not true.

First of all, let me state that I do believe LinkedIn here. They would have a very big problem if proof exists that they do indeed use the credentials of their members to access their email.

However, this is all based on a lot of trust that these same member give LinkedIn. I have never understood why anyone would give away their email credentials in order to let LinkedIn access their contacts. Especially since there is one very good and one less good alternative.

With most email providers you can export your contact to a .csv or .vcf file. Within LinkedIn you have the ability to upload this file so that LinkedIn can try to connect you to your email contacts. Even the fact that you upload your full contact database concerns me, but that is beside this point. I would clean up this file so that only the needed information is in there: email addresses.

The second option is to put a temporary password on your email when you connect it with LinkedIn. After the contacts transfer you switch it (back) to your private password.

In this day and age it is never a good idea to give away user credentials. A password is personal and has to be kept secret. There are lots of alternatives which do not give away credentials. Also when giving away permissions using OAuth(2) for example, alway look if the company asking for permissions is not asking for too much.

So, the fact that there is a class action lawsuit against is LinkedIn is a good thing if you ask me. Even when they do not abuse your credentials, they should never ask for them.

Juniper Does Not Understand BYOD

I love the J-net blogs at Juniper, with most of the time interesting content especially when it comes to security. And I have to agree that Buy Your Own Device (BYOD) is a big security concern for a lot of companies. There is always the tension between security and usability, but the author of this blog is taking it a bit too far. At first I get the feeling that he is getting it right from the user perspective:

How is it that MY device (the Y in BYOD) needs to run YOUR client to access Virtual Desktop Infrastructure (VDI) resources? With YOUR software, MY device is no longer truly MINE. I have to mess it up to accommodate YOUR crummy software.

But then the rest of the writing is only about VDI:

Our customers can now securely connect to protected VDI desktops and applications - not just from Windows and Mac computers, but also from locked down PCs, Chromebooks, iPad/iPhones, Android devices, RIM/BlackBerry/Playbooks, etc.

Just forget to do VDI-like things on a tablet or a phone. The device is, or better the Desktop is, not built to be operated by big fingers. That user experience is awful. But this seems to be the meme at Juniper today. For safe use of Office resources with BYOD you need to have galvanic separation and that can only be reach by VDI, according to Juniper.

This meme needs to change, because these tablets and phones are a fact of life these days and their count is growing faster than desktops or laptops. So BYOD needs better integration with touch-devices. But I am the first to agree that that is a challenge on it’s own.

About Diets and Fasting

Yesterday I read a post on the blog of Tim Ferris about a food experiment with Soylent:

I was struck by how much easier it was to stick to a diet as simple as Soylent versus any other diet I’ve tried. As they say, it’s easier to be 100% obedient to a diet than 99%.

Hours later I was listening to a podcast of Tony Robbins, where I heard almost the same phrase:

It’s much easier to fast than it is to be on a diet.

For me, the same applies to blogging. For the last year, until the holidays, I have been blogging daily. If I compare that to fasting the structure is clear and it is easy to discipline myself: blog everyday!

But if you compare that to being on a diet, the diet leaves room for discussion. For example, if I want to write twice a week I can still prolong a couple of days, until there is no post in the end.

True, I haven’t set goals like these for the last couple of weeks. And if you don’t set goals, you don’t reserve the time and don’t make it a priority. For this reason, and I knew that already when my challenge ended, I will be blogging daily again. Starting today!

Holiday Is Over: SDN Myths

Holiday is over. This time I chose to mention that after the holiday instead of before, because of known social media risks. Holiday also gave me some time to think about what is really going on in the networking world. This linked blog pretty much sums that up.

SDN in all its myriad visions, and as evangelized by all of its newly christened champions, is fascinating, eminently useful on some levels, and maddeningly silly in others. At the end of the day, however, it’s critical that we don’t get so involved in the excitement, promise, and religious fervor of new technology that we lose sight of what is real, what is useful, and what is “marketecture”.

SDN is for real, but the term is indeed not very useful. I have always compared it to the hype of “the cloud”; we have some real useful cloud solutions these days, but the term cloud has never been very clear. Some propose to define SDN as “programmatic networking” which defines the current movement a bit better but is still not very accurate.

One major term connected to SDN is automation. Part of this automation is the ability to implement standardized changes into the network with the added advantage of mitigating change risks. But this is not solely about SDN. Automation is a process, embedded in a culture, a cultures that is even not necessarily defined as DevOps. SDN possible makes automation easier, but today’s networks can already be automated.

SDN is not disruptive nor is it lowering cost. It certainly has the possibility to lower cost but the reality is that SDN will be an evolution and not a revolution. I am talking to some large scale enterprises and service providers and neither of them are thinking of implementing SDN in the next two years. Some of them are playing in the lab though.

This holiday certainly made me more aware that this SDN thing is a hype, with some nice possibilities. That is not to say that the processes and the culture are not changing. DevOps and automation surely made it to the agenda this year, so even if the technology is not changing, yet, the mindset certainly is.

Bye Bye Feedburner, Hello Feedpress

My expectation is that, after Reader and Latitude, Feedburner will be the next in line to be killed. Development has clearly been stopped in 2010 and the blog quit early 2012. It’s amazing that the service still exists today.

Google has clearly given up on RSS. Or let me rephrase that, they favor their own Google+ platform over RSS. Although I doubt if that platform is as successful as Google claims.

To not wait for the Feedburner killing, and get a ton of extra options, I switched today to Feedpress. They have a nice feature called white labeling, although in hindsight I could have done that partly with Feedburner also. The trick is that you let subscribers subscribe to your own feed and not to the feeders feed. That way, when you want to move out you always take your subscribers with you.

My feed will always be at and I will redirect you from there, so be warned when you are suscribed to my Feedburner feed. It is still redirecting, but that won’t last for long.