20:00:00 <nitzmahone> #startmeeting Ansible Windows Working Group 20:00:00 <zodbot> Meeting started Tue Sep 15 20:00:00 2020 UTC. 20:00:00 <zodbot> This meeting is logged and archived in a public location. 20:00:00 <zodbot> The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:00 <zodbot> The meeting name has been set to 'ansible_windows_working_group' 20:00:05 <nitzmahone> #chair jborean93 20:00:05 <zodbot> Current chairs: jborean93 nitzmahone 20:00:05 <jhawkesworth> hey 20:00:12 <briantist> hey-o 20:00:14 <jborean93> nice 20:01:38 <nitzmahone> brb 20:01:46 <jborean93> no worries 20:01:55 <jborean93> I don't believe there's anything on the agenda 20:02:24 <jborean93> I've been toying around with a generic security descriptor module util changer but it's still quite early and low on my priority list to work on 20:03:12 <jhawkesworth> nice. 20:03:13 <briantist> what kind of modules would that be used for? 20:04:00 <jborean93> it's to provide a generic group/owner/dacl/sacl set of properties that can be defined for any module that wants to set them on an object 20:04:13 <jborean93> so something like `win_file` or `win_regedit` could potentially use them for files or registry keys 20:04:55 <briantist> ooo very nice 20:05:01 <nitzmahone> The hardest part on those is naming the attributes 20:05:03 <jborean93> I'm trying to make it easily extendable so if you want to add a new object type, like a service, all you need to do is provide a method that can give you a handle to that object and also a mapping of rights to human readable names 20:05:04 <jhawkesworth> that could definitely be handy. I was wrestling with some acl stuff the other day 20:05:13 * nitzmahone wrote one of those in the distant past for something else 20:05:24 <jborean93> it's also designed to be a lot more efficient than win_acl which can only set 1 ACE on the dacl at a time 20:05:46 <jborean93> this new route is meant to allow you to define an full set of explicit ACEs for 1 object in module invocation 20:05:49 * nitzmahone wonders if jborean93 has hit the ACL canonicalization problem yet 20:05:59 <jborean93> still early days so no :) 20:06:08 <briantist> 🍿 20:06:31 <jborean93> curious, what is that problem 20:07:17 <nitzmahone> It's just about de-duping/combining ACEs that overlap, and ordering. The API does some of it now (didn't used to), but I think there are still some cases where it's easy to make a mess if you're altering an existing ACL 20:08:03 <nitzmahone> I inherited some code that just blindly added an ACE to an ACL every time and it eventually fell over 20:08:24 <nitzmahone> If it's always absolute, not an issue, but when it's additive it can get "fun" 20:08:28 <jborean93> ah ok, basicallyI was planning on an action that either add/set/remove the set of ACEs to the ACL 20:09:07 <jborean93> but I can see where that might be messy if the internal API merged an ACE if it was close to an existing one 20:09:16 <jborean93> making the idempotency checks harder to do 20:09:19 <nitzmahone> yep 20:09:27 <briantist> Matt, this issue is why you sometimes see a message in the UI when looking at ACLs about them being out or order, right? 20:09:28 <nitzmahone> It's been a long time 20:09:37 <nitzmahone> briantist: I believe so, yes 20:09:47 <jborean93> will keep an eye out of it 20:10:06 <jborean93> the next problem is figuring out how to deal with objects that don't actually provide a handle to get/set the SD from 20:10:09 <nitzmahone> Basically means something jacked it up and some optimized evaluation paths may not actually behave the way you think they should 20:10:30 <jborean93> there's a recent PR for cert keys that have it's own API to do all that instead of using the common one 20:10:35 <nitzmahone> lbeh 20:10:38 <nitzmahone> *bleh 20:10:57 <nitzmahone> I've fought with that one in former lives as well 20:12:00 <jborean93> but still early days, I've got a POC on dealing with the PInvoke side but still need to add the checks and idempotency to it 20:13:44 <nitzmahone> PS: especially if your setter is always an absolute ACL, I wouldn't worry about trying to deal with non-canonical ordered ACLs ;) 20:14:12 <jborean93> apart from that I've got nothing Windows related to share. Will probably do another round of collection releases but they don't have any major changes 20:14:20 <nitzmahone> (eg in the idempotence check- non-canonical == non-matching) 20:14:50 <briantist> is the release cadence for the Windows collections set/decided at this point? 20:15:03 <nitzmahone> "whenever jborean93 feels like it" ;) 20:15:09 <jborean93> it's meant to be around ~4 weeks per bugfix/feature release but currently it's that 20:15:29 <jborean93> we don't get enough traffic to guarantee that there's going to be anything in that 4 week timeframe 20:15:54 <briantist> cool 20:16:25 <jborean93> it could even be quicker depending on how much of an impact the current fixes ready to go are 20:16:26 <jhawkesworth> no eta on win_xml fixes. No train rides means my main time to work on it has kind of evaporated and stuff seems to fill the time I should have got back. 20:16:42 <jborean93> it's quite simple to create a release really which is one of the reasons we moved it all out 20:17:01 <nitzmahone> What, you don't want to be in close proximity with dozens of your fellow ~disease vectors~ humans? 20:17:32 <jhawkesworth> not much point since there's an empty office when I get there 20:18:04 <briantist> sweet, I've been working on other things for the past few months so I haven't done much on the Ansible dev side, but it sounds like it's going to be a much smoother experience in the future, and changes will be able to be published much faster 20:18:26 <jborean93> yea, once ansible 2.10 is actually out these changes will be even easier for people to adopt and consume 20:18:29 <nitzmahone> tis the hope and promise of collections :D 20:18:31 <jhawkesworth> most of the rest of the team I'm on now are 5 timezones away 20:18:39 <jborean93> welcome to my life :) 20:18:56 <nitzmahone> Heh, 5 TZs would be a win for you jborean93 20:19:14 <nitzmahone> I think I'm the closest at what, like 8? 20:19:18 <jborean93> I feel like we are within 5-7 though 20:19:20 <jhawkesworth> sort of in the middle here, some are +5 and some are -5 20:19:21 <jborean93> I'm UTC+10 20:19:30 <briantist> heh, yeah that has to be rough on you both. I worked from Japan for ~2 months with the rest of the team in NY, 14 hours behind me 20:19:36 <jborean93> you're what UTC-7 or something? 20:19:39 <nitzmahone> yeah 20:19:47 <nitzmahone> I don't even think about the extra day 20:20:40 <jborean93> yea it's really just become part of my life now 20:21:08 <nitzmahone> At least you're functional as an early morning person, or you'd never see > half the team ;) 20:21:10 <jhawkesworth> well nice to chat, but I'm brain-fried so I'm gonna let you all have $next_meal and catch you next time 20:21:12 <jborean93> nitzmahone is easy because he usually works later in the day and we get some overlap 20:21:29 <nitzmahone> See ya Jon- have a good one! 20:21:33 <jhawkesworth> cheers folks 20:21:37 <jborean93> cya, enjoy the meal 20:21:43 * jhawkesworth afk 20:21:49 <briantist> yeah being a night owl helped me too when I had the time difference 20:22:20 <nitzmahone> That's my default best working time, except not so compatible with having a family :( 20:23:54 <nitzmahone> welp, if nothing else pressing for the day, we'll close in 2... 20:24:21 <jborean93> enjoy 20:24:37 <briantist> I know that feeling, been a problem my whole life, school, jobs, etc. Glad my current place is pretty flexible 20:24:48 <briantist> yeah nothing pressing/relevant from me 20:25:11 <nitzmahone> Yeah, if I didn't have a family I'd totally do the polyphasic sleeping thing 20:25:23 <nitzmahone> 'til next week! 20:25:27 <nitzmahone> #endmeeting