=== 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