[13:50] <smoser> dking: user-data is not necessarily cloud-config. you need to prefix it with '#cloud-config' or cloud-init will ignore it (as if it were for something else)
[14:37] <dking> smoser: Thank you for getting back to me. Yes, I realized the issue yesterday. It seemed counter-intuitive to me as placing that line at the start of the file would invalidate it as JSON, but it seems that it still works like that for cloud-init. I was able to get the user_data section to work after that.
[14:39] <dking> However, I did notice an issue at https://cloudinit.readthedocs.io/en/latest/topics/examples.html Is that the official documentation? I can't seem to find a more definitive source.
[14:52] <Odd_Bloke> dking: That is the official documentation, yep!
[15:09] <dking> Odd_Bloke: Is there a place where they accept suggestions or edits? It's minor, but when discussing writing files, it gives a "hello" program which should be "gz+b64", but gives the type as "gzip".
[15:50] <smoser> dking: the 'hello' is actually correct type 'gzip'
[15:50] <smoser> yaml is really stupidly complex.
[15:51] <smoser> the '!!binary' means yaml is handling the fact that it is base64, so cloud-init would not ever even see it as base64. it gets the binary blob.
[15:51] <smoser> ie, if you 'yaml.load()' that, you'll get binary content in it.
[16:12] <dking> smoser: Oh, okay. I didn't catch that fact as I was actually using JSON, so I didn't realize that it was base64 decoding. Thank you for pointing that out.
[16:16] <smoser> dking: there is another way other than '#cloud-config' to state that the part is cloud-config.
[16:16] <smoser> but it requires mime or "cloud-config-archive". ... something to indicate the type.
[16:17] <smoser> cloud-init will not just assume data is for it, meaning you can pass data to other programs and cloud-init wont get in the way.
[16:19] <dking> I'm not entirely sure why that is valuable for only user_data, as opposed to meta_data or network_data, but as long as I know how it works, I should be fine.
[16:25] <smoser> the user doesn't provide user-data or network_data. (generically)
[16:25] <smoser> that comes from the platform
[16:25] <smoser> ie, you dno't get to modify the values or format of the  aws metadata service
[16:25] <smoser> but you do provide user-data.
[16:26] <smoser> er... above edit.  the user doesn't provide *meta*-data or network_data
[16:38] <dking> That's an interesting distinction. I suppose that makes some sense. Thank you for the information.


[09:22] <cheche> what is the "ubuntu way" to have a firefox 3.6 and ubuntu 10.04 ?
[09:57] <dupondje> why would you need prehistoric firefox ? :)
[10:51] <chrisccoulson> cheche, there isn't a way
[10:51] <chrisccoulson> and it's EOL next week too
[10:52] <cheche> dupondje: some app does not work with a new browser
[10:52] <cheche> chrisccoulson: It should be a way
[10:52] <chrisccoulson> why would we provide a way to install a browser that is no longer actively maintained?
[10:53] <cheche> chrisccoulson: because is up to the admin to choose whatever feels is needed for his own security
[10:53] <chrisccoulson> well, you didn't have to install the updates
[10:54] <chrisccoulson> but in any case, we're not going to provide any supported way to install unmaintained software
[10:54] <cheche> chrisccoulson: is just a problem with a webapp, and we need time until that problem is fixed.
[10:54] <cheche> chrisccoulson: when the systems were update we found out the problem
[10:55] <cheche> and I wnated to find a way to revert and stay with 3.6 instead