Building a Container Image

Containers are incredibly useful, even when just running images built by others. However you can make your own container image as your custom solution for anything you like. The key element is to write your own Dockerfile. As an example I will write a Dockerfile to run a Minecraft server below. As you’ll see, this can all be accomplished in very few lines of code.

Base Image: Alpine Linux

Container images need to be built on a base image. And as we’re most often hosting Docker on a Linux distribution, we need a Linux distro as the base of the image. The most common Linux distribution to use for containers is Alpine Linux, due to it’s small default footprint and performance tuning.

While Alpine Linux is great as a container base, it uses its own flavor of all of the basic utilities. For example, the package manager for Alpine is not apt or yum/dnf… it’s a utility called apk. Keep an eye out for the Alpine variations of commands that are noted on this site in order to use Alpine well.

Preparation

Since Dockerfile commands are more-or-less the same commands you would issue to a full installation of your chosen Linux distribution, completing a test installation to a full virtual machine first can be very helpful for figuring out the commands you need for your container image. Once you have the list of commands from the full virtual machine installation you are only left the much easier task of adapting those commands for use in your Dockerfile.

Creating the Example Service: Minecraft Server

It should be easier to understand the layout of the Dockerfile by stepping through the creation of an example. Let’s say that I was running my own Minecraft server on a traditional server or full virtual machine, but now wanted to run it in Docker instead (running it in Docker would confer the benefits of containerization: portability, faster service start up, easier management through division of the service into components, etc.) To prepare I am building a traditional virtual machine in order to record the commands needed to get the environment up and running. Since I intend to build the Docker image based on Alpine Linux (the most popular base for Docker images) I will also build my test virtual machine on Alpine.

Installing to a Full Virtual Machine

For anyone who wishes to run the Alpine install long-term, instead of the container, check out the Alpine installer configuration options I used

After completing the Alpine install on a fresh virtual machine I issued the following commands to install a Minecraft server:

• Enable the Alpine community repository in order to obtain the Java Runtime Environment (JRE) in a later command

vi /etc/apk/repositories
# uncomment the community repository for Alpine v3.17
# save and quit
apk update

• Add the necessary packages

apk add --no-cache openjdk17-jre-headless wget iptables tmux

• Create a text file in the current directory (where we will launch Minecraft server from eventually) to bypass the EULA check

vi eula.txt
# write the following
eula=true
# save and quit

• Download the Minecraft server.jar file. You can find the current URL for the server download at https://www.minecraft.net/en-us/download/server

wget https://piston-data.mojang.com/v1/objects/8f3112a1049751cc472ec13e397eade5336ca7ae/server.jar

• Alpine Linux does not come pre-installed with a firewall or network traffic manager. The preferred solution is to install iptables and set it to start automatically, then define the traffic rule, as below. Minecraft server utilizes TCP port 25565.

rc-update add iptables
iptables -A INPUT -p tcp --dport 25565 -j ACCEPT
/etc/init.d/iptables save

• Finally we’re ready to launch the Minecraft server, through a Java launcher running in a tmux session. The Xms option defines the minimum memory to allocate to the Java virtual machine, and Xmx defines the max that it will ramp up to. tmux is used in place of the common Linux command screen, which is not being supported as broadly anymore. tmux allows a program to run in a detachable shell session, which is especially handy for programs like Minecraft server that do not exit after running (they continue to run continuously) and can accept commands from the command line while they still run in the background. In other words, if Minecraft was coded to run in the background on its own and accept commands through a utility program, tmux wouldn’t be needed.

tmux new java -Xms1G -Xmx2G -jar server.jar nogui

Coding the Dockerfile

The Dockerfile should be formatted in Unix EOL format, which is easiest to achieve by using a program like Notepad++. You can find the setting for the Unix EOL under the menu Edit > EOL Conversion > Unix (LF).

Create a file called Dockerfile with no file extension. It should be filled with the following lines:

• Use the Alpine 3.17.3 base image (or latest version of Alpine). Base images are already hosted in the Docker repository

FROM alpine:3.17.3

• Set environment variables. We’ll eventually use these environment variables when instantiating a container, on the command line or in a Docker Compose file. The values we set here are default values that may be overridden by the environment variable definitions we set later

ENV MAX_HEAP=2
ENV MIN_HEAP=1
ENV EULA=false

• The RUN command causes a command to run during the image build process (not afterward, when the container is instantiating). The command here adds the Java JRE package from the Alpine repository. Interestingly, there is no need to enable the communitry repository this time, probably since the Docker Alpine base image already has it enabled

RUN apk add --no-cache openjdk17-jre-headless

• As we’ll see in a subsequent step, it is best to download and include the Minecraft server.jar file along with your Dockerfile to build the image, instead of using wget to download it (notice that we did not install wget this time either). The next command puts a copy of the server.jar file into the built image, copied from the build source we will put together later on. I’m also collecting the server.jar file, and the others we create later on, in a new directory at the root of the container’s file system - a directory called “data”. If the directory we copy into doesn’t exist then the COPY command creates it. Including the trailing slash in the command below copies the file to the specified directory, rather than copying to the file system as a file with the new file name specified.

COPY server.jar /data/

• The WORKDIR command changes the selected working directory within the image, during the build process and for build purposes only

WORKDIR /data

• Lastly we come to the ENTRYPOINT command. This command records to the image any commands that an instantiated container should run when it starts up. Alternatively we could have used the CMD command, however there are important distinctions between these two commands:
  • CMD can be overridden by specifying a command when instantiating a container (during the Docker command call). ENTRYPOINT does not allow this.
  • There are two forms for both CMD and ENTRYPOINT: shell or exec. The preferred form is the exec form, which is shown below with square bracket notation and with each argument passed in a comma separated list. The shell form passes the command just as it is usually issued on a command line. The difference is how the shell form expands variables, and the exec form does not, unless you use the exec form to call the shell directly as is done below.
  • Every Dockerfile must have a CMD or ENTRYPOINT command
• The variables in the command below are enclosed in curly braces due to the fact that the argument syntax requires a ‘G’ to follow the value that is passed in. The curly braces prevent an incorrect variable name match when the command line interpreter mistakenly includes the ‘G’ in the variable name.
• The EULA environment variable can only be used if it is evaluated by the container after instantiation, rather than at build time. Since the only code from the Dockerfile that is evaluated in a running container is in the ENTRYPOINT then it makes sense to include the code to set the EULA file IN the ENTRYPOINT definition, along with everything else.
• There is no need to run the java command behind a tmux command inside the container. This idea is useful in a full virtual machine so that the virtual machine can still be interacted with (for updates, administration, etc…) while the Minecraft server runs. If you need to do these same things for a container you would just stop it and update the image build, then relaunch the container. So tmux is no longer needed.

ENTRYPOINT ["sh", "-c", "echo eula=${EULA} > /data/eula.txt; java -Xms${MIN_HEAP}G -Xmx${MAX_HEAP}G -jar server.jar nogui"]

• That’s the end of the Dockerfile, but there is another important component from the full virtual machine build that we have not used here - iptables. In the Docker Compose definition we will create later we will define port mappings through the Docker API. Docker will impose these port mappings on the running container using iptables on its own. So we don’t need to add iptables ourselves.

Expand here to see the full Dockerfile, all together this time

FROM alpine:3.17.3

ENV MAX_HEAP=2
ENV MIN_HEAP=1
ENV EULA=false

RUN apk add --no-cache openjdk17-jre-headless

