| Age | Commit message (Collapse) | Author |
|---|
|
this just adds a cloud-init_all.deb symlink to the
deb that is created so its easier to scp it elsewhere after
you build it.
|
|
This just removes one place where i had the version string
and additionally makes bddeb built debs have a revno in their
version
|
|
Notes:
* This also makes cc_ssh.py *not* write ssh keys to the console.
That means that if keys-to-console is configured off, nothing will
write the keys to the console.
* I removed Garret's use of xargs, replacing with a shell for loop
in write-ssh-key-fingerprints.
taken from
git://pkgs.fedoraproject.org/cloud-init.git
commit 87f33190f43d2b26cced4597e7298835024466c2
Author: Garrett Holmstrom <gholms@fedoraproject.org>
Patch8: cloud-init-0.6.2-sshkeytypes.patch
|
|
instead of cloud-init_0.6.2.orig.tar.gz, create cloud-init-0.6.2.tar.gz
|
|
LP: #871297
|
|
|
|
|
|
This will allow this code to be called more easily elsewhere.
I'm considering having the "all the way up" message contain fingerprints
so that they're more or less guaranteed to get to the console where
the user could see them.
|
|
|
|
All other marker files by cloud-init live in /var/lib/cloud/sem
it makes sense for uncloud-init's file to live there too.
|
|
The new classes 'DataSourceNoCloud' and 'DataSourceNoCloudNet'
implement a way to get data from the filesystem, or (very minimal)
data from the kernel command line. This allows the user to seed data to
these sources.
There are now 2 "cloud-init" jobs, cloud-init-local that runs on
mounted MOUNTPOINT=/
and 'cloud-init' that runs on
start on (mounted MOUNTPOINT=/ and net-device-up IFACE=eth0 and
stopped cloud-init-local )
The idea is that cloud-init-local can actually function without network.
The last thing in this commit is "uncloud-init".
This tool can be invoked as 'init=/usr/lib/cloud-init/uncloud-init'
It will "uncloudify" things in the image, generally making it easier
to use for a simpler environment, and then it will exec /sbin/init.
|
|
|
|
if user data is of type text/cloud-boothook, or begins with
#cloud-boothook, then assume it to be code to be executed.
Boothooks are a very simple format. Basically, its a one line header
('#cloud-config\n') and then executable payload.
The executable payload is written to a file, then that file is executed
at the time it is read. The file is left in
/var/lib/cloud/data/boothooks
There is no "first-time-only" protection. If running only once is
desired, the boothook must handle that itself.
|
|
|
|
|
|
if the BUILD_FILE file had more than 4 fields in it, 'serial' would get
all additional fields and would then look wrong in the message.
protect from that case by adding a var to 'read'.
|
|
|
|
|
|
|
|
If a part of a multipart file is 'text/part-handler' then it is
expected to be python code that implements 2 methods
- list_types()
list the types that this part-handler supports, return
a list. ie: return(['text/plain'])
- handle_parts(data,ctype,filename,payload)
this method will be called:
once, when loaded, with ctype == '__begin__'
once per part
once, at the end, with ctype == '__end__'
- ctype is the content type ('text/plain')
- filename is the filename portion of the mime data
- payload is the content of the part
- data is currently the cloud object, but this could change
|
|
|
|
|
|
|
|
write-mime-multipart text/x-shellscript path/filename.sh \
text/x-cloud-config my.yaml \
> my.userdata
|
