nmon on your headless Proxmox server

Proxmox is great and after it is up and running you can control it from the web page or ssh in, so what do you do with the monitor connected to it. Here is a one-line command to get nmon to show you what the server is doing.

I set my script up in cron so it always comes up, also nmon will not refresh the entire screen so cron can also kill the old nmon and start a new one.

I called this headless because you don't need to login to have this work. The pgrep command finds the getty that has the login prompt.

( sleep 2; 
export NMON=cmVdn; 
export TERM=xterm-color; 
export NCURSES_NO_UTF8_ACS=1; 
nmon > /proc/$(pgrep -f agetty)/fd/1 ) &

And this is what it looks like.

The Perl Negative Modulus Bug

This is a bug that has been in Perl for all the years I have used it. There is a workaround, but I choose to avoid using Perl for anything beyond simple math.

The bug only shows when you try to calculate the modulus of negative values.

#!/usr/bin/perl

$A = 106;
printf("Division\n");
printf("106 / 10 = 10\t<- expected\n");
printf("%d / 10 = %01d\t<- correct\n", $A, $A / 10);

printf("\n");
printf("Modulus\n");
printf("106 %% 10 = 6\t<- expected\n");
printf("%d %% 10 = %d\t<- correct\n", $A,  $A % 10);

printf("\n\nNegative values\n");

$A = -106;
printf("Division\n");
printf("%d / 10 = 10\t<- expected\n", $A);
printf("%d / 10 = %01d\t<- correct\n", $A, $A / 10);

printf("\n");
printf("Modulus\n");
printf("%d %% 10 = -6\t<- expected\n", $A);
printf("%d %% 10 = %d\t<- WHAT THE!!!\n", $A,  $A % 10);

This is the output.

Division
106 / 10 = 10 <- expected
106 / 10 = 10 <- correct

Modulus
106 % 10 = 6 <- expected
106 % 10 = 6 <- correct


Negative values
Divsion
-106 / 10 = 10 <- expected
-106 / 10 = -10 <- correct

Modulus
-106 % 10 = -6 <- expected
-106 % 10 = 4 <- WHAT THE!!!

Simple Docker Example

This is a continuation of the Ultra minimal docker Node.JS example.

The code can be downloaded from GitLab.com

This is a very simple example of Docker running a simple NodeJS app.

Things to know. Containers are not VMs, they are more like a root jail. They use the host OS kernel and processes running in the container are visible to the host OS. Docker is just one of many ways to use containers. Proxmox is another, and it can also run VMs.

This example requires a Linux system with Docker installed. Installing Docker for Debian Installing Docker for CentOS

For more information see this cheat sheet.

Almost all of these steps require permission to execute privileged commands. In a production environment, a special group would be created with permissions to run these commands. If you are new to Linux the sudo command is commonly used to run commands as the root administrator, just prefix the commands with sudo. It is recommended that you practice this on a test system.

Image Files

Image files are a collection of Linux OS files needed to run in a container. They contain a directory tree like /bin/, /lib/, /usr/, /var/ and others, everything needed to run the required programs.

One popular image is BusyBox were hundreds of Linux programs such as ls, grep, find, cat are all just one binary program. This makes the image very small.

This sample project uses alpine-node, a small image with a functional NodeJS.

Building A Simple Project

Three files are included with this project.

service.js

This is a simple JavaScript to be run by NodeJS

package.json

This file tells NodeJS about the code to run.

It tells NodeJS:

• the name of the script to start
• dependencies that are needed
• how to start the script

Dockerfile

This tells Docker how to build an image that contains your project.

It tells Docker

• what image to source the build from, this one uses mhart/alpine-node
• where to install code files

The source image mhart/alpine-node is a very small Linux that includes a NodeJS service.

Building Images

On a Linux system where you have a running Docker, change to the working code directory where the Dockerfile is, then build a new image.

docker build -t <new image title> .

This will copy the mhart/alpine-node image and add the project code to it as instructed by the contents of the Dockerfile.

If your docker does not have the mhart/alpine-node image yet, the build will automatically download it. This may take extra time but after it has been downloaded, future builds will be much faster.

Running Containers

Once the image is built, it is just an image. It is not yet an instance of a container, for that it needs to be run. The container is created and initialized when it is first run.

Then run a container with this new image, this will create a new container.

docker run -d -p 3000:3000 <new image title>

The -p 3000:3000 will publish the service at port 3000 inside the container on the host OS.

The -d sets the container to run detached so it will fork to the background.

Monitoring

At this point, the docker service is running and should respond to web requests.

Open a browser to the IP address of the Linux host OS at port 3000

http://<linux>:3000

The node process can be seen running in the host OS.

From your host Linux system, run these commands.

ps -ef | grep node

netstat -naptu |grep 3000.*LISTEN

List the status of running containers

docker ps 
docker container ls

List the status of all containers.

docker ps -a
docker container ls -a

Status

Get a top like status of the running containers.

docker stats

To just get a one time report of stats.

docker stats --no-stream

Stopping Containers

Containers must be stopped before they can be deleted.

docker stop <container ID>

Re-Starting Containers

Once a container has been ran, it has been initialized and can be restarted.

docker start <container ID>

Deleting Containers

List the containers, use -a all to see the ones that are not running.

docker container ls -a

Containers must be deleted before the associated image can be deleted.

docker rm <container ID>

Deleting Images

First, list the images.

docker image ls

Then use the image name or ID to delete it.

docker rmi <image name or ID>

Get your data together!

Analyzing logs is fun, kind of like how going to the dentists is fun. You stair at lon-n-n-n-g pages of data and your brain goes numb from the overwhelming amount of information.

GBT is a Perl script that can condense and extract meaningful information from time-indexed logs and numbers. GBT is Group-By-Time and rather than have sporadic bursts of data separated by black holes of emptiness, GBT produces a consistent flow of data that is easily graphable 

GBT by default will condense data into ten minute blocks of maximum values for each column given. The size of the time block can be changed using the -t argument. The output data format can be changed to provide min, max, mean, sum, delta or count. 

The main use for GBT is to pipe data into GNU Plot to produce graphs.

GBT hosted on GitLab.com

Here is the gnuplot PNG created from the sample data.

Ooooh that shell, Can't you shell that shell

Staying up late to work on a fun project. Building a custom PXE boot image that will be used to pre-load our servers and get them ready for Puppet management. It has been about eight years since I had built a custom boot image. At that time busybox was my goto for small, powerful environments that needed to run from very small RAM mounted file systems.

BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides replacements for most of the utilities you usually find in GNU fileutils, shellutils, etc. The utilities in BusyBox generally have fewer options than their full-featured GNU cousins; however, the options that are included provide the expected functionality and behave very much like their GNU counterparts. BusyBox provides a fairly complete environment for any small or embedded system.

When most distros offer boot images that do little more than boot, or fail to boot; for my systems I used busybox to create a very compact environment that would allow you to perform diagnostics and fix any problems.

As great as busybox was at the time, I found it lacked a lot of compatibilities with even old POSIX systems and scripts. Arguments that you rely on for find, grep and even ls, just were not there. Things have changed; somewhat. Busybox has grown up and is full of new abilities.

Screenshot of "make menuconf" providing the ability
to choose the features to build into the binary.