You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
lib missing - /lib64/libc.so.6: version `GLIBC_2.18 - cfn submit zip missing library #180
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)
changed the title [-]LIB 2. - cfn submit zip missing library[/-][+]lib missing - /lib64/libc.so.6: version `GLIBC_2.18 - cfn submit zip missing library[/+]on Apr 3, 2022
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.
Activity
[-]LIB 2. - cfn submit zip missing library[/-][+]lib missing - /lib64/libc.so.6: version `GLIBC_2.18 - cfn submit zip missing library[/+]maslick commentedon Jun 29, 2022
Same thing with me. I was hoping to make
cfnwork with private Python repos (I have a dependency to my Cloudformation hook sitting in a private Python registry), but"use_docker": truedoesn'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.aws-cloudformation/cloudformation-cli#890
maslick commentedon Jul 1, 2022
So the problem is that you're building your hook without docker, which means that
cfnwill use your host architecture to build certain dependencies (.sofiles, 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#890JohnPreston commentedon Oct 19, 2022
So I figured out what was wrong for me but the thing is I re-implemented what
cfn submitdoes 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 submitcommand.ericzbeard commentedon Oct 19, 2022
Is any of that open source? Would love to see it!
kddejong commentedon Oct 19, 2022
We also switched to that image in this PR #193
JohnPreston commentedon Oct 19, 2022
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.
JohnPreston commentedon Oct 19, 2022
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
ericzbeard commentedon Oct 19, 2022
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.
ericzbeard commentedon Oct 19, 2022
Looks like that one is private.
JohnPreston commentedon Oct 19, 2022
Fixed. I never did realize that. Thanks for pointing it out.