cloud-init data from vmware guest info as it described in the link below
https://github.com/vmware/cloud-init-vmware-guestinfo
Signed-off-by: Birol Bilgin <birolbilgin@gmail.com>
Co-authored-by: Birol Bilgin <birol.bilgin@basefarm.com>
This adds a new configuration provider that just reads a file.
This is needed for Docker Desktop, where we will run a LinuxKit distro in an isolated namespace within WSL 2.
In this scenario, the config will be accessible trough the WSL2 built-in 9p mount of the Windows filesystem.
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
Use the packet metadata to set up bonding, also get ssh keys and hostname.
This does not yet do anything with disk metadata.
Userdata is not used if it has been used for ipxe, but is otherwise available.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This checks if any CDROM in the system has metadata. Useful if
you boot off CDROM and also have a metadata CDROM.
Also switch the metadata container to read only, as it is only
writing to bind mounted in directories, and /tmp.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
If the configuration .json has contents like:
{
"etc": {
"ssl": {
"certs": {
"ca-certificates.crt": {
"perm": "0644",
"content": "large amount of certificate text"
}
}
}
},
...
}
then we print a warning because the node "ssl" has no "perm".
Previously the warning would include the contents of "ssl", which
would be large (and in theory could include secret information).
This patch modifies the warning print to only print the key and
not the value.
Without this patch, I see on the console:
2017/07/20 10:03:04 CDROM: Probe succeeded
2017/07/20 10:03:04 No permission provided ssl:map[certs:map[ca-certificates.crt:map[perm:0644 content:large amount of certificate text]]]
- 000-metadata
With this patch, I see on the console:
2017/07/20 09:54:18 CDROM: Probe succeeded
2017/07/20 09:54:18 No permission provided ssl
- 000-metadata
Signed-off-by: David Scott <dave.scott@docker.com>
Use os.Mkdirall() instead of os.Mkdir() as it does not
error if the path already exists.
This enables specifying a default config file with the image
and then over writing it with metadata.
While at it, also update to the latest alpine base image.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Vultr uses a very similar approach to AWS, including using the
same IP address for serving metadata. In fact, it seems
as though if AWS appears first in the list of providers, that
provider mistakenly believes to be running on AWS (hence the
insertion of `NewVultr` in between GCP and AWS. I don't believe
AWS servers will accidentally try to use the Vultr provider,
as it seems that the `/v1/` endpoint doesn't exist on AWS.
Signed-off-by: Luke Hodkinson <furious.luke@gmail.com>
If a file is a simple string (as opposed to a map) then write it with the
default perms. This makes for slightly terser metadata when creating a simple
datafile.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
`ok` was not assigned when type casting to `map[string]interface{}` so the
subsequent check was testing a stale value.
Also, the error message upon failure had the wrong sense.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Implementing a String() interface for each provider makes it
easier for users to prefix log strings with the provider.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This package handles meta and user data for different cloud
and other platforms. It should be easy to extend to new
platforms.
Currently, it handles GCP metadata and a simple CDROM userdata
provider.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
