Bug 274958 - sysutils/ec2-scripts: Core dump when configinit is given an archive
Summary: sysutils/ec2-scripts: Core dump when configinit is given an archive
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Colin Percival
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-11-07 22:59 UTC by Allan Saddi
Modified: 2023-11-08 08:16 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (cperciva)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Allan Saddi 2023-11-07 22:59:06 UTC
This seems to be related to:

https://github.com/aws/aws-ec2-imdsv2-get/issues/3

When passing an archive via EC2 userdata, aws-ec2-imdsv2-get dumps core due to "stream did not contain valid UTF-8."

The old method of fetching the configuration data from http://169.254.169.254/latest/user-data still seems to work fine.
Comment 1 Colin Percival freebsd_committer freebsd_triage 2023-11-08 05:22:15 UTC
Whoops.  Yeah, that's a bug in aws-ec2-imdsv2-get.  I'll see if the author can fix it; if not I'll work something out (but I don't really do Rust, so I'd rather get it fixed by someone else).  Unfortunately it's too late for this to be fixed in 14.0-RELEASE. :-(

In case it helps, parsing a tarball should work just fine since those are 7-bit-safe; it's parsing *compressed* archives which will break.

(Incidentally, I'd love to hear about how you're using FreeBSD on EC2; I don't get much feedback from users.)
Comment 2 Allan Saddi 2023-11-08 07:47:54 UTC
(In reply to Colin Percival from comment #1)

Thanks for the tip about using an uncompressed tarball. Though with the EC2 userdata limit being something like 16K(?), I will probably run into issues.

I'm just a hobbyist who has a tendency to self-host; I've been running FreeBSD on EC2 since around 2014 on a few instances (much thanks to you ;-)

It's just a few reserved instances hosting websites, web applications (Java/PHP/Python), mail, among other things. Basically a glorified VPS. Prior to that, my services ran on physical hardware in a Bay Area datacenter...

Anyway, I ran into this issue while updating the base image for my package builder (poudriere) AMI to 13.2-RELEASE-p4. My image builder script usually does a "pkg upgrade" and a "freebsd-update" before snapshotting so the resulting instance launched from that AMI comes up faster. Skipping the "pkg upgrade" so it uses the older version of ec2-scripts seems to work around the problem for now.

Thanks again for your help. I found that aws-ec2-imdsv2-get github issue and noticed it was from August. So I was curious if you knew about it and opened this bug...
Comment 3 Colin Percival freebsd_committer freebsd_triage 2023-11-08 08:16:42 UTC
Indeed, I was not aware of the github issue from August.  (It's possible that someone told me about it but I forgot -- I was pretty busy that month.)  So thanks for alerting me to it.