Skip to content

CFE-3427/master: Changed references from bundle server access_rules to my_access_rules#2369

Merged
nickanderson merged 1 commit intocfengine:masterfrom
nickanderson:CFE-3427/master
Oct 5, 2020
Merged

CFE-3427/master: Changed references from bundle server access_rules to my_access_rules#2369
nickanderson merged 1 commit intocfengine:masterfrom
nickanderson:CFE-3427/master

Conversation

@nickanderson
Copy link
Copy Markdown
Member

@nickanderson nickanderson commented Sep 24, 2020

This change is intended to help clarify the fact that users can (and should)
define their own server bundles instead of modifying the vendored policy and
that bundle server access_rules is not a special name.

Merge with: cfengine/masterfiles#1839

@nickanderson
Copy link
Copy Markdown
Member Author

Ping @basvandervlies to clarify that bundle server access_rules isn't anything unique and special.

#########################################################
# Server config
#########################################################
#########################################################
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the only section that made me pause. Which "full configuration" file would this be in? If you were modifying controls/cf_execd.cf then you probably wouldn't change to my_access_rules bundle name. If you were creating a replacement you would need to change promises.cf inputs[cf_execd].

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I have tweaked it very slightly. This part of the documentation is about the configuration for collect_calls access. This "full configuration" snippet shows all of the various settings related to enabling client-initiated reporting. It's not specific to MPF. If you have any suggestions to clarify further please let me know. It's challenging to straddle the difference between documentation about core, and then conventions from MPF which won't necessarily apply if you run a completely custom policy set.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool. I think for me I would like to see the text before the example say: change controls/cf_serverd.cf as follows (and then the two examples), or if my_access_rules() is really just augmenting what is in cf_server.cf, which it is, then you might break that section apart and prefix it with some text like: include this bundle server my_access_rules() in a separate file and include in inputs with augments (def.json).

Something like that make any sense to you?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, the access rules are already present by default, and we have augments about them.

Again, this documetation about the control body is about the core component with has nothing really to do with MPF. I could however add some See Also references to the MPF augments for these settings.

@basvandervlies
Copy link
Copy Markdown
Contributor

Thanks @nickanderson for me it is now clear how to use it. I will try it in out configuration

Copy link
Copy Markdown
Member

@olehermanse olehermanse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, please squash commits.

This change is intended to help clarify the fact that users can (and should)
define their own server bundles instead of modifying the vendored policy and
that bundle server access_rules is not a special name.

Ticket: CFE-3427
Changelog: Title
@nickanderson nickanderson merged commit 6e7bbf5 into cfengine:master Oct 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

4 participants