COPY server.jar /data/

WORKDIR /data

ENTRYPOINT ["sh", "-c", "echo eula=${EULA} > /data/eula.txt; java -Xms${MIN_HEAP}G -Xmx${MAX_HEAP}G -jar server.jar nogui"]

Packaging your Dockerfile and Source Files

While you could certainly construct your Dockerfile to not require accompanying source files, my end goal is to upload the bundle as a .tar file to the image build section in my Portainer Docker management system. In order for me to get a successful build I need to create a directory on my admin machine and place the Dockerfile and the Minecraft server.jar (obtained from Minecraft Server Download) in the top level of the directory, then create a .tar file where these files are at the top level of the .tar file. You can create a .tar file with the 7zip archiving program. When selecting the files to include, multi-select the Dockerfile and the server.jar files and then have 7zip create the .tar - don’t tar the directory or else this will cause a directory to exist at the top level of the .tar file.

Next we upload to Portainer and build the image. I named my image minecraft:custom, which will be referenced in the Docker Compose

Docker Compose / Docker Stack Definition

The final step is to create a Docker Compose for your image to be launched from. In Portainer this is done by creating a Stack. However, before we create the stack we should create a Docker volume and network

Docker volume and network definition

The volume definition is trivial as you only need the default options. You can set the name of the Docker volume to minecraftdata.

Your network definition will depend on your network setup. In my case I will need to define a new VLAN with specific rules in my firewall, tag this through my switch and hypervisor down to my Docker host, and then into a new Docker network definition. Alternatively you can use the port mapping that I show below and simply point your Minecraft client at the IP address of your Docker host (not recommended for production deployments as this can carry security concerns).

Docker compose and stack definition

The elements of a Docker compose definition are discussed elsewhere on this site, so I will cut to the chase of the full compose definition below:

version: "3"

services:
  minecraft:
    image: minecraft:custom
	restart: unless-stopped
	volumes:
	  - minecraftdata:/data
	environment:
	  - MAX_HEAP=2
	  - MIN_HEAP=1
	  - EULA=true
	ports:
	  - "25565:25565"

volumes:
  minecraftdata:
	external: true

Launch this definition and you will see the container start and run, and then with a few more minutes’ time the Minecraft server will be available at the IP address of your Docker host. With the Docker volume in place, even if you take down the running container and start it again, the server will still load the server data and the save. Without the Docker volume a restart of the container will lose all game progress and start a new world.

Docker Macvlan Networks

and other types of Docker network drivers

See further information about Docker networks here: https://docs.docker.com/network/drivers/

In my Docker environment I make use of a few Docker Swarm features and also run Swarm on my single Docker host in preparation so I could add more Docker hosts to the swarm in future. Of the various Docker network types the basic ones are: Bridge and Overlay. Bridge is scoped for use on an individual Docker host (not swarm-aware), while Overlay is swarm-aware.

Docker Network Types

Each type of network is enabled through use of a specific driver, so Docker network types are also referred to as Docker network drivers. Docker provides an excellent summary of each driver on their documentation page (linked above), so I’ll just say what they’ve said. The ones that I typically use are in bold:

• Bridge: the “default” network type that is good for running most containers, or containers that don’t require special networking capabilities. User-defined bridge networks enable containers on the same Docker host to communicate with each other (network is not swarm-aware). Bridge networks are isolated networks such that all containers attached to it can communicate with each other - useful when needing a common network for all containers in the same “project”. Bridge networks are isolated from the host and require specific port mappings to be “exposed / published”.
• Host: shares the host’s network with the container. When you use this driver the container’s network isn’t isolated from the host.
• Overlay: best when you need containers running on different Docker hosts to communicate with each other. Like a Bridge network, but swarm-aware so that swarm services can automatically share the network configuration to all Docker hosts in the swarm. Overlay networks are isolated from their hosts, so they require specific port mappings to be “exposed / published”.
• MACvlan: good for migrating from a traditional VM environment or when you need your containers to appear like physical hosts on the network. This network type, and the IPvlan type, allows your containers to gain direct access to the network and be managed by traditional network security tools (like firewalls).
• IPvlan: similar to the MACvlan type but doesn’t assign a unique MAC address to each container. Use this type if there is a restriction on the number of MAC addresses you can assign to a network interface or port on your Docker host (the restriction would likely come from the Docker host’s underlying OS).
• none: completely isolate a container from the host and other containers. Containers with this network type are not meant to have any network communication, so publishing ports to expose services does not work. This type of network is not available when running a container on a Docker Swarm.

Preference for Docker MACvlan Network Type

In my homelab environment I am the administrator for every aspect of service delivery, including system administration and network administration. Network firewalls are still a recommended security technology for all types of networks, and I certainly run one myself and recommend it for any homelab network. Modern firewalls provide many services useful to a homelab network, not least of which is a firewall’s primary function - the list of traffic forwarding rules. Since firewall rules are still based on where traffic came from and which interface, IP address, or port that it wants to go to, managing network traffic destined for containers can become messy with each container using the Docker host’s IP address. Using MACvlan networks to make containers “first class citizens” on the network means firewall management becomes more organized. Each Docker MACvlan network is its own VLAN and thus is a separate interface in the firewall, which simply enhances the organization of firewall rules. There are security considerations as well, especially for environments where traditional VMs and containers operate side-by-side.

For a more complete discussion of network security practices for Docker MACvlan containers and subnet separation, please see my article (Network Security Through Subnet Separation) on the topic

Hugo Docker Image

Hugo is a popular open-source static site generator. A static site generator creates flat HTML files rather than relying on dynamic content like Javascript. Static sites typically have a smaller storage requirement and are more performant than dynamic websites, though they also have a much reduced feature set. However most people would say a site that supports full dynamic content that is used just for article content (like this site) would be a waste.

There are a fair few Hugo Docker images out there, but I decided to make my own to practice Dockerfile creation and to fully understand the image that I end up running. Please see my article regarding building a Docker image for the first time as a prerequisite to this build.

TAR file build-out

In addition to the Dockerfile for the .tar file I’ll be creating I also need to include several other files:

• entrypoint.sh file contents detailed herein; script for container start
• hugo binary downloaded from https://github.com/gohugoio/hugo/releases/latest
• nginx.conf file contents detailed herein; main configuration options for Nginx webserver
• net.redbarrel.knowhow.conf specific Nginx config for the site

SSH server is also installed so that the site contents can be managed by the administrator. Tips on defining content for a blog site in Hugo is covered in another article.

Dockerfile

FROM alpine:3.17.3

ENV SSHUSER=
ENV SSHPASSWORD=

RUN apk add --update --no-cache \
	git \
	gcompat \
	libc6-compat \
	libstdc++ \
	nginx \
	openssh

RUN echo 'PasswordAuthentication yes' >> /etc/ssh/sshd.config

RUN ln -s /lib/libc.so.6 /usr/lib/libresolv.so.2

RUN mkdir /etc/nginx/sites-available /etc/nginx/sites-enabled

COPY nginx.conf /etc/nginx/

COPY net.redbarrel.knowhow.conf /etc/nginx/sites-available/

RUN ln -s /etc/nginx/sites-available/net.redbarrel.knowhow.conf /etc/nginx/sites-enabled/net.redbarrel.knowhow.conf

COPY hugo /usr/local/bin/

RUN chmod +x /usr/local/bin/hugo

