AWS Boundary Deployment script not running on controllers after terraform apply

I have tested the boundary-reference-architecture/ at main · hashicorp/boundary-reference-architecture · GitHub repository for AWS deployment.
After creating both controllers and workers ubuntu servers on my AWS account I have connected to one of the controllers to check if the was copied to the machine but when trying to run it (using the same command on terraform “sudo ~/./ controller” and it write:
: not 4:

also from terraform itself we can see that remote-exec: not found pops up:

I have checked with simple script “hello world” to check if there is some problem with the commands on thee server but it runs fine

what do I need to proceed with running the script as it should?

I just tried the reference architecture and it worked as it should, e.g. this happens on one of my controllers at the provisioning stage:[1] (remote-exec): Connected![1] (remote-exec): Adding system user `boundary' (UID 113) ...[1] (remote-exec): Adding new group `boundary' (GID 119) ...[1] (remote-exec): Adding new user `boundary' (UID 113) with group `boundary' ...[1] (remote-exec): Creating home directory `/home/boundary' ...[1] (remote-exec): Unable to capture a lock on the database.[1] (remote-exec): Created symlink /etc/systemd/system/ → /etc/systemd/system/boundary-controller.service.[1]: Creation complete after 3m18s [id=*redacted*]

…which is exactly what should happen.

Has the script maybe gotten changed? The sha256sum of the copy on my controller is:

$ sha256sum /home/ubuntu/ 
0b844f64a04dabcf313e23c4381d3396f326fa656362ce5b8e220ea3c9cf7c06  /home/ubuntu/

Yes It is, can you provide me the exact I haven’t changed there nothing

Installs the boundary as a service for systemd on linux



sudo cat << EOF > /etc/systemd/system/{NAME}-{TYPE}.service


Description={NAME} {TYPE}


ExecStart=/usr/local/bin/{NAME} server -config /etc/{NAME}-${TYPE}.hcl





CapabilityBoundingSet=CAP_SYSLOG CAP_IPC_LOCK



Add the boundary system user and group to ensure we have a no-login

user capable of owning and running Boundary

sudo adduser --system --group boundary || true

sudo chown boundary:boundary /etc/{NAME}-{TYPE}.hcl

sudo chown boundary:boundary /usr/local/bin/boundary

Make sure to initialize the DB before starting the service. This will result in

a database already initizalized warning if another controller or worker has done this

already, making it a lazy, best effort initialization

if [ “${TYPE}” = “controller” ]; then

sudo /usr/local/bin/boundary database init -skip-auth-method-creation -skip-host-resources-creation -skip-scopes-creation -skip-target-creation -config /etc/{NAME}-{TYPE}.hcl || true


sudo chmod 664 /etc/systemd/system/{NAME}-{TYPE}.service

sudo systemctl daemon-reload

sudo systemctl enable {NAME}-{TYPE}

sudo systemctl start {NAME}-{TYPE}

####This is my

Also when trying to run manually commands from on DB init I get:“command not found”
Its from DB Init row in the script

Your script looks fine – I’m not sure why the sums are coming out differently for us. Might be as simple as a trailing newline or something. In any case the known-good version is here.

There are two things that might be going on here:

One is that the uploaded Boundary binary should be located at /usr/local/bin/boundary – there shouldn’t be a directory called that like there is in your screenshot, it should be the actual Boundary binary. Make sure your -var boundary_bin=[path to Boundary] points to the directory that contains the boundary binary within itself, not a higher-level directory.

The other is that if the Boundary binary you pointed at with boundary_bin is a Windows binary, it won’t work when uploaded to a Linux host. You’d need to download the Linux amd64 binary and point at that.

As a fellow Windows user, I ran into this same problem (actually both problems) so I thought it might be useful to document what happened for anyone else who stumbles across this.

When I cloned the boundary-reference-architecture repo, evidently something translated the files to windows format. All of the line endings show up as CRLF rather than the unix standard of LF. That doesn’t seem to be a problem for the *.tf files, but it does cause issues for the file.

Took me the better part of a day to figure that out…