How I Fixed: Error: The number of path segments is not divisible by 2 in “”

Perhaps “how I fixed” is a poor title for this one. I don’t think I fixed it, but I found a workaround.

Here’s the gist of the problem:

docker run --rm \
		--env-file /path/to/my/terraform/azure/.env \
		-v /path/to/my/terraform/azure:/workspace \
		-w /workspace \
		my-custom/terraform:local \
		apply --auto-approve
╷
│ Error: The number of path segments is not divisible by 2 in ""
│ 
│   with azurerm_linux_virtual_machine.christest,
│   on create-instance.tf line 1, in resource "azurerm_linux_virtual_machine" "christest":
│    1: resource "azurerm_linux_virtual_machine" "christest" {
│ 
╵
╷
│ Error: The number of path segments is not divisible by 2 in ""
│ 
│   with azurerm_linux_virtual_machine.christest,
│   on create-instance.tf line 1, in resource "azurerm_linux_virtual_machine" "christest":
│    1: resource "azurerm_linux_virtual_machine" "christest" {
│ 
╵
╷
│ Error: The number of path segments is not divisible by 2 in ""
│ 
│   with azurerm_linux_virtual_machine.christest,
│   on create-instance.tf line 1, in resource "azurerm_linux_virtual_machine" "christest":
│    1: resource "azurerm_linux_virtual_machine" "christest" {
│ 

Some extra info that may / may not be helpful in this particular instance is that I wanted to run Terraform through Docker. In order to work with Azure command line (az) I had to bake that into the Dockerfile

FROM hashicorp/terraform:1.0.10

RUN \
  apk update && \
  apk add bash py-pip && \
  apk add --virtual=build gcc libffi-dev musl-dev openssl-dev python3-dev make && \
  python3 -m pip install --upgrade pip && \
  python3 -m pip install azure-cli && \
  apk del --purge build

To build the Dockerfile I then do a docker build -t my-custom/terraform:local . which is where that custom Docker image is coming from above. Names changed to protect the innocent.

Anyway, I have a bunch of files in this project mainly to split things out for the sake of my sanity. Where Terraform seemed to die was with this first file:

resource "azurerm_linux_virtual_machine" "christest" {
  name                            = "${var.owner}-vm"
  resource_group_name             = azurerm_resource_group.christest.name
  location                        = azurerm_resource_group.christest.location
  size                            = var.instance_size
  admin_username                  = "adminuser"
  admin_password                  = "abadpassword"
  disable_password_authentication = false
  network_interface_ids = [
    azurerm_network_interface.christest.id,
  ]

  source_image_id = var.source_image_id

  os_disk {
    storage_account_type = "Standard_LRS"
    caching              = "ReadWrite"
  }
}

By and large, I’d simply copied this from the docs and then tried to be a smart arse and turned some of the things into variables.

Here’s where things got confusing.

As above, the Terraform output complains that:

Error: The number of path segments is not divisible by 2 in ""

This error repeats three times.

Hmmm. Three times… well, wait. Don’t I have three variables here, right at the top? Probably them, right?

No. No matter what I did – and it got to the point where I hardcoded them – the error remained. If it remained when they were just plain old strings, there was no way it was these lines causing the problem.

So, I dutifully copy / pasted the entire Azure config in from the docs, and lo-and-behold, that worked first time. D’oh.

What else had I changed?

source_image_id = var.source_image_id

And the associated variable I’d created:

# az vm image list --output table

variable "source_image_id" {
  description = "The ID of the Image which this Virtual Machine should be created from"
  type        = string
  default     = "Canonical:UbuntuServer:18.04-LTS:latest"
}

That’s not how it’s set in the example from the docs. Here’s what they have:

  source_image_reference {
    publisher = "Canonical"
    offer     = "UbuntuServer"
    sku       = "18.04-LTS"
    version   = "latest"
  }

Annoyingly, I didn’t even need this set as a variable. I’d just tried to be that aforementioned smart arse, which had bitten me on said arse.

There isn’t an example in the docs of how to use source_image_id, I’d just guessed. Wrongly, it seems.

And why I say I haven’t fixed this is I still don’t know the right format to use here. I just know that by using source_image_reference then the error goes away. Good enough for me.

How I Fixed: docker: Error response from daemon: Decoding seccomp profile failed: json: cannot unmarshal array into Go value of type seccomp.Seccomp.

Another day, another cryptic error message from Docker.

Right, so here’s what I was trying to do.

Blindly following the Playwright docs for getting a Playwright Docker container up and running, I first created a new file, seccomp_profile.json inside the current directory. The location of this directory is irrelevant, just the file needs to live in the directory from which you (or I) run the command.

And the command is directly lifted from the 1.14 docs:

docker run -it --rm --ipc=host --user pwuser --security-opt seccomp=seccomp_profile.json mcr.microsoft.com/playwright:focal /bin/bash

When doing this, I got the error above, but for clarity (and for SEO purposes) here it is again:

docker: Error response from daemon: Decoding seccomp profile failed: json: cannot unmarshal array into Go value of type seccomp.Seccomp.

This tells us that whilst the file was read, the contents are somehow wrong.

I’m just going to skip straight to the fix here, as I tried a few things and got lucky. Sadly, I don’t know jack about Golang, but I loosely understand the error above as saying hey, Chris, that JSON file doesn’t decode into a format my program is expecting.

Here’s what MS give:

[
  {
    "comment": "Allow create user namespaces",
    "names": [
      "clone",
      "setns",
      "unshare"
    ],
    "action": "SCMP_ACT_ALLOW",
    "args": [],
    "includes": {},
    "excludes": {}
  }
]

And here’s what it needs to be:

  {
    "comment": "Allow create user namespaces",
    "names": [
      "clone",
      "setns",
      "unshare"
    ],
    "action": "SCMP_ACT_ALLOW",
    "args": [],
    "includes": {},
    "excludes": {}
  }

Or, in short, not an array. Just a single object.

Why the docs have it that way, I don’t know.

Go figure.

Arf arf.

How I Fixed: unknown flag: –project-name in GitHub Actions

Bit of an obscure one this, and given that I received absolutely no Google results, I’m guessing may be of little help to … well, anyone. But perhaps this is the price one pays for being an early adopter.

The Problem

I created a GitHub actions workflow that ran a Makefile command. It looked something like this:

---
name: E2E Tests

on: [push, pull_request]

jobs:
    test:
        runs-on: ubuntu-latest

        steps:
            - uses: actions/checkout@v2

            - name: make install
              run: make install

            - name: make serve
              run: make serve

Excuse the crappy steps, I was / am still kinda experimenting with this workflow.

Anyway, what we really care about (and where the problem actually lies) is in what the make install command represents:

serve:
	docker compose \
		-p my_project_name_here \
		 --remove-orphans && \
		docker compose up --remove-orphans
.PHONY: serve

Don’t be put off if you don’t use / understand Makefile‘s, but if you don’t, they are pretty useful. Other solutions exist, yadda yadda.

Keen eyed readers will have spotted something potentially curious:

docker compose ...

Not:

docker-compose ...

Yeah, so I got this from a little info at the end of my local command line output:

➜  my-project git:(e2e-tests-setup) docker-compose
Define and run multi-container applications with Docker.

Usage:
  docker-compose [-f <arg>...] [--profile <name>...] [options] [--] [COMMAND] [ARGS...]
  docker-compose -h|--help

 ...

Docker Compose is now in the Docker CLI, try `docker compose`

(Excuse the formatting, WP does its own thing)

See that line at the very end. Why not try the new stuff, right? Who doesn’t love the shiny.

But herein lies the problem. Note, even the official docs aren’t (yet) consistent in what format they use.

The Solution

The solution to this problem is super simple.

Use docker-compose for your GitHub actions commands.

The problem arises because GitHub actions thinks I’m trying to run docker commands, and must be using an older version of the Docker CLI.

Locally:

docker -v
Docker version 20.10.7, build f0df350

GitHub Actions:

Run docker -v
Docker version 20.10.7+azure, build f0df35096d5f5e6b559b42c7fde6c65a2909f7c5

Anyway, my fix was to change the Makefile command to use docker-compose instead of docker compose:

serve:
	docker-compose \
		-p my_project_name_here \
		 --remove-orphans && \
		docker-compose up --remove-orphans
.PHONY: serve

How I Fixed: Error response from daemon: Get https://registry.example.com/v2/: unauthorized: HTTP Basic: Access denied

OK – silly problem time.

A while back I force reset the password of one of my automated CI users. For a variety of reasons, I never checked that this had worked properly.

When I went to log in via the command line today, I was getting this:

➜  docker login -u myuser registry.example.com
Password: 
Error response from daemon: Get https://registry.example.com/v2/: unauthorized: HTTP Basic: Access denied

Very confusing.

I hard reset the user’s password via the GitLab Admin Panel, but still the problem persisted.

Simple fix: log in as this user via the web GUI.

Once you do that, you should see the password change prompt. Change your password there, and et voila, you can now login from the command line again.

It would be useful if the service offered a better message around this occurrence, but I’m guessing it’s a bit of a weird edge case. I’m actually not sure if the issue lies with GitLab or the Docker Registry image honestly.

Either way, hopefully that solves your problem.

How I Fixed: docker: invalid reference format With Makefile

I’m a big fan of makeshift Makefiles. Largely because I don’t seem to have the brain capacity to remember long winded commands. Or maybe, I just don’t like typing out long winded commands. One of the two reasons, for sure.

In using a Makefile to set up a local DNS server to help resolve an issue with multiple different related, but separated Docker projects being able to talk to one another, I ended up coming across this Stack Overflow post which was very helpful.

The solution from the post calls for running a Docker command to spin up a local DNS server, which then allows all the disparate services to talk to one another via hostname, rather than IP address.

I dutifully created a new Makefile entry:

start_dev_dns:
	@docker run \
		--rm \ 
		--hostname=dns.mageddo \
		-p 5380:5380 \
		-v /var/run/docker.sock:/var/run/docker.sock \
		-v /etc/resolv.conf:/etc/resolv.conf \
		defreitas/dns-proxy-server

It’s hard to spot the fault here. That command looks right to me.

I copy / pasted the command direct from the Stack Overflow post, added in the --rm flag to ensure the resulting container gets removed when I kill it, and then tried to run the command:

 ➜ myproject.whatever make start_dev_dns
docker: invalid reference format.
See 'docker run --help'.
make: *** [Makefile:8: start_dev_dns] Error 125

Boo.

Anyway, after a bit of head scratching, it turns out the issue was an extra space after the line continuation slash.

Really hard to display this one on a blog post. But essentially if you see this and you’re in a similar situation, check you don’t have any rogue spaces after the \‘s at the end of each line.