COPY hugo-cron /etc/cron.d/hugo-cron
RUN chmod +x /etc/cron.d/hugo-cron
RUN crontab /etc/cron.d/hugo-cron
RUN touch /var/log/cron.log

COPY entrypoint.sh /

WORKDIR /srv

ENTRYPOINT ["/entrypoint.sh"]

entrypoint.sh

#!/bin/sh
adduser $SSHUSER
echo -n "$SSHUSER:$SSHPASSWORD" | chpasswd
chown $SSHUSER:$SSHUSER /srv
ssh-keygen -A
/usr/sbin/sshd -D -e "$@" > /dev/null 2>&1 &
/usr/sbin/crond -l 2 -L /var/log/cron.log
while true; do { if [ -d /srv/knowhow ] && [ -f /srv/knowhow/config.toml ]; then /usr/local/bin/hugo server -D -s /srv/knowhow --bind=0.0.0.0; break; else wait 30; fi } done > /dev/null 2>&1 &
nginx -g "daemon off;"

nginx.conf

user nginx;
worker_process auto;
pcre_jit on;
error_log /var/log/nginx/error.log warn;
pid /run/nginx.pid;

include /usr/share/nginx/modules/*.conf;

events {
	worker_connections 1024;
}

http {
	log_format main '$remote_addr - $remote_user [$time_local] "$request" '
					'$status $body_bytes_sent "$http_referer" '
					'"$http_user_agent" "$http_x_forwarded_for"';

	access_log /var/log/nginx/access.log main;

	sendfile on;
	tcp_nopush on;
	tcp_nodelay on;
	keepalive_timeout 65;
	type_hash_max_size 2048;
	server_tokens off;

	include /etc/nginx/mime.types;
	default_type application/octet-stream;

	include /etc/nginx/conf.d/*.conf;
	include /etc/nginx/sites-enabled/*.conf;

	server {
		listen 80 default_server;
		listen [::]:80 default_server;
		
		server_name _;
		
		root /usr/share/nginx/html;
		
		include /etc/nginx/default.d/*.conf;
		
		location / {
		}
		
		error_page 404 /404.html;
			location = /40x.html {
		}
	}
}

net.redbarrel.knowhow.conf

server {
	listen 80;
	listen [::]:80;
	
	server_name knowhow.redbarrel.net;
	
	root /srv/knowhow/public;
	
	index index.html;
	
	access_log /var/log/nginx/www_access.log;
	error_log /var/log/nginx/www_error.log;
	
	location ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bpm|rtf)$ {
		access_log off; log_not_found off; expires max;
	}
	
	location / {
		try_files $uri $uri/ =404;
	}
}

hugo-cron

* 4 * * * cd /srv/knowhow;/usr/local/bin/hugo --minify

Portainer Build

• Upload Dockerfile .tar to Portainer as hugo.custom
• Create a docker volume called hugodata
• Create a macvlan config network called br_knowhow_config
  • subnet: <subnet>
  • gateway: <gateway>
  • IP range: <ip range>
  • parent network card: <interface>.<vlan> (i.e. ens10.5)
• Create a macvlan network based on br_knowhow_config caled br_knowhow
  • ☑ enable manual container attachment
• Create VLAN in your firewall and switches, tagging through to your container host

Portainer Stack / Docker Compose Definition

version: "3"

services:
	hugo:
		image: hugo:custom
		volumes:
			- hugodata:/srv
		networks:
			- br_knowhow
		environment:
			- SSHUSER=<username>
			- SSHPASSWORD=<password>

volumes:
	hugodata:
		external: true

networks:
	br_knowhow:
		external:
			name: br_knowhow

Installing Docker Engine

(on RHEL derivatives)

Also See Official Docker Documentation Install Docker Engine

While other methods are provided in the offical documentation (see above), I prefer adding the offical Docker repository to my package manager as my source for Docker packages.

sudo dnf -y install dnf-utils
sudo dnf-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

Add the packages

sudo dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Enable the Docker system service and start it

sudo systemctl enable --now docker

Portainer Management of Docker

Portainer offers an excellent management webgui for your Docker host. Simply run the Portainer Docker Compose project to get it going. See my article Installing Portainer to get the steps.

Considerations for Hosting Docker

When considering my designs for hosting services in containerized or virtualized infrastructure I realized that I could reduce all services to containers and then just run docker engine directly on my server farm (an environment with 100% containers, 0% VMs). In the end I chose to install a VM hypervisor directly on the servers instead (ProxMox VE), with docker installed as a virtual machine. This allowed me the flexibility to run full virtual machines from time to time, while most of my services would be containers on Docker. ProxMox has compatibility to run LXC containers directly, but not Docker containers; I enabled Docker containers by running my Docker engine inside a full virtual machine under ProxMox.

Initially I had concerns about how performance would turn out, but for the workloads I run in my homelab this hasn’t been a real concern. For the type and quantity of services run in a home lab I don’t have any problem recommending this setup.

Installing Portainter

for Graphical Docker container management

See official Portainer installation documentation for Community Edition on Linux with Docker Swarm

A vanilla installation of Docker can be entirely managed through Docker’s command line tools, however graphical tools like Portainer offer a GUI representation of commands and are preferred by some administrators. Portainer’s GUI is a webgui, providing the additional benefit of managing your Docker installation through a web browser instead of a locally installed app.

Portainer is offered in a free community-support-only edition (Portainer CE) and an edition for business with paid tiers and direct support (Portainer BE). The business edition includes features that aren’t available in the community edition, though these features are typically of interest for business computing environments, including: tying to centralized access management systems, additional security and reporting, and auditing features. All editions of Portainer also support Docker Swarm, Kubernetes, and Azure ACI.

Installation

Portainer can be run with a one-line Docker command, however since I like to launch Portainer without needing to remember all the options, using a Docker Compose file is much better. This also allows me to add comments (like the previous image version of Portainer that I had running before I did an update) and provides a visually organized layout for the options I use.

Prerequisites

• Docker Volume: I created a persistent volume to hold the data that Portainer uses to run, including the database it creates. If you’re starting from a fresh Docker or Portainer installation then you’ll need to create the Docker volume first; for all other runs of Portainer you’ll be referencing your previously created persistent volume.

docker volume create: replace portainer_data with whatever name you want for the volume, but be sure to continue replacing it in upcoming commands as well

docker volume create portainer_data

• Docker Network: I prefer to keep network traffic for each container separated all the way through the network to the external firewall. In order to do this, separate Docker networks are created and VLAN tags specified. The Portainer container is also isolated into its own VLAN, so if you follow this same network design and you’re starting fresh you’ll need the following command. If you prefer standard Docker networking, where each container is connected to the network by specifing a port on the Docker host to expose, then you can skip this step (however my commands do not include the options for exposing docker host ports - see official Docker documentation here and official Portainer documentation here).

docker network create: be sure to set your own values for subnet, gateway, and parent (which should be the name of your network adapter that connects the docker host with your VLAN). portainer_network should be whatever name you want docker to know the network as.

docker network create --driver=macvlan --subnet=192.168.0.0/24 --gateway=192.168.0.1 -o parent=eth38.23 portainer_network

• Certificate: I also wanted the Portainer webgui to use proper HTTPS, however I’m not serving the webgui to the internet and can’t (and don’t want to) pull a LetsEncrypt certificate. A self-signed certificate would still throw an error in my browser (unless I also installed the certificate to my workstation), but I have a better solution since I run my own local certificate authority - i.e. generate my own server certificate and install the root certificate from my local CA. This is why you see options to include Portainer’s SSL certificate shown in the compose yaml below. Don’t forget to create and upload your certificate and key files to the Docker host! - put them in a folder named ssl/ in the directory where you have your Portainer docker-compose.yml file.

• HTTPS: Lastly, to enable use of the certificates previously mentioned and turn on HTTPS the ’entrypoint’ section is added to the Portainer compose file. This line disables serving Portainer on HTTP while specifying the HTTPS port as 443 (Portainer’s default is port 9443).

docker-compose.yml

version: '3'

services:
  portainer:
    #image: portainer/portainer-ce:2.20.1 <-- previous version noted for easy rollback
    image: portainer/portainer-ce:2.20.2
    container_name: portainer
    restart: always
    networks:
      portainer_network:
    entrypoint:
      /portainer --http-disabled --bind-https :443
    command:
      --sslcert /data/ssl/cmgmt.crt
      --sslkey /data/ssl/cmgmt.key
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - portainer_data:/data
      - ./ssl:/data/ssl

networks:
  portainer_network:
    external: true

volumes:
  portainer_data:
    external: true

Starting and Stopping the Docker compose

This section assumes that you have Docker Compose available in your Docker host somehow. Contemporary Docker installation can include a native plugin to enable Docker Compose - in the past this would have required obtaining the source and running Docker Compose separately. See my article for Installing Docker to see how I add Docker Compose.

Once you have Docker Compose available make sure your current directory is the one containing your Portainer Docker Compose yaml file (docker-compose.yml), and your SSL directory containing your certificate and key inside.

Starting Portainer

docker-compose up -d

Stopping Portainer

docker-compose down

Kubernetes Introduction: Docker vs Containerd

Kubernetes (also written as k8s) is an advanced container management and orchestration platform. It sits above the container management engine, which provides command interfaces for running containers and managing them. Docker is one example of a container management engine; Containerd is another. In fact, Docker is more of a hybrid, providing enhancements and programming interface to the Containerd engine it actually uses under the hood. As k8s sits above Containerd and Docker, it is required to install a container management engine when installing k8s.

In the past Docker directly developed a shim that would interface between itself and k8s, but has since ceased development on it. This produced blog posts announcing that k8s could no longer support Docker. However, development for the shim was picked up by Mirantis. It can found hosted on Github: cri-dockerd

Re-adding Utilities to Minimal Containers

Docker images are purposefully minimal and notoriously omit standard utilities an administrator would need during troubleshooting. See below for reminders of package names to use for reinstalling these utilities

• ping
• ip
• dig
• ss “old netstat”
• ps
• vi

Hypervisor Comparison

The following list of popular hypervisor software includes a short description and comparison of features. Any recommendations noted are from the perspective of someone wanting to host a homelab, so priority is given to the availability of a full feature set at no cost.

Xen Hypervisor

XenServer / Citrix Hypervisor

XenServer has a storied past. The commercial product is currently offered by the XenServer company. The free version is their “Trial Edition”, which only has the limitation of no support and smaller pool sizes (similar to free versions of XenServer offered in the past). Although I haven’t investigated this today, my experience in the past is likely to still be true, that you will probably need to sign up for a free account in order to download XenServer.

In the past the Xen hypervisor has been offered through several different sources, with most changes happening because the governance of an offering changed from open to closed source, or vice versa. Xen was offered as an open source community-driven project from its early days, with a company (XenSource) developed to offer support and a commercial product. Citrix had a product for app virtualization around this time, but no bare-metal hypervisor, and ended up acquiring XenSource to fill that gap. Citrix began offering the product as XenServer, but then forked the source in 2018 and changed the product name to Citrix Hypervisor for version 8. In 2022 Citrix was acquired by Vista and Evergreen, and the hypervisor product was spun off into a standalone business unit, now called XenServer again.

XenServer Company Story

XCP / XCP-ng and Xen Project

The Xen Hypervisor started out as an open source community-driven project, and that open source community project is still maintained by the Xen Project community at https://xenproject.org. They are primarily focused on the hypervisor elements, and an API. The Xen hypervisor can be installed manually on supported Linux distributions, however it is much easier, and I recommend, installing the XCP-ng distribution which bundles Xen in a custom Linux distribution (loosely based on CentOS 7). Installing XCP-ng is a similar experience similar in ease to installing VMware ESXi.

The XCP-ng Wikipedia article clairifies some history about XCP/XCP-ng. It seems that after Citrix acquired XenSource in 2007 and continued to sell the XenServer product, they decided to move XenServer to closed source in 2010. This prompted the creation of the XCP version of Xen Hypervisor, maintained by an open source community. However, Citrix took the XenServer code open source again in 2013, prompting XCP to abandon their now redundant efforts. But then in 2018 XenServer was again closed-sourced (with the branding change to Citrix Hypervisor), so XCP-ng was born as the successor to XCP. XCP-ng continues to offer an open source version of Xen Hypervisor bundled in a Linux distribution. XCP-ng also offers several other projects: Xen Orchestra, XOSTOR, XO Lite, XCP-ng Center. XCP-ng partners closely with Vates to offer commercial support services for XCP-ng through https://xcp-ng.com.

Recommendation

The Xen Hypervisor is a fine system for running virtual machines, and has compatibility to run Windows OS’s too. Xen offered an easier and all-GUI experience when I was directly attaching external harddrives for passthrough into VMs, but had no support for private VLANs (which I researched for a period, but never implemented). In the end XCP-ng is fine to run a homelab, especially with their Xen Orchestra web gui. I ended up choosing ProxMox, but if that ever stopped working for me then I would return to XCP-ng.

Proxmox

A KVM-based hypervisor, Proxmox provides management through a comprehensive webgui. Based in Germany, Proxmox Server Solutions GmbH provides commercial solutions and support. Even though Proxmox does not mention a free or trial tier in their pricing tables, their docs include information for running Proxmox without a subscription. This only provides access to the no-subscription repository, instead of the enterprise repository, however I ran my homelab on the no-subscription repository for years without any issues. Handily Proxmox does not gate any features behind subscriptions, so you can run Proxmox without a subscription and still have an unlimited number of clusers and cluster members, among all other features. Support with no subscription is limited to their community forums of course.

Recommendation

Proxmox is my first choice for homelab hypervisor. It does not have native support for Docker containers, however it does natively support LXE Linux-native containers. This hasn’t proved to be a serious obstacle, since I run Docker containers from a full-size VM hosted on Proxmox.

One difficulty I found getting Proxmox working was passing through a Link Aggregation Group (LAG) from my switch (or NIC teaming) to the Proxmox server. With a bit of searching on the Proxmox forums I found commands to run in the server terminal that got the job done, however in Xen or VMware the process could have been handled through the GUI.

VMware / ESXi

Until recently VMware was my recommendation for enterprise hypervisor environments. The licensing has always been the most expensive of all commercial environments, and some IT professionals have told me VMware is too complicated to learn, however I found that VMware’s GUI tools were comprehensive which made administration easier than I’ve experienced anywhere else. This includes GUI tools for hyperconverged infrastructure and clustering.

Unfortunately, after the completion of Broadcom’s acquisition of VMware, the licensing model became much more disadvantageous for VWware customers. Perpetual licensing was removed in favor of subscriptions, and free or trial offerings disappeared. I see many news articles and forum posts indicating that companies are looking to move to other hypervisor providers, based on the changes to VMware’s terms.

Even if there wasn’t the Broadcom acquisition playing up, I still couldn’t recommend VMware as a homelab hypervisor. There are no, and never were, any free or trial offerings that could sustain a homelab for the long term. It is unfortunate when enterprise technology providers do not offer a way for technologists to practice using their software, including practice for keeping a long-term environment up and running. I would honestly tell my employers that I am more comfortable setting up a Proxmox or Xen system than VMware (if I hadn’t been employeed with a company already using VMware).

Microsoft Hyper-V

I’ve had somewhat little experience with Hyper-V until I recently helped my company stand up a cluster of Hyper-V VMs. Previously I only experienced Hyper-V if I wanted to run a VM on my home Windows client OS. And of course those VMs were typically short-lived and did not need a complex network or storage setup, and I typically ran just a few VMs at a time.

Now that I’ve experienced setting up a production cluster of Hyper-V servers for an enterprise I can say that I do not recommend Hyper-V, unless the IT administrator is shackled to choosing only from Microsoft products when designing the solution. In any case it is certainly not a great solution for homelab, though it would be possible to run Microsoft Server OS and Hyper-V in a homelab through some type of trial or educational program.

If you are tasked with setting up a Hyper-V server cluster (hyperconverged even), then I offer this advice: be aware that Hyper-V does not support failover clustering on its own. Hyper-V servers can be connected through the same Hyper-V management client and this permits VMs to be moved between servers while offline, but this is not the “live migration” that we all expect from enterprise hypervisors these days. In order to acheive this you will need to learn about and setup Windows Server Failover Clustering, which is a separate server role outside of Hyper-V. For hyperconverged storage you will need to setup Storage Spaces Direct, again separately and outside of Hyper-V. Lastly when this is all setup, the Hyper-V management client will still not recognize the server cluster - so you will deploy the VM direcly in the Failover Cluster Manager console, “outside” of Hyper-V. My recommendation is to research several documents online before taking on the project - Microsoft does not offer the administrator handy cluster or HCI setup workflows like VMware or others do.

Cockpit for Linux

Cockpit is a remote host management system for Linux hosts, allowing management through a web portal hosted locally on the Linux host via a lightweight web server. As such, and like all remote management systems, enabling Cockpit carries inherit risks since this technology allows anyone with knowledge of system access to issue any command to the host. Cockpit is capable of managing system services, viewing all running processes, running commands (even as root), and more.

Installing Cockpit

dnf install -y cockpit
systemctl enable --now cockpit.socket
firewall-cmd --add-service=cockpit --permanent
firewall-cmd --reload

apt install -y cockpit
systemctl enable --now cockpit
ufw allow 9090
ufw allow 80

pacman -Syu cockpit

Modify Cockpit to Defeat Automatic User Session Login

Cockpit supports passing your local user session login details to the remote host, through the web browser session. This can be helpful if your local host and the remote host are both joined to the same domain, and you are logged in to your local host with your domain credentials. In this situation your domain user session details (kerberos ticket) will be passed through the web browser to the remote host and you’ll be logged in to the remote host under your domain user account, automatically.

However, this automatic login behavior can be problematic if your local user account does not have administrative permission on the remote host, yet your intend is to log in to the remote host as the administrator. The workaround is to log off of Cockpit after the automatic login so that you can login under your admin account. rather frustrating

Unfortunately Cockpit does not provide configuration options for this behavior, so to modify Cockpit’s automatic login we must change Cockpit’s source HTML.

The auto login feature (and other advanced features of the login page) are coded as JavaScript functions at the top of the HTML file. There are some good comments in this section, so I eventually found the function responsible for the auto login: function I. Unfortunately, deleting or commenting out I breaks the login page pretty badly. I found that it really must be left in place, but that I could achieve the desired effect by altering the call for function I (happens in the code block just before the function I definition). function q seems to be related to login functions, and based on my trial-and-error experience, it is the magic function to replace I with.

Altering Cockpit HTML

Edit the login HTML page file with:

vi /usr/share/cockpit/static/login.min.html

Search for function I, as your reference point, by typing /function I then press [enter]. Use n to find the next instance of the search term (p would find the previous). In the code block just before function I (commented with /*Try automatic/kerberos authentication*/) you’ll see the following originals - replace these lines with the new lines as indicated:

