Parameters are not being respected

[vallamost]

When deploying GitHub enterprise by following the deployment buttons on this page: https://aws.amazon.com/quickstart/architecture/github-enterprise/

The parameters you give during the CFN setup are not respected / used. When you visit the IP of the new instance you're brought to a screen where you have to specify your license and user credentials to set up your environment with.

[emcfins]

Can you provide more details on the parameters you are entering and how they are not being respected?
Also, please provide any errors you may be seeing from the /var/log/cloud-init-output.log
These details will help in troubleshooting.
Thank you.

[vallamost]

@emcfins
https://console.aws.amazon.com/cloudformation/home?region=us-west-2#/stacks/new?stackName=GitHub-Enterprise&templateURL=https://s3.amazonaws.com/quickstart-reference/github/enterprise/latest/templates/quickstart-github-enterprise.template

Run this Deployment URL through CFN, you'll get errors with AMIs, if you fix the AMIs, and then proceed to the next step and fill out all of the parameters CFN is asking you, S3 license location, admin password, admin username, etc, none of these will be configured on the newly launched GitHub Server. It will instead take you to the initial setup screen asking you for the license file, admin password, etc.

[vallamost]

Here's my cloud-init-output
https://gist.githubusercontent.com/isseiler/7b33158d4f794ba8b212fb66c99fe67c/raw/f2e313dd5526cc6726aaf90039ffe41fab5671d0/cloudinit-git-hub-issues

notable spot from it:

Loading config/console.rb
The Make Org HTTP status code: 401
Script bash [FAILED]
exit code 1

Just to note, the license does get copied from my S3 bucket as I was able to md5sum the license in /tmp and see that it matched the MD5 of the license file in my bucket.

[emcfins]

We are working with the Github team on this issue.

[vallamost]

Thanks for letting me know, do you have any updates at this time?

[ju2wheels]

The current templates do not acknowledge the parameters provided and cause you to configure everything from the UI because the templates attempt to download the scripts from the S3 buckets via HTTPS instead of using aws s3 cp like the scripts themselves use. So since the cloud init cannot download the scripts unless you have actually enabled HTTPS on your bucket, this silently fails and none of the configuration actually happens, therefore leaving it to you to configure yourself once the instance comes up.

Also im not sure if the default bucket in these examples is supposed to work or not, but it didnt for me, so I had to move the scripts folder from this repo into my own bucket.

[emcfins]

It is my understanding that this issue was resolved by #9 and #13
@ju2wheels - are you having the same issue as above from your cloud-init-output log ?
Error as:

Loading config/console.rb
The Make Org HTTP status code: 401
Script bash [FAILED]
exit code 1

If not, please open a new issue with details on what you are seeing.

[ju2wheels]

@emcfins I rebuilt my instance quite a few times today so dont have the exact errors. But I opened #18 and #19 which were the root cause of me getting the same general result of the parameters being supplied to the template getting ignored and having to manually do the license upload, user creation, and org creation.

1. The default bucket (QSS3BucketName which is set to aws-quickstart) its trying to get scripts/ from didnt work with the default template so that causes none of the subsequent configuration to happen. Its unclear whether that bucket is expected to exist on AWS's side as part of making the examples work or if it is assumed we would point that at the same bucket we use to hold our license (LicenseLocation) and copy the scripts/ content there ourselves.
2. The GHELicense location cannot begin with / or it fails in the same way that QSS3KeyPrefix would, but QSS3KeyPrefix explicitly says that already in its description.
3. The templates assume all buckets used to get the license and scripts have HTTPS web access enabled but dont specifically mention that anywhere.

An error in any of these things leads to the same general issue described in the title of this ticket despite the fact that the individual errors for each condition may be different and occur at different points in the scripts.

On the same note, the scripts themselves may be using -e in the shebangs but the cloud-init script is not so it may be ignoring the exit errors from the scripts and keep on chugging instead of stopping the instance creation with an error.