local RPM install

[evandena]

Expected behavior

Option to install a local RPM in the spel build box.

Actual behavior

From packer:

    amazon-ebs.minimal-rhel-8-hvm: + git clone --branch master https://github.com/plus3it/AMIgen8.git /tmp/el-build
    amazon-ebs.minimal-rhel-8-hvm: Cloning into '/tmp/el-build'...
    amazon-ebs.minimal-rhel-8-hvm: fatal: unable to access 'https://github.com/plus3it/AMIgen8.git/': OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to github.com:443
==> amazon-ebs.minimal-rhel-8-hvm: Provisioning step had errors: Running the cleanup provisioner, if present...

This is due to our MITM firewall and a base RHEL OS not trusting our internal certificate.

Suggestions for fix

Is there an easy way to specify a local RPM to install during the build? We could easily bundle up our internal certificates as an RPM. I see the EXTRARPMS variable, but it appears that's just doing a yum install.
It would be neat to be able to provide a local RPM and have packer push it to the build box, and one of the spel processes be able to install it.

[lorengordon]

Hmm, that's tricky. Is there any host where you could push the RPM where it is accessible by either HTTP (not TLS), or HTTPS such that the network path bypasses or is exempted by the firewall, and where the network path allows the instance to reach the host? That's how we do it, when building images that require custom certs. Basically just host the RPM with the certs somewhere the instance can actually download it, and specify it as the first package in the amgien8_extra_rpms argument. It gets downloaded by yum, installed, and then the certs are available for everything else.

[evandena]

Thanks for the response @lorengordon.
That's definitely an option, and probably the easiest one to implement, but I can imagine an internal scan finding an insecure webserver and that causing some misguided issues.

Maybe I could look into terraform building an s3 bucket in the pipeline and destroying it after the spel build.

An option we use on our post-spel EC2 builds is to add the certs in the cloudinit user-data, but I'm trying to solve the spel problem with little (if any) spel code modification. We're already doing a handful of sed commands in our pipeline against the minimal-linux.pkr.hcl, but solving the cert issue would be more involved.

[lorengordon]

I assume you're using this cloud-init module to update certs?

We hadn't considered a mechanism to further customize the build quite like that, but I can understand the use case. It would need to be optional, of course. I can see a few ways to get there:

1. Use the cloud-init module, perhaps with packer's templatefile() function to inject the values, with a list of certs as a new input. That will work for the builders, but that won't get the certs into the resulting images. But, if you also host the rpm via HTTPS you could pass then pass the url via amigen8_extra_rpms.
2. Similar, but don't use cloud-init (we've been moving things out of cloud-init, to improve logging/debugging in the packer output). Just add the logic to the amigen scripts to install the certs.
3. Use the file provisioner to upload local rpms to a directory on the builders. Prepend the local paths to the extra rpms list. That should work for both the builders and the resulting images.

[ferricoxide]

Worth noting that, at least in the meantime, you can bootstrap from arbitrary AMIs. You could select a customized AMI that was the same as the one(s) you're currently selecting but for having baked-in the requisite certs. That would get you past the git errors (and then use the amigen8_extra_rpms var to also bake your site's private certs into the spel-built AMI(s). Effectively, this is what's done by other user of spel that have similar SSL-validation-breaking security-appliances.

[lorengordon]

@evandena Would you be interested in working on a PR that implements a solution for this use case? I don't really see us getting to it any time soon... But if you open a PR that works for you, I'll be happy to review it and provide feedback and get it merged.