[14:09] <krono> hi there. I have a system init'ed with cloud init and due to the config it contains sensitive data in /var/lib/cloud/instance/*data.txt 
[14:10] <krono> Do I understand that right that simply deleting these files is _not_ safe?
[14:40] <falcojr> krono: what files are you wanting to delete?
[14:40] <krono> falcojr: user-data.txt
[14:44] <falcojr> yeah, that's not really something that's supposed to be deleted. Off the top of my head, I'm not sure it would hurt anything, but it would probably re-appear next boot anyway
[14:45] <falcojr> permissions are root only though, and (depending on the cloud) that data is going to be accessible from the cloud metadata service too
[14:49] <krono> well, I'm provisioning with MAAS and I somehow need to convey the existence of a root user and their password -.-
[14:52] <krono> (also, I've seen on my ovirt setup that changing network stuff via the "cloud-init" option there has no effect whatsoever after subsequent boots)
[14:54] <krono> anyway, thanks for the info, falcojr . I'll just try it out and see what happend :D
[15:10] <minimal> krono: I think the general idea would be for user-data to set a random password for root - which then appears on the console during boot - rather than to put an actual password in user-data. When you talk about a root password in user-data do you mean the actual password or the "encrypted" form of it?
[15:11] <krono> minimal: I have just observed that the password I put in the cloud-init section of ovirt ended up unencrypted in the user-data.txt on the resulting virtual machine.
[15:12] <krono> I now want to provision hardware machines and have to enable and password-ize that ubuntu (for "enterprise" reasons)
[15:12] <krono> In the end, If I'm doing things right,I could put a "wrong" initial password there and then override it in postinstall or something
[15:15] <minimal> krono: are you setting the "plaintext" password in either the "chpasswd" section or within "users:" section? If within the "users:" section then you really should be using "hashed_passwd". Unfortunately the top-level "chpasswd:" setting only support plaintext passwords
[15:16] <krono> minimal: thanks for the info, I'll keep that in mind, makes sense to use hashed password.
[15:17] <krono> minimal: this is what oVirt creates from its gui for cloud-init:
[15:17] <krono> https://www.irccloud.com/pastebin/1Pcoyk1G/user-data.txt
[15:17] <minimal> krono: as falcojr pointed out, depending on how MAAS provided the user-data, there's a risk that the source of user-data (i.e. metadata server) would be accessible by users on the machine
[15:18] <krono> aah that makes sense... I'll see whether there's an impact in my case
[15:20] <minimal> have a quick look at MAAS datasource and it does use a URL to retrieve the user-data (though with Oauth in place) - I guess the presence of Oauth gives a degree of security to protect the user-data
[15:22] <minimal> krono: as you're setting the default user to root then you could put something like this in user-data:
[15:23] <minimal> users: \n   - default \n    hashed_passwd,: <value>
[15:23] <minimal> that's 3 sets of lines each indented from the previous one
[15:25] <krono> neat! thanks a bunch :D
[15:26] <minimal> if you choose a strong hash method (bcrypt? PBKDF2?) it will be harder to bruteforce if someone ever got hold of it
=== meetingology` is now known as meetingology
=== blackboxsw_ is now known as blackboxsw
=== jchittum_ is now known as jchittum
=== nicolasbock_ is now known as nicolasbock
=== c355E3B_ is now known as c355E3B