lib missing - /lib64/libc.so.6: version `GLIBC_2.18 - cfn submit zip missing library
JohnPreston opened this issue · 10 comments
Submitted a new resource version using the latest versions of the CLI and LIB and when running in CFN I am getting
the following error.
Lambda function handler threw an uncaught exception: Unable to import module 'mongodb_atlas_awsiamdatabaseuser.handlers': /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /var/task/cryptography/hazmat/bindings/_rust.abi3.so)
.cfn_metata.json content (as uploaded by cfn submit)
{"plugin-tool-version": "2.1.5", "plugin-name": "python", "cli-version": "0.2.24"}.rpdk-config content (as uploaded by cfn submit)
{
"artifact_type": "RESOURCE",
"typeName": "MongoDb::Atlas::AwsIamDatabaseUser",
"language": "python37",
"runtime": "python3.7",
"entrypoint": "mongodb_atlas_awsiamdatabaseuser.handlers.resource",
"testEntrypoint": "mongodb_atlas_awsiamdatabaseuser.handlers.test_entrypoint",
"settings": {
"version": false,
"subparser_name": null,
"verbose": 0,
"force": false,
"type_name": null,
"artifact_type": null,
"use_docker": false,
"protocolVersion": "2.0.0"
}
}Only workaround found is to build the ResourceProvider.zip myself.
Same thing with me. I was hoping to make cfn work with private Python repos (I have a dependency to my Cloudformation hook sitting in a private Python registry), but "use_docker": true doesn't allow that, so I set "use_docker": false, but that would lead to my Hook fail at runtime since it (the generated lambda function with dependencies) doesn't have proper libraries installed e.g. glibc etc.
So the problem is that you're building your hook without docker, which means that cfn will use your host architecture to build certain dependencies (.so files, etc. ) and/or some dependencies will use some low-level libraries (e.g. glibc) in runtime. That means that while building your hook (cfn submit) you will need to mimic the Lambda execution environment. See my comment in aws-cloudformation/cloudformation-cli#890
So I figured out what was wrong for me but the thing is I re-implemented what cfn submit does via makefile, because that allowed me to make more gradual changes and run local tests. And also write my own CFN template to allow for StackSet based deployment.
But to build the layer / resource zip file, I was using Docker for that and the source image I was using was a lean one. Using the ones from https://gallery.ecr.aws/lambda/python fixed that all and then I'd get all that was needed to work in the layer "build" folder.
Apologies for not commenting on that earlier / when I figured a workaround that "worked for me" (again, mostly out of not using the cfn submit command.
Is any of that open source? Would love to see it!
Is any of that open source? Would love to see it!
I rarely do close source. Also, hard to get trust for publicly available resources when it's closed up (haha)
This one is most likely the latest and most up to date: https://github.com/compose-x/aws-cfn-confluentcloud-iam-serviceaccount
It's GPL-2.0 because Confluent licenses things with licenses that betray their Apache 2.0 root, in case you were wondering.
Here is another I haven't given much love in a while, I should update the deps some time soon and align the Makefile.
https://github.com/compose-x/aws-cfn-mongodb-atlas-awsiamdatabaseuser
Thanks for sharing! If you haven't seen it already, check out our Discord at https://discord.gg/9zpd7TTRwq, and the new community registry extensions repo at https://github.com/aws-cloudformation/community-registry-extensions.
Here is another I haven't given much love in a while, I should update the deps some time soon and align the Makefile. https://github.com/compose-x/aws-cfn-mongodb-atlas-awsiamdatabaseuser
Looks like that one is private.
Here is another I haven't given much love in a while, I should update the deps some time soon and align the Makefile. https://github.com/compose-x/aws-cfn-mongodb-atlas-awsiamdatabaseuser
Looks like that one is private.
Fixed. I never did realize that. Thanks for pointing it out.