Add support for pulling LCM changes

[majst32]

I don't know if this is possible - or possible without changes to the protocol or LCM. But there was a discussion I was reading on twitter yesterday about wanting to be able to pull an LCM change - a meta-mof - from the pull server. Thought this was an interesting concept - and a feature I'd be very much interested in. But I'm not sure if it's technically feasible - or if others think it would be worthwhile.
Discuss!

[ebekker]

I think this is an interesting idea -- would it just be possible to create a DSC Resource that itself just does updates to the LCM config?

[ebekker]

So I'm curious -- in the twitter discussion, did they indicate what sort of use cases they were interested in? The utility of this type of support may be limited -- you would have to be careful with what settings you served up to reconfigure the LCM. For example, you shouldn't touch the RefreshMode or you would hose your connection beween the Node and Pull Server.

You could update ConfigRepoWeb settings, but you could hose yourself there too if you're not careful. I supposed you could adjust the timing settings and config names, but whatever config you choose, the server would need to "formulate" to include the LCM changes in addition to whatever config MOF was actually being requested.

[majst32]

I would be interested in it for the Certificate ID.

[ebekker]

Ah, to deploy a client-side certificate, when a node first registers with the Pull Server, for example, for all subsequent communication? Yeah, that's an interesting scenario.

[stefanstranger]

I started this discussion on twitter:-) I'm interested in updating/changing named configuration setting in LCM Config.

[ebekker]

@stefanstranger, do you typically use multiple/partial configs?

[majst32]

Well so first, it would have to be a meta-mof, so we would need a way of distinguishing a request for the config mof from a request for the meta-mof. This is where I am concerned - as the LCM doesn't currently request this. So it would be some sort of new-ish request that is distinguishable from a "register" or "get-config" or "get-module" action. Which would then need to do a register and send the meta-mof and the LCM would need some way to apply it. (Not necessarily in that order.)

[thedevopsmachine]

You'd need to do this in a Scheduled Task/PowerShell script. Writing a controller in the application to return a string containing your LCM data would be pretty trivial, but since the client isn't requesting the data from the server, you need to write a client to do it. In addition, the client has to be aware of the LCM's status, because meta configs can only be applied when the LCM is in the "Idle" state.

Also keep in mind that controlling the LCM meta means you control the source of the configurations and what configurations are applied (since you can specify ConfigurationId in backwards compatible mode), so it opens up a new attack vector. Just something to keep in mind for the threat model.

[ebekker]

I threw together a very rough proof-of-concept to show that it's possible to do this and without really any special support from the Pull Server, i.e. I tested this just using the built-in LCM and the Classic xDscPullService.

Note, I had to alter the extension on each file and append a .txt because GitHub would not let me attach them otherwise (presumably a security precaution).

Assuming these two LCM config scripts are on the Node:

• LCMConfig.dsc.ps1.txt
• LCMConfig_dynamic.dsc.ps1.txt

And these Configs are on the Pull Server:

• DynamicLCM_1.dsc.ps1.txt
• DynamicLCM_2.dsc.ps1.txt

[ebekker]

So as I mentioned, this is rough, but to test the idea, I used the Script resource to implement most of the logic that you would actually put into a custom DSC Resource.

• I start by defining the LCM meta-config to pull a config named DynamicLCM_1
• DynamicLCM_1 defines two resources
  • a temporary folder
  • a script that checks to see if the current LCM is configured with DynamicLCM_2 -- if not:
    • it updates the LCM meta-config to use this config; it does this with the help of a second LCM meta-config that is already defined on the local Node in a pre-defined path -- this is just to make things simple in this PoC -- normally, all the logic of defining/updating the LCM meta-config would be encapsulated in a custom DSC Resource
    • it immediately applies the DynamicLCM_2 config
• DynamicLCM_2 defines only one resource, a file that is placed into the temp folder created by the predecessor config

I've run through this setup a few times just to be sure, but it seemed to work every time without any issue. NOTE, the files I uploaded are a bit sanitized from the ones I actually used so I didn't actually use these copies, but hopefully there are no errors that were introduced in my sanitation process.

