UNCLASSIFIED - NO CUI

Skip to content

guacamole-client:1.3.0 will not start in AWS GovCloud Fargate

Summary

(Summarize the bug encountered concisely)

I created an AWS GovCloud ECS cluster, service, task definition, container definitions, security groups, policies, and RDS postgres to run guacamole/guacamole:latest and guacamole/guacd:latest containers. These containers ran fine and I was able to access the http://[host]:8080/guacamole login page. I swapped the guacd container with guacamole-server:1.3.0 and there was no issue. I swapped the guacamole container with guacamole-client:1.3.0, and the container tries to initialize and then stops. The only log output from the container (or anything for that matter) is: mkdir: cannot create directory ‘/opt/guacamole/.guacamole’: Permission denied. I checked the postgres init.sql dump from guacamole-client:1.3.0 docker run --rm registry1.dso.mil/ironbank/opensource/apache/guacamole/guacamole-client:1.3.0 /opt/guacamole/bin/initdb.sh --postgres > init.sql but it is the same as what I currently have.

Steps to reproduce

(How one can reproduce the issue - this is very important)

I believe at a minimum you can do the following:

  • Create an ecs task role that has a trust relationship with ecs-tasks.amazonaws.com and the following permissions:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ecr:GetAuthorizationToken",
                "ecr:BatchCheckLayerAvailability",
                "ecr:GetDownloadUrlForLayer",
                "ecr:BatchGetImage",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue"
            ],
            "Resource": [
                "[arn for secret manager secret: guacamole database user/pass]"
            ]
        }
    ]
}
  • Stand up an RDS postgres instance with the following settings and configure it with init.sql and a user/pass that go into AWS Secret Manager.
settings = {
    "az"                    = "us-gov-east-1a",
    "dbname"                = "guacamole",
    "backup_retention"      = "7",
    "storage_type"          = "gp2",
    "storage_encrypt"       = "true",
    "storage_min"           = "10",
    "storage_max"           = "100",
    "engine"                = "postgres",
    "engine_version"        = "13.3",
    "engine_type"           = "db.t3.micro",
    "license"               = "postgresql-license",
    "port"                  = "5432"
  }
  • Stand up an ECS cluster

  • Stand up a Task definition with the following settings:

settings = {
    cpu                = 256
    memory             = 1024
    execution_role_arn = [ECS task arn]
}
  • Add container definitions with the following properties:
{
  "name": "guacamole-server",
  "image": "[ECR endpoint]/guacamole-server:1.3.0",
  "portMappings": [
    {
      "containerPort": 4822
    }
  ]
},
{
  "name": "guacamole-client",
  "image": "[ECR endpoint]/guacamole-client:1.3.0",
  "portMappings": [
    {
      "containerPort": 8080
    }
  ],
  "environment": [
    {
      "name": "GUACD_HOSTNAME",
      "value": "0.0.0.0"
    },
    {
      "name": "GUACD_PORT",
      "value": "4822"
    },
    {
      "name": "POSTGRES_HOSTNAME",
      "value": "[RDS hostname]"
    },
    {
      "name": "POSTGRES_PORT",
      "value": "5432"
    },
    {
      "name": "POSTGRES_DATABASE",
      "value": "[RDS guacamole database name]"
    }
  ],
  "secrets": [
    {
      "name": "POSTGRES_USER",
      "valueFrom": "[secretsmanager arn]:username::"
    },
    {
      "name": "POSTGRES_PASSWORD",
      "valueFrom": "[secretsmanager arn]:password::"
    }
  ]
}

What is the current bug behavior?

(What actually happens)

The task launches, the containers guacamole-server:1.3.0 and guacamole-client:1.3.0 both go to a PENDING status. After a moment the guacamole-server:1.3.0 container goes to RUNNING and the guacamole-client:1.3.0 container goes to STOPPED.

What is the expected correct behavior?

(What you should see instead)

The task launches, the containers guacamole-server:1.3.0 and guacamole-client:1.3.0 both go to a PENDING status. After a moment the guacamole-server:1.3.0 container goes to RUNNING and the guacamole-client:1.3.0 container goes to RUNNING.

If using the guacamole/guacamole:latest container, this is what happens.

Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's very hard to read otherwise.)

The only log I have found so far is the container log for guacamole-client:1.3.0

mkdir: cannot create directory ‘/opt/guacamole/.guacamole’: Permission denied

Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

I believe the relevant lines of code are:

scripts/start.sh line 33: GUACAMOLE_HOME="$HOME/.guacamole"
scripts/start.sh line 55: mkdir -p "$GUACAMOLE_HOME"

I don't know if it matters, but AWS Fargate is now running platform 1.4 which uses containerd instead of Docker.

Defintion of Done

  • Bug has been identified and corrected within the container
Edited by Colton Freeman
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information