So now, in either case q runs and I never will. Now the login page will never try to autologin using the local session kerberos ticket. Now we need to restart the Cockpit service:

systemctl restart cockpit

SCP vs. SFTP

From my expeditions into the internet I’ve found that there is much confusion around Secure Copy (SCP) and related protocols like Secure File Transfer Protocol (SFTP). There are plenty of forum posts and search queries of the type “Which is more secure, SCP or SFTP?” The short answer is: SFTP is preferred, though SCP can be fine. Sounds like there is more to it? Well there is, and to understand the answer better let’s first touch on how files were transferred through the early internet.

Original Network File Transfer Programs

When computer networking and the internet were young there was little to no focus on, and no need for, robust security. Therefore commands like rcp and ftp were just fine, even though they are woefully insecure by today’s standards. The habits that users formed using these commands were difficult to banish. Today we must worry about (and write extensive articles about) which command is the most secure, lest we ever forget the lesson of putting security second.

In the late 1990s security was eventually added to the older network file transfer commands - new scp and sftp commands were created. These commands rely on SSH connections for security, but otherwise utilize the original protocols to be effective. While these commands continue to be maintained through the OpenSSH package, it’s doubly true that the commands are based on much older commands and that both incorporate SSH. Therefore, as far as the security of the connection is concerned: SCP and SFTP are equally secure.

