Sunday 22 December 2019

Democratization of truth

America elected Trump. The UK elected a prime minister who had already been tried by the courts and found guilty of an abuse of power. Both election campaigns seem to have involved a great deal of "fake news" (attributed, amongst others, to foreign states).

This week (among other excitement) I've been working on an infrastructure plan for a target architecture which will also allow progressive migration of legacy systems. Actually, this is taking a bit longer than a week, but the question of shared file access has bubbled up to the top of my list. I'd like to think I've learned a few things over the years, but I always like to check my facts - and to check if there are new facts to be discovered. So I hit the search engines, starting off with a comparison of NFS and SMB.

The first page of results searching for "NFS vs SMB in the datacentre" in both Google and DuckDuckgo was pitiful. Biased and misinformed blog postings and marketing SEO spam. I spent a very long time trudging through misinformation and idiot guides before realizing that the internet, formerly the definitive source for technology guides and (informed) opinions was a mere shadow of its former self. While most institutions dwindle due to under-subscription, it is the exact opposite which has harmed the internet's utility to me. I don't think the Kremlin is behind this, indeed I think the poor quality information is mostly published with good intentions, but I wish Google and Duckduckgo provided the a facility where I could easily feedback on the quality of articles they index.

It seemed like a more productive use of my time might be to record what I already know about the protocols rather than try to find out something new.

So, for the record....SMB was not invented by Microsoft. They did develop the technology. CIFS is also based on the same technology but forked the protocol to implement support for POSIX hard/symbolic links and large files. This was then added to the SMB 2.0 specification.

Both exist in multiple iterations. Both are intended for file sharing, but SMB also supports a lot of other network oriented operations.

The key differences between (most) NFS and SMB installations are that the former uses UDP while the latter uses TCP with in-band authentication and session handling. This has a lot of impact on data transfer speeds - a LAN, the internet and a datacentre are each very different network environments - so benchmarks from one will be misleading in another.

NFS doesn't (normally) use passwords on encryption - it is based on trust between the existing devices. Enforcing authentication for every operation makes implementing some security models easier.

But a flip side of this, is that once an SMB connection is lost (i.e. if the client, the server, or the network in between fail at any point) it is upt to the client to renegotiate the connection. Although that technology exists within smbmount (used on Linux and other POSIX systems) it is not the most reliable.

OTOH the intrinsic authentication but absence of network-based user identifiers means that it is a lot simpler to align client users with the permissions on the files in the remote filesystem of SMB than NFS. Until NFSv4 it was not enough to have the same user configured on multiple machines - to get the same access they needed to have same (numerical) user id.

I'm not going to tell you that one is better than the other, because, despite trying to fulfill the same goal of providing shared access to remote files, they are different.

Thursday 10 October 2019

Installing the new Fortinet VPN client on MS-Windows

After the last round of MS-Windows updates, running Fortinet's VPN client on my work laptop (MS-Windows) resulted a BSOD. So I downloaded the new client from Fortinet - round about 1Mb and it didn't take too long. But then I discovered that the thing I had downloaded was not the client, but a downloader to download the client.

This took rather a long time to do its job (on a 200Mb internet link). Meanwhile I:

  • Found a spare Linux host,
  • ran an OS update/upgrade
  • installed openfortivpn
  • configured this for first time round
  • discovered the remote end does not use a trusted certificate
  • reconfigured vpn
  • discovered the remote end is publishing routes which trash the local routing configured
  • rebooted the server ( I was connecting over ssh)
  • made myself a coffee
  • RTFM
  • Went for lunch
  • Came back and discovered the download had finished
  • Installed the new version of the MS-Windows client
  • Discovered that 
  •   1) it had overwritten the old client
  •   2) that it would not connect - turns out to be a *different* VPN client from what I had before
  • Started downloading something else from Fortinet (as advised by colleague)
  • Worked out how to manually set up the routes on Linux and got a working connection
  • Finished the task for which I wanted a VPN connection
  • Startup the new client and found it was the same as the one I had installed earlier