Rudder

I think you're trying to fix this in the wrong place. ncf has a configuration option for the port number. The whole point of a configuration option is that you don't need to modify the code.

It looks like you need a different ncf.conf file for Windows hosts. That would make sense. Can you see that working?

Because ncf.conf is read directly by ncf, in 10_ncf_internals/configuration.cf, not by Rudder

Right, but it's read on each node. And each node copies the files that Rudder's configs tell it to. Why can't you copy a different ncf.conf for Enteprise nodes, or maybe edit the ncf.conf on those nodes, or something like that?

I'm sorry if I seem to be causing you trouble here, but this really is an engineering problem: we have many moving parts, and need to figure out which one to change to fix this issue. I can tell from a simple rule of thumb that your original proposed change is not the right moving part because this simple rule dictates that no exceptions should be made in ncf's code on account of Rudder. However, maybe your solution lies in adding a different configuration option to ncf, that Rudder could take advantage of. Or maybe Rudder can just use the existing configuration option.

Whatever the solution, you're the one that knows the constraints here, and until you share them, I can't help more than giving you the occasional pointer. Currently, I don't know why you don't think using 2 different config files is an option. Until I do, I don't know what else to suggest.

You have nodes withs both Enterprise and Community, like the Rudder server root, and Server Relay. On ncf.conf file would not be enough for these nodes

Editing ncf.conf to have specifics means that you'll always have promises repaired for ncf copy, unless you:
- copy all directories, but 10, with purge
- in 10, copy all files, but ncf.conf, without purge
- finally copy ncf.conf based on some parameters
It is clunky, and fragile.
You cannot exclude a specific file from copy with purge, otherwise it is removed from the destination (as it is not in the source list, it must be removed from the destination list), so always removed

Ok, I don't even understand how this can work in Rudder... bundle configuration is never called, but thanks to some magic it is evaluated, read the file and fill the variable.
But we are relying on side effect here, which is clearly not future-proof

Applied in changeset policy-templates:commit:9da2f26c7305b089031e035441c411033d2f7dff.