Another Contender, FTPS

But they were all of them deceived, for another command was made…

…but seriously, another variation of secure FTP service was made, FTP over SSL. It’s fine choice for those who want to use it, though an argument can be made that SFTP is superior in environments that are already capable of SSH. FTPS requires the use of ports 989 and 990, and must have an X.509 certificate (from a public certificate authority). Meanwhile SFTP uses your existing port 22 (because it runs over SSH’s port) and utilizes SSH’s configured certification method. Adding FTPS to your environment that already has SSH configured means extra work configuring firewalls and certification, when you could just piggyback on SSH.

Who is SSHFS?

Some may know of yet another command, sshfs. This command is for connecting to a remote host’s file system using SSH, allowing you to create a mount point or “mapping” to access the remote file system locally. In actuality sshfs runs over SFTP, so the security of the command and other considerations are the same as those for SFTP.

So how does SFTP work out to be the “preferred” method?

No surprise, this recommendation comes with a slight caveat. Before OpenSSH version 9 scp was still based on the original rcp command, which had some limitations I’ll discuss below, but which ultimately meant that scp was not as performant for some operations and had many vulnerabilities that couldn’t be mitigated without breaking command functionality. The caveat is that in OpenSSH version 9 a change was made to completely retool scp so that it now uses sftp in the backend. So now, scp is sftp, and this concludes the argument over which is better.

But why was old scp abandonded? Though the underlying SSH connection was just as secure in scp as it was insftp there were other flaws that could be exploited maliciously. Typically only by authorized users though.

In one scenario an scp connection would request a file from a remote host, but would not check the filename of the file returned by the remote host, which would see scp accept any file from the remote host. scp was later fixed to check the filenames of the files it would receive, but at that time OpenSSH noted that scp was “outdated, inflexible and not readily fixed”.

