Open Bug 1678999 Opened 4 months ago Updated 2 months ago

Use instead of a single policies.json a split-file approach for policies...

Categories

(Firefox :: Enterprise Policies, enhancement, P5)

78 Branch
enhancement

Tracking

()

People

(Reporter: gaio, Unassigned)

Details

Currently FF (and also TB, indeed) support policies via a single policy.json file; in this way if a configuration management system need different configuration for different (set of) host, it is forced to prepare a different 'policy.json' file for every (set of) host.

It is true that modern configuration management engine support direct in-file editing (take Ansible as an example), but this is a bit 'clumsy' and can lead to trouble (if the editing corrupt the json format, all the policy get discarded).
Also, 'split file' is a modern way of configuring things, see Debian distro that use extensively split file for their configuration.

Consider an example: i need to install FF in my organization; management sector need plugin A and B, production sector need plugin B and C. I need to setup three json file: the base one without plugin, the 'AB' one and the 'BC' one.

A better approach would be to have FF to load policy as 'split file', eg load all the json file in a particular folder: in this way i can check json syntax correctness before uploading the file, and FF policy parser can reject a single json file, not all the policy.
Even direct in-file editing will be safer, if needed, because i can modify a single file and not all the policy.

Staying in my example, in this way i setup the base policy 'policy.json' and the plugin policies 'A.json', 'B.json' and 'C.json'.
With this setup i need only to copy 'policy.json' to all computer, and copy the plugin policies file where needed.

I hope i was clear.

How would we choose which JSON would "win" if there were conflicts?

As for old preferences (AutoConfig) simply (forward) lexicographic order or reverse lexicographic order, eg first policy definition win or last policy definition win.

Distributions and package mantainers typically suggest to 'force' lexicographic order by using prefixes, eg:
000-some-less-important-policy.json
050-mild-important-policy-1.json
050-mild-important-policy-2.json
999-this-have-to-be-the-last.json

(clearly supposing that last wins), or using aaaa...zzzz as prefixes.

Ops forgot... to prevent accidental drop of invalid file in the policy folder, tipically parser does not read 'all file in folder' but 'all file json in folder', eg *.json, so you can put also here README, backup files, ... all stuff you need for your use, it suffices NOT have json extension.

I'll confirm this, but it would be a way future thing.

Severity: -- → N/A
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.