=== jj623_ is now known as jj623
=== cpaelzer__ is now known as cpaelzer
[09:01] <otubo> smoser, Hey, do you know if this was merged at some point? https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+ref/fix/1788915-vlan-sysconfig-rendering
[09:01] <otubo> smoser, looks like we have an issue on RHEL that could benefit from this fix.
[09:03] <otubo> smoser, I mean, I can't find the exact commit entry on the log, but perhaps it was merged as a different title on github, I don't know
[10:00] <Zador> Hello creme de la creme ! :)
[10:08] <Zador> Can we use passowrd hash to implement Linux instance AD domain join ?
[12:01] <otubo> Odd_Bloke, quick ping for PR 428 to make sure it does not get closed to inactivity :-) thanks for the reviews!
[12:41] <Zador> hello everyone !
[13:03] <Zador> any Guru in the channel ?
[13:05] <Zador> I want to know if it's possible to use password hash to implement Linux AD integration
[13:05] <Zador> ?
[13:08] <ananke> not sure how that's related to cloud-init
[13:09] <Zador> we need to join the AD domain using admin credentials
[13:10] <Zador> and I was wondering if it's possible to use password hash to automate and secure the domain join
[13:11] <Zador> or if you have any suggestion/doc or use case of cloud-init and AD integration
[13:11] <Zador> thank you ananke !
[13:16] <ananke> you may want to check in ##linux, or a distro specific channel, there may be tools already present in your distro of choice.
[13:18] <Zador> alright thanks
[13:28] <Odd_Bloke> otubo: Thanks for the ping!  I've removed the tag, so it should have another 14 days of grace (and I would hope I'd get to it before then!).
[13:37] <Odd_Bloke> Zador: ananke is correct: cloud-init doesn't have any specific Active Directory integration.  You'll want to look into how to configure this using your distro's available tooling.  Once you have some scripting that works for it, then you could look into having cloud-init run that by passing it as user-data.
[14:09] <otubo> Odd_Bloke, thanks :)
[15:22] <amansi26> blackboxsw_: We have some modules specific to a particular platform, what should be procedure to contribute a new module in the cloud-init ? Is there any restriction on doing so? I came across this document https://cloudinit.readthedocs.io/en/latest/topics/hacking.html . Wanted to confirm is there anything apart from that is needed to contribute?
[16:02] <meena> what *is* HiBee?
[17:19] <AnhVoMSFT> @Odd_Bloke @rharper Is is possible to disable network configuration of cloud-init from user-data (network: config: disabled)
[17:32] <AnhVoMSFT> I guess not, from cloud-init doc: "User-data cannot change an instance’s network configuration."
[17:35] <blackboxsw_> AnhVoMSFT: sorry right, it is either from /etc/cloud/cloud.cfg.d/* file that contains "network:\n config: disabled" or kernel commandline params provided like "network-config=disabled"
[17:36] <blackboxsw_> also note if providing kernel cmdline params that any network config can be provided directly via kernel cmdline "network-config=<any-base64-encoded-networkYAML>"
[17:36] <blackboxsw_> per commitish https://github.com/canonical/cloud-init/commit/1d2dfc5d879dc905f440697c2b805c9485dda821
[17:38] <blackboxsw_> user-data (cloud-config) is processed too late to disable network config I believe (so even emitting a write_files: - /etc/cloud/cloud.cfg.d/disable-net.cfg with the right content I *think* will still not disable networking until after a cloud-init clean --reboot
[19:12] <tt_> Hello, is it possible to have cloud-init run a script on first boot of a machine on aws without needing to pass it in via user-data? I would ideally like to make an ami with the script already there in the proper place.
[19:18] <tt_> Is it as simple as dropping the script into scripts/per-instance? https://cloudinit.readthedocs.io/en/latest/topics/modules.html#scripts-per-instance
[19:20] <blackboxsw_> tt_: if you want first-boot only, you would drop them in https://cloudinit.readthedocs.io/en/latest/topics/modules.html#scripts-per-once
[19:22] <blackboxsw_> if you want them to run each time the platform tells you that this instance is "new" (maybe redeployed from a cloned AMI) then you would use scripts-per-instance
[19:22] <blackboxsw_> Odd_Bloke: I think I got you some good questions comment on the oracle branch https://github.com/canonical/cloud-init/pull/493#pullrequestreview-462784349
[19:22] <blackboxsw_> thanks for all the work there
[19:22] <tt_> @blac
[19:27] <tt_> blackboxsw_: Awesome, thank you. Would the user-data script example here(https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html#using-instance-data) work if I put it in scripts/per-instance or scripts/per-once?
[19:27] <Odd_Bloke> blackboxsw_: Ack, thanks, will take a look!
[19:46] <blackboxsw_> tt_: no prob. Hrm I'll have to check if scripts-per-* actually handles jinja templates for those scipts.
[19:46] <blackboxsw_> checking now . If not, then your script would likely be able to run `cloud-init query <somekey>` and react to the values in that output
[19:48] <cut> is cloud-init supposed to stay installed for the lifetime of the vm? or can i have it uninstall itself after firstboot when it sets everything up?
[19:49] <blackboxsw_> cut: if cloud-init is uninstalled, it can't re-run if the vm is rebooted and instance-data (the metadata provided by the cloud platform) changes across reboot. So your VMs would be missing out on any potntial configuration changes that are supposed to affect the system if provided by the platform.
[19:50] <blackboxsw_> so, it depends, some platforms don't to any configuratin across vm boots, others "may"
[19:50] <cut> thanks
[19:51] <blackboxsw_> cut, no prob. there are facilities as mentioned about by tt  that try to run some things across each instance boot, or each time the instance-id changes for that cloud. So, it all depends on what you want your final image to support and which cloud you are running on.
[19:51]  * blackboxsw_ gets some lunch
[19:57] <Odd_Bloke> cut: If you remove cloud-init and capture an image from such an instance, then it won't perform its usual first boot functions (which include SSH host key rotation, authorized_keys handling, network rendering, and handling of any user-data passed in): you'll have to handle that all yourself (assuming that the network config/authorized keys in the captured image will even allow you access to the new
[19:57] <Odd_Bloke> instance).
[19:59] <blackboxsw_> ahh right gd pt Odd_Bloke . much more critical than I implied
[20:09] <blackboxsw_> tt_: confirmed you cannot provide cloud-config as per-instance per-boot sripts, they are actually just executable scripts and are not rendered as user-data. . So if you wanted to rely on instance data variables as shown in (https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html#using-instance-data, you would probably want something like https://paste.ubuntu.com/p/tFDfWN3Wpp/
[20:09] <blackboxsw_> be back in a bit
[21:52] <Odd_Bloke> blackboxsw_: Thanks for the review, your point about metadata is a really good one.
[21:52] <Odd_Bloke> I'll address that tomorrow.
[21:59] <blackboxsw_> good deal Odd_Bloke