In another scenario, requesting a filename that includes single quotes and a section in backticks would result in the ability to execute arbitrary code included within the backtick section on the remote host.

So, in short, OpenSSH understood the codebase of sftp to be more robust and wished to support it over the work required to fix scp (which would also likely break it).

Windows SSH/SCP and GUI Utilities

Since I prefer to run Windows as my everyday driver, and management host, I’ve certainly needed SCP-like functionality between my Windows environment and my Unix-like servers from time to time. What to do since SSH has historically been Unix-only? Well, ever since Windows 10 version 1809/Windows Server 2019, Windows has included support for OpenSSH (including SSH, SCP, and SFTP). Therefore, you can initiate an ‘ssh’, ‘scp’, or ‘sftp’ session directly from Powershell (or Command Prompt, should you choose).

WinSCP

However my preferred utility for managing SCP connections from my Windows host is WinSCP. This GUI utility provides excellent file transfer management, over an SCP or SFTP connection (and some others too). The software also provides an SSH client direct from the GUI. It uses the features of SSH and your chosen protocol to show directory listings in the GUI, and can also keep directories automatically synced while the connection is active. Connection properties can also be saved so that remote hosts can be revisited quickly in future.

Rsync

And lest we forget, there is also rsync, which is an extremely capable tool, though somewhat to it’s own detriment. Many users complain that Rsync’s options are too complex for daily use, requiring such a verbose command specification that issuing an rsync command with sane behavior constraints may require up to 6 or more command line switches. Most are appreciative of the simpler command syntax of ‘scp’ and even ‘sftp’ for daily use, over that of rsync.

References

I leaned a lot from the following articles as I researched for this summary:

• Deprecating scp
• SFTP vs SCP: Which is Better?
• SFTP File Transfer Protocol - get SFTP client & server
  • Note that ssh.com is not affiliated with OpenSSH or the SSH protocol or a governing body in control of SSH… they are a security consulting firm with a confusing website name
• OpenSSH in Windows overview

Running iPerf3 Commands

Likely helpful to disable firewall for the iperf3 host:

systemctl stop firewalld
systemctl disable firewalld

Start the iperf server on one of your endpoints:

iperf3 -s

Run the client on the other endpoint:

iperf3 -c <ip address of server>

Example iperf command with several options specified:

iperf3 -c <ip address of server> -i 20 -udp -b 10000M

Linux: ARP Command

ARP commands are useful for showing the ARP table in use by the OS. Certainly the ARP table will contain the MAC addresses of known network nodes.

ip n

ip n

ip n

ip n

Install the ip command with:

dnf -y install iproute2

apt -y install iproute2

apk add iproute2

pacman -Syu iproute2

Linux: Default Gateway

The standard command for showing IP address in Linux is ip a. ip also provides an option to view configured gateways:

ip r

ip r

ip r

ip r

Here is an example of adding a default gateway:

ip route add default via 192.168.1.1

If your distribution or container is missing this command you can add it with:

dnf -y install iproute2

apt -y install iproute2

apk add iproute2

pacman -Syu iproute2

Linux: Disk Space Usage

Simple command to show disk space used for all connected file systems, in human readable sizes instead of bytes

df -h

df -h

df -h

df -h

Linux: Network Connection Statistics

Troubleshooting network applications is often aided by reviewing the applications on the system with open ports, waiting for network traffic to connect. To do this in a Linux terminal, run this command:

ss -tulpn

ss -tulpn

ss -tulpn

ss -tulpn

ss options mean:

Install the ss command with:

dnf -y install iproute2

apt -y install iproute2

apk add iproute2

pacman -Syu iproute2

Linux: Ping Command

Though many commands in Linux don’t match to Windows, in the case of ping it does:

ping <ip address|hostname>

ping <ip address|hostname>

ping <ip address|hostname>

ping <ip address|hostname>

If missing from your distribution or container, install with:

dnf -y install iputils

apt -y install iputils

apk add iputils-ping

pacman -Syu iputils

Linux: PS Command

In Linux use the ‘ps’ command to list running processes. Sometimes I’ve found this basic command missing from Linux containers.

ps aux

ps aux

ps aux

ps aux

If missing from your distribution or container, install with:

dnf -y install procps

apt -y install procps

apk add procps

pacman -Syu procps-ng

Linux: Resolve DNS Names to IP Address

Another part of standard troubleshooting for network connections is testing your DNS server connectivity and name resolution. In Windows this is command would be nslookup; in Linux it’s:

drill <hostname>

drill <hostname>

drill <hostname>

drill <hostname>

dnf -y install bind-utils

apt -y install dnsutils

apk add bind-tools

pacman -Syu bind

If missing from your distribution or container, install with:

dnf -y install ldns

apt -y install ldnsutils

apk add drill

pacman -Syu ldns

Linux: Setting Static or Dynamic IP Address

Virtually no computer used today would not have an IP address of some kind assigned to it. Here’s how to assign IP address settings in various Linux OS flavors. See the following sections for commands to show the current IP settings:

Command: Show IP Address

​

Red Hat Family Debian Family Alpine Family Arch Family

ip a

ip a

ip a

ip a

Command: Show Default Gateway

​

Red Hat Family Debian Family Alpine Family Arch Family

ip r

ip r

ip r

ip r

Command: Show DNS Server

​

Red Hat Family Debian Family Alpine Family Arch Family

drill <hostname>

drill <hostname>

drill <hostname>

drill <hostname>

Command: Ping

​

Red Hat Family Debian Family Alpine Family Arch Family

ping <ip address|hostname>

ping <ip address|hostname>

ping <ip address|hostname>

ping <ip address|hostname>

Direct Configuration File Method

The various Linux OS families have different ways to set their IP address (on the command line), typically through a configuration file and a restart of a system service.

vi /etc/NetworkManager/system-connections/<IFACE_NAME>.nmconnection
systemctl restart NetworkManager

vi /etc/network/interfaces
systemctl restart networking

vi /etc/network/interfaces
vi /etc/resolv.conf
/etc/init.d/networking restart

vi /etc/systemd/network/10-net0.link
> [Match]
> PermanentMACAddress=<interface MAC address>
>
> [Link]
> Name=net0
>
> [Network]
> Address=<address>
> Gateway=<gateway>
> DNS=<dns1>
> DNS=<dns2>

Ubuntu

In this case, like many others, even though Ubuntu is a Debian derrivative it doesn’t follow Debian’s example, and has to do it it’s own ‘special’ way:

vi /etc/netplan/<interface>_config.yaml
netplan apply

NetworkManager Method

Many distributions support various network managers - command line tools to consolidate and simplify the commands to manage IP address settings. Several distributions support NetworkManager and I’ve made notes here to show how to install NetworkManager and the commands to set static IP values

dnf -y install NetworkManager
systemctl enable --now NetworkManager
nmcli connection modify <iface name> ipv4.gateway <gateway ip>
nmcli connection modify <iface name> ipv4.address <ip address>
nmcli connection modify <iface name> ipv4.dns <dns ip address>
nmcli connection up <iface name>

apt-get install network-manager
systemctl enable --now NetworkManager
nmtui

apk add networkmanager
rc-service networkmanager start
rc-update add networkmanager default
adduser <your username> plugdev #you will need to relog to apply the new group membership
nmtui

pacman -Syu networkmanager
systemctl --now enable NetworkManager.service
nmtui

Linux: Show IP Address

Another standard command needed for common troubleshooting in every OS - in Linux you show IP addresses with:

ip a

ip a

