Saturday, 16 May 2020

Microsoft - unsafe at any OS

At $WORK we are trying to move from a traditional model of software development and deployment to agile methods. They were already well down the road of using Microsoft DevOps when I joined the party.
This week I was working on setting up the deployment targets. This uses a Microsoft supplied agent running on the target machine which has a constant connection out to Microsoft Azure pipelines.That avoids the whole issue of firewalls, but that is where the thinking ended.

As you would expect, there a massive feature set in the tool chain - with lots of integration. And most of it actually seems to work! But my experience with Microsoft products is that most of the big issues arise in the things that are generally lumped together under the "non-functional requirements".

The installation takes around half a gigabyte. I've seen smaller, full-featured Linux distributions. That might be because it contains a whole lot of DLL files. DLL? On Linux? Is this a dual Linux and MS-Windows installation? Or have they implemented their own runtime linker?

The daemon part is node.js  - That's good. Its a sensible bit of software, although a bit heavy for microservice containers. And there is a large bundle of Javascript files.

But according to the github page,It is "Written for .NET Core in C#."

But the elephant in the room is that it runs as root.

There's absolutely no requirement for this to run as root.

It is just a huge security risk. The Devops user does not control permissions, the system administrator does not control permissions, Microsoft control permissions.

Monday, 11 May 2020

Loving nginx - but still loving apache

I am now running nginx on my production servers.

Having written a book which features the Apache webserver heavily, a lot of people seem surprised when I tell them I am migrating my work environments onto nginx.

Of course the truth is not nearly as black and white as one product always being better than another; nginx is simply a better fit for what I, and the organization I work for need for the foreseeable future. I believe and practice the philosophy of strong opinions weakly held

We are constrained by computing resource. A lot of this arises from bad choices made by the previous admin and lack of governance. There is no way to sugar-coat or justify the practices which were the norm for a very long time. One of several undesirable outcomes is that the systems are not nearly as efficient as they should be. I still believe you can do more with Apache, but that comes at a slightly higher cost in terms of CPU and memory. Certainly if you don't track what resources are assigned for what purpose, you will never achieve any operational efficiency, regardless what tech you use.

Another major consideration is the availability of skills. I am not the only systems admin in the company, I would rather the systems were maintained by people with strong skills in one product than a competency in lots. Maybe one day tech will be as simple as the sales guy like to pretend, but it looks to me that skills will continue to trump tech for a very long time. But the choice of product does have an impact. While Apache can be used as a forward or reverse proxy, this is not its metier - if I had decided to run Apache httpd as the origin webserver I would have been looking at Apache Traffic Server, nginx or even pound at the front end. Being able to use the same product in both places means less cognitive load.

Nginx (along with haproxy for client side and non-HTTP traffic) provides a powerful toolset for distributing traffic around your infrastructure.

If I'm being completely honest, nginx's lack of functionality also looks like a benefit. The Apache config files for the legacy servers were humungous. And more than half of what they contained should never have been there in the first place: thousands of redirect rules for content which had moved, retired or simply put in the wrong place to begin with. Different ssl configurations for every browser released in the last 20 years. Servers writing the same request to four different log files in different formats which nobody ever read. Despite all this config, it was alarming what was missing - no content caching, no keepalives, no process limits!

That's not to say nginx is easy or minimal in its capabilities. With a syntax which looks very much like C or PHP: blocks bounded with curly brackets: statements ending in semi colons: it is easy to assume that the syntax is procedural. That is not the case. It is, as one would expect without looking at the syntax, declarative. Failing to understand this can lead to problems and frustration.

Another misdirection arising from the syntax is an assumption that the hierarchy of the configuration is merely structural - again not true. Many of the directives are very contextual.

But I do miss Apache's server-status page. Running php-fpm means you still need to worry about concurrent connections but nginx's server status metrics don't show the number of back end connections / where they are connected. Creeping up my todo list is to write something to present useful information about these connections and other metrics on the servers.