Contents

Profiles

A folder of plain files carrying a whole configuration: what it holds, what it may set, how it is validated and applied as a whole, and how a deployment is compared with it.

A profile is a folder of plain files holding a whole configuration: the settings, the sources, and the rules that decide who may read them. It is how a second office is set up like the first, and how a rebuilt server comes back the way it was, without anyone remembering which settings were changed.

shell01
prem profile validate <folder>    check it against this deployment, change nothing
prem profile apply <folder>       apply it, or refuse the whole profile
prem profile show [<folder>]      what is applied, and how this deployment differs

The folder holds profile.json (a name, a version, and the seam versions it expects) and, as it needs them, settings.json, sources.json and golden-set.json. A file a profile does not know is refused rather than ignored: a profile that quietly skips a file is a profile that quietly does not configure something.

A profile can set what an administrator can set, and nothing further. There is no file in it that creates a user, grants a role, or writes a rule naming somebody who does not exist. It follows that every group a profile names has to exist first, and that is not only the groups in its rules: the starter profile's rule names hr, and its golden set asks a question as somebody in engineering to prove that person is told nothing.

shell02
prem groups add hr
prem groups add engineering
prem profile apply ./samples/profiles/starter

prem profile validate names every group it cannot resolve, so the list of groups to create is the output of a validate run rather than something to work out by reading the files.

validate reports every problem it finds rather than the first, and changes nothing. apply validates the whole profile before it writes anything, so a profile with one bad item changes nothing at all. The apply itself is not one transaction, because the settings, sources and rules each carry their own; what holds is that nothing is applied unless everything validated, and a failure part way through names exactly what was applied and what was not.

A source's folder may be written relative to the profile, so a profile can ship the documents it configures. A source's folder and prefix cannot be changed by applying a profile, since that would mean removing the source and indexing a whole corpus again.

golden-set.json is copied to a folder the server can read (--golden-set-dir, by default the shared application data folder) and the golden set path is set to the copy. The default is shared rather than per-account on purpose: the file is read by the account the service runs as, which is usually not the account applying the profile.