ip a

ip a

If missing from your distribution or container, install with:

dnf -y install iproute2

apt -y install iproute2

apk add iproute2

pacman -Syu iproute2

Linux: Vi Command

An essential function for any computer system is file editing. In Linux Vi (or Vim being the enhanced version) is the standard command line text editor.

vim

vim

vim

vim

If missing from your distribution or container, install with:

dnf -y install vim

apt -y install vim

apk add vim

pacman -Syu vim

Linux: View DNS Server

While Linux provides straight forward command for viewing the ip address configured on your host (ip or ifconfig), none of these commands include information about your DNS servers. To view your DNS servers use:

cat /etc/resolv.conf

cat /etc/resolv.conf

cat /etc/resolv.conf

cat /etc/resolv.conf

DNS servers are typically managed through the network manager for your distribution, or directly through network configuration files

Red Hat Family OS's: Extending Root Partition

Windows easily allows extending a partition, while the disk is in use or “online”. Extending a partition is a common task when managing guests in a virtual environment. This process has always been straight forward in Windows, but the Linux commands had eluded me for some time.

Fedora 30 maintains the root partitions as a volume group - a composition from several partitions made into one logical volume. So the solution is to create a new partition, empty and of the size you wish to exapand your root partition by, then add it to the volume group. xvda is the designation for the virtual disk attached to my guest that I’ll be adding the new partition to.

Creating the new partition

fdisk /dev/xvda
n  #new partition
p  #primary type partition
[enter]  #default option
[enter]  #default option
[enter]  #default option
w  #write partition table
q  #quit fdisk

Adding the new partition xvda3 to the volume group

partprobe
pvcreate /dev/xvda3
vgextend /dev/fedora /dev/xvda3
lvextend -l+100%FREE /dev/fedora/root
fsadm resize /dev/fedora/root

partprobe
pvcreate /dev/xvda3
vgextend /dev/cl /dev/xvda3
lvextend -l+100%FREE /dev/cl/root
fsadm resize /dev/cl/root

partprobe
pvcreate /dev/xvda3
vgextend /dev/rl /dev/xvda3
lvextend -l+100%FREE /dev/rl/root
fsadm resize /dev/rl/root

Check that your free space has increased with:

df -h

The volume group will appear in the listing as:

/dev/mapper/fedora-root

/dev/mapper/cl-root

/dev/mapper/rl-root

Windows: Modifying the Command Line Path

For command line environments the default locations where the terminal will look for executable programs is called the Path. The path may have several directories noted in it, meaning that all of the noted locations will be searched for executable files to match the command that you’re issuing. The purpose of the path is to save system users the time it would take to type a full file path to each executable file they want to run. Path is the reason why, when you type ‘cmd’ or ‘ipconfig’ or any other command, your command runs even though you did not specify C:\Windows\System32 in front of it (which is the directory where many commands live).

When you create your own programs or commands certainly you would like to run them without needing to specify the file path to them, and you can do so by modifying the path variable to include the directory where you store your own programs. Certainly you could also just place your programs in the C:\Windows\System32 folder, however that is not recommended for several reasons:

• Modifying the contents of this folder (including adding or removing files) requires system administrator permission. Modifying the path variable allows normal system users to enjoy the benefits of path too (though non-admins should modify the non-system version of the path variable instead).
• The C:\Windows\System32 folder is meant for Windows system files - files that are provided with an installation of Windows. Including your own programs breaks that file organization. Windows updates will also assume that the Windows folder does not contain user files, so future updates or restores could overwrite your files stored in this location.
• Other file system locations are more suitable, such as: C:\Program Files or C:\Users\<my user>\Programs

As an example, let’s add the C:\Program Files\Scripts directory to the system path variable, by using Windows Powershell. C:\Program Files\Scripts is not located in a user accessible area - you must be a system administrator to modify the contents of the C:\Program Files directory. However, I am the system administrator and I also want to ensure that the script that I am including in this directory is available to all users. If the script were placed in C:\Users\<my user>\Programs (or similar) then only I would be able to access it. However I would use C:\Users\<my user>\Programs or similar if I were working on a system that I did not have administrator permissions to.

$env:path += ";C:\Program Files\Scripts\"
[Environment]::SetEnvironmentVariable('Path',$env:path,[System.EnvironmentVariableTarget]::Machine)

That’s it! Note the use of the += operator which tells Powershell to add the string that I specified to the existing value of $env:path, rather than removing the previous value of $env:path and replacing it. This preserves what was in the path before (things like C:\Windows\System32) so that the other programs in the system don’t break. That is also the point of the ; at the start of the string - each file path stored in the path variable is separated by a semicolon, but typically there isn’t one already on the end of the existing path, so we add that first.

System Properties GUI

Also keep in mind that you can edit the system path variable through the System Properties window, on the Advanced tab, in the Environment Variables window. You can get to these windows through the File Explorer, by right-clicking on ‘This PC’ and then select Properties, then find ‘Advanced system settings’ at the bottom of the page. Alternatively you can open a run box and run the command systempropertiesadvanced to jump right there.

Windows: Verify File Checksums

Windows doesn’t provide a brilliant utility for verifying the checksum value on files (typically a task I want to perform on files downloaded from the internet). Well… in fact there is a utility, however the biggest drawn back is how it only generates the hash of the file while stopping short of comparing the file hash to the checksum provided by the website. That’s a feature I believe deserves support in a checksum utility, so I’ve created my own in a Powershell script.

## File Checksum Verifier
## Calculate a file's checksum, chosen from a list of supported hashes, then compare to a provided checksum value

param ($path, $hash, $checksum)

$HelpKeywords = @("-h", "-help", "-?")
if ($HelpKeywords -contains $args[0])
{
  Write-Output "verify-checksum -path <path to target file> -hash <SHA1|SHA256|SHA512|MD5> -checksum <provided checksum>"
  exit
}

Write-Output "File Checksum Verifier"

