forked from mirrors/nixpkgs
{ec2,openstack}-metadata-fetcher: unconditionally fetch metadata
The metadata fetcher scripts run each time an instance starts, and it is not safe to assume that responses from the instance metadata service (IMDS) will be as they were on first boot. Example: an EC2 instance can have its user data changed while the instance is stopped. When the instance is restarted, we want to see the new user data applied.
This commit is contained in:
parent
8c39655de3
commit
43bfd7e5b1
|
@ -8,9 +8,14 @@
|
|||
# Make sure that every package you depend on here is already listed as
|
||||
# a channel blocker for both the full-sized and small channels.
|
||||
# Otherwise, we risk breaking user deploys in released channels.
|
||||
#
|
||||
# Also note: OpenStack's metadata service for its instances aims to be
|
||||
# compatible with the EC2 IMDS. Where possible, try to keep the set of
|
||||
# fetched metadata in sync with ./openstack-metadata-fetcher.nix .
|
||||
''
|
||||
metaDir=${targetRoot}etc/ec2-metadata
|
||||
mkdir -m 0755 -p "$metaDir"
|
||||
rm -f "$metaDir/*"
|
||||
|
||||
get_imds_token() {
|
||||
# retry-delay of 1 selected to give the system a second to get going,
|
||||
|
@ -65,19 +70,8 @@
|
|||
wget ${wgetExtraOptions} --header "X-aws-ec2-metadata-token: $IMDS_TOKEN" "$@";
|
||||
}
|
||||
|
||||
if ! [ -e "$metaDir/ami-manifest-path" ]; then
|
||||
wget_imds -O "$metaDir/ami-manifest-path" http://169.254.169.254/1.0/meta-data/ami-manifest-path
|
||||
fi
|
||||
|
||||
if ! [ -e "$metaDir/user-data" ]; then
|
||||
wget_imds -O "$metaDir/user-data" http://169.254.169.254/1.0/user-data && chmod 600 "$metaDir/user-data"
|
||||
fi
|
||||
|
||||
if ! [ -e "$metaDir/hostname" ]; then
|
||||
wget_imds -O "$metaDir/hostname" http://169.254.169.254/1.0/meta-data/hostname
|
||||
fi
|
||||
|
||||
if ! [ -e "$metaDir/public-keys-0-openssh-key" ]; then
|
||||
wget_imds -O "$metaDir/public-keys-0-openssh-key" http://169.254.169.254/1.0/meta-data/public-keys/0/openssh-key
|
||||
fi
|
||||
wget_imds -O "$metaDir/ami-manifest-path" http://169.254.169.254/1.0/meta-data/ami-manifest-path
|
||||
wget_imds -O "$metaDir/user-data" http://169.254.169.254/1.0/user-data && chmod 600 "$metaDir/user-data"
|
||||
wget_imds -O "$metaDir/hostname" http://169.254.169.254/1.0/meta-data/hostname
|
||||
wget_imds -O "$metaDir/public-keys-0-openssh-key" http://169.254.169.254/1.0/meta-data/public-keys/0/openssh-key
|
||||
''
|
||||
|
|
|
@ -1,7 +1,12 @@
|
|||
{ targetRoot, wgetExtraOptions }:
|
||||
|
||||
# OpenStack's metadata service aims to be EC2-compatible. Where
|
||||
# possible, try to keep the set of fetched metadata in sync with
|
||||
# ./ec2-metadata-fetcher.nix .
|
||||
''
|
||||
metaDir=${targetRoot}etc/ec2-metadata
|
||||
mkdir -m 0755 -p "$metaDir"
|
||||
rm -f "$metaDir/*"
|
||||
|
||||
echo "getting instance metadata..."
|
||||
|
||||
|
@ -9,19 +14,8 @@
|
|||
wget ${wgetExtraOptions} "$@"
|
||||
}
|
||||
|
||||
if ! [ -e "$metaDir/ami-manifest-path" ]; then
|
||||
wget_imds -O "$metaDir/ami-manifest-path" http://169.254.169.254/1.0/meta-data/ami-manifest-path
|
||||
fi
|
||||
|
||||
if ! [ -e "$metaDir/user-data" ]; then
|
||||
wget_imds -O "$metaDir/user-data" http://169.254.169.254/1.0/user-data && chmod 600 "$metaDir/user-data"
|
||||
fi
|
||||
|
||||
if ! [ -e "$metaDir/hostname" ]; then
|
||||
wget_imds -O "$metaDir/hostname" http://169.254.169.254/1.0/meta-data/hostname
|
||||
fi
|
||||
|
||||
if ! [ -e "$metaDir/public-keys-0-openssh-key" ]; then
|
||||
wget_imds -O "$metaDir/public-keys-0-openssh-key" http://169.254.169.254/1.0/meta-data/public-keys/0/openssh-key
|
||||
fi
|
||||
wget_imds -O "$metaDir/ami-manifest-path" http://169.254.169.254/1.0/meta-data/ami-manifest-path
|
||||
wget_imds -O "$metaDir/user-data" http://169.254.169.254/1.0/user-data && chmod 600 "$metaDir/user-data"
|
||||
wget_imds -O "$metaDir/hostname" http://169.254.169.254/1.0/meta-data/hostname
|
||||
wget_imds -O "$metaDir/public-keys-0-openssh-key" http://169.254.169.254/1.0/meta-data/public-keys/0/openssh-key
|
||||
''
|
||||
|
|
Loading…
Reference in a new issue