custom type/provider case insensitive title

Question

Is there anyway to normalize the title value through a munge call or something similiar?

I have a custom type/provider that manages local group membership on Windows machines (we needed more granularity over group membership, than just inside the user/group types.

group_member{"Group => Member":
   ensure=>present,
}

group_member{"Group => DOMAIN\Member":
   ensure=>present,
}

resources{'group_member':
   purge =>true,
}

In general, when everything is consistent everything works great. The issue comes in that windows/active directory are not case sensitive. Therefore, when self.instances gets called, It generates a resource Group_member["Users => DOMAIN\SomeGroup"], but in our puppet manifest, Users is hardcoded, DOMAIN comes from a fact, and SomeGroup comes from a hiera value.

We've been fighting with the case sensitivity of puppet for about 5 years on this, and most of our administrators have gotten used to ensuring case matches between domain and yaml configurations.

Now, we have a new problem... somehow DOMAIN is messing up. On a new testing domain, the NETBIOS name is lowercase. The fact we had returning DOMAIN still returns uppercase, but Windows ADSI is returning a lowercase form. This wouldn't be an issue if we wern't using resources{'group_member': purge=>true}, but now in this test environment the groups get added (through their respective .pp files) and removed (through resources{'group_member': purge=>true}}) every puppet run.

Ideally i'd like to just normalize everything to lowercase in self.instances and in all of our .pp files, but we have 400 puppet modules and we use group_member 120 times, managed by quite a few different teams. It would be significantly easier if I could just munge the title metaparameter.

Any suggestions?

I am unaware of any means to intercept or modify a resource title, but I think you can set up munging for your type's namevar. You would then want to confirm that the munging is in fact triggered when the namevar takes its value automatically from the resource title, as opposed to having it expressed explicitly. You would also want to confirm that this mechanism protects your resources against purging -- I suspect it will, if done right, but I have not actually done it before. — John Bollinger
@JohnBollinger I am using two parameters as part of the namevar, and although i've tried munging them, the title retains the original string value pre-title_pattern. — ruckc
You should indeed focus on the namevar code in your custom type. Munging is certainly supported in type code and I have seen examples. That will help greatly with the duct tape approach you are trying to apply here. However, there is some really suspicious stuff you have described here regarding the custom type and the custom fact code. Both of these comments require seeing the relevant code for further assistance instead of vague descriptions. If you have NDA concerns, sanitize it first. — Matt Schuchard
@ruckc, as I said, I don't think you can intercept or change resource titles. I perhaps assumed too much, however, when I failed to explicitly say that you should not need to do. Munging the namevar or its components will result in (sometimes) resources whose names differ from their titles, which is perfectly ok. — John Bollinger

ruckc ruckc · Accepted Answer · 2018-01-02T15:03:25

So, the way i'm handling this is to rename the existing type/provider and wrapping it in a define type that downcase's the title.

custom type/provider case insensitive title

1 Answers