if (!$path) {$TargetFilePath = $(read-host "Path to file").Replace("`"","")} else { $TargetFilePath = $path }

$SupportedHashes = @("SHA1", "SHA256", "SHA512", "MD5")
if ($SupportedHashes -notcontains $hash) {
  $HashSelectionMenu = "
[1] SHA1
[2] SHA256
[3] SHA512
[4] MD5
"
  $HashSelectionPrompt = "Select hash to use (type ? for help)[MD5]"
  $HashSelectionMenu
  do {
    try {
      $HashMenuSelection = read-host "$HashSelectionPrompt"
	  if ($HashMenuSelection -eq "") {$HashMenuSelection=4}
	  if (($HashMenuSelection -ge 1 -and $HashMenuSelection -le 4) -and $HashMenuSelection -as [int])
	  {
  	    $NoError=$true
	  }
	  else
	  {
	    if ($HashMenuSelection -eq "?")
	    {
	      $HashSelectionMenu
	    }
	    else
	    {
  	      "Not a menu selection!`n"
	    }
	    throw "bad value"
	  }
    }
    catch {$NoError = $false}
  }
  until ($NoError)
  $SelectedHash = switch($HashMenuSelection)
  {
    1 {"SHA1"}
    2 {"SHA256"}
    3 {"SHA512"}
    4 {"MD5"}
    default {"MD5"}
  }
}
else
{
  $SelectedHash = $hash
}

if (!$checksum) {$ProvidedChecksum = read-host "Provided Checksum"} else { $ProvidedChecksum = $checksum }

$FileChecksum = $(get-filehash $TargetFilePath -algorithm $SelectedHash).hash
Write-Output "File Checksum: $FileChecksum"

$ChecksumChecksOut = "$FileChecksum" -eq "$ProvidedChecksum"

Write-Output "Checksum matches: $ChecksumChecksOut"

I’ve then placed this file in C:\Program Files\Scripts and added that directory to my system Path variable (see how in this article). Now I simply call the script with verify-checksum. The script accepts the following options: -path for the full path to the file you want a checksum of, -hash to specify which hash to use on the file (one of: SHA1, SHA256, SHA512, or MD5), and -checksum for the checksum value supplied by the website you got the file from. Or, instead of passing everything to the command during the call, it will recognize any and all options missing and prompt you for each one that is still needed (or that did not match an accepted value).

Minecraft Server using MineOS

Find links to MineOS downloads and instructions here

For those wanting to run their own Minecraft server (Java edition) MineOS makes for a straightforward setup. Running any flavor of their platform provides a webUI for managing the server, plus easy tools to download the server binary from the Minecraft website or do updates on it. Choosing to run MineOS (especially the Turnkey full OS option) means you can focus on learning system administration and get strait to enjoying the satisfaction of hosting your own server.

Hosting Options

MineOS provides several iterations to choose from when hosting:

• Node.JS webapp that can be added to Minecraft servers hosted in other ways
• MineOS built on Turnkey Linux (Debian-based), for a full OS experience that is ready to go through a single installation
• A Docker image (though I host a Docker Minecraft server through a different method)

My experience with MineOS was as my first Minecraft server, hosted as a virtual machine some years ago. Many features have been added since, but I would still recommend it for first time Minecraft server administrators, especially if hosting for a small group of friends.

Init Script

It has been years since I ran the system, but at the time I found that I needed a custom init script to start the server and run it as a background process that I could reattach and interact with later on, as needed. Considering the intervening years the init script may not be necessary any longer; it has also been lost. However, the utility that I used to run it in the background (so that it could be reattached) was called screen. The screen utility allowed the server to run in a “detached” (with CTRLASpaceD) terminal that could be reattached (with screen -r) at any point so that commands could be run, or output reviewed.

Please try out MineOS as it stands today - I’d be surprised if an init script would be needed these days

Breaking into Windows 10 locally

From time to time you may find that you’re locked out of your account in Windows. Well… if you have local access to the machine running Windows (meaning you can force a reboot and a temporary boot device) then there is a convenient vulnerability still present in Windows after all these years that will allow you to break in.

Insert your installation media and reboot, following the instructions for your BIOS to choose a temporary boot device, and choosing your installation media. If using a Windows 10 installation ISO chose the Repair your computer option. Choose Troubleshoot, then Advanced Options, then Command Prompt. Then run the following commands:

diskpart
list volume

Having identified the volume that contains the Windows system (for example D:), we’re going to take advantage of the way that Windows accessibility tools can launch from the login screen, before any user has yet logged in. The accessibility tool is simply an executable in the Windows System32 directory called sethc.exe. The login screen lauches the tool by calling the executable with the name sethc.exe, so we can trick the login screen to launch any executable by setting the desired executable’s name to sethc.exe and placing it in the same path.

To start with, let’s keep a backup copy of sethc.exe in case we want to restore it later (…maybe accessibility is important to your users!)

ren D:\Windows\System32\sethc.exe sethc.exe.bak

While we can cause any executable to be launched from the login screen, likely the most versitile is cmd.exe. Make a copy and name it sethc.exe

cp D:\Windows\System32\cmd.exe D:\Windows\System32\sethc.exe

And with that you’re set to reboot and regain your access! When you’re back to the login page of your existing Windows installation, press Shift five times to trigger the launch of sethc.exe (our impersonating cmd.exe). Alternately you can launch sticky keys from the accessibility menu icon in the lower right. Doing so should present you with an elevated command window with Administrator access. From here you could enable the built-in Administrator account and set the password for it

net user Administrator [password] /active:yes

Since the built-in administrator account has local administrator permissions, and you know the password to it now (since you just set it), you can log in and take any action you need to, such as resetting the password on any user account, creating a user account, or whatever.

Linux OS Families

All Linux distributions rely on certain types of utilities for basic work, things like package managers and service managers. As distributions fork from other distributions a lineage is formed. Therefore we can rely, to some extent, on families of distributions typically using the same basic utilities as their parent. Outlined below is a non-comprehensive list of distributions and their decedents

Red Hat Family

The popular enterprise flavor of Linux, Red Hat is developed by Red Hat, Inc. It is probably the distribution with the most built in and compatible tools for managed networks. Uses the YUM and DNF package managers.

graph TD;
	B(Fedora) --> C(CentOS Stream)
	C --> A[Red Hat Enterprise Linux]
	A --> D(Rocky Linux)
	A --> E(AlmaLinux)
	A --> F(Oracle Linux)
	A --> G(ClearOS)
	click A "https://www.redhat.com"
	click B "https://getfedora.org"
	click C "https://www.centos.org"
	click D "https://rockylinux.org"
	click E "https://almalinux.org"
	click F "https://www.oracle.com/linux"
	click G "https://www.clearos.com"

Debian Family

Debian is actually less popular than its most popular descendant, Ubuntu. Uses the APT package manager.

graph TD;
	A[Debian] --> B(Ubuntu)
	A --> C(Kali Linux)
	A --> D(Linux Mint)
	A --> E(PureOS)
	click A "https://www.debian.org"
	click B "https://ubuntu.com"
	click C "https://www.kali.org"
	click D "https://linuxmint.com"
	click E "https://pureos.net"

Alpine Family

The Alpine distribution is most often used as a base for light weight container images, due to it’s minimal size and the performance benefits of its design to run entirely in RAM. Uses the apk package manager.

graph TD;
	A[Alpine Linux]
	click A "https://alpinelinux.org"

Arch Family

Created with the objective of being a minimal Linux distribution, Arch was loosely based on another minimal Linux distro called CRUX. Arch uses the pacman package manager.

graph TD;
	A[Arch Linux] --> B(Manjaro)
	A --> C(EndeavourOS)
	A --> D(Garuda Linux)
	A --> E(SteamOS)
	click A "https://archlinux.org"

Suse Family

Suse is one of the oldest Linux distributions still in active development, and is geared towards an enterprise environment. This was the OS I built my first hypervisor on back in 2013, using its built-in virtualization environment. Uses the YaST standard package management system.

graph TD;
	A[SUSE Linux Enterprise Server]
	click A "https://www.suse.com"

Slackware Family

A special mention to Slackware, another very old Linux distribution, and the first Linux OS that I installed. Extremely minimal and package stable, this distro aims to be very trimmed down. Available today with a desktop manager preinstalled it used to be command-line only. It was a fork of Softlanding Linux, back around the dawn of Linux.

graph TD;
	B(Softlanding Linux System) --> A[Slackware Linux]
	click A "http://www.slackware.com"

Read more about the history of Linux, which began with Unix, in this article from The Register: https://www.theregister.com/2024/01/27/opinion_column/

Setting Up SNMP Windows 10 Client

It used to be possible to monitor your Windows 10 client with SNMP by enabling it in Windows Features, however SNMP has been deprecated since Windows 10 version 1809. This article stands as a reminder that it is no longer supported in modern version of Windows. Microsoft offers Common Information Model (CIM) as the preferred replacement service.