[ebekker]

@thedevopsmachine -- to address your security concern, I agree about your comment regarding the control of LCM, but it goes further than that -- if you control the Pull Server, you control the LCM and you control the Node. Remember, the Pull Server tells you what config you should apply, and that includes what DSC Resources you need to include, and the Pull Server gives you those Resource Modules.

So it is indeed an attack vector -- but I think it's easily an existing one, not a new one

Also, to address your comment regarding the Scheduled Task and conflict with Idle status -- also true -- but the current LCM state is easily queryable and you can time it so that any LCM config changes are not coinciding with the LCM applying a change or with "tolerance" preceding the next scheduled consistency check

[HaloX69]

Without configuration ID support we have no means of implementing partial configurations. Partial configurations are critical because we have different groups authoring configurations based on skills (i.e. security, SQL, SharePoint). For this to be a replacement for the standard pull server platform this needs to support configuration ID's or some other comparable means of implementing this capability.

[Zuldan]

Configuration ID support would be a great addition. We only use partial configurations.

[HaloX69]

Partial configurations means a single server can only host a single config mof per server. In our configuration for SharePoint we have different engineers responsible for different configurations and partials (i.e. Search, request manager). Otherwise they would need to edit the same file and that adds complexity, risk, and with TFS they each edit their own files they have permission to. Is there any hope for configuration if support in the near future? Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Zuldan <[email protected]> Sent: Saturday, September 30, 2017 9:43:50 PM To: PowerShellOrg/tug Cc: HaloX69; Comment Subject: Re: [PowerShellOrg/tug] Add support for pulling LCM changes (#56) Configuration ID support would be a great addition. We only use partial configurations. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#56 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AIEgkEgfPn-Aquew_hz2U-IGvqBv7wZfks5snu5WgaJpZM4Ltomw>.

[PlagueHO]

👍 from me. Our teams like to use partial configurations to enable assembling MOFs for machines at deploy time. It is a bit harder to do this with composite configs. An example of this is that we like to be able to configure alternate Nuget and Chocolatey package sources for some machines. Being able to allow an Infrastructure admin to just include the "Nuget Package Source" partial config in is much easier and eliminates the need for monolithic composite resources.

[HaloX69]

We use partial configs from multiple sources, configuration id's, and composites to prevent single monolithic mofs. With partial config and configuration ids we can have multiple mofs published to a single endpoint. Again a example SharePoint configurations are relegated to assigned engineers, but since the endpoint is just for SharePoint engineering we need to publish multiple mofs for any given server or machine role. From my understanding Configuration names don't work like this. Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Daniel Scott-Raynsford <[email protected]> Sent: Saturday, September 30, 2017 10:06:03 PM To: PowerShellOrg/tug Cc: HaloX69; Comment Subject: Re: [PowerShellOrg/tug] Add support for pulling LCM changes (#56) 👍 from me. Our teams like to use partial configurations to enable assembling MOFs for machines at deploy time. It is a bit harder to do this with composite configs. An example of this is that we like to be able to configure alternate Nuget and Chocolatey package sources for some machines. Being able to allow an Infrastructure admin to just include the "Nuget Package Source" partial config in is much easier and eliminates the need for monolithic composite resources. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#56 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AIEgkNOeEL-p44aD6Qh6w9uZL5HHfR4Uks5snvOLgaJpZM4Ltomw>.

[ebekker]

@HaloX69 @Zuldan @PlagueHO -- so I wasn't particularly opposed to Partial Configs (although there seems to be some concern with using them), however, I'm not sure how Configuration IDs are related here.

My understanding is Partial Configs were introduced in PS 5.0 and that means they rely on Configuration Names, not IDs.

Am I missing something? I'm not familiar with Partial Configs so clue me in, please.

[bbollard]

I was able to configure my Windows 10 test box with partial configurations using Tug as the back end and my POC NoSQL provider. I did not see any issues specific to partial configurations.

[ebekker]

Sweet, thanks for the info. What NoSQL provider concept have you proven, if you don't mind sharing?