The Crisis in the Software Industry

To be fair I have not seen this at any one company. I have seen it at every company I have worked for. And as a software developer with 20+ years experience I can also say, in my more immature days, I was guilty of the same sin.

What is that problem that I observe?

Just the arrogant self absorbed know-it-all behavior of  software development shops. Sure, some may be nice people. Some even care.

However I have a slightly different perspective. I have this perspective because I have been within development teams and outside development teams. I was known as the software developer/architect that talked to QC. Talked to support. The response I received from these teams that this was rare behavior.

My observations of development teams are as follows:

1. Do not consult, even if others outside development may have more experience on the technical issues they are working on.
2. Get easily impressed by "cool" technology. Nay, they are a slave to it.
3. Only address problems in how that cool technology can solve it.
4. Are easily impressed by technology that they think the "cool" kids are using.
5. Cannot address the core problem or use case. Unless it is in terms of that cool technology.
6. Cannot address problems with humility and respect. Are treated like unicorns and as such behave like unicorns.
7. Some even have a know-it-all behavior to the point of absurdity - such as the time a colleague announced that HE was a breast feed expert. (His wife was expecting and he read a book on it).

The end result of these issues is a product that has security (amongst other) flaws. By design. Combined with a FISI (F*ck it ship it) management methodology you can understand why shipped or cloud based software is garbage that customers end up becoming the quality testers.

Logging and the haproxy docker container

So you have configured and built and/or run your configuration file in the haproxy image as per https://hub.docker.com/_/haproxy/.

To repeat the steps are :

1. Create a haproxy.cfg file in a local directory
2. Create a Dockerfile in same directory containing

FROM haproxy:1.5
COPY haproxy.cfg /usr/local/etc/haproxy/haproxy.cfg

3. Build image with  above docker file using

docker build -t myhaproxy .

4. Check that your image with your configuration is in your image list using

docker images

5. Run your docker image....

docker run -d --name my-running-haproxy my-haproxy

Note that you could also mount the volume with the configuration.

But once its running how do you know what the problem is if something goes wrong? How do you access the logs?

Haproxy logs to syslog, so we would need to build our own version of haproxy with a underlying system with syslog configuration changes.

Or we could do this:


1. Change the configuration in haproxy.cfg to log to /dev/log and rebuild your image.

global

log /dev/log local2

2. When we run our haproxy run with -v /dev/log:/dev/log like this:

docker run -d --name my-running-haproxy -v /dev/log:/dev/log my-haproxy

3. See what is happening in your "host" syslog (/var/log/syslog)

References:
1. https://hub.docker.com/_/haproxy/
2. https://github.com/dockerfile/haproxy/issues/3

TightVNC Client, SSH, TightVNC Server

I have to make some notes on this before I forget. This post attempts to be that note.

Perhaps you have a Virtual Private Server (VPS) or just a server out there somewhere in the ether. You want to share or view a remote desktop, but you want a secure tunnel for those bits to travel down. In this scenario your server is a linux (some variant, lets not start a religious war about it) and you installed tightvncserver. In addition you have SSH running. On your client, lets say windows, you have putty and tightvncserver.

For those with OCD here is a recap:

Server:
1. TightVNCServer.
2. SSH

Client:
3. Putty
4. TightVNC Viewer.

The only note I will make about tightvncserver is that you should have it only listen on loopback (127.0.0.1) since this typically is not a service you want exposed. We use '-nolisten tcp' to ensure we do not allow external tcp connections outside of our SSH tunnel.

In /etc/init.d/tightvncserver you would have a start line such as:

su $USER -c '/usr/bin/tightvncserver -nolisten tcp -localhost :1'

On the client follow the instructions at: http://www.penguintutor.com/linux/tightvnc

In a nutshell, you: 

1. In Putty create a session  with a hostname (or IP) and port of the SSH service running on your remote linux box.
2. Select Connection->SSH->Tunnels and enter source port 5901 and destination of localhost:5901
3. Back to session selection in the left pane and type a name for saved sessions and click save.
4. Then Click open for the session and a SSH window to your target should open where you can login.
5. Once logged in there is now a tunnel in place.
6. Run TightVNCViewer and connect to 'localhost:1'